Cómo revisar la accesibilidad

Rob Dodson

Determinar si se puede acceder a tu sitio web o aplicación puede parecer una una tarea abrumadora. Si estás abordando la accesibilidad por primera vez, el la amplitud del tema puede hacer que te preguntes por dónde empezar. Después de todo, trabajar para adaptarse a un rango diverso de capacidades significa que hay la variedad de cuestiones correspondiente a tener en cuenta.

Esta publicación desglosa estas cuestiones en un proceso lógico paso a paso revisar un sitio existente para comprobar su accesibilidad.

Comenzar con el teclado

Para los usuarios que no pueden o deciden no usar el mouse, la navegación con teclado es el medio principal para llegar a todo lo que aparece en pantalla. Este público incluye usuarios con discapacidades motrices, como lesiones por estrés repetitiva (RSI) parálisis, al igual que los usuarios de lectores de pantalla.

Para una buena experiencia con el teclado, intenta tener un orden lógico de tabulaciones y y estilos de enfoque perceptibles.

  • Para comenzar, explora tu sitio con la tecla Tab. El orden en que se enfocan los elementos debería seguir el orden del DOM. Si no estás seguro de qué elementos deberían recibir consulta el módulo del curso Aprende sobre accesibilidad. Los mejores práctica es que cualquier control con el que un usuario pueda interactuar o proporcionar entradas a deben ser enfocables y mostrar un indicador de enfoque (como un anillo de enfoque).

  • Los controles interactivos personalizados deben ser enfocables. Si usas JavaScript para <div> en un menú desplegable atractivo, no se insertará automáticamente en el el orden de tabulación. Para que un control personalizado pueda enfocarse, asígnale un tabindex="0". Los valores de tabindex mayores que 0 cambian el orden de tabulación y pueden ser confusos para usuarios de lectores de pantalla.

  • Haz que solo se pueda enfocar el contenido interactivo. Se está agregando tabindex a los elementos interactivos, como los encabezados, ralentizan a los usuarios del teclado que pueden ver las la pantalla y no ayuda a los usuarios de lectores de pantalla, ya que este ya sabe anunciarlos.

  • Si agregas contenido nuevo a una página, dirige la atención del usuario a ese contenido. para que puedan tomar medidas al respecto. Consulta Cómo administrar el enfoque a nivel de la página para ver ejemplos.

  • Diseñe su sitio de modo que el usuario siempre pueda centrar el siguiente elemento cuando quieren. Ten cuidado con los widgets de autocompletar y otros contextos que pueden atrapar el enfoque del teclado. Puedes atrapar temporalmente el enfoque cuando quieres que el usuario interactuar con una ventana modal y no con el resto de la página, pero siempre debes una forma accesible desde el teclado para escapar de la ventana modal. Consulta Trampas para teclados y modales para ver un ejemplo.

Haz que el control de enfoque sea utilizable

Si creaste un control personalizado, permite que los usuarios utilicen todas sus funciones usando solo el teclado. Leído Cómo administrar el enfoque en los componentes para conocer técnicas que mejoren el acceso al teclado.

Cómo administrar el contenido fuera de pantalla

Muchos sitios tienen contenido fuera de pantalla que está presente en el DOM, pero que no está visible. como vínculos dentro de un menú de panel lateral responsivo o un botón dentro de una ventana modal que todavía no se mostró. Si dejas estos elementos en el DOM, se puede crear un una experiencia de teclado confusa, especialmente para los lectores de pantalla, que anunciar el contenido fuera de pantalla como si fuera parte de la página.

Consulta Cómo controlar el contenido fuera de pantalla. para obtener consejos sobre cómo manejar estos elementos.

Cómo realizar pruebas con un lector de pantalla

La mejora de la compatibilidad general con el teclado sienta las bases para el siguiente paso, que es comprobar si la página tiene las etiquetas y semánticas correctas, y si hay obstrucciones para navegación por el lector de pantalla.

