Resultados de la décima encuesta del WebAIM sobre el uso de lectores de pantalla

Ya se han publicado los resultados de la décima encuesta del WebAIM sobre el uso de lectores de pantalla que se abrió en diciembre de 2023: Screen Reader User Survey #10 Results.

La encuesta recibió 1539 respuestas válidas, un número muy alto de respuestas, pero menor que las 2515 y 1792 respuestas que se recibieron en la sexta y séptima encuesta respectivamente.

En los resultados de la encuesta actual, JAWS es el principal lector de pantalla con un 40.5%, seguido de NVDA con un 37.7% y VoiceOver con un 9.7%.

Respecto a los elementos más problemáticos, los que más causan problemas de accesibilidad, son los mismos que en anteriores ocasiones.

Los culpables son:

1. CAPTCHA - images presenting text used to verify that you are a human user
2. Interactive elements like menus, tabs, and dialogs do not behave as expected
3. Links or buttons that do not make sense
4. Screens or parts of screens that change unexpectedly
5. Lack of keyboard accessibility
6. Images with missing or improper descriptions (alt text)
7. Complex or difficult forms
8. Missing or improper headings
9. Too many links or navigation items
10. Complex data tables
11. Inaccessible or missing search functionality
12. Lack of "skip to main content" or "skip navigation" links

Décima encuesta del WebAIM sobre el uso de lectores de pantalla

Durante los últimos años, el WebAIM ha realizado varias encuestas online destinadas a analizar los hábitos de uso de los lectores de pantalla.

Ahora ya está abierta la décima edición: Screen Reader User Survey #10.

La encuesta estará disponible hasta el 31 de enero de 2024 y la pueden contestar todos los usuarios de lectores de pantalla, incluso los que los usan únicamente para evaluación y pruebas.

Cinco mitos sobre los lectores de pantalla

Muy interesante lo que se explica en 5 Myths About Screen Readers That Can Hurt Accessibility:

• Myth 1: Everyone with blindness or low vision uses a screen reader to "listen" to content
• Myth 2: Only people with blindness or low vision use screen readers
• Myth 3: You can sufficiently test accessibility with a single, in-app screen reader
• Myth 4: All screen readers are exactly the same
• Myth 5: Content is automatically compatible with screen readers

Resultados de la novena encuesta del WebAIM sobre el uso de lectores de pantalla

Ya se han publicado los resultados de la novena encuesta del WebAIM sobre el uso de lectores de pantalla que se abrió en mayo de 2021: Screen Reader User Survey #9 Results.

La encuesta recibió 1568 respuestas válidas, un número muy alto de respuestas, pero menor que las 2515 y 1792 respuestas que se recibieron en la sexta y séptima encuesta respectivamente.

En cuanto a porcentaje de preferencia de los usuarios, sorprende que el lector de pantallas JAWS vuelva a ser el más preferido. En la encuesta anterior, el lector de pantalla principal dejó de ser JAWS, ya que el principal fue NVDA con un 40.6%, seguido de JAWS con un 40.1%. El tercero fue VoiceOver con un 12.9% y el resto de lectores de pantalla tenían un porcentaje de uso muy pequeño.

En los resultados de la encuesta actual, JAWS es el principal con un 53.7%, seguido de NVDA con un 30.7% y VoiceOver con un 6.5%.

El navegador que más se usa es Chrome, con un 53.6%, seguido de Microsoft Edge con un 18.4% y Firefox con un 16.5%.

En esa misma página están enlazados los resultados de las encuestas anteriores.

Novena encuesta del WebAIM sobre el uso de lectores de pantalla

Durante los últimos años, el WebAIM ha realizado varias encuestas online destinadas a analizar los hábitos de uso de los lectores de pantalla.

Ahora ya está abierta la novena edición: Screen Reader User Survey #9.

La encuesta estará disponible hasta el 15 de junio de 2021 y la pueden contestar todos los usuarios de lectores de pantalla, incluso los que los usan únicamente para evaluación y pruebas.

