Usé la web por un día usando un lector de pantalla

Este artículo es parte de una serie en la que intento usar la web bajo varias restricciones, que representan un grupo demográfico determinado de usuarios. Espero elevar el perfil de las dificultades que enfrentan las personas reales, que son evitables si diseñamos y desarrollamos de una manera que sea comprensiva con sus necesidades. La última vez, navegué por la web durante un día solo con mi teclado. Esta vez, estoy evitando la pantalla y estoy usando 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 cosas en la pantalla (texto, imágenes, enlaces, etc.) y las convierte a un formato que las personas con discapacidad visual pueden consumir e interactuar. 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 braille.

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

En Windows, el lector de pantalla más popular es JAWS, con casi la mitad del mercado general de lectores de pantalla. Es un software comercial, que cuesta alrededor de mil dólares para la edición casera. Una alternativa de código abierto para Windows es NVDA, que es utilizada por poco menos de un tercio de todos los usuarios de lectores de pantalla en el escritorio.

Hay otras alternativas, que incluyen Microsoft Narrator , System Access , Window-Eyes y ZoomText (no un lector de pantalla completa, sino una lupa de pantalla que tiene capacidad de lectura); la suma combinada de estos equivale a aproximadamente el 6% del uso del lector de pantalla. En Linux, Orca se incluye de forma predeterminada 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 de escritorio y asciende al 69 % de los usuarios de lectores de pantalla en dispositivos móviles. Los otros lectores de pantalla importantes en el espacio móvil son Talkback en Android (29,5 %) y Voice Assistant en Samsung (5,2 %), que a su vez se basa en Talkback, pero con gestos adicionales.

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

Cómo habilitar y usar su lector de pantalla

Mis instrucciones son para VoiceOver, pero debe haber comandos equivalentes para el lector de pantalla que elija.

VoiceOver en el escritorio

Si nunca antes ha usado un lector de pantalla, puede ser una experiencia desalentadora. Es un gran choque cultural ir a una experiencia solo auditiva, y no saber cómo controlar la avalancha de ruido es desconcertante. Por esta razón, lo primero que querrás aprender es cómo apagarlo.

El atajo para desactivar VoiceOver es el mismo que el atajo para activarlo: ⌘ + F5 ( ⌘ también se conoce como la tecla Cmd ). En las Mac más nuevas con barra táctil, el atajo es mantener presionada la tecla de comando y presionar tres veces el botón Touch ID. ¿VoiceOver habla demasiado rápido? Abra VoiceOver Utility, presione la pestaña 'Voz' y ajuste la velocidad en consecuencia.

