Accesibilidad para desarrolladores web

Si mejoras la accesibilidad, tu sitio será más útil para todos.

Addy Osmani

Sugerencia: Toma Aprende sobre accesibilidad, un curso perdurable sobre accesibilidad y una referencia para mejorar tu desarrollo web.

Es importante crear sitios que sean inclusivos y accesibles para todos. Existen al menos seis áreas clave de discapacidad que puedes optimizar: visual, auditiva, movilidad, cognición, voz y neural. Muchas herramientas y recursos pueden ayudar aquí, incluso si eres nuevo en la accesibilidad web.

Más de mil millones de personas viven con alguna forma de discapacidad.

Para que sean accesibles, los sitios deben funcionar en varios dispositivos con diferentes tamaños de pantalla y diferentes tipos de entrada, como lectores de pantalla. Además, los sitios deben ser utilizables por un grupo más amplio de usuarios, incluidos aquellos con discapacidades.

Estas son algunas discapacidades que pueden tener los usuarios:

Vision	Audición	Movilidad
Visión reducida Ceguera Daltonismo Cataratas Brillo solar	Personas con hipoacusia Sordera Ruido Infección del oído	Lesión en la médula espinal Destreza limitada Manos ocupadas
Cognitivos	Voz	Neurona
discapacidad de aprendizaje Somnolencia o distracción Migraña Autismo Convulsión	Ruido ambiental Dolor de garganta Imedimento del habla No se puede hablar	Depresión TEPT Trastorno bipolar Ansiedad

Los problemas visuales abarcan desde la incapacidad para distinguir los colores hasta la ausencia de visión.

• Asegúrate de que el contenido de texto cumpla con un umbral de proporción de contraste mínimo.
• Evita comunicar información usando solo color y asegúrate de que se pueda resizable de todo el texto.
• Asegúrate de que todos los componentes de la interfaz de usuario se puedan usar con tecnologías de accesibilidad, como lectores de pantalla, lupas y pantallas braille. Esto implica garantizar que los componentes de la IU estén marcados de manera que las APIs de accesibilidad puedan determinar de manera programática el role, state, value y title de cualquier elemento.

Nota: La función de inspección de elementos en el navegador muestra información sobre las propiedades de CSS que incluye una verificación rápida de la proporción de contraste de color.

Vivo personalmente con problemas de visión y, a menudo, me centro en los sitios, las Herramientas para desarrolladores y la terminal. Si bien la compatibilidad con zoom casi nunca es una prioridad en las listas de tareas de los desarrolladores, puede marcar una gran diferencia para usuarios como yo.

Problemas de audición significan que un usuario puede tener problemas para escuchar el sonido que se emite desde una página.

• Proporciona alternativas de texto para todo el contenido que no sea estrictamente texto.
• Comprueba que los componentes de la IU aún funcionen sin sonido.

Los problemas de movilidad pueden incluir la imposibilidad de operar un mouse, un teclado o una pantalla táctil.

• Haz que el contenido de tus componentes de la IU sea accesible funcionalmente desde un teclado para cualquier acción que, de otro modo, se usaría con un mouse.
• Asegúrate de que las páginas estén marcadas correctamente para tecnologías de accesibilidad, incluidos los lectores de pantalla, el software de control por voz y los controles de interruptores físicos, que suelen usar las mismas APIs.

Los problemas cognitivos implican que un usuario puede necesitar tecnologías de accesibilidad para ayudarlo a leer texto, por lo que es importante asegurarse de que existan alternativas de texto.

• Ten cuidado cuando uses animaciones. Evita los videos y las animaciones que se repitan o flash, lo que puede causar problemas para algunos usuarios.

  La consulta de medios de CSS prefers-reduced-motion te permite limitar las animaciones y los videos de reproducción automática para los usuarios que prefieren el movimiento reducido:

  /*
  If the user expresses a preference for reduced motion, don't use animations on buttons.
  */
  @media (prefers-reduced-motion: reduce) {
    button {
      animation: none;
    }
  }
  

• Evita las interacciones basadas en el tiempo.

Esto puede parecer muchas bases por tratar, pero analizaremos el proceso para evaluar y, luego, mejorar la accesibilidad de tus componentes de la IU.

Para obtener asistencia visual adicional, el equipo de accesibilidad de GOV.UK creó una serie de pósteres digitales de accesibilidad que puedes y no debes hacer, que puedes usar para compartir las prácticas recomendadas con tu equipo.

Seis pósteres que enumeran las prácticas recomendadas de accesibilidad. Lee el texto completo.

Cómo medir la accesibilidad de los componentes de la IU

Cuando audites los componentes de la interfaz de usuario de tu página para evaluar la accesibilidad, pregúntate lo siguiente:

• ¿Se puede usar el componente de IU solo con el teclado?

  ¿El componente administra el enfoque y evita las trampas de enfoque? ¿Puede responder a los eventos del teclado apropiados?

• ¿Se puede usar el componente de IU con un lector de pantalla?

  ¿Proporcionaste alternativas de texto para la información presentada visualmente? ¿Agregaste información semántica con ARIA?

• ¿El componente de la IU puede funcionar sin sonido?

  Apaga las bocinas y revisa tus casos de uso.

• ¿Tu componente de IU puede funcionar sin color?

  Asegúrate de que alguien que no pueda ver los colores pueda usar tu componente de IU. Una herramienta útil para simular el daltonismo es una extensión de Chrome llamada Colorblindly. (Prueba las cuatro formas de simulación de daltonismo disponibles). Es posible que también te interese la extensión Daltonize, que es igualmente útil.

• ¿El componente de la IU puede funcionar con el modo de contraste alto habilitado?

  Todos los sistemas operativos modernos admiten un modo de contraste alto. La extensión de Chrome alto contraste puede ayudarte en este caso.

Los controles estandarizados (como <button> y <select>) tienen accesibilidad integrada en el navegador. Son enfocables con la tecla Tab; responden a eventos del teclado (como Enter, Space y las teclas de flecha) y tienen funciones, estados y propiedades semánticos que usan las herramientas de accesibilidad. Su estilo predeterminado también debe cumplir con los requisitos de accesibilidad enumerados.

Los componentes de IU personalizados (excepto los que extienden los elementos estándar como <button>) no tienen capacidades integradas, incluida la accesibilidad, por lo que debes proporcionarla. Un buen punto de partida cuando implementas la accesibilidad es comparar tu componente con un elemento estándar análogo (o una combinación de varios elementos estándar, según la complejidad del componente).

La mayoría de las herramientas para desarrolladores de navegadores admiten la inspección del árbol de accesibilidad de una página. En las Herramientas para desarrolladores de Chrome, esta opción se encuentra disponible en la pestaña Accesibilidad del panel Elementos.

Firefox también tiene un panel de Accesibilidad.

Safari muestra la información de accesibilidad en la pestaña Nodo del panel Elementos.

La siguiente es una lista de preguntas que puedes hacerte cuando intentas hacer que los componentes de la interfaz de usuario sean más accesibles.

Mejora el enfoque del teclado

Lo ideal es que puedas acceder a todas las funcionalidades del componente de IU con un teclado. Cuando diseñes la experiencia del usuario, piensa en cómo usarías tu elemento solo con el teclado y piensa en un conjunto coherente de interacciones de teclado.

Primero, asegúrate de tener un objetivo de enfoque razonable para cada componente. Por ejemplo, un componente complejo, como un menú, puede ser un objetivo de enfoque en una página, pero luego debe administrar el enfoque dentro de sí mismo para que siempre se enfoque el elemento de menú activo.

Cómo administrar el enfoque dentro de un elemento complejo.

Cómo usar tabindex

Puedes agregar el foco del teclado para elementos y componentes de la IU con el atributo tabindex. Los usuarios de solo teclado y de tecnología de accesibilidad deben poder colocar el enfoque del teclado en los elementos para interactuar con ellos.

Los elementos interactivos integrados (como <button>) son enfocables de manera implícita, por lo que no necesitan un atributo tabindex, a menos que debas cambiar su posición en el orden de tabulación.

Existen tres tipos de valores tabindex:

• tabindex="0" es el más común y coloca el elemento en el orden natural de pestañas (definido por el orden del DOM).
• Un valor tabindex mayor que 0 coloca el elemento en un orden de tabulación manual. Todos los elementos de la página con un valor de tabindex positivo se visitan en orden numérico, antes de los elementos en el orden natural de tabulación.
• Un valor tabindex igual a -1 hace que el elemento se pueda enfocar de manera programática, pero no en el orden de tabulación.

Para los componentes de IU personalizados, usa siempre valores tabindex de 0 o -1, ya que no podrás determinar el orden de los elementos en una página determinada con anticipación. Un valor tabindex de -1 es particularmente útil para administrar el enfoque en componentes complejos.

Asegúrate de que el enfoque esté siempre visible, ya sea con el estilo predeterminado de anillo de enfoque o aplicando un estilo de enfoque personalizado distinguible. Recuerda no atrapar a los usuarios que usan el teclado: deberían poder alejar el enfoque de un elemento usando solo el teclado.

Nota: Es posible que también te interesen los enfoques itinerantes tabindex o aria-activedescendant, como se describe en MDN.

Cómo usar el enfoque automático

