HTML5, Roles ARIA, y lectores de pantalla en mayo de 2010

Window-Eyes 7.11, por otro lado, y esto es una cosa que ya sabíamos, no reconoce los papeles de la ARIA en absoluto. Además, Window-Eyes parece que no resisten en IE8 cuando se trata de HTML5 y ARIA papeles que se utiliza en conjunto: en el “modo de exploración” que no puede encontrar los enlaces dentro de un elemento de seccionamiento HTML 5, que también tiene un papel ARIA. Si activa “modo de exploración” off, que hace una lista de los enlaces, pero esto significa que tendría que cambiar continuamente “modo de exploración” de vez en cuando para leer y utilizar la página en realidad.

Algunas pruebas rápidas adicional me mostró que en IE8, Window-Eyes tiene ningún problema para encontrar enlaces dentro de un simple div, que también han de un papel ARIA, o dentro de un elemento de seccionamiento HTML5 sin un rol ARIA, pero combinar los dos y Window-Eyes en IE8 simplemente se pierde. Esto se confirma, por ejemplo, el sitio de Bruce Lawson, lo que hace un buen uso de HTML5 y ARIA. Si visita el sitio de Bruce con Window-Eyes y IE8, ninguno de los eslabones de la headero el #sidebar navse encuentran, ya que ambos de estos elementos HTML5 a tener posiciones de ARIA implementadas. Pero no hay ningún problema con los enlaces en el área de contenido principal, a pesar de que tiene role="main"ya que sólo utiliza un habitual div. Si se utiliza unasection elemento en su lugar, la mayoría de los enlaces en la página desaparecería para Window-Eyes en IE8.

Si bien no tengo los números para demostrarlo, me imagino que la mayoría de los usuarios de Window-Eyes ejecutar Internet Explorer en lugar de Firefox, así que esto puede ser una razón para evitar el uso de funciones de HTML5 y ARIA juntos por el momento, en función de cómo se siente acerca de que atienden a los usuarios de Window-Eyes con IE8. Será interesante ver cómo cambian las cosas una vez IE9 y Window-Eyes 8 están fuera.

Los resultados más detallados de las pruebas son a continuación. A menos que se indique lo contrario, el lector de pantalla realiza como cabría esperar y esperar para una experiencia utilizable.

Actualización #1 (30 de junio de 2010): Parece que incluso anidar un elemento con un roleatributo dentro de un elemento de seccionamiento HTML5 padres de manera similar causa problemas para Window-Eyes. Por ejemplo, los enlaces dentro de un ulcon role="navigation"anidado dentro de un padre navelemento no se encontrará por Window-Eyes.

Actualización #2 (5 de julio de 2010): Por otra parte, y de manera interesante, anidando un elemento HTML5 dentro de una divcon un aria roleno parece desencadenar el problema de Window-Eyes. Por ejemplo, los enlaces en un navelemento que está anidado dentro de undivconrole="navigation"todavía se encuentran por Window-Eyes. Así que esto es, por ahora, probablemente la mejor manera de utilizar los elementos de HTML5 y ARIA papeles emblemáticos juntos sin impactar negativamente en los usuarios de Window-Eyes.

Actualización # 3 (7 de julio de 2010): Con la última actualización de Window-Eyes 7.2, los enlaces dentro de los elementos HTML5 que tienen un punto de referencia ARIA rolese encuentran ahora y utilizable. Por desgracia, anidando al menos algunas semánticas HTML 4 elementos con un roleatributo dentro de un elemento de seccionamiento HTML5 padre todavía causa problemas para Window-Eyes 7.2. Es decir, los enlaces dentro de una ulcon role="navigation"anidado dentro de un padre navelemento, por ejemplo, se continúa sin encontrar y accionable mediante esta última versión de Window-Eyes.