Una vez que haya dominado cómo encenderlo y apagarlo, deberá aprender a usar la "tecla VoiceOver" (que en realidad son dos teclas presionadas al mismo tiempo): Ctrl y ⌥ (la última tecla también se conoce como "Opción ” o la tecla Alt ). Usando la tecla VO en combinación con otras teclas, puede navegar por la web.

Por ejemplo, puede usar VO + A para leer la página web desde la posición actual; en la práctica, esto significa mantener Ctrl + ⌥ + A . Recordar a qué corresponde VO es confuso al principio, pero la notación VO es por brevedad y consistencia. Es posible configurar la tecla VO para que sea otra cosa, por lo que tiene sentido tener una notación estándar que todos puedan seguir.

Puede usar VO y las teclas de flecha ( VO + → y VO + ← ) para recorrer cada elemento en el DOM en secuencia. Cuando encuentre un enlace, puede usar VO + Espacio para hacer clic en él; también usará estas teclas para interactuar con los elementos del formulario.

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

VoiceOver en el móvil

El atajo móvil/tableta para activar VoiceOver varía según el dispositivo, pero generalmente es un 'tres clics' en el botón de inicio (después de habilitar el atajo en la configuración).

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

¡Ahora sabe tanto sobre iOS VoiceOver como sobre el escritorio!

Navegación por tipo de contenido

Piense en cómo usa la web como usuario vidente. ¿Lees cada palabra cuidadosamente, en secuencia, de arriba a abajo? No. Los humanos son perezosos por diseño y han aprendido a 'escanear' 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 por tipo de contenido, por ejemplo, encabezados, enlaces o controles de formulario. Una forma de hacerlo es abrir el menú de accesos directos con VO + U , navegar hasta el tipo de contenido que desee con las teclas de flecha ← y → , luego navegar a través de esos elementos con las teclas ↑↓ .

Otra forma de hacer esto es habilitar 'Quick Nav' (manteniendo presionado ← junto con → al mismo tiempo). Con Quick Nav habilitado, puede seleccionar el tipo de contenido manteniendo presionada la flecha ↑ junto a ← o → . En iOS, esto se hace con un gesto Two-Finger Rotate .

Una vez que haya seleccionado su tipo de contenido, puede omitir cada elemento del rotor con las teclas ↑↓ (o Swipe Up or Down en iOS). Si parece mucho para recordar, vale la pena marcar esta súper práctica hoja de trucos de VoiceOver como referencia.

Una tercera forma de navegar a través de los tipos de contenido es usar gestos del trackpad. Esto acerca la experiencia a la forma en que podría usar VoiceOver en iOS en un iPad/iPhone, lo que significa tener que recordar solo un conjunto de comandos del lector de pantalla.

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

¡Después de completar el tutorial, tenía muchas ganas de empezar!

Estudio de caso 1: YouTube

Buscando en YouTube

Navegué a la página de inicio de YouTube en la barra de herramientas de Safari, donde VoiceOver me dijo que "ingresara" al contenido web con Ctrl + ⌥ + Shift + ↓ . Pronto me acostumbraría a ingresar al contenido web, ya que el mismo mecanismo se aplica al contenido incrustado y 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.

Busqué algún contenido de calidad:

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

Sin embargo, cuando activé el botón con VO + Espacio , no se anunció nada.

Abrí los ojos y la búsqueda había ocurrido y la página se había llenado con resultados, pero no tenía forma de saberlo solo a través del audio.

Desconcertado, reproduje mis acciones con devtools abierto y vigilé la pestaña de red.

Como se sospechaba, YouTube está haciendo uso de una técnica de rendimiento llamada "representación del lado del cliente", lo que significa que JavaScript intercepta el envío del formulario y presenta los resultados de la búsqueda en el lugar, para evitar tener que volver a pintar toda la página. Si los resultados de la búsqueda se hubieran cargado en una nueva página como un enlace normal, VoiceOver habría anunciado la nueva página para que yo navegara.

Hay artículos completos dedicados a la accesibilidad para aplicaciones renderizadas por el cliente; en este caso, recomendaría que YouTube implemente una región aria-live que anuncie cuando el envío de la búsqueda sea exitoso.

Sugerencia n.º 1: use regiones aria-live para anunciar cambios del lado del cliente en el DOM.

 <div role="region" aria-live="polite" class="off-screen"></div> <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 para mirar, cerré los ojos y navegué hasta el primer video de los resultados, cambiando al modo de "títulos" de Quick Nav y luego recorriendo los resultados desde allí.

Reproducción de video en YouTube

Tan pronto como carga una página de video de YouTube, el video se reproduce automáticamente. Esto es algo que valoro en el uso diario, pero fue una experiencia dolorosa cuando se mezcló con VoiceOver hablando sobre él. No pude encontrar una manera de deshabilitar la reproducción automática para videos posteriores. Todo lo que realmente podía hacer era cargar mi próximo video y rápidamente presionar CTRL para detener los anuncios del lector de pantalla.

Sugerencia n.º 2: proporcione siempre una forma de suprimir la reproducción automática y recuerde la elección del usuario.

El video en sí se trata como un "grupo" en el que debe ingresar para interactuar. Podía navegar por cada una de las opciones en el reproductor de video, lo que me sorprendió gratamente. ¡Dudo que ese fuera el caso en los días de Flash!

Sin embargo, descubrí que algunos de los controles del reproductor no tenían etiquetas, por lo que 'Modo cine' simplemente se leía como "botón".

Consejo #3: Siempre etiquete sus controles de formulario.

Mientras que los usuarios de lectores de pantalla son predominantemente ciegos, alrededor del 20% se clasifican como "baja visión", por lo que pueden ver parte de la página. Por lo tanto, un usuario de lector de pantalla aún puede apreciar poder activar el "Modo cine".

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

Consejo #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 de otro modo podrían usar.

Dicho esto, hay casos en los que una característica no 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 casos como estos, podemos aplicar el atributo 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 o tabla de datos fuera de la pantalla como respaldo.

Consejo n.º 5: use aria-hidden para ocultar contenido que no se aplica a los usuarios de lectores de pantalla.

Me llevó mucho tiempo descubrir cómo ajustar la posición de reproducción para poder rebobinar parte del contenido. Una vez que haya "entrado" en el control deslizante ( VO + Shift + ↓ ), mantenga presionado ⌥ + ↑↓ para ajustar. Me parece poco intuitivo, pero, de nuevo, no es la primera vez que Apple toma decisiones controvertidas sobre atajos de teclado.

Reproducción automática al final del video de YouTube

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

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

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

Estudio de caso 2: BBC

Como las noticias se consumen pasivamente en lugar de buscar algo específico, decidí navegar por BBC News por encabezados. Vale la pena señalar que no necesita usar Quick Nav para esto: VoiceOver proporciona comandos de búsqueda de elementos que pueden ahorrar tiempo para el usuario avanzado. En este caso, podría navegar por los encabezados con las teclas VO + ⌘ + H.

El primer encabezado era el aviso de cookies y el segundo encabezado era un <h2> titulado 'Enlaces de accesibilidad'. Debajo de ese segundo encabezado, el primer enlace era un enlace "Saltar al contenido" que me permitió saltarme toda la otra navegación.

Los enlaces 'Saltar al contenido' son muy útiles, y no solo para los usuarios de lectores de pantalla; consulte mi artículo anterior "Usé la web por un día con solo un teclado".

Sugerencia n.º 6: Proporcione enlaces para "saltar al contenido" para los usuarios de su teclado y lectores de pantalla.

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

Mientras que el acceso directo para saltar al contenido de la página de inicio se vinculaba muy bien con un ancla #skip-to-content-link-target (que luego leía el titular de la noticia principal), el enlace para saltar la página del artículo estaba roto. Se vinculó a una ID diferente ( #page ) que me llevó al group que rodea el contenido del artículo, en lugar de leer el título.

En este punto, presiono VO + A para que VoiceOver me lea el artículo completo.

Se las arregló bastante bien hasta que llegó a la inserción de Twitter, donde comenzó a volverse bastante detallado. En un momento, se leyó inútilmente "Enlace: 1068987739478130688".

Esto parece deberse a un marcado ligeramente dudoso en la parte incrustada del video del tweet:

Parece que VoiceOver no lee el atributo alt de la imagen anidada y no hay otro texto dentro del ancla, por lo que VoiceOver hace lo más útil que sabe hacer: 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 una etiqueta aria-label , o algún texto oculto visualmente fuera de la pantalla, para llevar el texto alternativo. Mientras estemos aquí, probablemente cambiaría "Video incrustado" a algo un poco más útil, por ejemplo, "Video incrustado: haga clic para reproducir").