El reto de probar la accesibilidad con lectores de pantalla

 Muy interesante el análisis que se presenta en A developer's perspective: the problem with screen reader testing:

Screen readers are an essential part of using the web for people who are vision impaired, illiterate or have a learning disability.

Today’s screen readers traverse web pages and applications and read out user interface elements, content and allow users to navigate and interact with the web.

There are many screen readers available for different devices and platforms, each with differing levels of functionality, interfaces and features. The most common are JAWS, NVDA, VoiceOver and TalkBack.

[...]

As a developer regularly faced with time constraints, I have often wondered: what should be the baseline in terms of testing for screen readers, and what browser and screen reader combinations are the most important to cover in order to achieve the greatest level of WCAG compliance?

Contratando un seguro con la pantalla apagada

El vídeo Accesibilidad web. Contratando un seguro con la pantalla apagada dice:

A veces no pensamos en la forma en la que otras personas realizan trámites cotidianos, como sacar un billete o contratar un seguro. En este mini vídeo, os enseño cómo el traje de developer me podría salvar el día cuando una web, la de mundial seguros, no ha sido desarrollada pensando en la accesibilidad. ¿Conseguiré introducir las fechas de cobertura? :P

Intermundial: un seguro que seguro que no es accesible.

Breve historia de los lectores de pantalla

Realmente, la historia que se cuenta en A Brief History of Screen Readers es muy breve, pero algo es mejor que nada.

¿Cómo programa una persona ciega?

El vídeo ¿Cómo programa una persona ciega? dice:

En este vídeo, más largo que un día sin pan, y grabado de madrugada con mucho sueño (perdonad el tono de voz, xD) os enseño cómo un usuario ciego utiliza un ordenador, no solo a nivel de usuario, sino también para desarrollar software, y así, contestar a algunos comentarios que leí en la noticia de Meneame: 

https://www.meneame.net/m/tecnolog%C3%ADa/programador-ciego-espanol-denuncia-miserias-sector-nadie

¿Un programador ciego puede programar webs y apps de escritorio o solo backend? ¿qué pasa si hay iconos y botoncitos? ¿cómo depura? ¿cómo lee el código? ¿puede indentar o le vale para algo?
Todo esto y mucho más, en una hora y pico de vídeo. ¡Si llegáis al final ponedlo en los comentarios para que os lo agradezca personalmente, :P

Maquetación de páginas web para lectores de pantalla

Muy interesante todo lo que se explica en Designing Layouts for Screen Readers:

It’s easy to think about a layout as being a primarily visual concern. The header goes up top, the sidebar is over here, the call to action is in an overlay on top of the content (just kidding). Grids, borders, spacing and color all portray valuable visual data, but if these hints to the structure of a page are only visible, some users may find your content unintelligible.

You can experience this first hand if you try using a screen reader on the web. When I fired up VoiceOver on my Mac and took it out for a test drive, I realized that to a screen reader user, a lot pages are just a big heap of ‘content’, missing helpful organizational cues.

The experience can be kind of like listening to a long rambling story without any indication to what details are important or related to the main thread of the story. Halfway through the story, you aren’t sure whether it’s worth it to keep listening because you don’t know if you’ll even find what it is you’re looking for. In the context of a website, your screen reader might be halfway through reading you a list of 50 sidebar links when you start wondering if there is any valuable content on the site at all.

Experiences like this are caused by websites that are built with layouts that are only visual. Ideally, however, our visual layouts should point to an underlying organizational model of our content. They should be visual indicators for a conceptual model. The visual indicators are just one way of revealing this model. The Web Accessibility Initiative’s ARIA (Accessible Rich Internet Applications) project provides alternative indicators to users who may need them.

I’ll walk through how to make use of these indicators to make a simple web page easy to use, navigate and read for users of assistive technology. All the example code is available on github.

Semántica, ARIA y lectores de pantalla

En Semantics to Screen Readers se explica:

Assistive technologies (ATs), which are hardware and software that help us perceive and interact with digital content, come in diverse forms. ATs can use a whole host of user input, ranging from clicks and keystrokes to minor muscle movements. ATs may also present digital content in a variety of forms, such as Braille displays, color-shifted views, and decluttered user interfaces (UIs). 

One more commonly known type of AT is the screen reader. Programs such as JAWS, Narrator, NVDA, and VoiceOver can take digital content and present it to users through voice output, may display this output visually on the user’s screen, and can have Braille display and/or screen magnification capabilities built in. 

If you make websites, you may have tested your sites with a screen reader. But how do these and other assistive programs actually access your content? What information do they use? We’ll take a detailed step-by-step view of how the process works.

Cómo diseñar para lectores de pantalla

En Designing Layouts for Screen Readers se explica:

It’s easy to think about a layout as being a primarily visual concern. The header goes up top, the sidebar is over here, the call to action is in an overlay on top of the content (just kidding). Grids, borders, spacing and color all portray valuable visual data, but if these hints to the structure of a page are only visible, some users may find your content unintelligible.

You can experience this first hand if you try using a screen reader on the web. When I fired up VoiceOver on my Mac and took it out for a test drive, I realized that to a screen reader user, a lot pages are just a big heap of ‘content’, missing helpful organizational cues. 

The experience can be kind of like listening to a long rambling story without any indication to what details are important or related to the main thread of the story. Halfway through the story, you aren’t sure whether it’s worth it to keep listening because you don’t know if you’ll even find what it is you’re looking for. In the context of a website, your screen reader might be halfway through reading you a list of 50 sidebar links when you start wondering if there is any valuable content on the site at all.
Experiences like this are caused by websites that are built with layouts that are only visual. Ideally, however, our visual layouts should point to an underlying organizational model of our content. They should be visual indicators for a conceptual model. The visual indicators are just one way of revealing this model. The Web Accessibility Initiative’s ARIA (Accessible Rich Internet Applications) project provides alternative indicators to users who may need them. 

I’ll walk through how to make use of these indicators to make a simple web page easy to use, navigate and read for users of assistive technology. All the example code is available on github.

Ejemplo de uso de un lector de pantalla

El vídeo Enciende tu ordenador. Desenchufa el ratón. Desconecta la pantalla... ¡Y ponte a trabajar,! dice:

¿Te has planteado qué pasaría si de repente no pudieras utilizar la pantalla de tu ordenador? ¿Te ves capaz de manejarlo sin poder verlo? ¿Y un iPhone? ¿Es eso posible?
En este vídeo veremos cómo las personas ciegas hacemos uso de la tecnología, y cómo ésta nos permite ser mucho más independientes siempre que sea accesible. Adéntrate conmigo en una realidad diferente que seguro te sorprenderá.

Aprender los atajos de teclado de los lectores de pantalla

En Learning common keyboard shortcuts for screen readers se explican algunas técnicas para aprender los atajos de teclado de los lectores de pantalla más populares.

¿Por qué un usuario que utiliza un lector de pantalla querría tener una línea braille?

En Why would a screen reader user have a braille display? se explica:

As he wasn’t deaf-blind, I asked why he uses such expensive equipment, when devices have built-in free screen readers. One of his reasons was, in retrospect, so blazingly obvious, and so human.
He likes to read his kids bedtime stories. With the braille display, he can read without a synthesised voice in his ear. Therefore, he could do all the characters’ voices himself to entertain his children.
My take-home from this: Of course free screen readers are an enormous boon, but each person has their own reasons for choosing their assistive technologies. Accessibility isn’t a technological problem to be solved. It’s an essential part of the human condition: we all have different needs and abilities.

Y los comentarios también proporcionan información interesante:

Comentario 1

there are so many reasons to use braille. By the way, the screen reader is also controling braille output. Among the reasons: Learning to spell and format, ability to read silently, becoming literate in a foreign language (or in one’s own,) reading music notation, not having to listen to speech synthesis, playing sudoku and other word games, and others.

Comentario 2