Actualización # 4 (21 de julio de 2010): creo que las he arreglado para hacer las cosas un poco confuso en este punto, así que vamos a recapitular: En Internet Explorer 8, versiones Window-Eyes 7.2 y siguientes, cuando se encuentra en modo de exploración normal, tienen algunos problemas para encontrar y utilizando enlaces en el contenido donde ARIA roles se utilizan en conjunción con HTML5 elementos en ciertas modalidades de seccionamiento. El uso de enlaces en un elemento HTML5 con un ariaroleatributo es un problema con Window-Eyes 7,11 y por debajo. Esto no es un problema con Window-Eyes 7.2, pero con la versión 7.2 no hace seguir siendo un problema con al menos desordenada y ordenados listas, y posiblemente algunos otros elementos, así, que tienen una ARIA roleaplica. Ni Window-Eyes 7.11 ni 7.2 puede utilizar los enlaces en un ulelemento con role="navigation", si es o no está anidada dentro de unanavelemento. Lo mismo ocurre, por ejemplo, para los enlaces dentro de un olelemento con role="contentinfo". (Este error Window-Eyes también se manifiesta en cierto grado con Firefox 3.6). Sin embargo, anidando el elemento HTML5 dentro de un genérico divcon un aria role, o viceversa, anidando un divAria roledentro de un elemento HTML 5, no parece causar un problema en Window-Eyes. Así, por ejemplo, se podría envolver su navelemento con <div role="navigation">o, alternativamente, envolver los contenidos internos de la naven una divcon el ARIA role. Ejemplos de estos diferentes arreglos se pueden encontrar en esta página especial de prueba para Window-Eyes .

Caso de Prueba Sólo HTML5

JAWS 11

IE8

• no hay problemas o cuestiones obvias

FF3.6

• no le gusta navdentro del headerelemento: al cargar la página, JAWS salta algún lugar por debajo de la headery empieza a leer, a menudo el h1o la “Sección Primera” vínculo interno; y los navenlaces dentro de la headerno aparecen en la lista de enlaces JAWS’
• puede presionar TABpara llegar a cada enlace, pero, en modo VirtualPC cursor, los enlaces dentro de la header, al ser seleccionado por el teclado, registrar y actuar como cualquier enlace fuera del headerfoco tenido previamente (por ejemplo, a menudo la “Primera Sección” vínculo interno dentro de la “ principal” section)
• con el modo de VirtualPC cursor más allá, los enlaces en el headertrabajo fino a través del teclado
• los eslabones de la headerparecen funcionar bien cuando se selecciona con el ratón, si el modo de VirtualPC cursor está encendido o apagado
• enlaces fuera de la headerestán reconocidos y funcionan correctamente

Window-Eyes 7.11

IE8 y FF3.6

• no hay problemas o cuestiones obvias

SAToGo 3.0.202

IE8 y FF3.6

• no hay problemas o cuestiones obvias

Narración

4.0.3 Safari

• no hay problemas o cuestiones obvias

Roles HTML5 + ARIA caso de prueba

JAWS 11

IE8

• misma que la única versión HTML 5, excepto que,
• Puntos de referencia ARIA se encuentran y navegable
• También se considera role="article"un punto de referencia

FF3.6

• mismos problemas con el naven el headerque el HTML5 Sólo versión
• Puntos de referencia ARIA se encuentran y navegable, a excepción de la navigationreferencia ARIA anidado dentro de laheader
• También se considera role="article"un punto de referencia

Window-Eyes 7.11

IE8

• no hay puntos de referencia ARIA encontrados
• no se han encontrado enlaces porque tres secciones principales de la página utilizan elementos HTML5 junto con papeles ARIA
• el headercon role="banner", la sectioncon role="main", y la footercon role="contentinfo"son cada uno reconocido como controles (por ejemplo, se puede acceder pulsando C) y están en el TABorden

FF3.6

• no hay puntos de referencia ARIA encontrados
• todos los enlaces se encuentran, al contrario que en IE8
• el header, la section, con role="main", y footerno se reconocen como controles, ya que son en IE8

SAToGo 3.0.202

IE8

• Puntos de referencia ARIA se encuentran y navegable, pero sólo en una dirección (pulsando ;el próximo hito), y el tipo de papel hito no se anuncia

FF3.6

• Puntos de referencia ARIA se encuentran y navegables en ambas direcciones (pulsando ;y Shift+ ;), pero el tipo de papel hito no se anuncia

SAToGo 3.1.24 (21 de mayo de 2010)

IE8

• mientras que esta versión de SAToGo ahora permite la navegación por punto de referencia ARIA en ambas direcciones en Internet Explorer 8 (pulsando ;y Shift+ ;), que ya no encuentra el complementarypapel hito
• el tipo de papel hito permanece sin previo aviso

FF3.6

• SAToGo todavía encuentra todos los puntos de referencia, permite la navegación en ambas direcciones, y el tipo de papel hito permanece sin previo aviso

Narración

4.0.3 Safari

• no hay puntos de referencia ARIA encontrados