Los problemas de enlace no estaban allí:

Debajo del contenido principal del tweet, hay un botón de 'me gusta' que se duplica como un contador de 'me gusta'. Visualmente tiene sentido, pero desde la perspectiva del lector de pantalla, no hay contexto aquí. Esta experiencia con el 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 gustará el tweet.

A los usuarios de lectores de pantalla se les debe dar más contexto, por ejemplo, “A 1.887 usuarios les gustó este tweet. Haz clic para dar me gusta”. Esto podría lograrse con un texto considerado fuera de la pantalla:

 <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="/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 #7: Asegúrese de que cada enlace tenga sentido cuando se lea de forma aislada.

Leí algunos artículos más en la BBC, incluido un artículo de 'formato largo'.

Leer los artículos más largos

Mire la siguiente captura de pantalla de otro artículo de formato largo de la BBC: ¿cuántas imágenes diferentes puede ver y cuáles deberían ser sus atributos alt ?

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

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

Tenga en cuenta que no debemos prefijar nuestro texto alt con "Imagen:", o "Imagen de" ni nada por el estilo. Los lectores de pantalla ya brindan ese contexto al anunciar la palabra "imagen" antes de nuestro texto alt . Además, mantenga el texto alt corto (menos de 16 palabras). Si se necesita un texto alt más largo, por ejemplo, una imagen tiene mucho texto que necesita copiarse, busque en el longdesc .

Consejo #8: Escribe textos alt descriptivos pero eficientes.

Semánticamente, el ejemplo de la captura de pantalla debe marcarse con los elementos <figure> y <figcaption> :

 <figure> <img src="/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 muestra varios vasos y equipos). Como regla general, las imágenes de fondo o de presentación como estas deben tener un atributo alt vacío ( alt="" ), de modo que VoiceOver sepa explícitamente que no hay texto alternativo y no intente leerlo.