Reading bedtime stories to your child using a braille display, that’s a really powerful example indeed!
However, a braille display isn’t an alternative for a using screenreader. It’s the screenreader that outputs information to the braille display (and it often also doubles as a braille input device).
Most bind professionals I know, simply can’t do their job without using a braille display. Every-day tasks like editing an article, for example, is a dreadful experience when you have to rely on text-to-speech only.

¿Cómo usa Visual Studio un desarrollador ciego?

En How A Blind Developer Uses Visual Studio:

Saqib Shaikh, a developer who happens to be blind, shows how he uses Visual Studio 2017 with screen reader software for writing and debugging code.

¿Cómo programa un desarrollador ciego?

Muy interesante el vídeo How does a blind developer code? Plus start of react firebase starter project:

I am a totally blind coder and thought I would post this video of me doing some coding to let others know how I do it. Part of me wants to totally edit this video but I am leaving it as is. This is my first video. 

¿Se usa Orca?

Hace unos días me preguntaron por el uso de Orca, el lector de pantalla más conocido para Linux, o quizás el único que existe.

¿Se usa Orca? En el último Screen Reader User Survey #8 de WebAIM, ni se nombra.

¿Orca es un buen lector de pantalla? En el análisis Practical Screen Reader Comparison: A user-oriented approach no obtenía buenos resultados, quedaba el peor, pero bueno, es un estudio de 2011:

Screen Reader	Points	Percentage
JAWS	85.5	93%
HAL	85.5	93%
NVDA	69	75%
VoiceOver	58	63%
Orca	54	59%

Duda sobre cómo se navega con un lector de pantalla

Un estudiante mío está desarrollando una página web y le ha surgido la siguiente duda:

Me ha surgido una duda leyendo documentación y aprendiendo a utilizar VoiceOver de MacOS. Mi idea era que un usuario pudiera navegar por cada Chunk con el tabulador con información adicional, pero no sé hasta qué punto eso concuerda con la especificación. Por ejemplo, si una lección sigue esta secuencia de Chunks:

• Heading
• Text
• Text
• Heading-Text
• Bulleted-List
• Multiple-Answers

La idea era que el usuario empezara navegando con el tabulador y el lector de pantalla avisara con un “Chunk Heading… [contenido]” y al volver a presionar el tabulador “Chunk Text…[contenido]” y así hasta llegar al final de la lección, pero mi duda es si esto se debería hacer o va contra la especificación.

Y mi respuesta:

Tienes que distinguir dos posibles tipos de usuarios mediante teclado: el que puede ver y el que no.

El que puede ver normalmente es una persona con discapacidad motora que tiene dificultad para usar el ratón, pero también puede ser un usuario "pro" que prefiere el teclado porque es más rápido o un usuario norma con una "discapacidad temporal" (por ejemplo, se le ha roto el ratón). Estos usuarios pueden usar los cursores para realizar scroll up/down, así que no necesitan el tabulador para desplazarse por el contenido y leerlo, pero sí que necesitan el tabulador para desplazarse por los elementos de interacción. También les ayuda que pongas un enlace al final de la página para volver al principio de la página.

El que no puede ver usará un lector de pantalla, como VoiceOver, y conocerá todo los atajos que proporciona (y si no los conoce... es su problema, que los aprenda). La lista de comandos es enorme:

https://help.apple.com/voiceover/info/guide/10.8/spanish.lproj/_1203.html

El que no puede ver tiene dos problemas: cómo desplazarse por el contenido y leerlo (el que puede ver no tiene este problema) y cómo desplazarse por los elementos de interacción. Lo segundo lo hace con el tabulador, como el resto de usuarios. Lo primero no lo puede hacer con los cursos igual que lo hacemos nosotros porque no puede ver, así que tiene atajos para desplazarse a nivel de carácter, palabra, frase y párrafo:

Leer el párrafo del cursor de VoiceOver
VO + P

Leer el párrafo siguiente
VO + Mayúsculas + Av Pág

Leer el párrafo anterior
VO + Mayúsculas + Re Pág

Leer la frase del cursor de VoiceOver
VO + S

Leer la frase siguiente
VO + Comando + Av Pág

