Blog

Utilicé la web durante un día con un lector de pantalla

Un usuario vidente se pone en la piel de un usuario no vidente. Chris Ashton experimenta de primera mano las dificultades a las que se enfrentan los usuarios con discapacidad visual y describe lo que podemos hacer como desarrolladores web para ayudar.

Este artículo forma parte de una serie en la que intento utilizar la web bajo diversas limitaciones, representando a un determinado grupo demográfico de usuarios. Espero dar a conocer las dificultades a las que se enfrentan las personas reales, que son evitables si diseñamos y desarrollamos de forma que se adapte a sus necesidades. La última vez, navegué por la web durante un día sólo con mi teclado. Esta vez, estoy evitando la pantalla y estoy utilizando la web con un lector de pantalla.

¿Qué es un lector de pantalla?

Un lector de pantalla es una aplicación de software que interpreta lo que aparece en la pantalla (texto, imágenes, enlaces, etc.) y lo convierte en un formato que las personas con discapacidad visual pueden consumir e interactuar con él. Dos tercios de los usuarios de lectores de pantalla eligen el habla como salida del lector de pantalla, y un tercio de los usuarios de lectores de pantalla eligen el braille.

Los lectores de pantalla pueden utilizarse con programas como procesadores de texto, clientes de correo electrónico y navegadores web. Funcionan asignando el contenido y la interfaz de la aplicación a un árbol de accesibilidad que puede ser leído por el lector de pantalla. Algunos lectores de pantalla tienen que asignar manualmente programas específicos al árbolmientras que otros son más genéricos y deberían funcionar con la mayoría de los programas.

La accesibilidad tiene su origen en la UX

Debe asegurarse de que sus productos son inclusivos y utilizables para las personas con discapacidad. Un caso práctico de BBC iPlayer, por Henny Swan. Leer artículo →

El gráfico que muestra la popularidad de los lectores de pantalla de escritorio sitúa a JAWS en primer lugar, NVDA en segundo y VoiceOver en tercero.
Gráfico circular de la Encuesta de Lectores de Pantalla 2017, que muestra que JAWS, NVDA y VoiceOver son los lectores de pantalla más utilizados en el escritorio. (Vista previa ampliada)

En Windows, el lector de pantalla más popular es JAWS, con casi la mitad del mercado global de lectores de pantalla. Se trata de un software comercial que cuesta alrededor de mil dólares para la edición doméstica. Una alternativa de código abierto para Windows es NVDA, que es utilizado por algo menos de un tercio de los usuarios de lectores de pantalla en el escritorio.

Existen otras alternativas, como Microsoft Narrador, Acceso al sistema, Ojos de ventana y ZoomText (no es un lector de pantalla completa, sino un magnificador de pantalla con capacidad de lectura); la suma combinada de estos equivale a cerca del 6% del uso de lectores de pantalla. En Linux, Orca se incluye por defecto en varias distribuciones.

El lector de pantalla incluido en macOS, iOS y tvOS es VoiceOver. VoiceOver representa el 11,7% de los usuarios de lectores de pantalla en ordenadores de sobremesa y se eleva al 69% de los usuarios de lectores de pantalla en móviles. Los otros lectores de pantalla más importantes en el espacio móvil son Talkback en Android (29,5%) y Asistente de voz en Samsung (5,2%), que a su vez es basado en Talkback, pero con gestos adicionales.

Tabla que muestra la popularidad de los lectores de pantalla para móviles. El primero es VoiceOver, el segundo Talkback y el tercero Voice Assistant.
Popularidad de los lectores de pantalla para móviles: VoiceOver en primer lugar, Talkback en segundo, Voice Assistant en tercero. (Vista previa grande)

Tengo un MacBook y un iPhone, así que utilizaré VoiceOver y Safari para este artículo. Safari es el navegador recomendado para usar con VoiceOverya que ambos son mantenidos por Apple y deberían funcionar bien juntos. El uso de VoiceOver con un navegador diferente puede dar lugar a comportamientos inesperados.

Cómo activar y utilizar su lector de pantalla

Mis instrucciones son para VoiceOver, pero debería haber comandos equivalentes para el lector de pantalla de su elección.

VoiceOver en el escritorio

Si nunca has utilizado un lector de pantalla, puede ser una experiencia desalentadora. Es un gran choque cultural pasar a una experiencia sólo auditiva, y no saber cómo controlar la avalancha de ruido es desconcertante. Por eso, lo primero que querrás aprender es a apagarlo.

El atajo para desactivar VoiceOver es el mismo que para activarlo: + F5 ( es también conocido como el Cmd ). En los Macs más nuevos con barra táctil, el atajo es mantener pulsada la tecla de comando y pulsar tres veces el botón de Touch ID. ¿VozOver habla demasiado rápido? Abre VoiceOver Utility, pulsa la pestaña ‘Speech’ y ajusta la velocidad en consecuencia.