Si no estás familiarizado con cómo se interpreta el lenguaje de marcado semántico por parte de Tecnología, consulta Estructura del contenido.

  • Verifica que todas las imágenes incluyan texto alt adecuado. La excepción a esta práctica ocurre cuando las imágenes son principalmente para fines de presentación y no son piezas esenciales de contenido. Para indicar que los lectores de pantalla deben omitir una imagen, establece la valor a una string vacía: alt="".
  • Revisa todos los controles de una etiqueta. En el caso de los controles personalizados, es posible que necesites el uso de aria-label o aria-labelledby. Consulta Etiquetas y relaciones de ARIA para ver ejemplos.
  • Marca todos los controles personalizados para un role adecuado y cualquier ARIA requerido. atributos que comunican su estado. Por ejemplo, una casilla de verificación personalizada necesita una role="checkbox" y una aria-checked="true|false" para transmitir correctamente su para cada estado. Consulta Introducción a ARIA para obtener información general Descripción general de cómo ARIA puede proporcionar la semántica faltante para los controles personalizados
  • Haz que el flujo de información a través de tu página tenga sentido. Porque la pantalla los lectores naveguen por la página en orden DOM, anunciarán cualquier elemento que hayas reposicionarse visualmente mediante CSS en un orden sin sentido. Si necesitas algo que aparezca antes en la página, muévelo físicamente antes en el DOM.
  • Procura que la navegación del lector de pantalla para todo el contenido de la página sea compatible. Asegúrate de que ninguna sección del sitio se oculta ni se bloquea de la pantalla de forma permanente el acceso de los lectores.
    • Si el contenido debe ocultarse para un lector de pantalla, por ejemplo, si está fuera de pantalla o solo de presentación, establece ese contenido en aria-hidden="true". Para obtener una explicación más detallada, consulta Oculta contenido.

Familiarízate con los lectores de pantalla

Aunque aprender a usar un lector de pantalla puede parecer abrumador, en realidad son bastante fácil de usar. En general, la mayoría de los desarrolladores pueden lograrlo con solo comandos clave.

Si usas una Mac, mira este video sobre VoiceOver el lector de pantalla que viene con Mac OS. Si usas una PC, consulta este video sobre NVDA, un lector de pantalla de código abierto para Windows financiado con donaciones.

aria-hidden no impide el enfoque del teclado

Es importante comprender que ARIA solo puede afectar la semántica de una element; no tiene efecto en el comportamiento del elemento. Puedes hacer un elemento oculto para los lectores de pantalla con aria-hidden="true", pero no cambiar el comportamiento del foco de ese elemento. Para el contenido interactivo fuera de pantalla, Para el contenido interactivo fuera de pantalla, usa el atributo inert. para asegurarte de que se quite realmente del flujo del teclado. En navegadores anteriores, combina aria-hidden="true" con tabindex="-1".

Los elementos interactivos deben indicar su propósito y estado

Proporcionar sugerencias visuales o indicaciones sobre lo que hará un control ayuda una amplia variedad de personas en una amplia variedad de dispositivos operan y navegan por tu .

  • Los elementos interactivos, como enlaces y botones, deben distinguirse de elementos no interactivos. A los usuarios les resulta difícil navegar por un sitio o una aplicación cuando no pueden distinguir si se puede hacer clic en un elemento. Hay muchas formas válidas de indicar elementos interactivos. Una práctica común es subrayar vínculos a diferenciarlos del texto que lo rodea.
  • Al igual que el requisito de enfoque, los elementos interactivos, como los vínculos y los botones, Requerir un estado hover para indicarles a los usuarios del mouse cuando su puntero está sobre algo en el que se puede hacer clic. Sin embargo, para hacer que estos elementos sean accesibles a otros métodos de entrada, deben distinguirse sin un estado hover.

Aprovecha los encabezados y los puntos de referencia

