Cómo revisar la accesibilidad

Rob Dodson

Determinar si tu sitio web o aplicación son accesibles puede parecer una tarea abrumadora. Si es la primera vez que abordas la accesibilidad, la gran amplitud del tema puede hacer que te preguntes por dónde empezar. Después de todo, trabajar para adaptarse a un rango diverso de habilidades significa que hay un rango correspondientemente diverso de problemas que se deben considerar.

En esta publicación, se desglosan estos problemas en un proceso lógico paso a paso para revisar la accesibilidad de un sitio existente.

Comienza con el teclado

En el caso de los usuarios que no pueden usar el mouse, la navegación con teclado es el medio principal para llegar a todo lo que se muestra en la pantalla. Este público incluye a usuarios con discapacidades motrices, como lesiones por estrés repetitivo (RSI) o parálisis, así como usuarios de lectores de pantalla.

Para obtener una buena experiencia con el teclado, intenta establecer un orden de tabulación lógico y estilos de enfoque claramente distinguibles.

  • Comienza por navegar por tu sitio con la tecla Tab. El orden en el que se enfocan los elementos debe seguir el orden del DOM. Si no sabes qué elementos deben enfocarse, consulta Conceptos básicos de enfoque para un repaso. La práctica recomendada es que cualquier control con el que un usuario pueda interactuar o al que proporcione entradas debe ser enfocable y debe mostrar un indicador de enfoque (como un anillo de enfoque).

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

  • Haz que solo el contenido interactivo sea enfocable. Agregar tabindex a elementos no interactivos, como los encabezados, ralentiza la velocidad de los usuarios del teclado que pueden ver la pantalla, lo que no ayuda a los usuarios de lectores de pantalla porque el lector de pantalla ya sabe cómo anunciarlos.

  • Si agregas contenido nuevo a una página, dirige el enfoque del usuario a ese contenido primero para que pueda realizar acciones al respecto. Consulta Cómo administrar el enfoque a nivel de la página para ver ejemplos.

  • Diseña tu sitio de modo que el usuario siempre pueda enfocar el siguiente elemento cuando lo desee. Ten cuidado con los widgets de autocompletado y otros contextos que pueden capturar el enfoque del teclado. Puedes capturar temporalmente el enfoque cuando quieras que el usuario interactúe con una ventana modal y no con el resto de la página, pero siempre debes proporcionar una forma accesible mediante el teclado para escapar de la ventana modal. Consulta Modals y trampas para teclado para ver un ejemplo.

Haz que tu control de enfoque sea fácil de usar

Si creaste un control personalizado, permite que los usuarios accedan a todas sus funciones solo con el teclado. Lee Cómo administrar el enfoque en los componentes a fin de conocer las técnicas para mejorar el acceso al teclado.

Administra el contenido fuera de pantalla

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

Consulta Cómo controlar el contenido fuera de pantalla si quieres obtener sugerencias para controlar 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 consiste en verificar la página para verificar la semántica y el etiquetado correctos, así como cualquier obstrucción en la navegación del lector de pantalla.

Si no conoces cómo la tecnología de accesibilidad interpreta el lenguaje de marcado semántico, consulta Estructura del contenido.

  • Comprueba que el texto alt sea correcto en todas las imágenes. La excepción a esta práctica es cuando las imágenes tienen como objetivo principal la presentación y no son elementos de contenido esenciales. Para indicar que los lectores de pantalla deben omitir una imagen, establece el valor en una cadena vacía: alt="".
  • Marca todos los controles para ver una etiqueta. En el caso de los controles personalizados, esto puede requerir el uso de aria-label o aria-labelledby. Consulta Etiquetas y relaciones de ARIA para ver ejemplos.
  • Verifica todos los controles personalizados para encontrar un role adecuado y cualquier atributo ARIA obligatorio que comunique su estado. Por ejemplo, una casilla de verificación personalizada necesita un role="checkbox" y un aria-checked="true|false" para transmitir su estado de manera correcta. Consulta Introducción a ARIA para obtener una 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. Como los lectores de pantalla navegan por la página en el orden del DOM, anunciarán los elementos que hayas reubicado visualmente con CSS en un orden sin sentido. Si necesitas que un elemento aparezca antes en la página, muévelo físicamente antes en el DOM.
  • Intenta admitir la navegación del lector de pantalla para todo el contenido de la página. Asegúrate de que ninguna sección del sitio esté oculta de forma permanente ni que se bloquee el acceso del lector de pantalla.
    • Si el contenido debe ocultarse de un lector de pantalla, por ejemplo, si está fuera de la pantalla o solo es una presentación, establece ese contenido en aria-hidden="true". Para obtener una explicación más detallada, consulta Cómo ocultar contenido.