Una vez que domines la activación y desactivación, tendrás que aprender a utilizar la “tecla VoiceOver” (que en realidad son dos teclas pulsadas al mismo tiempo): Ctrl y (esta última tecla también se conoce como “Opción” o la Alt ). Con la tecla VO en combinación con otras teclas, puedes navegar por la web.

Por ejemplo, puedes utilizar VO + A para leer la página web desde la posición actual; en la práctica, esto significa mantener Ctrl + + A. Recordando lo que VO corresponde es confuso al principio, pero el VO La notación es por brevedad y coherencia. Es posible configurar el VO para ser otra cosa, así que tiene sentido tener una notación estándar que todos puedan seguir.

Puede utilizar VO y las teclas de flecha (VO + y VO + ) para recorrer cada elemento del DOM en secuencia. Cuando te encuentres con un enlace, puedes utilizar VO + Espacio para hacer clic en él – también utilizarás estas teclas para interactuar con los elementos del formulario.

¡Hurra! Ahora ya sabes lo suficiente sobre VoiceOver para navegar por la web.

VoiceOver en el móvil

El atajo de teclado del móvil/tableta para activar VoiceOver varía según el dispositivo, pero generalmente es un ‘triple clic’ en el botón de inicio (después de activar el acceso directo en los ajustes).

Se puede leer todo desde la posición actual con un Two-Finger Swipe Down y puedes seleccionar cada elemento del DOM en secuencia con un comando Swipe Right or Left.

¡Ahora sabes tanto de iOS VoiceOver como de escritorio!

Piensa en cómo utilizas la web como usuario vidente. ¿Lee cada palabra cuidadosamente, en secuencia, de arriba a abajo? No. Los humanos son perezosos por diseño y han aprendido a “escanear” las páginas en busca de información interesante lo más rápido posible.

Los usuarios de lectores de pantalla tienen esta misma necesidad de eficiencia, por lo que la mayoría navegará por la página según el tipo de contenido, por ejemplo, títulos, enlaces o controles de formularios. Una forma de hacerlo es abrir el menú de accesos directos con VO + U, navegue hasta el tipo de contenido que desee con el botón y teclas de flecha, y luego navegar a través de esos elementos con la ↑↓ llaves.

Captura de pantalla de la pantalla de VoiceOver tutoriasl 'Practicar la navegación de la página web'
(Vista previa grande)

Otra forma de hacerlo es activar la “Navegación rápida” (manteniendo pulsado junto con al mismo tiempo). Con la navegación rápida activada, puede seleccionar el tipo de contenido manteniendo pulsada la tecla flecha al lado o . En iOS, esto se hace con un Two-Finger Rotate gesto.

Captura de pantalla de la rotación en VoiceOver, actualmente en 'Headings'.
Configuración del tipo de elemento del rota usando los atajos de teclado. (Vista previa grande)

Una vez que haya seleccionado el tipo de contenido, puede saltar a través de cada elemento del rotor con el botón ↑↓ teclas (o Swipe Up or Down en iOS). Si te parece que es mucho lo que tienes que recordar, vale la pena que guardes en tus favoritos esta página tan útil Hoja de trucos de VoiceOver como referencia.

Una tercera forma de navegar a través de los tipos de contenido es utilizar los gestos del trackpad. Esto hace que la experiencia se acerque más a la forma de utilizar VoiceOver en iOS en un iPad/iPhone, lo que significa tener que recordar sólo un conjunto de comandos del lector de pantalla.

Captura de pantalla del tutorial de VoiceOver
(Vista previa grande)

Puedes practicar la navegación basada en gestos y muchas otras técnicas de VoiceOver en el programa de entrenamiento incorporado en OSX. Puede acceder a él a través de Preferencias del Sistema → Accesibilidad → VoiceOver → Abrir VoiceOver Training.

Después de completar el tutorial, ¡estaba ansioso por empezar!

Caso práctico 1: YouTube

Búsqueda en YouTube

Navegué hasta la página principal de YouTube en la barra de herramientas de Safari, tras lo cual VoiceOver me dijo que “entrara” en el contenido de la web con Ctrl + + Shift + . Pronto me acostumbraría a entrar en el contenido de la web, ya que el mismo mecanismo se aplica al contenido incrustado y a algunos controles de formulario.

Usando Quick Nav, pude navegar a través de los controles de formulario para saltar fácilmente a la sección de búsqueda en la parte superior de la página.

Captura de pantalla de la página de inicio de YouTube
Cuando se centra en el campo de búsqueda, VoiceOver anuncia: “Buscar, buscar campo de texto Buscar”. (Vista previa grande)

He buscado un contenido de calidad:

Captura de pantalla de
¿A quién no le gusta Impractical Jokers? (Vista previa grande)

Y navegué hasta el botón de búsqueda:

