febrero 2010

Última actualización: 30 enero 2012

20.01.2011 - Añadido estudio 7. "Screen Readers lack emphasis" sobre el soporte de em, i, b, strong, del, ins, blockquote por los lectores de pantalla.
02.03.2011 - Añadido estudio 8. "Screen Reader User Survey 2001 de WebAIM"
26.08.2011 - Añadido resultado de la encuesta realizada por coaccesibilidad.com 9. Encuesta sobre las barreras que encuentran los usuarios de lectores de pantalla
30.01.2012 - Añadido el estudio Testing form control labelling support in popular browsers and screen readers sobre el soporte de legend y label (explícito e implícito)

Índice

Empty Links and Screen Readers, 2008, Yahoo.
Prueba de comportamiento de lectores de pantalla frente a abreviaturas y acrónimos, Sidar
Survey of Preferences of Screen Readers Users, 2009, WebAIM
Screen Reader User Survey Results, 2009, WebAIM
Guidelines for Accessible and Usable Web Sites: Observing Users Who Work With Screen Readers1, 2003, United States National Cancer Institute
What Frustrates Screen Reader Users on the Web: A Study of 100 Blind Users, 2007, Towson University
Screen Readers lack emphasis, 2010, Paciello Group Blog
Screen Reader User Survey 2011, 2011, WebAIM
Encuesta sobre las barreras que encuentran los usuarios de lectores de pantalla
Testing form control labelling support in popular browsers and screen readers, publicado el 10.12.2012

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.

3. Survey of Preferences of Screen Readers Users

Realizado por WebAIM (enero 2009)

El resultado de la encuesta lo comentó uninstallme en "Preferencias y modos de uso de lectores de pantalla" (01.02.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:

"Resultados de la encuesta a usuarios de lectores de pantalla", de accesibilidadweb.com (02.11.2009)
"Encuestas sobre uso de lectores de pantalla", de Accesibilidad en la web, (17.02.10)

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 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 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 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.