Tenga en cuenta que un alt="" vacío NO es lo mismo que no tener ningún atributo alt , lo cual es un gran no-no. Si falta un atributo alt , los lectores de pantalla leerán los nombres de los archivos de las imágenes, ¡lo que a menudo no es muy útil!

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

Estudio de caso 3: Facebook

Me dirigí a Facebook ahora, y estaba teniendo síntomas de abstinencia desde antes, así que fui a buscar más Jokers poco prácticos.

Facebook lleva las cosas uno o dos pasos más allá que los otros sitios que he probado hasta ahora, y en lugar de un enlace 'Saltar al contenido', tenemos no menos de dos menús desplegables que enlazan a páginas o secciones de páginas respectivamente.

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

Jugué con estos, 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 accesos directos funcionen fuera de Facebook), pero es bueno que Facebook se esfuerce mucho aquí.

Si bien mi primera impresión de la accesibilidad de Facebook fue buena, pronto descubrí pequeñas rarezas que dificultaban la navegación por el sitio.

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

El primer encabezado de la página es un encabezado de nivel 3, escondido en la barra lateral. A esto le sigue inmediatamente el nivel de encabezado SEIS en la columna de contenido principal, que corresponde a un estado compartido por la página.

Esto se puede visualizar con el complemento Web Developer para Chrome/Firefox.

Como regla general, es una buena idea tener encabezados secuenciales con una diferencia no superior a 1. No es un factor decisivo si no lo hace, pero sin duda es confuso llegar a él desde la perspectiva del lector de pantalla y preocuparse de que Accidentalmente omití información importante porque saltaste de h1 a h6 .

Consejo #10: Valide su estructura de encabezado.

Ahora, en la carne del sitio web: las publicaciones. Facebook se trata de mantenerse en contacto con las personas y ver lo que están haciendo. Pero vivimos en un mundo donde el texto alt es un concepto desconocido para la mayoría de los usuarios, así que, ¿cómo traduce Facebook esos selfies presumidos y fotos de perros a una audiencia de lectores de pantalla?

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

El texto alt de esta imagen era "La imagen puede contener: cielo, césped y exterior". Está muy lejos de reconocer la "Catedral de Cambridge al anochecer", pero definitivamente es un paso en la dirección correcta.

Quedé increíblemente impresionado con la precisión de algunas descripciones. Otra imagen que probé salió como "La imagen puede contener: 3 personas, incluidos John Smith, Jane Doe y Chris Ashton, personas sonriendo, primer plano e interior", muy descriptivo y absolutamente correcto.

Pero me molesta que los memes y las bromas que se vuelven virales en las redes sociales sean intrínsecamente inaccesibles; Facebook trata lo siguiente como "La imagen puede contener: pájaro y texto", lo que, si bien es cierto, está muy lejos de la descripción real.

Afortunadamente, los usuarios pueden escribir su propio texto alt si lo desean.

Estudio de caso 4: Amazonas

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

Es probable que su sitio web esté en un orden lógico visualmente. ¿Qué pasaría si alguien moviera aleatoriamente partes de su página web? ¿Seguiría teniendo sentido?

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

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

Por qué estos dos sitios de alto perfil eligen no adoptar esta guía de mejores 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 orden provoque un gran problema de accesibilidad.

Encabezados en Amazon

Nuevamente, al igual que Facebook, Amazon tiene un orden de encabezados extraño. Busqué a través de encabezados y estaba muy confundido porque el primer encabezado en la página era un encabezado de nivel 5 en la sección "Otros vendedores en Amazon":

Pensé que esto debía ser un error con el lector de pantalla, así que busqué en el código fuente de Amazon para verificar:

El h1 de la página aparece casi 10.000 líneas hacia abajo en el código fuente.

No solo es pobre semánticamente y pobre para la accesibilidad, sino que también es pobre para el SEO. Un SEO deficiente significa menos conversiones (ventas), ¡algo que espero que Amazon esté muy al tanto!

Consejo #12: Accesibilidad y 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. Los encabezados semánticamente válidos y el texto alt detallado son excelentes para los rastreadores de los motores de búsqueda, lo que debería significar que su sitio ocupa un lugar más alto en la búsqueda, lo que debería significar que atraerá a una audiencia más amplia.

Si alguna vez tiene dificultades para convencer a su gerente comercial de que la creación de sitios accesibles es importante, intente un ángulo diferente y señale los beneficios de SEO en su lugar.