VoiceOver anuncia
VoiceOver anuncia “Pulse el botón de búsqueda”. (Vista previa grande)

Sin embargo, cuando he activado el botón con VO + Espaciono se ha anunciado nada.

Abrí los ojos y la búsqueda se había producido y la página se había llenado de resultados, pero no tenía forma de saberlo sólo por el audio.

Desconcertado, reproduje mis acciones con devtools abierto, y mantuve un ojo en la pestaña de red.

Como se sospechaba, YouTube está haciendo uso de una técnica de rendimiento llamada “renderización del lado del cliente”, lo que significa que JavaScript intercepta el envío del formulario y renderiza los resultados de la búsqueda en el lugar, para evitar tener que repintar toda la página. Si los resultados de la búsqueda se cargaran en una nueva página como un enlace normal, VoiceOver me habría anunciado la nueva página para que pudiera navegar.

Hay artículos enteros dedicados a la accesibilidad de las aplicaciones renderizadas por el cliente; en este caso, yo recomendaría que YouTube implementara un aria-live que anuncie cuando el envío de la búsqueda sea exitoso.

Sugerencia #1: Utilice aria-live para anunciar los cambios del lado del cliente en el DOM.

<div role="region" aria-live="polite" class="off-screen" id="search-status"></div>

<form id="search-form">
  <label>
    <span class="off-screen">Search for a video</span>
    <input type="text" />
  </label>
  <input type="submit" value="Search" />
</form>

<script>
  document.getElementById('search-form').addEventListener('submit', function (e) {
    e.preventDefault();
    ajaxSearchResults(); // not defined here, for brevity
    document.getElementById('search-status').textContent="Search submitted. Navigate to results below."; // announce to screen reader
  });
</script>

Ahora que había hecho trampa y sabía que había resultados de búsqueda que mirar, cerré los ojos y navegué hasta el primer vídeo de los resultados, cambiando al modo “encabezados” de Quick Nav y recorriendo los resultados desde allí.

Reproducir vídeo en YouTube

En cuanto se carga una página de vídeo de YouTube, el vídeo se reproduce automáticamente. Esto es algo que valoro en el uso diario, pero era una experiencia dolorosa cuando se mezclaba con VoiceOver hablando por encima. No pude encontrar la manera de desactivar la reproducción automática de los vídeos siguientes. Lo único que podía hacer era cargar el siguiente vídeo y pulsar rápidamente CTRL para detener los anuncios del lector de pantalla.

Consejo #2: Proporcione siempre una forma de suprimir la reproducción automática, y recuerde la elección del usuario.

El vídeo en sí es tratado como un “grupo” en el que tienes que entrar para interactuar. Puedo navegar por cada una de las opciones del reproductor de vídeo, lo que me ha sorprendido gratamente – ¡dudo que fuera así en los tiempos de Flash!

Sin embargo, me encontré con que algunos de los controles del reproductor no tenían ninguna etiqueta, por lo que “Modo cine” se leía simplemente como “botón”.

captura de pantalla del reproductor de YouTube
Centrándonos en el botón “Modo Cine”, no había ninguna etiqueta que indicara su finalidad. (Vista previa grande)

Consejo #3: Siempre etiquete sus controles de formulario.

Mientras que los usuarios de lectores de pantalla son predominantemente ciegos, alrededor del 20% están clasificados como “baja visión”, por lo que pueden ver parte de la página. Por lo tanto, un usuario de lector de pantalla puede apreciar la posibilidad de activar el “modo cine”.

Estos consejos no están enumerados por orden de importancia, pero si lo estuvieran, éste sería mi número uno:

Consejo nº 4: Los usuarios de lectores de pantalla deben tener paridad funcional con los usuarios videntes.

Al no etiquetar la opción “modo cine”, estamos excluyendo a los usuarios de lectores de pantalla de una función que podrían utilizar.

Dicho esto, hay casos en los que una función no lo hará ser aplicable a un lector de pantalla – por ejemplo, un gráfico de líneas SVG detallado que se leería como un galimatías de números sin contexto. En estos casos, podemos aplicar la función especial aria-hidden="true" al elemento para que los lectores de pantalla lo ignoren por completo. Tenga en cuenta que todavía tendríamos que proporcionar algún texto alternativo fuera de la pantalla o una tabla de datos como alternativa.

Consejo #5: Utilice aria-hidden para ocultar el contenido que no es aplicable a los usuarios de lectores de pantalla.

Me llevó mucho tiempo averiguar cómo ajustar la posición de reproducción para poder rebobinar algún contenido. Una vez que has “entrado” en el deslizador (VO + Shift + ), usted sostiene + ↑↓ para ajustar. A mí me parece poco intuitivo pero, de nuevo, no es la primera vez que Apple hace algún controvertidas decisiones de atajos de teclado.

Reproducción automática al final del vídeo de YouTube