El atributo de enfoque automático de HTML permite que un autor especifique que un elemento en particular debe enfocarse automáticamente cuando se carga la página. autofocus ya es compatible con todos los controles de formularios web, incluidos los botones. Para enfocar elementos de forma automática en tus propios componentes de IU personalizados, llama al método focus(), que es compatible con todos los elementos HTML que pueden enfocarse (por ejemplo, document.querySelector('myButton').focus()).

Agregar interacción con el teclado

Una vez que tu componente de IU pueda enfocarse, brinda una buena historia de interacción con el teclado cuando se enfoque un componente controlando los eventos de teclado adecuados. Por ejemplo, permite que el usuario use las teclas de flecha para seleccionar las opciones del menú y Space o Enter para activar los botones. La guía de patrones de diseño de ARIA proporciona orientación aquí.

Por último, asegúrate de que las combinaciones de teclas sean detectables. Una práctica común es tener una leyenda de combinación de teclas (texto en pantalla) para informar al usuario que existen combinaciones de teclas. Por ejemplo, “¿Presiona ? para los atajos del teclado". Como alternativa, se puede usar una sugerencia de este tipo para informar al usuario sobre un atajo.

No se puede sobrestimar la importancia de gestionar el enfoque. Un ejemplo importante es un panel lateral de navegación. Si agregas un componente de IU a la página, deberás dirigir el enfoque a un elemento dentro de ella. De lo contrario, es posible que los usuarios deban avanzar por toda la página para llegar allí. Esta puede ser una experiencia frustrante, así que asegúrate de probar el enfoque para todos los componentes navegables del teclado de tu página.

Sugerencia: Puedes usar Puppeteer para automatizar la ejecución de pruebas de accesibilidad del teclado y activar o desactivar los estados de la IU. WalkMe Engineering tiene una excelente guía sobre esto, que te recomiendo leer.

// Example for expanding and collapsing a category with the Space key
const category = await page.$(`.category`);

// verify tabIndex, role and focus
expect(await page.evaluate(elem => elem.getAttribute(`role`), category)).toEqual(`button`);
expect(await page.evaluate(elem => elem.getAttribute(`tabindex`), category)).toEqual(`0`);
expect(await page.evaluate(elem => window.document.activeElement === elem, category)).toEqual(true);

// verify aria-expanded = false
expect(await page.evaluate(elem => elem.getAttribute(`aria-expanded`), category)).toEqual(`false`);

// toggle category by pressing Space
await page.keyboard.press('Space');

// verify aria-expanded = true
expect(await page.evaluate(elem => elem.getAttribute(`aria-expanded`), category)).toEqual(`true`);

Asegúrate de usar correctamente el lector de pantalla

Aproximadamente, entre el 1% y el 2% de las personas usan un lector de pantalla. ¿Puedes comprender toda la información importante e interactuar con el componente usando solo el lector de pantalla y el teclado?

Las siguientes preguntas deberían ayudarte a abordar la accesibilidad del lector de pantalla.

¿Todos los componentes e imágenes tienen alternativas de texto significativas?

Siempre que la información sobre el nombre o el propósito de un componente interactivo se transmita visualmente, proporciona una alternativa de texto accesible.

Por ejemplo, si tu componente de IU <fancy-menu> solo muestra un ícono de ajustes para indicar que es un menú de configuración, necesita una alternativa de texto accesible, como "configuración", que transmita la misma información. Según el contexto, puedes proporcionar una alternativa de texto con un atributo alt, un atributo aria-label, un atributo aria-labelledby o texto sin formato en el Shadow DOM. Encontrarás sugerencias técnicas generales en la Referencia rápida de WebAIM.

Cualquier componente de la IU que muestre una imagen debe proporcionar un mecanismo para brindar texto alternativo para esa imagen, análogo al atributo alt.

¿Tus componentes proporcionan información semántica?

La tecnología de accesibilidad transmite información semántica que, de otro modo, se expresa a los usuarios videntes con indicadores visuales, como el formato, el estilo del cursor o la posición. Los elementos estandarizados tienen esta información semántica integrada por el navegador, pero en el caso de los componentes personalizados, debes usar ARIA para agregar la información.

En general, cualquier componente que escuche un clic del mouse o un evento de desplazamiento del mouse debe tener algún tipo de objeto de escucha de eventos del teclado y una función de ARIA, posiblemente estados y atributos de ARIA.

Por ejemplo, un componente de IU <fancy-slider> personalizado podría tener una función ARIA de control deslizante, que tiene algunos atributos ARIA relacionados: aria-valuenow, aria-valuemin y aria-valuemax. Si vinculas estos atributos a las propiedades relevantes en tu componente personalizado, puedes permitir que los usuarios de tecnología de accesibilidad interactúen con el elemento, cambien su valor y provoquen que la presentación visual del elemento cambie en consecuencia.

Un componente del control deslizante de rango.

