Accesibilidad para desarrolladores web

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

Addy Osmani

Sugerencia: Realiza Aprende sobre accesibilidad, un plan perdurable. accesibilidad y referencias para nivelar el desarrollo web.

Es importante crear sitios que sean inclusivos y accesibles para todos. Existen al menos seis áreas de discapacidad clave para las que puedes optimizar: visual, auditoría, movilidad, cognición, voz y neural. Hay muchas herramientas y recursos que pueden ser útiles en este caso, incluso si es la primera vez que usas la accesibilidad web.

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

Para que los sitios sean accesibles, deben funcionar en varios dispositivos con diferentes tamaños de pantalla y diferentes tipos de entrada, como lectores de pantalla. Además, el grupo más amplio de usuarios debería poder usar los sitios, incluidas las personas con discapacidades.

Estas son algunas de las discapacidades que pueden tener los usuarios:

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

Los problemas visuales varían desde la incapacidad para distinguir colores hasta la falta de visión.

• Asegúrate de que el contenido de texto cumpla con un umbral de relación de contraste.
• Evita comunicar información usando únicamente color y asegurarte de que todo el texto esté resizable.
• Garantizar que todos los componentes de la interfaz de usuario se puedan utilizar con tecnologías de accesibilidad como lectores de pantalla, lupas y pantallas braille. Esto implica asegurarse de que los componentes de la IU estén marcados. para que las APIs de accesibilidad puedan determinar de forma programática el role, state, value y title de cualquier elemento.

Nota: La función de inspección de elementos del navegador muestra la información sobre la herramienta Propiedades de CSS que incluye una verificación rápida de la proporción de contraste de color.

Personalmente vivo con visión reducida y, a menudo, hago zoom en sitios, sus Herramientas para desarrolladores y la terminal. Si bien la compatibilidad con el zoom casi nunca es una prioridad listas de tareas pendientes, puede marcar una gran diferencia para usuarios como yo.

Los problemas auditivos indican que un usuario puede tener problemas auditivos emitidos por una página.

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

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

• Crea el contenido de los componentes de la interfaz de usuario que sea funcionalmente accesible desde un teclado para las acciones para las que se usaría el mouse.
• Asegúrate de que las páginas estén marcadas correctamente para tecnologías de accesibilidad, incluidas lectores de pantalla, software de control por voz y controles de interruptores físicos, que tienden a usar las mismas APIs.

Problemas cognitivos significan que un usuario puede necesitar tecnologías de asistencia para ayudarlos a leer un 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 repetir o flash, lo que puede causar problemas para algunos usuarios.

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

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

• Evita interacciones que sean basadas en el tiempo.

Puede parecer que hay que tratar muchos temas, pero analizaremos el proceso para evaluar y, luego, mejorar la accesibilidad de los componentes de la interfaz de usuario.

Para obtener soporte visual adicional, el equipo de accesibilidad de GOV.UK ha creado una serie de pósteres digitales que se deben hacer y no sobre la accesibilidad, que puedes usar para compartir 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 IU

Cuando audites los componentes de IU de tu página para comprobar la accesibilidad, pregúntate lo siguiente:

• ¿Puedes usar tu 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 adecuados?

• ¿Puedes usar tu componente de IU con un lector de pantalla?

  ¿Proporcionaste alternativas de texto para la información que se presentó 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 el componente de IU. Una herramienta útil para simular el daltonismo es la extensión de Chrome llamada Para daltónicos. (prueba las cuatro formas de simulación de daltonismo disponibles). También te puede interesar la Daltonizar que es igualmente útil.

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

  Todos los sistemas operativos modernos admiten un modo de contraste alto. Contraste alto es una extensión de Chrome que puede ser de ayuda.

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