Al final del video fui redirigido automáticamente a un nuevo video, lo cual fue confuso – no ocurrió ningún anuncio.

Captura de pantalla de la reproducción automática del vídeo de YouTube
Hay una señal visual al final del vídeo que indica que el siguiente vídeo comenzará en breve. Se proporciona un botón de cancelación, pero los usuarios pueden no activarlo a tiempo (¡si es que saben que existe!) (Vista previa grande)

Pronto aprendí a navegar hasta los controles de reproducción automática y a desactivarlos:

Desactivar la reproducción automática en vídeo
Desactivación de la reproducción automática en vídeo. (Vista previa grande)

Esto no impide que un vídeo se reproduzca automáticamente cuando cargo una página de vídeo, pero sí impide que esa página de vídeo se redirija automáticamente al siguiente vídeo.

Estudio de caso 2: BBC

Como las noticias son algo que se consume de forma pasiva y no mediante la búsqueda de algo específico, decidí navegar por BBC News a través de los títulos. Cabe destacar que no es necesario utilizar Quick Nav para ello: VoiceOver proporciona comandos de búsqueda de elementos que pueden ahorrar tiempo al usuario avanzado. En este caso, pude navegar por los títulos con el comando VO + + H llaves.

El primer epígrafe era el aviso de galleta, y el segundo epígrafe era un <h2> titulado “Enlaces de accesibilidad”. Debajo de ese segundo epígrafe, el primer enlace era un enlace “Saltar al contenido” que me permitía saltar todo el resto de la navegación.

El enlace
El enlace “Saltar al contenido” es accesible a través de la pestaña del teclado y/o la navegación del lector de pantalla. (Vista previa grande)

Los enlaces “Saltar al contenido” son muy útiles, y no sólo para los usuarios de lectores de pantalla; véase mi artículo anterior “Usé la web durante un día sólo con un teclado”.

Consejo nº 6: Proporcione enlaces de “salto al contenido” para sus usuarios de teclado y lectores de pantalla.

Navegar por los encabezados fue un buen enfoque: cada noticia tiene su propio encabezado, por lo que pude escuchar el titular antes de decidir si quería leer más sobre una historia determinada. Y como el propio titular estaba envuelto dentro de una etiqueta de anclaje, ni siquiera tenía que cambiar de modo de navegación cuando quería hacer clic; podía simplemente VO + Espacio para cargar mi corriente elección del artículo.

Los títulos también son enlaces en la BBC
Los títulos también son enlaces en la BBC. (Vista previa grande)

Mientras que el acceso directo a la página de inicio para saltar al contenido enlazaba muy bien con un #skip-to-content-link-target (que leía el titular de la noticia principal), el enlace para saltar a la página del artículo estaba roto. Enlazaba con un ID diferente (#page) que me llevaba a la página group que rodea el contenido del artículo, en lugar de leer el titular.

“Pulse visitado, enlace: Saltar al contenido, grupo” – no es el resultado más útil para saltar el enlace. (Vista previa grande)

En este punto, golpeé VO + A para que VoiceOver me lea todo el artículo.

Se las arregló bastante bien hasta que llegó a la inserción en Twitter, donde empezó a ser bastante verboso. En un momento dado, me leyó de forma poco útil “Link: 1068987739478130688”.

VoiceOver puede leer en voz alta enlaces largos sin contexto.
VoiceOver puede leer en voz alta enlaces largos sin contexto. (Vista previa grande)

Parece ser que esto se debe a un marcado ligeramente dudoso en la parte de la inserción del vídeo en el tweet:

Tenemos una etiqueta de anclaje, luego un div anidado, luego un img con un atributo <code>alt</code> con el valor:
Tenemos una etiqueta de anclaje, luego un div anidado divy luego una etiqueta img con un alt atributo con el valor: “Vídeo incrustado”. (Vista previa grande)

Parece que VoiceOver no lee el alt de la imagen anidada, y no hay ningún otro texto dentro del ancla, por lo que VoiceOver hace lo más útil que sabe: leer una parte de la propia URL.

Otros lectores de pantalla pueden funcionar bien con este marcado – su kilometraje puede variar. Pero una implementación más segura sería que la etiqueta de anclaje tuviera un aria-labelo algún texto oculto fuera de la pantalla, para llevar el texto alternativo. Ya que estamos aquí, probablemente cambiaría “Vídeo incrustado” por algo un poco más útil, por ejemplo “Vídeo incrustado: haga clic para reproducir”).

Los problemas con los enlaces no estaban ahí:

Un enlace simplemente dice
Un enlace simplemente dice “Enlace: 1,887”. (Vista previa grande)

Bajo el contenido principal del tuit, hay un botón de “me gusta” que hace las veces de contador de “me gusta”. Visualmente tiene sentido, pero desde la perspectiva de un lector de pantalla, no hay contexto aquí. Esta experiencia del lector de pantalla es mala por dos razones:

  1. No sé qué significa el “1,887”.
  2. No sé si al hacer clic en el enlace, me estará gustando el tuit.