<fancy-slider role="slider" aria-valuemin="1" aria-valuemax="5" aria-valuenow="2.5">
</fancy-slider>

¿Pueden los usuarios entender todo sin depender del color?

El color no debe usarse como único medio de transmisión de información, por ejemplo, para indicar un estado, solicitar una respuesta al usuario o visualizar datos. Por ejemplo, si tienes un gráfico circular, proporciona etiquetas y valores para cada porción, de modo que los usuarios que tengan discapacidades visuales puedan comprender la información, incluso si no pueden ver dónde comienzan y terminan las secciones:

Un gráfico circular accesible (Fuente: Iniciativa de accesibilidad web de W3C).

¿Hay suficiente contraste?

Cualquier contenido de texto que se muestre en tu componente debe cumplir con el umbral de contraste mínimo de nivel AA WCAG. Considera proporcionar un tema de alto contraste que cumpla con el umbral de AAA más alto y asegúrate de que se puedan aplicar las hojas de estilo del usuario-agente si los usuarios necesitan contraste personalizado o colores diferentes. Puedes usar este Verificador de contraste de colores como ayuda cuando diseñes tu componente.

¿El contenido en movimiento o flash es seguro?

Los usuarios deben poder pausar, ocultar o detener el contenido que se mueve, se desplaza o parpadea durante más de cinco segundos. En general, evita escribir contenido en la memoria flash.

Si algo debe parpadear, asegúrate de que no lo haga más de tres veces por segundo.

Herramientas y pruebas de accesibilidad

Existen más de 100 herramientas disponibles para evaluar la accesibilidad de tu sitio y sus componentes. Algunas herramientas son automatizadas, mientras que otras requieren pruebas manuales.

Estos son algunos para que los tengas en cuenta:

• Axe proporciona pruebas de accesibilidad automatizadas para el framework o el navegador que elijas. Axe Puppeteer se puede usar para escribir pruebas de accesibilidad automatizadas.

• Una auditoría de accesibilidad de Lighthouse proporciona estadísticas útiles para descubrir problemas comunes de accesibilidad. La puntuación de accesibilidad es un promedio ponderado de todas las auditorías de accesibilidad que se basa en las evaluaciones de impacto del usuario de Axe. Para supervisar la accesibilidad con la integración continua, consulta Lighthouse CI.

  

• Tenon.io es útil para probar problemas comunes de accesibilidad. Tenon ofrece una sólida integración con herramientas de compilación, navegadores (mediante extensiones) y hasta editores de texto.

• Hay muchas herramientas específicas de bibliotecas y frameworks para destacar problemas de accesibilidad con los componentes. Por ejemplo, usa eslint-plugin-jsx-a11y para destacar problemas de accesibilidad de los componentes de React en tu editor.

  

  Si usas Angular, codelyzer también proporciona auditorías de accesibilidad en el editor:

  

Trabajar con tecnologías de asistencia

Sugerencia: Obtén información para realizar pruebas de tecnología de accesibilidad.

• Puedes examinar la forma en que las tecnologías de accesibilidad ven el contenido web con el Inspector de accesibilidad (Mac) o las Herramientas de prueba de la API de automatización de Windows y AccProbe (Windows). También puedes navegar a about://accessibility para ver el árbol de accesibilidad completo que crea Chrome.
• La mejor manera de probar la compatibilidad con el lector de pantalla en una Mac es utilizar la utilidad VoiceOver. Usa ⌘F5 para habilitarlo o inhabilitarlo, Ctrl+Option ←→ para desplazarte por la página y Ctrl+Shift+Option + ↑↓ para moverte hacia arriba y hacia abajo en el árbol de accesibilidad. Para obtener instrucciones más detalladas, consulta la lista completa de comandos de VoiceOver y la lista de comandos web de VoiceOver.

• En Windows, NVDA es un lector de pantalla gratuito y de código abierto. Sin embargo, tiene una curva de aprendizaje muy pronunciada para los usuarios videntes.

  

• ChromeOS tiene un lector de pantalla integrado.

Tenemos un largo camino por recorrer para mejorar la accesibilidad en la Web. Según el informe web:

• 4 de cada 5 sitios tienen texto que se mezcla con el fondo, lo que los hace ilegibles.
• El 49.91% de las páginas aún no proporcionan atributos alt para algunas de sus imágenes.
• Solo el 24% de las páginas que utilizan botones o vínculos incluyen etiquetas.
• Solo el 22.33% de las páginas proporciona etiquetas para todas las entradas del formulario.

Hay mucho que podemos hacer para crear experiencias que sean más accesibles para todos.

Sugerencia: Para obtener más información sobre los aspectos básicos de accesibilidad y ayudar a mejorar esas estadísticas, consulta Accesible para todos y Información sobre accesibilidad.