Diverso

Es difícil condensar el valor de un día de navegación y experiencias en un solo artículo. Aquí hay algunos aspectos destacados y aspectos negativos que hicieron el corte.

Notarás los sitios lentos

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

Es interesante notar que si bien 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 formulario como este de NatWest pueden depender en gran medida de la cercanía espacial para indicar relaciones. En la tierra de los lectores de pantalla, no hay cercanía espacial, solo hermanos y padres, y se requieren conjeturas para saber a qué está marcando 'sí'.

Habría sabido lo que estaba aceptando si el descargo de responsabilidad hubiera sido 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

Intenté leer un artículo técnico sobre CSS Tricks usando mi lector de pantalla, pero, sinceramente, encontré que la experiencia era totalmente imposible de seguir. Esto no es culpa del sitio web de CSS Tricks; creo que es increíblemente complejo explicar ideas técnicas y ejemplos de código de una manera completamente auditiva. ¿Cuántas veces ha intentado depurar con un compañero y, en lugar de explicar la sintaxis exacta que necesita, le da algo para copiar y pegar o lo completa usted mismo?

Mira con qué facilidad puedes leer este ejemplo de código del artículo:

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

barra barra barra primero obtenemos la altura de la ventana gráfica y la multiplicamos por uno [pausa] por ciento para obtener un valor para una unidad vh deje que vh sea igual a la altura interior de la ventana estrella [pausa] cero cero una barra barra barra luego establecemos el valor en la [pausa ] propiedad personalizada vh a la raíz del documento propiedad de conjunto de estilo de elemento de documento de documento [pausa] vh dólar llave izquierda vh llave derecha px

Es totalmente ilegible en el paisaje sonoro. Tendemos a no tener puntuación en los comentarios y, en este caso, una línea fluye sin problemas a la siguiente en el área del lector de pantalla. El texto camelCase se lee como palabras separadas como si hubieran sido escritas en una oración. Los períodos como window.innerHeight se ignoran y se tratan como "altura interior de la ventana". El único 'código' que se lee son las llaves al final.

El código está marcado con elementos HTML estándar <pre> y <code> , por lo que no sé cómo podría mejorarse para los usuarios de lectores de pantalla. Cualquiera que persevere con la codificación tiene mi total admiración.

De lo contrario, la única falla que pude encontrar fue que el logotipo del sitio tenía un enlace a la página de inicio, pero no alt text, por lo que todo lo que escuché fue "enlace: barra oblicua". Solo 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 descubrí para qué era el enlace, pero "enlace: trucos CSS página de inicio” hubiera sido mejor!

VoiceOver en iOS es más complicado que OSX

¡Usar VoiceOver en mi teléfono fue una experiencia!

Me di el reto de navegar por la aplicación de Twitter y escribir un Tweet, con la pantalla apagada y usando el teclado del móvil. Fue más difícil de lo esperado y cometí una serie de errores ortográficos.

Si yo fuera un usuario habitual de lectores de pantalla, creo que tendría que unirme al 41 % de 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.

Fue genial activar el modo Cortina de pantalla con un triple toque con tres dedos. Esto apagó la pantalla pero mantuvo el teléfono desbloqueado, por lo que pude continuar navegando en mi teléfono sin que nadie mirara. Esta función es esencial para los usuarios ciegos que, de lo contrario, podrían estar dando sus contraseñas sin saberlo a la persona que vigila por encima del hombro, pero también tiene el beneficio adicional de ser excelente 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 las 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, especialmente si te interrumpe una llamada telefónica o algo así; para cuando regrese al lector de pantalla, habrá perdido su lugar.

Mi mayor conclusión es que hay un gran impacto cultural al ir a una experiencia de solo audio. Es una forma totalmente diferente de navegar por la web, y debido a que existe tal contraste, es difícil incluso saber qué constituye una experiencia de lector de pantalla 'buena' o 'mala'. Puede ser bastante abrumador, y no es de extrañar que muchos desarrolladores eviten probarlos.

Pero no debemos evitar hacerlo solo porque es difícil. Como dijo Charlie Owen en su charla, Estimado desarrollador, la Web no se trata de usted : Esto. Es. Tu. trabajo 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.

Did you enjoy this article? This was the third one in a series; read how I Used The Web For A Day With JavaScript Turned Off and how I Used The Web For A Day With Just A Keyboard.