Los usuarios de lectores de pantalla deberían recibir más contexto, por ejemplo, “A 1.887 usuarios les ha gustado este tuit. Haz clic para que te guste”. Esto podría lograrse con algún texto fuera de pantalla considerado:

<style>
  .off-screen {
    clip: rect(0 0 0 0);
    clip-path: inset(100%);
    height: 1px;
    overflow: hidden;
    position: absolute;
    white-space: nowrap;
    width: 1px;
  }
</style>

<a href="https://www.smashingmagazine.com/tweets/123/like">
  <span class="off-screen">1,887 users like this tweet. Click to like</span>
  <span aria-hidden="true">1,887</span>
</a>

Consejo nº 7: Asegúrese de que cada enlace tiene sentido cuando se lee de forma aislada.

He leído algunos artículos más en la BBC, incluido un artículo de “formato largo”.

Lectura de los artículos más largos

Mira la siguiente captura de pantalla de otro artículo de larga duración de la BBC – ¿cuántas imágenes diferentes se pueden ver, y cuál debe ser su alt atributos?

Captura de pantalla del artículo de la BBC que contiene el logotipo, la imagen de fondo y la imagen en primer plano (con leyenda).
Captura de pantalla del artículo de la BBC que contiene el logotipo, la imagen de fondo y la imagen en primer plano (con leyenda). (Vista previa grande)

En primer lugar, observemos la imagen en primer plano del lago Havasu en el centro de la fotografía. Tiene una leyenda debajo: “El lago Havasu se creó tras la finalización de la presa Parker en 1938, que retuvo el río Colorado”.

Es una buena práctica proporcionar una alt incluso si se proporciona un título. El alt debe describir la imagen, mientras que el pie de foto debe proporcionar el contexto. En este caso, el alt podría ser algo así como “Vista aérea del lago Havasu en un día soleado”.

Tenga en cuenta que no debemos anteponer el prefijo alt con “Imagen: “, o “Imagen de” o algo parecido. Los lectores de pantalla ya proporcionan ese contexto anunciando la palabra “imagen” antes de nuestro alt texto. Además, mantenga alt breve (menos de 16 palabras). Si un texto más largo alt se necesita un texto más largo, por ejemplo, si una imagen tiene mucho texto que necesita ser copiado, buscar en el longdesc atributo.

Consejo nº 8: Escriba de forma descriptiva pero eficaz alt textos.

Semánticamente, el ejemplo de la captura de pantalla debería marcarse con <figure> y <figcaption> elementos:

<figure>
  <img src="https://www.smashingmagazine.com/havasu.jpg" alt="Aerial view of Lake Havasu on a sunny day" />
  <figcaption>Lake Havasu was created after the completion of the Parker Dam in 1938, which held back the Colorado River</figcaption>
</figure>

Ahora veamos la imagen de fondo en esa captura de pantalla (la que transmite varios vasos y equipos). Por regla general, las imágenes de fondo o de presentación como éstas deben tener un alt vacío (alt=""), para que VoiceOver sepa explícitamente que no hay texto alternativo y no intente leerlo.

Tenga en cuenta que un alt="" NO es lo mismo que no tener alt lo cual es un gran error. Si un alt atributo es faltaLos lectores de pantalla leerán en su lugar los nombres de los archivos de imagen, que a menudo no son muy útiles.

captura de pantalla del artículo de la BBC
Mi lector de pantalla leyó ‘pushbutton-mr_sjdxzwy.jpg, image’ porque no se proporcionó el atributo `alt`. (Vista previa grande)

Consejo #9: No tengas miedo de usar vacíos alt para el contenido de presentación.

Caso práctico 3: Facebook

Me dirijo a Facebook ahora, y estaba teniendo síntomas de abstinencia desde antes, así que fui a buscar algo más Impractical Jokers.

Facebook lleva las cosas un paso o dos más allá que los otros sitios que he probado hasta ahora, y en lugar de un enlace “Saltar al contenido”, tenemos nada menos que dos desplegables que enlazan con páginas o secciones de páginas respectivamente.

Facebook ofrece un montón de atajos de teclado para saltar el enlace.
Facebook ofrece un montón de atajos de teclado para omitir enlaces. (Vista previa grande)

Facebook también define una serie de teclas como teclas de acceso directo que se pueden utilizar desde cualquier lugar de la página:

Atajos de teclado para desplazarse entre los elementos del feed de noticias, hacer nuevas publicaciones, etc.
Atajos de teclado para desplazarse entre los elementos de la fuente de noticias, hacer nuevas publicaciones, etc. (Vista previa grande)