Leer la frase anterior
VO + Comando + Re Pág

Leer la línea del cursor de VoiceOver
VO + L

Leer la línea siguiente
VO + Flecha abajo

Leer la línea anterior
VO + Flecha arriba

Leer la palabra del cursor de VoiceOver
VO + W

Deletrear la palabra del cursor de VoiceOver
VO + W + W

Deletrear fonéticamente la palabra del cursor de VoiceOver
VO + W + W + W

Leer la palabra siguiente
VO + Flecha derecha

Leer la palabra anterior
VO + Flecha izquierda

Leer el carácter del cursor de VoiceOver
VO + C

Leer el carácter del cursor de VoiceOver
VO + C + C

Leer el carácter siguiente
VO + Mayúsculas + Flecha derecha

Leer el carácter anterior
VO + Mayúsculas + Flecha izquierda


La página web no tiene que proporcionar ningún mecanismo para ello, más allá de usar correctamente HTML. Por ejemplo, si creas "falsos párrafos", texto separado mediante BR, para el lector de pantalla no existirán esos párrafos que nosotros sí que vemos.

Para lo que me preguntas, no tienes que usar el tabulador, tienes que usar correctamente HTML. En concreto, los usuarios de lector de pantalla se desplazan por una página mediante los encabezados h1, h2, h3, etc.:


Buscar el encabezamiento siguiente
VO + Comando + H

Buscar el encabezamiento anterior
VO + Comando + Mayúsculas + H


Buscar el siguiente encabezamiento del mismo nivel
VO + Comando + M

Buscar el anterior encabezamiento del mismo nivel
VO + Comando + Mayúsculas + M


Y también usan la lista de encabezados, que en el caso de VoiceOver está disponible a través del Web Item rotor:

https://www.apple.com/voiceover/info/guide/_1134.html#mchlp2719

Por tanto, lo que quieres hacer lo tienes que hacer con un buen uso de los encabezados. Deberías usar h1 para el título del curso, h2 para el título de la lección y a partir de h3 para los chunks.

Lo que pasa cuando se usa la Web con un lector de pantalla durante un día

Muy interesante lo que se cuenta en I Used The Web For A Day Using A Screen Reader:

This was an interesting and challenging experience, and the hardest article of the series to write so far.

I was taken aback by little things that are obvious when you stop and think about them. For instance, when using a screen reader, it’s almost impossible to listen to music at the same time as browsing the web! Keeping the context of the page can also be difficult, especially if you get interrupted by a phone call or something; by the time you get back to the screen reader you’ve kind of lost your place.

My biggest takeaway is that there’s a big cultural shock in going to an audio-only experience. It’s a totally different way to navigate the web, and because there is such a contrast, it is difficult to even know what constitutes a ‘good’ or ‘bad’ screen reader experience. It can be quite overwhelming, and it’s no wonder a lot of developers avoid testing on them.

But we shouldn’t avoid doing it just because it’s hard. As Charlie Owen said in her talk, Dear Developer, the Web Isn’t About You: This. Is. Your. Job. Whilst it’s fun to build beautiful, responsive web applications with all the latest cutting-edge technologies, we can’t just pick and choose what we want to do and neglect other areas. We are the ones at the coal face. We are the only people in the organization capable of providing a good experience for these users. What we choose to prioritize working on today might mean the difference between a person being able to use our site, and them not being able to.

Let us do our jobs responsibly, and let’s make life a little easier for ourselves, with my last tip of the article:

Tip #13: Test on a screen reader, little and often.

I’ve tested on screen readers before, yet I was very ropey trying to remember my way around, which made the day more difficult than it needed to be. I’d have been much more comfortable using a screen reader for the day if I had been regularly using one beforehand, even for just a few minutes per week.

Test a little, test often, and ideally, test on more than one screen reader. Every screen reader is different and will read content out in different ways. Not every screen reader will read “23/10/18” as a date; some will read out “two three slash one zero slash one eight.” Get to know the difference between application bugs and screen reader quirks, by exposing yourself to both.