Componentes de IU personalizados (a excepción de los componentes que extienden elementos como <button>) no tienen ninguna función integrada, lo que incluye accesibilidad, por lo que debes proporcionarla. Un buen punto de partida cuando para implementar la accesibilidad es comparar tu componente con un estándar análogo (o una combinación de varios elementos estándar, según la complejidad de ese 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 función está disponible en la pestaña Accesibilidad del panel Elements.

Firefox también tiene un panel de Accesibilidad.

Safari expone la información de accesibilidad en la pestaña Nodo del panel Elements.

La siguiente es una lista de preguntas que puedes hacerte cuando intentes hacer que tus componentes de IU sean más accesibles.

Mejora el enfoque del teclado

Idealmente, asegúrate de que se pueda acceder a todas las funciones de tu componente de IU con un teclado. Cuando diseñes tu experiencia del usuario, piensa en cómo usarías tu elemento solo con el teclado y determinar un conjunto coherente de interacciones con el 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 dentro de pero debe administrar el enfoque dentro de sí mismo para que el elemento activo del menú siempre se enfoca.

Administra el enfoque dentro de un elemento complejo.

Usar tabindex

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

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

Existen tres tipos de valores tabindex:

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

Advertencia: Como regla general, evita los tabindexes positivos. Interrupción del orden de enfoque normal puede confundir y frustrar a los usuarios. Por lo tanto, es probable que cause una falla de Criterio de éxito 2.4.3.

Consulta algunos casos de uso de tabindex en el artículo Usa tabindex.

Asegúrate de que el enfoque esté siempre visible, ya sea mediante el anillo de enfoque predeterminado o aplicando un estilo de enfoque personalizado que se distinga. Recuerda no atrapar usuarios de teclado, deberían poder alejar el enfoque de un elemento usando solo el teclado.

Nota: Puede que también te interesen los objetos tabindex o Enfoques de aria-activedescendant, como se aborda en MDN.

Cómo usar el enfoque automático

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

Agregar interacción del teclado

Una vez que el componente de la interfaz de usuario pueda enfocarse, proporciona una buena historia de interacción con el teclado. Cuando un componente se enfoca mediante el control de eventos del teclado apropiados Por ejemplo, permite que el usuario utilice 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.

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 atajos. Por ejemplo, "¿Presiona ? para teclado atajos". Como alternativa, se puede usar una sugerencia de este tipo para informar al usuario sobre un atajo.

No se puede negar la importancia de administrar el enfoque. Un ejemplo importante es un panel lateral de navegación. Si agregas un componente de IU a la página, debes dirigir el enfoque a un elemento que está dentro de él; De lo contrario, es posible que los usuarios tengan que navegar con tabulación por toda la página para acceder a ella. Esta puede ser una experiencia frustrante, así que asegúrate de probar el enfoque de todos los componentes navegables con el teclado en tu página.

Sugerencia: Puedes usar Puppeteer. para automatizar la ejecución de pruebas de accesibilidad del teclado para activar o desactivar los estados de la IU. WalkMe Engineering tiene una gran guía sobre este tema, te recomiendo leerlo.

// 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`);

Cómo garantizar un uso correcto del lector de pantalla

Alrededor del 1% al 2% de las personas usan un lector de pantalla. ¿Puedes entender todas las responsabilidades información e interactuar con el componente a través del lector de pantalla y el teclado solo?

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

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

Siempre que la información sobre el nombre o el propósito de un componente interactivo se transmite visualmente, proporcionan 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. Puedes encontrar sugerencias técnicas generales en la Referencia rápida de WebAIM.

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

¿Tus componentes proporcionan información semántica?

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

En general, cualquier componente que escucha un evento de clic o desplazamiento del mouse debe tener algún tipo de objeto de escucha de eventos de teclado y un rol de ARIA, Además, los estados y atributos de ARIA.

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

Un componente de 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 el único medio de transmisión de información, como 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 para que los usuarios con discapacidad visual puedan comprender la información, incluso si no pueden ver dónde comienzan y terminan las porciones:

Un gráfico circular accesible (de la Iniciativa de accesibilidad web del W3C).

¿Hay suficiente contraste?

Todo el contenido de texto que se muestre en el componente debe cumplir con los umbral de contraste mínimo de WCAG de nivel AA. Considera proporcionar un tema de alto contraste que cumpla con los umbral de AAA más alto, y garantizar que se puedan aplicar las hojas de estilo del usuario-agente si los usuarios requieren un 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 intermitente se puede detener y es seguro?

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

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

Herramientas de accesibilidad y pruebas

Hay 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 tener en cuenta:

• Axe brinda accesibilidad automatizada. las pruebas para el framework o navegador que elijas. Títere con hacha se puede usar para escribir pruebas automatizadas de accesibilidad.

• Accesibilidad de Lighthouse proporciona información útil para descubrir problemas comunes de accesibilidad. La puntuación de accesibilidad es un promedio ponderado de todas las auditorías de accesibilidad según las evaluaciones de impacto de los usuarios de Axe. Para supervisar la accesibilidad con integración continua, consulta Lighthouse CI.

  

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

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

  

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

  

Cómo trabajar con tecnologías de asistencia

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

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

• En Windows, NVDA es una pantalla gratuita de código abierto. de lectura. Sin embargo, tiene una curva de aprendizaje empinada 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 almanato web:

• 4 de cada 5 sitios tienen texto que combina con el fondo, por lo que son 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 usan botones o vínculos incluyen etiquetas.
• Solo el 22.33% de las páginas incluyen etiquetas en todas las entradas del formulario.

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

Sugerencia: Para obtener más información sobre los aspectos básicos de la accesibilidad y ayudar a mejorarlos estadísticas, consulta Accesible para todos y Obtén información sobre Accesibilidad.