He jugado con ellos y funcionan bastante bien con VoiceOver, una vez que sabes que están ahí. El único problema que veo es que son propietarios (no puedo esperar que estos mismos atajos funcionen fuera de Facebook), pero es bueno que Facebook se esfuerce en este sentido.

Aunque mi primera impresión de la accesibilidad de Facebook fue buena, pronto detecté pequeñas rarezas que dificultaban la navegación por el sitio.

Por ejemplo, me confundí mucho al intentar navegar por esta página a través de los encabezados:

El encabezado
El encabezado “Páginas que le gustan a esta página” (en la parte inferior derecha de la página) está enfocado, y es un “encabezado de nivel 3”. (Vista previa grande)

El primer epígrafe de la página es un epígrafe de nivel 3, escondido en la barra lateral. A éste le sigue inmediatamente un encabezamiento de nivel SEIS en la columna de contenido principal, que corresponde a un estado compartido por la página.

Rúbrica de nivel 6' en un estado compartido con la Página.
Nivel de encabezamiento 6′ en un estado compartido con la página. (Vista previa grande)

Esto se puede visualizar con el Plugin de desarrollo web para Chrome/Firefox.

h1 va a múltiples h6s, saltando h2/h3/h4/h5
h1 va a múltiples h6s, saltando h2, h3, h4, h5. (Vista previa grande)

Como regla general, es una buena idea tener títulos secuenciales con una diferencia no superior a 1. No es un problema si no lo hace, pero es ciertamente confuso llegar a él desde la perspectiva de un lector de pantalla y preocuparse de que se haya saltado accidentalmente alguna información importante porque ha saltado de un h1 a un h6.

Consejo nº 10: Valide la estructura de sus rúbricas.

Ahora, pasemos al meollo del sitio web: las publicaciones. En Facebook se trata de estar en contacto con la gente y ver lo que hacen. Pero vivimos en un mundo en el que alt texto es un concepto desconocido para la mayoría de los usuarios, así que ¿cómo traduce Facebook esos selfies engreídos y las fotos de perros a un público lector de pantalla?

Facebook tiene un Texto alternativo automático que utiliza la tecnología de reconocimiento de objetos para analizar qué (o quién) hay en una foto y generar una descripción textual de la misma. Entonces, ¿qué tan bien funciona?

Catedral de Cambridge
¿Cómo crees que le fue a esta imagen con el generador automático de texto alternativo? (Vista previa grande)

El alt texto para esta imagen era “La imagen puede contener: cielo, hierba y exterior”. Está muy lejos de reconocer “La catedral de Cambridge al atardecer”, pero sin duda es un paso en la dirección correcta.

Me impresionó increíblemente la precisión de algunas descripciones. Otra imagen que probé salió como “La imagen puede contener: 3 personas, incluyendo a John Smith, Jane Doe y Chris Ashton, gente sonriendo, primer plano e interior” – ¡muy descriptivo, y absolutamente correcto!

Pero me molesta que los memes y los chistes que se hacen virales en las redes sociales sean intrínsecamente inaccesibles; Facebook trata lo siguiente como “La imagen puede contener: pájaro y texto”, que aunque es cierto está muy lejos de la representación real.

Científicamente, un cuervo tiene 17 plumas primarias en las alas, las grandes al final del ala. Se llaman plumas de piñón. Un cuervo tiene 16. Por lo tanto, la diferencia entre un cuervo y una corona es sólo cuestión de un piñón.
Lamentablemente, Facebook alt no se extiende a las imágenes con texto. (Vista previa grande)

Por suerte, los usuarios pueden escribir sus propios alt texto si lo desean.

Caso práctico 4: Amazon

Algo que noté en Facebook, también sucede en Amazon. El botón de búsqueda aparece antes de el campo de entrada de la búsqueda en el DOM. Eso es a pesar de que el botón aparece después de el campo de entrada visualmente.

Captura de pantalla del inspector de Chrome contra el área de búsqueda de Amazon
La entrada de texto ‘nav-fill’ aparece más abajo en el DOM que el botón de búsqueda. (Vista previa grande)

Es probable que su página web tenga un orden lógico visualmente. ¿Qué pasaría si alguien moviera al azar partes de su página web, seguiría teniendo sentido?

Probablemente no. Eso es lo que puede ocurrir con la experiencia de tu lector de pantalla si no eres disciplinado a la hora de mantener la estructura del DOM sincronizada con tu diseño visual. A veces es más fácil mover el contenido con CSS, pero normalmente es mejor moverlo en el DOM.

Consejo #11: Haz que el orden del DOM coincida con el orden visual.

Por qué estos dos sitios de alto perfil deciden no adoptar esto directriz de buenas prácticas con su navegación de búsqueda me desconcierta. Sin embargo, el botón y el texto de entrada no están tan separados como para que su ordenación cause un gran problema de accesibilidad.

Encabezados en Amazon