Los encabezados y los elementos de punto de referencia le dan una estructura semántica a tu página, y aumentar considerablemente la eficiencia de navegación de los usuarios de tecnología de asistencia. Muchos los usuarios de lectores de pantalla informan que, cuando llegan por primera vez a una página desconocida, suelen intentar navegar por encabezados

Del mismo modo, los lectores de pantalla también ofrecen la posibilidad de saltar a puntos de referencia importantes como <main> y <nav>. Por estas razones, es importante considerar cómo la La estructura de la página se puede utilizar para guiar la experiencia del usuario.

  • Usa la jerarquía h1-h6. Piensa en los encabezados como herramientas para crear un esquema para tu página. No confíes en el estilo integrado de los encabezados. En su lugar, trátalos como si todas fueran del mismo tamaño y usaran el nivel para el contenido primario, secundario y terciario. Luego, usa CSS para que coincidan con tu diseño.
  • Usa elementos y roles de puntos de referencia para que los usuarios puedan evitar el contenido repetitivo. Muchos las tecnologías de asistencia ofrecen accesos directos para ir a partes específicas de la página, como las definidas por elementos <main> o <nav>. Estos elementos tienen roles de puntos de referencia implícitos. También puedes usar el atributo role de ARIA para lo siguiente: Define de manera explícita las regiones en la página, como en <div role="search">. Consulta Semántica y navegación por el contenido para obtener más información ejemplos.
  • Evita role="application", a menos que tengas experiencia trabajando con él. El rol del punto de referencia application le indica a la tecnología de accesibilidad que inhabilite su de acceso directo y pasar todas las pulsaciones de teclas a la página. Esto significa que las claves de lector de pantalla que los usuarios suelen usar para moverse por la página, ya no funcionan Además, deberás implementar por tu cuenta todo el manejo del teclado.

Revisa encabezados y puntos de referencia con un lector de pantalla

Los lectores de pantalla, como VoiceOver y NVDA, proporcionan un menú contextual para omitir regiones importantes de la página. Cuando pruebas la accesibilidad, puedes usar estos menús para obtener una visión general de la página y determinar si el encabezado niveles son apropiados y qué puntos de referencia están en uso.

Para obtener más información, consulta estos videos instructivos sobre los conceptos básicos de VoiceOver y NVDA

Automatiza el proceso

Probar manualmente la accesibilidad de un sitio puede ser tedioso y propenso a errores. Es conveniente automatizar las pruebas, ya que tanto como sea posible. Puedes usar las extensiones del navegador y la accesibilidad de la línea de comandos paquetes de pruebas.

  • ¿La página pasa todas las pruebas de la aXe o WAVE extensiones del navegador? Aunque existen otras opciones, estas extensiones pueden ser un complemento útil para cualquier proceso de prueba manual porque pueden detectar problemas sutiles, como fallas en las relaciones de contraste y ausencia de ARIA atributos.
    • Si prefieres trabajar en la línea de comandos, axe-cli proporciona las mismas funciones. como la extensión del navegador aXe, pero puedes ejecutarla desde tu terminal.
  • Para evitar regresiones, especialmente en un entorno de integración continua, Incorporar una biblioteca como axe-core en tu paquete de pruebas automatizadas. axe-core es el mismo motor que impulsa extensión de Chrome aXe, pero en una utilidad de línea de comandos.
  • Si usas un framework o una biblioteca, ¿ofrecen sus propias funciones de accesibilidad herramientas de administración? Por ejemplo, el protractor-accessibility-plugin para Angular. Aprovechar las herramientas disponibles siempre que sea posible

Usa Lighthouse para probar las AWP

Lighthouse es una herramienta que mide el rendimiento de tu app web progresiva (AWP). Además, usa la biblioteca axe-core para potenciar sus pruebas de accesibilidad.

Si ya usas Lighthouse, busca errores de accesibilidad en el informe. Corrige los errores para mejorar la experiencia general del usuario de tu sitio.

Recursos adicionales