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

Los resultados

Brevemente, NVDA hace muy bien con el HTML5 y el HTML5 con papeles ARIA casos de prueba, si es en IE8 o FF3.6. La navegación, la lectura y la interacción con los marcadores y puntos de referencia ARIA HTML5 es sencillo. Tanto es así que no se justificaba su inclusión en los resultados de las pruebas: Basta con decir que NVDA rocas.

JAWS le va bien, a pesar de que no parece en FF3.6 a como un navelemento anidado dentro de una header. Por ahora, al menos, puede ser razonable para evitar la anidación de navelementos dentro de headerelementos. Actualización (27 de agosto de 2010): Ver el comentario # 3 por Terrill Thompson a continuación. Por desgracia, JAWS 11 en Firefox 3.6 no trata bien con el headerelemento en cualquier aplicación.

SAToGo también lo hace bien, y ahora incluso permite la navegación por punto de referencia ARIA, aunque no anuncia automáticamente el tipo de señal, ya que viene a través de ella. Y sólo pude conseguir que navegar por punto de referencia en una dirección en IE8, mientras que en FF3.6, podría desplazarse tanto a la siguiente y anterior hito presionando ;y Shift+ ;, respectivamente. Actualización: Los nuevos resultados para SAToGo versión 3.1.24, 21 de Mayo del 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.