Una vez más, al igual que Facebook, Amazon tiene un extraño orden de encabezados. Busqué a través de los encabezados y lo que más me confundió fue que el primer encabezado de la página era un nivel de encabezado 5 en la sección “Otros vendedores en Amazon”:

Captura de pantalla de la página de productos de Amazon con la superposición de VoiceOver
‘Primer título, nivel de título 5, Otros vendedores en Amazon’. (Vista previa grande)

Pensé que debía tratarse de un error del lector de pantalla, así que indagué en el código fuente de Amazon para comprobarlo:

captura de pantalla del código fuente
El h5 ‘Otros vendedores en Amazon’ aparece en la línea 7730 del código fuente de la página. Es el primer título de la página. (Vista previa grande)

Aparece el h1 de la página casi 10.000 líneas más abajo en el código fuente.

captura de pantalla del código fuente
El h1 de ‘Red Dead Redemption 2 PS4’ aparece en la línea 9054. (Vista previa grande)

Esto no sólo es pobre semánticamente y pobre para la accesibilidad, sino que también es pobre para el SEO. Un SEO pobre significa menos conversiones (ventas) – ¡algo que espero que Amazon tenga muy en cuenta!

Consejo #12: La accesibilidad y el SEO son dos caras de la misma moneda.

Mucho de lo que hacemos para mejorar la experiencia del lector de pantalla también mejorará el SEO. Títulos semánticamente válidos y detallados alt texto son excelentes para los rastreadores de los motores de búsqueda, lo que debería significar que su sitio se clasifica mejor en las búsquedas, lo que debería significar que atraerá a un público más amplio.

Si alguna vez tienes problemas para convencer a tu jefe de empresa de que es importante crear sitios accesibles, prueba a cambiar el punto de vista y señala las ventajas del SEO.

Varios

Es difícil condensar en un solo artículo todo un día de navegación y experiencias. He aquí algunos de los aspectos más destacados y los menos destacados de la jornada.

Notarás los sitios lentos

Los lectores de pantalla no pueden analizar la página y crear su árbol de accesibilidad hasta que el DOM se haya cargado. Los usuarios videntes pueden escanear una página mientras se está cargando, determinando rápidamente si vale la pena y pulsando el botón de retroceso en caso contrario. Los usuarios de lectores de pantalla no tienen más remedio que esperar a que se cargue el 100% de la página.

Captura de pantalla de un sitio web, con
87 por ciento cargado. No puedo navegar hasta que termine. (Vista previa grande)

Es interesante observar que, aunque hacer un sitio web eficaz beneficia a todos, es especialmente beneficioso para los usuarios de lectores de pantalla.

¿Estoy de acuerdo con qué?

Los controles de formularios como éste de NatWest pueden depender en gran medida de la cercanía espacial para denotar las relaciones. En la tierra de los lectores de pantalla, no hay cercanía espacial -sólo hermanos y padres- y es necesario hacer conjeturas para saber a qué estás marcando “sí”.

Captura de pantalla de un formulario web,
Navegando por los controles del formulario, me salté el aviso “Importante” y fui directamente a la casilla “Marque para confirmar”. (Vista previa grande)

Habría sabido lo que estaba aceptando si el descargo de responsabilidad hubiera formado parte de la etiqueta:

<label>
  Important: We can only hold details of one trip at a time.
  <input type="checkbox" /> Tick to confirm you have read this. *
</label>

Seguir el código es una pesadilla

He intentado leer un artículo técnico sobre Trucos CSS utilizando mi lector de pantallapero, sinceramente, me resultó totalmente imposible seguir la experiencia. Esto no es culpa del sitio web de Trucos de CSS – creo que es increíblemente complejo explicar ideas técnicas y ejemplos de código de una manera totalmente auditiva. ¿Cuántas veces has intentado depurar con un compañero y en lugar de explicarle la sintaxis exacta que necesitas, le das algo para que copie y pegue o lo rellenas tú mismo?

Mira qué fácil es leer este ejemplo de código del artículo:

Muestra de código de Trucos CSS
(Vista previa grande)

Pero aquí está la versión del lector de pantalla:

slash slash primero obtenemos la altura de la ventana gráfica y la multiplicamos por uno [pause] por ciento para obtener un valor para una unidad vh dejemos que vh sea igual a la altura interior de la ventana estrella [pause] cero cero uno barra diagonal entonces establecemos el valor en el [pause] vh custom property a la raíz del elemento del documento style set property [pause] vh corchete izquierdo vh corchete derecho px

Es totalmente ilegible en el paisaje sonoro. No solemos tener puntuación en los comentarios, y en este caso, una línea fluye sin problemas hacia la siguiente en la tierra del lector de pantalla. El texto en camelCase se lee como palabras separadas, como si hubieran sido escritas en una frase. Los puntos como window.innerHeight se ignoran y se tratan como “altura interior de la ventana”. El único “código” que se lee son las llaves del final.

