jueves, 25 de febrero de 2010

Sobre el uso de lectores de pantalla

Última actualización: 7 de noviembre 2014

En este artículo voy recopilando estudios sobre el uso de lectores de pantalla y el soporte por parte de los mismos de determinados elementos o atributos.

Índice

  1. Empty Links and Screen Readers, 2008, Yahoo.
  2. Prueba de comportamiento de lectores de pantalla frente a abreviaturas y acrónimos, Sidar
  3. Survey of Preferences of Screen Readers Users, 2009 (enero), WebAIM
  4. Screen Reader User Survey Results, 2009 (noviembre), WebAIM
  5. Guidelines for Accessible and Usable Web Sites: Observing Users Who Work With Screen Readers1, 2003, United States National Cancer Institute
  6. What Frustrates Screen Reader Users on the Web: A Study of 100 Blind Users, 2007, Towson University
  7. Screen Readers lack emphasis, 2010, Paciello Group Blog
  8. Screen Reader User Survey 2011, 2011, WebAIM
  9. Encuesta sobre las barreras que encuentran los usuarios de lectores de pantalla, por coaccesibilidad.com (2011)
  10. Testing form control labelling support in popular browsers and screen readers, de html5accessibility.com, 2012 (diciembre)
  11. Soporte de ARIA Roles con diferentes lectores de pantalla (JAWS, NVDA, VoiceOver, Chrome, Windows Eyes de Paciello Group Blog, 2011 (noviembre)
  12. Soporte de diferentes etiquetas por lectores de pantalla en dispositivos móviles de Henny Swan (2011)
  13. Screen Reader User Survey #4 Results, WebAIM, 2012 (mayo)
  14. Screen Reader User Survey #5 Results, WebAIM, 2014 (enero)
  15. Text Links: Best Practices for Screen Readers, deque.com, 2014 (febrero)
  16. Test: Atributo lang en un elemento dentro de un enlace, Olga Carreras, 2014 (julio)
  17. Accessibility test. JAWS and NVDA test, maxdesign.com.au

Antes de empezar con los estudios, os dejo un recurso muy útil, un esquema de las teclas de NVDA:

Imagen de NVDA Keyboard Commands de Stamford Interactive

1. Empty Links and Screen Readers

Realizado por Mike Davies, desarrollador de Yahoo y publicado en yuiblog.com en enero de 2008. Estudia los problemas de accesibilidad que se encuentran los usuarios de lectores de pantalla ante los diferentes tipos de enlaces.


Los casos que cubre este estudio son:

  • Enlaces normales con un texto de enlace apropiado
  • Enlaces sin texto de enlace o sin atributo "title"
  • Enlaces con atributo "title" pero sin texto de enlace
  • Enlaces cuyo texto de enlace son sólo espacios en blanco

Cada uno de estos enlaces fue implementado de la siguiente manera:

  • Se muestra de manera predeterminada (mediante el elemento A sin ocultarlo)
  • Posicionado fuera de pantalla (posicionamiento negativo)
  • Se oculta mediante visibility:"hidden"
  • Se oculta mediante display:"none"


Sus conclusiones son:


  • Los enlaces siempre deben tener un texto de enlace apropiado y asegurar que el texto del enlace tenga sentido en el contexto. Entonces el enlace puede ser ocultado por posicionamiento fuera de pantalla. Si el enlace se oculta con display:none (no será leído por los lectores de pantalla), garantizar que el contenido tenga sentido con y sin el texto del enlace en su sitio.
  • Nunca tener un ancla únicamente con el atributo HREF. El lector de pantalla lee la URL completa o trata de extrapolar algo legible de la misma o una combinación de ambas cosas. Esto puede llevar a resultados impredecibles.
  • Nunca use visibility: "hidden" para ocultar un enlace vacío de la vista. Esto conduce a que el atributo TITLE sea ignorado en JAWS/IE6, y la URL absoluta del enlace sea leída con Firefox. Además provoca una dependencia de las CSS para evitar una barrera de accesibilidad.
  • Nunca use sólo espacios en blanco como texto de un enlace. La elección del texto del enlace entre las configuraciones testeadas difiere significativamente, con todas las combinaciones se produjeron barreras de accesibilidad - ya sea de la lectura de la URL, o para adivinar el texto del enlace basándose en una extrapolación de la URL, o como en Window Eyes que anuncia un enlace pero sin texto de enlace que leer.
  • Nunca use display:"none" para ocultar un enlace, pues los lectores de pantalla no lo leen (ver artículo: "JAWS, Window-Eyes and display:none: Return to 2007").
  • Nunca confíe en el atributo TITLE como único medio para proporcionar una forma de texto del enlace ya que es inconcluyente si el atributo TITLE es permitido por todos los usuarios de lectores de pantalla.



2. Prueba de comportamiento de lectores de pantalla frente a abreviaturas y acrónimos


Realizado por SIDAR. Complementa al artículo "Abreviaturas vs. Acrónimos"

Las pruebas indican que ninguna versión de los diversos lectores de pantalla analizados (JAWS hasta la versión 8) responde al atributo "title" de la etiqueta de abreviatura o de acrónimo.

Por ello es muy importante que, al menos la primera vez que se usan en el texto, se expanda su significado en el propio texto. Sería también muy útil que los autores ofrecieran una relación de las abreviaturas y acrónimos que se utilizan en la página.

Nota Olga:

NVDA 2014 no lee el title de las abreviaturas. En realidad la nota #3828 dice que te la puede anunciar cuando navegas por objetos, pero no es cierto o yo nunca lo he conseguido. NVDA anuncia el párrafo que contiene la abreviatura (con NVDA+5 teclado numérico), y cuando accedes a su objeto contenido, la (con NVDA+2 teclado numérico) te la anuncia como texto y no te lee el texto del title.

3. Survey of Preferences of Screen Readers Users

Realizado por WebAIM (enero 2009)

Esta primera encuesta nos recuerda la importancia de:


  • Que los enlaces sean significativos, pues el 35% navega por el listado de enlaces de la página.
  • Incluir un enlace "Saltar al contenido", pues 38% lo utiliza siempre que puede o a menudo y un 28% algunas veces.
  • Incluir teclas de acceso rápido ("accesskey") pues un 35% las usa siempre que puede o a menudo y un 24% algunas veces.
  • Que los encabezados deben utilizarse para reflejar la estructura del contenido, pues el 76% navega por los encabezados siempre que puede o a menudo y un 14% algunas veces.
  • Que el buscador sea fácil de encontrar y usar. El 61% lo buscan dirigiéndose al primer FORM o campo de edición de texto de la página, por tanto debe ser el primero que encuentren.
  • No abusar de los pop-ups, pues los usuarios con menos experiencia en el uso de lectores de pantallas tienen bastantes dificultades con ellos.
  • Flash mejor no, el 71% consideran este contenido muy difícil o bastante difícil.


4. Screen Reader User Survey Results


Realizado por WebAIM (noviembre 2009)

La han comentado:

Los elementos más problemáticos que se resaltan son:

  • CAPTCHA - imágenes que presentan texto para verificar que un formulario lo está rellenando un ser humano.
  • La presencia de contenido Flash inaccesible.
  • Enlaces o botones sin sentido.
  • Imágenes sin texto alternativo o descripciones no adecuadas.
  • Formularios complejos o difíciles.
  • Falta de accesibilidad mediante el teclado.
  • Pantallas o partes de la pantallas que cambian de forma inesperada.
  • Encabezados ausentes o no adecuados.
  • Demasiados enlaces o elementos de navegación.
  • Tablas de datos complejas.
  • Falta de enlaces "saltar al contenido principal" o "saltar navegación".
  • Funcionalidad de búsqueda inaccesible o ausente.


5. Guidelines for Accessible and Usable Web Sites: Observing Users Who Work With Screen Readers1


Realizado por el United States National Cancer Institute. Aunque es antiguo (2002-2003) resulta muy recomendable.

El objetivo del estudio es:

  • Comprender la relación entre accesibilidad y usabilidad.
  • Comprender como las personas ciegas y con poca visión interactúan con los sitios web
  • Desarrollar directrices de accesibilidad y usabilidad basadas en la investigación
  • Evaluar la usabilidad de sitios Web específicos para usuarios ciegos o con poca visión.

Establece 32 pautas a seguir:


Guideline 1. Write for the web. Write in short, clear, straightforward sentences. Use bulleted lists. Put the main point at the beginning of a paragraph. Write links that start with keywords.

Guideline 2. Use empty ALT text, ALT="" or use a space as ALT-text, ALT=" " for decorative elements on a page so that users do not have to listen to "decorative bullet image" or "decorative line." Using empty ALT text for decorative elements complies with 508 guidelines. When links are bulleted, there is no need to identify the bullet, just the link name.

Guideline 3. For developers of screen-reading software: Make the commands mnemonic and intuitive.

Guideline 4. For designers and developers of Web sites: Make the site structure clear and obvious. The more obvious the structure of the site, the easier it will be for screen-reader users (as well as for sighted users) to understand and use the site.

Guideline 5. For developers of the screen-reading software: Consider providing training to help users get the most value from the screen-reading software that they use. Consider building easy-to-use demos and tutorials on new features.

Guideline 6. Write "home page" as two words.

Guideline 7. Do not make up unusual names for products, services, or elements of a Web site. Do not combine two or more words into one name. (Of course, these names often predate the Web site, and designers and developers cannot change them. Just do not add to the problem – and alert others to the problem as well.)

Guideline 8. To make screen readers read an acronym or abbreviation as letters rather than attempting to read it as a word, use the ACRONYM and ABBR tags as explained at http://www.w3.org/TR/WCAG10-HTML-TECHS/#text-abbr.

Guideline 9. For most Web sites, spend the available time and effort making one version that is accessible to all rather than creating and having to later maintain two separate versions.

Guideline 10. Include a "skip" link at the top of every Web page. Name it "Skip to main content." JAWS reads that correctly as the noun "content" with the accent on the first syllable. That wording was much more meaningful to participants than "skip navigation."

Guideline 11. Make links descriptive. Be sure that the link will be useful by itself, with no surrounding text. Do not use "click here," "more," "answer," or other repetitive words or phrases as links. Look at www.aarp.org for a site that consistently expands what used to be "more" into meaningful links, such as "more travel articles," "more of today's news," and so on.

Guideline 12. Start links with relevant keywords.

Guideline 13. Try not to have many links that start with the same word or phrase. In some ways, these guidelines are obvious and easy to implement. We know that even for sighted users, links should be descriptions of what they go to rather than "click here" or the URL

Guideline 14. Start question headings with a keyword followed by the question.

Guideline 15. Pay attention to the wording on pages and be sure that keywords that users would look up are actually on the page. (This is useful for sighted users, too.)

Guideline 16. Make sure that the keywords are not in images.

Guideline 17. For makers of screen-reading software: Make Find cycle through the entire page.

Guideline 18. Do not create subtle differences between the text on the page and the ALT text that can trip users up when they search for words on the page.

Guideline 19. Use a search engine that provides help with spelling, such as the one at www.google.com.

Guideline 20. Use anchor links when a page has several topics.

Guideline 21. Keep pages from refreshing when users select an anchor link. Do not include a time and date stamp on a page with anchor links.

Guideline 22. Encourage authors to use many headings in their content and to be sure that those headings are clear, meaningful, and parallel. This guideline is critical for both sighted users and screen-reader users.

Guideline 23. Be sure that the headings are coded properly in HTML, for example, as H1, H2, etc. JAWS looks for the heading tag.

Guideline 24. Put the keyword at the beginning of the heading. If many headings are about the same thing, differentiate them in meaningful ways.

Guideline 25. Do not put a lot of text on the same page as a form.

Guideline 26. Do not put a form far down on the page or far to the right.

Guideline 27. Make sure that all fields are coded so that users do not have to switch to and from Edit mode. Use the HTML [label] element. To add more information than is in the label, use the Title attribute.

Guideline 28. In addition to checking your site with an automated tool like Bobby or LIFT, listen to it with a screen reader.

Guideline 29. Do not put information between fields on a form.

Guideline 30. If the user has an option of filling out either of two fields, and they are mutually exclusive, inform the user with the label of the first field.

Guideline 31. Do not exclude labels from fields.

Guideline 32. Avoid making pages refresh.


6. "What Frustrates Screen Reader Users on the Web: A Study of 100 Blind Users" (PDF)

Realizado por Towson University en 2007.

Es destacable el apartado Motivos de frustación. Consultar la tabla resumen de los principales motivos de frustación.


7. Screen Readers lack emphasis


Estudio de Paciello Group Blog sobre el soporte de em, i, b, strong, del, ins por los lectores de pantalla. La última actualización del estudio es del 28.01.2010


La conclusión del estudio es que ni JAWS 8.0 ni Window Eyes 5.5 indican al usuario mediante el cambio de voz (o por otro medio) cuando el texto contiene estas etiquetas, ni tampoco tienen la opción de poder definirlo en las preferencias del programa.


Sin embargo, en una actualización posterior, indican que en el caso de JAWS, si bien no se puede configurar en las opciones habituales del programa (Utilities > Configuration Manager > Set Options) si que has a document proofreading scheme called Proofreading (attributes), using this scheme italicized, stricken and bolded text is indicated by a change in voice. Se puede acceder mediante las teclas INS+ALT+S. Se indica que no distingue entre em/i y strong/b.


Por otro lado se señala, ya en los comentarios, que ambos programas sí reconocen las etiquetas, puesto que se puede consultar la información de la fuente de un texto y se indicará si está en negrita, itálica, etc. El problema reside en que no se indica de forma automática al leer el texto (mediante por ejemplo el cambio de voz) la presencia de estas etiquetas.


En los comentarios se indica que VoiceOver (sobre OSX) no reconoce los elementos pero se para al llegar a ellos.


Se propone que el modo para cambiar el énfasis en estos elementos sea mediante la CSS media=audio.


Por último se indica que JAWS sí anuncia "blockquote" en el inicio y el final del texto marcado como tal (notificación que puede ser deshabilitada). Los usuarios pueden sacar una lista de blockquotes en la página mediante CTRL+ INSERT + Q o saltar entre ellos usando la tecla Q. Window Eyes cuenta con un apoyo a la etiqueta blockquote similar a JAWS.




8. Screen Reader User Survey 2011 de WebAIM


En diciembre de 2010 WebAIM realizó una nueva encuesta a usuarios de lectores de pantalla, usuarios que en su amplia mayoría lo utilizan por una discapacidad y que tienen un nivel avanzado o intermedio de uso de la herramienta.

El lector de pantalla para uso general más utilizado fue JAWS (70%) seguido de lejos por Windows-Eyes(19%), VoiceOver(20%) y NVDA (35%), observándose un aumento significativo en el uso de este último (desde el 8% de uso en enero de 2009). También es significativo que el 47% usa más de un lector de pantalla.

Los navegadores con los que usan el lector de pantalla son: IE 8 (43.%), seguido de Firefox 3+ (23.5%), IE7 (12.5%), Safari (9.6%), IE 6 (5.2%) y IE 9 (4.5%). Por tanto Explorer supone un 65.3% de la cuota de navegador.

Los resultados más significativos son:

  • Sólo el 1.6% de los encuestados tienen javascript deshabilitado frente al 10.4% de 2009.
  • El 66.7% utilizan un lector de pantalla en el teléfono móvil (las plataformas más utilizadas fueron Nokia con un 42.4% y iPhone/iPod con un 32.6%) que supone un aumento del 550% respecto a enero de 2009.
  • El 27.5% de los encuestados usan las "accesskey", esto supone una disminución del 38%.
  • Hay un ligero descenso del uso de los enlaces "saltar".
  • Ha un incremento de los usuarios que buscan la información prioritariamente a través de los encabezados frente a los que buscan información con la opción de buscar o navegando a través de los enlaces.
  • Un 60.8% encuentran útil la propiedad LONGDESC aunque hay un 22.7% que la desconocen.
  • Aumenta el conocimiento de los ARIA landmarks, aunque sigue habiendo un 30.9% que no los conoce.

En contra de la mayoría de las recomendaciones, el 50.3% prefiere dos H1, uno para el nombre del sitio y otro para el título del documento. Sólo un 12.5% prefiere que el H1 sea el nombre del sitio frente al 37.1% que refiere que sea el título del documento.



9. Encuesta sobre las barreras que encuentran los usuarios de lectores de pantalla


Encuesta realizada por coaccesibilidad.com en 2011 a 53 usuarios.

La barrera que menos preocupa a los usuarios es: "Páginas en las que no existe un título que resuma su objetivo o propósito"

Las barreras que más dificultan la navegación según los usuarios son:

  • Capcha sin alternativa accesible.
  • Formularios en los que no se indica cómo introducir los datos (etiquetas inexistentes o poco precisas) y en los que resulta complejo detectar qué errores has cometido al cumplimentarlos.
  • Imágenes con funcionalidad (por ejemplo, un enlace o botón) sin descripción alternativa.
  • Contenidos que recogen instrucciones visuales (incluyen referencias a colores o a zonas de la página) para ser comprendidos o para llevar a cabo acciones (por ejemplo, frases del tipo “marca el botón rojo”, “activa el enlace situado a la derecha de la imagen”).
  • Cambios en el contenido que no son percibidos por el lector de pantalla (por ejemplo, nuevos avisos que aparecen en la página, enlaces que aparecen y desaparecen en función de la acción que realizas, etc.)
Gráfica de resultados. Están explicados en la página del estudio


10. Testing form control labelling support in popular browsers and screen readers


Resumen publicado por html5accessibility.com el 12.01.2012 sobre el soporte de legend (en un fieldset) y label al etiquetar campos de un formulario web (implementado de forma explícita e implícita)

Se ha probado con JAWS 13, VoiceOver 4.0 y NVDA 2011.3 beta 1 sobre IE 9, Firefox 11.a2, Chrome 17beta, Safari 5.1.2 y Opera 11.6.

Se analiza también el soporte del atributo aria-labelledby

Destaca que tanto JAWS como NVDA sobre Chrome, como VoiceOver sobre Safari, leen el label y no el legend. En el resto de casos leen ambos.

El soporte de label, tanto de forma implícita como explícita es general, aunque en ciertos casos se lee dos veces.

11. Soporte de ARIA Roles con diferentes lectores de pantalla (JAWS, NVDA, VoiceOver, Chrome, Windows Eyes de Paciello Group Blog (2011)

Trato este tema en el artículo: Navegación más accesible y semántica en 2 minutos con Landmark Roles (WAI-ARIA)

Puedes consultar diferentes vídeos donde se muestra el soporte de ARIA-Roles por diferentes navegadores en mi lista de reproducción de Youtube "HTML 5 y accesibilidad".

12. Soporte de diferentes etiquetas por lectores de pantalla en dispositivos móviles

Henry Swan tiene dos artículos muy interesantes de 2011:

13. Screen Reader User Survey #4 Results, 2012, WebAIM

Como en años anteriores WebAIM presentó en 2012 su informe sobre el uso de lectores de pantalla (informes anteriores: informe 2009 (enero), informe 2009 (noviembre), informe 2011 (enero))

Contestada fundamentalmente por un público norteamericano y con un nivel avanzado o medio de Internet y el lector de pantalla. Los porcentajes del lector que usan normalmente son: JAWS 64%, NVDA 43%, VoiceOver 31%, SAToGo 22%, Window-Eyes 21%.

Esta es la evolución en los últimos años:

Sólo el 27.7% utiliza salida por Braille. Explorer, en sus diferentes versiones, era usado por el 67.5%, seguido de Firefox con un 20%. Solo el 1.4% navegaba con javascript desactivado.

El uso del móvil en los tres últimos años se ha incrementado un 600%. El 58.5% usaba iPhone,iPad o iPod, seguido por un 20.3% que usaba Nokia. El 48.7% usaba VoiceOver.

El 35% opinaba que había mejorado la accesibilidad web en general en los sitios de Internet, pero un 39% opinaba que era igual.

El conocimiento y uso de ARIA landmarks parece haberse incrementado entre los usuarios. El 60% navega usando los encabezados (se consideran útiles o muy útiles por el 82%), 16% usa el buscador, el 13% navega a través de los enlaces. El uso del enlace para "saltar al contenido" es muy variado.

El 90% considera los captcha muy difíciles, siendo después de Flash el principal problema que reportan.

G´rafica de principale sproblemas, explicada en la web del estudio de WebAIM

14. Screen Reader User Survey #5 Results, 2014, WebAIM

Como en años anteriores WebAIM presenta en 2014 su informe sobre el uso de lectores de pantalla (informes anteriores: informe 2009 (enero), informe 2009 (noviembre), informe 2011 (enero), informe 2012 (mayo))

La encuesta se realiza a usuarios de todo el mundo, especialmente a usuarios de Norteamérica (61.4%) y Europa (20.6%), que en un 95% indican tener una discapacidad. El 58% son usuarios de lector de pantalla avanzados, un 39% intermedios y un 3% dicen ser principiantes, un porcentaje muy similar a su experiencia en Internet.

Un 85% usa varios dispositivos. El sistema operativo mayoritario es Windows (82.8%). Se ve un claro aumento del uso del lector de pantalla en los dispositivos móviles, del 61% de 2012 al 72% de 2014.

El lector de pantalla principal en escritorio/portatil es JAWS para el 50% de los usuarios. En Asia es el más popular con un 65% y en Norteamérica con un 52%, sin embargo en Europa es de un 44%. El uso de Window-Eyes cae del 12.3% de 2012 a un 6.7% en 2014. NVDA avanza significativamente siendo tres veces más popular en Europa que en Norteamérica.

Si estos porcentajes los vemos relativos a los lectores de pantalla que usan comúnmente (el 62% usa más de uno), el uso de NVDA es del 51.2%, frente al 63.9% de JAWS, y por tanto se acortan sensiblemente las distancias.

Gráfica de lectores de pantalla preferidos en 2009, 2010, 2012 y 2014. Window-Eyes cae y es el menos usado. JAWS desciende pero sigue siendo el más usado. NVDA sufre un gran aumento cerca ya de JAWS. VoiceOver también tiene un gran avance pero se mantiene por debajo de NVDA.

El navegador más usado es IE9+ con un 38.9% que cae drásticamente comparado con el 67.5% de 2012. Le sigue Firefox con un 24.2%, IE8 con un 12.6% y Safari con un 10%. Chrome solo es usado por un 2.8% por debajo incluso de IE6 e IE7. Este uso de Chrome, mucho más bajo del uso general, dicen que es presumiblemente por falta de apoyo de lectura.

El 97.6% navega con javascript activo.

El 82% usa un lector de pantalla en los dispositivos móviles, frente al 12% de 2009, y en Norteamérica lo usan menos. El 65% utilizan un iPhone, iPad o iPod, que aumentan año tras año, seguidos de lejos por Android que sube del 7.9% al 16%. Por tanto es lógico que el lector de pantalla más usado en dispositivos móviles sea VoiceOver (60.5%) seguido de TalkBack for Android con 21.6% y Nuance Talks con un 15.6%. El 44% usa los lectores de pantalla de dispositivos móviles tanto o más que los de escritorio.

Un 41.5% considera que la accesibilidad de los sitios es la misma que la del año anterior, pero un 36.7% cree que los sitios han mejorado su accesibilidad, siendo por primera vez en cinco años de encuestas más positivos.

Sobre temas concretos:

  • Migas de pan (ver ejemplo propuesto en la encuesta): el 27% prefiere que se marquen como lista ordenada (ol) frente al 11.9% que las prefiere desordenadas (ul). Un 20.4% las prefiere como texto plano. Pero un 32.6% no sabía. Las personas sin discapacidad son dos veces más propensas a preferirlas como listas anidadas que es la más compleja de las presentaciones.
  • Qué les parece que el sitio pudiera detectar si usan un lector de pantalla: el 78.4% estaría muy o bastante cómodo con esta práctica que sube al 86.5% cuando se indica que sería para mejorar la accesibilidad del sitio.
  • ¿Cuál crees que es la principal razón de que los sitios no sean accesibles?: las respuestas son casi idénticas a las de 2009. Las personas con discapacidad son más propensis a atribuirlo a la falta de conciencia, mientras que las personas sin discapacidad lo atribuyen más a la falta de habilidades o conocimientos.
  • Landmark regions: el conocimiento y uso de los landmark ha crecido significativamente. El 48% de los usuarios de JAWS los usa siempre o a menudo (el 41.4% en NVDA, el 34.9% en VoiceOver). El 28.7% prefiere de 4-6, aunque un 40.2% no sabe contestar a cuántos prefiere. Trato este tema en el artículo: Navegación más accesible y semántica en 2 minutos con Landmark Roles (WAI-ARIA)
  • Para buscar información en una página larga, ¿qué es lo primero que haces?: el 65.6% usa los encabezados (porcentaje que crece cada año, en el caso de los usuarios avanzados sube al 71%), el 15.2% usa la búsqueda, el 9.8% navega a través de los enlaces. Es curioso que con el gran porcentaje de usuarios que dice usar los landmarks, solo el 2.8% los señala como lo primero que hace, posiblemente porque pocos sitios los incluyen.

15. Text Links: Best Practices for Screen Readers, febrero 2014, deque.com

En este test se evalúan los atributos title y aria-label en los enlaces. JAWS 15 (con Firefox y IE), NVDA 2013 (Firefox) y VoiceOver (en iPad) leen el texto del enlace más el title. JAWS solo leerá el title si este es diferente del texto del enlace.

Se han evaluado con las preferencias por defecto de los lectores de pantalla.

Nota Olga:

Con NVDA el title de los enlaces se leerá en Firefox y en Chrome solo cuando accedas a ellos con el tabulador.

La razón que dan para este comportamiento es que la información del title es secundaria y que así la experiencia es similar a la de las personas que ven, que solo perciben la información del title cuando colocan el cursor sobre el enlace. Ver nota #3715

16. Test: Atributo lang en un elemento dentro de un enlace, julio 2014, Olga Carreras

El objetivo de este test es evaluar, mediante diferentes ejemplos, si los lectores de pantalla leen una parte de un enlace definido en otro idioma (mediante el atributo lang) correctamente.

El resultado indica que depende del lector de pantalla, del navegador e incluso de si accedemos al enlace mediante las flechas o el tabulador.

17. Accessibility tests. JAWS and NVDA tests, maxdesign.com.au

En esta página encontraréis un listado de diferentes tests sobre WAI-ARIA (aria-describedby, landmark roles, aria-valuemax y aria-valuemin) y diferentes elementos de HTML (encabezados, listas, tablas, title, elementos de formulario, etiquetas semánticas de HTML5, etc.)

Enlaces recomendados sobre el tema