Familiarízate con los lectores de pantalla

Aunque puede parecer abrumador aprender a usar un lector de pantalla, en realidad son bastante fáciles de usar. En general, la mayoría de los desarrolladores se las arreglan con solo algunos comandos clave simples.

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

aria-hidden no impide el enfoque del teclado.

Es importante comprender que ARIA solo puede afectar la semántica de un elemento; no influye en el comportamiento del elemento. Con aria-hidden="true", puedes ocultar un elemento para los lectores de pantalla, pero eso no cambia el comportamiento del enfoque de ese elemento. En el caso del contenido interactivo fuera de pantalla, usa el atributo inert para asegurarte de que se quite realmente del flujo del teclado. Para navegadores más antiguos, combina aria-hidden="true" con tabindex="-1".

Los elementos interactivos deben indicar su propósito y estado

Proporcionar sugerencias visuales (o condiciones) sobre lo que hará un control ayuda a que una gran variedad de personas con una gran variedad de dispositivos funcionen y naveguen por tu sitio.

  • Los elementos interactivos, como los vínculos y los botones, deben distinguirse de los elementos no interactivos. Es difícil para los usuarios navegar por un sitio o una app 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 enlaces para diferenciarlos del texto que los rodea.
  • De manera similar al requisito de enfoque, los elementos interactivos, como los vínculos y los botones, requieren 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 que estos elementos sean accesibles a otros métodos de entrada, deben distinguirse sin un estado hover.

Aprovechar los encabezados y los puntos de referencia

Los encabezados y los elementos de punto de referencia le dan una estructura semántica a la página y aumentan en gran medida la eficiencia de navegación de los usuarios de tecnología de accesibilidad. Muchos usuarios de lectores de pantalla informan que, cuando llegan por primera vez a una página desconocida, por lo general, intentan navegar por encabezados.

De manera similar, los lectores de pantalla también ofrecen la capacidad de ir a puntos de referencia importantes, como <main> y <nav>. Por estos motivos, es importante considerar cómo se puede usar la estructura de tu página para guiar la experiencia del usuario.

  • Usa la jerarquía de h1-h6. Piensa en los encabezados como herramientas a fin de crear un esbozo para tu página. No confíes en el estilo integrado de los encabezados. En cambio, trátalas como si fueran todas del mismo tamaño y usa el nivel semánticamente adecuado para el contenido primario, secundario y terciario. Luego, usa CSS para que los encabezados coincidan con tu diseño.
  • Usa elementos y roles que sean puntos de referencia para que los usuarios eviten el contenido repetitivo. Muchas tecnologías de asistencia proporcionan accesos directos para saltar a partes específicas de la página, como las definidas por elementos <main> o <nav>. Estos elementos tienen roles de punto de referencia implícitos. También puedes usar el atributo role de ARIA para definir explícitamente regiones en la página, como en <div role="search">. Consulta Semántica y navegación por el contenido para obtener más ejemplos.
  • Evita role="application", a menos que tengas experiencia trabajando con él. El rol de punto de referencia application le indica a la tecnología de accesibilidad que inhabilite sus combinaciones de teclas y pase todas las presiones a la página. Esto significa que las teclas que los usuarios del lector de pantalla suelen usar para desplazarse por la página ya no funcionan, y deberás implementar todo el manejo del teclado por tu cuenta.

Cómo revisar 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 descripción general de la página y determinar si los niveles de encabezado 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.

Automatizar el proceso

Probar manualmente la accesibilidad de un sitio puede ser tedioso y propenso a errores. Es conveniente automatizar las pruebas lo más posible. Puedes usar extensiones del navegador y paquetes de pruebas de accesibilidad de la línea de comandos.

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

Cómo usar 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 las pruebas de accesibilidad fallidas en tu informe. Corrige los errores para mejorar la experiencia general del usuario en tu sitio.

Recursos adicionales