El código se marca utilizando el estándar <pre> y <code> elementos HTML, así que no sé cómo se podría mejorar esto para los usuarios de lectores de pantalla. Los que perseveren en la codificación tienen mi total admiración.

Por lo demás, el único fallo que he podido encontrar es que el logotipo del sitio tenía un enlace a la página de inicio, pero no alt texto, por lo que lo único que escuché fue “enlace: barra”. Sólo en mi calidad de desarrollador web sé que si tienes un enlace con un atributo href="/" entonces te lleva a la página de inicio del sitio web, así que me imaginé para qué servía el enlace – pero “enlace: Página de inicio de Trucos CSS” habría sido mejor.

captura de pantalla mostrando el marcado del sitio web de CSS Tricks
(Vista previa grande)

VoiceOver en iOS es más complicado que en OSX

Usar VoiceOver en mi teléfono fue toda una experiencia.

Me propuse el reto de navegar por la aplicación de Twitter y escribir un Tweet, con la pantalla apagada y utilizando el teclado del móvil. Fue más difícil de lo esperado y Cometí varias faltas de ortografía.

Si yo fuera un usuario habitual de lectores de pantalla, creo que tendría que unirme a la El 41% de los usuarios de lectores de pantalla móviles que utilizan un teclado externo e invierten en un teclado Bluetooth. Clara Van Gerven llegó a la misma conclusión cuando utilizó un lector de pantalla durante cuarenta días en 2015..

Ha sido muy chulo activarlo Modo cortina de pantalla con un triple toque usando tres dedos. Esto apagaba la pantalla pero mantenía el teléfono desbloqueado, por lo que podía seguir navegando por mi teléfono sin que nadie lo viera. Esta función es esencial para los usuarios invidentes que, de otro modo, podrían dar sus contraseñas sin saberlo a la persona que les vigila por encima del hombro, pero también tiene la ventaja de ser genial para ahorrar batería.

Resumen

Esta fue una experiencia interesante y desafiante, y el artículo más difícil de escribir de la serie hasta ahora.

Me sorprendieron pequeñas cosas que son obvias cuando te paras a pensar en ellas. Por ejemplo, cuando se utiliza un lector de pantalla, ¡es casi imposible escuchar música al mismo tiempo que se navega por la web! Mantener el contexto de la página también puede ser difícil, sobre todo si te interrumpe una llamada telefónica o algo así; para cuando vuelves al lector de pantalla ya has perdido el rumbo.

Lo que más me ha llamado la atención es que hay un gran choque cultural al pasar a una experiencia sólo de audio. Es una forma totalmente diferente de navegar por la web y, como hay tanto contraste, es difícil saber siquiera qué constituye una “buena” o “mala” experiencia con el lector de pantalla. Puede ser bastante abrumador, y no es de extrañar que muchos desarrolladores eviten hacer pruebas con ellos.

Pero no deberíamos evitar hacerlo sólo porque sea difícil. Como dijo Charlie Owen en su charla, Querido desarrollador, la web no es sobre ti: Esto. Es. Tu. Trabajo. Aunque es divertido crear aplicaciones web bonitas y con capacidad de respuesta con las últimas tecnologías de vanguardia, no podemos elegir lo que queremos hacer y descuidar otras áreas. Nosotros somos los que estamos en la cara del carbón. Nosotros somos las únicas personas de la organización capaces de proporcionar una buena experiencia a estos usuarios. Lo que elijamos como prioridad para trabajar hoy puede significar la diferencia entre que una persona pueda utilizar nuestro sitio y que no pueda hacerlo.

Hagamos nuestro trabajo con responsabilidad, y hagamos la vida un poco más fácil para nosotros, con mi último consejo del artículo:

Consejo #13: Haz pruebas con un lector de pantalla, poco y a menudo.

Ya he hecho pruebas con lectores de pantalla en otras ocasiones, pero me resultaba muy difícil recordar el camino, lo que dificultó el día más de lo necesario. Me habría sentido mucho más cómodo utilizando un lector de pantalla durante el día si hubiera utilizado uno con regularidad de antemano, aunque fuera sólo unos minutos a la semana.

Prueba un poco, prueba a menudo e, idealmente, prueba en más de un lector de pantalla. Cada lector de pantalla es diferente y leerá el contenido de distintas maneras. No todos los lectores de pantalla leerán “23/10/18” como fecha; algunos leerán “dos tres barra uno cero barra uno ocho”. Conoce la diferencia entre los errores de la aplicación y las peculiaridades del lector de pantalla, exponiéndote a ambos.

¿Te ha gustado este artículo? Este es el tercero de una serie; lee cómo usé la web durante un día con JavaScript desactivado y cómo usé la web durante un día sólo con un teclado.

Publicaciones relacionadas

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Botón volver arriba
Cerrar
Cerrar