¿Cómo hacer una revisión de accesibilidad?

Obtener una idea de qué tan accesible es tu módulo, tema o sitio puede parecer una tarea abrumadora. Si eres nuevo en accesibilidad, este tema por sí solo puede dejarte desconcertado sobre por dónde empezar. Adaptarse a un amplio espectro de habilidades significa que se deben considerar una variedad correspondiente de cuestiones. En esta documentación hemos listado las consideraciones necesarias en un proceso lógico y paso a paso para revisar la accesibilidad de un tema o sitio de tu módulo.

Comienza ejecutando herramientas automatizadas

Muchos problemas de accesibilidad pueden detectarse ejecutando la página con herramientas automatizadas. Algunas de estas herramientas incluyen WAVE, Tenon, Accessibility Insights, Google Lighthouse, Siteimprove y la extensión Siteimprove Accessibility Checker para Chrome. También puede automatizarse parcialmente con axe-core. Estas herramientas te ayudarán a identificar rápidamente problemas de accesibilidad, como estructura incorrecta del marcado, atributos ARIA faltantes y bajo contraste de color.

Prueba la navegación con teclado

La navegación con teclado es un medio fundamental para acceder a todo en pantalla para usuarios que no pueden o eligen no usar el ratón. Esto incluye usuarios de lectores de pantalla, así como usuarios con discapacidades motoras, como lesiones por esfuerzo repetitivo (RSI) o parálisis. Para una buena experiencia con teclado, asegúrate de tener un orden lógico de tabulación y estilos de foco claramente visibles. También debes asegurarte de que el usuario no tenga que tabular demasiados elementos innecesarios.

Qué buscar

• ¿Puedes saltarte el contenido repetido?

Debe proporcionarse un enlace para saltar que redirija a los usuarios directamente al contenido único de la página, evitando contenido repetitivo como menús de navegación. El enlace de salto debe ser el primer punto de tabulación en la página y debe ser visible cuando está enfocado.

• ¿Todos los controles son completamente funcionales?

Cada elemento interactivo debe poder usarse con teclado. Expandir/contraer, vistas en árbol, deslizadores, diálogos y superposiciones, arrastrar y soltar — todo. O debe haber una forma alternativa de realizar la acción.

• ¿Puedes tabular en ambas direcciones?

Hemos visto algunas aplicaciones donde avanzar con tabulaciones funciona bien, pero no se puede retroceder (usando Shift + Tab), creando una trampa de teclado. Asegúrate de poder navegar con tabulación en ambas direcciones.

• ¿Existen trampas de teclado?

Cuidado con el enfoque totalmente atrapado en cualquier punto. ¿Hay forma de que el usuario evada superposiciones, modales y widgets de autocompletado usando solo el teclado? Si no, acabas de crear una trampa de teclado.

• ¿Tu foco está restringido cuando hay un diálogo?

Cuando hay un diálogo, el foco del teclado debe estar limitado dentro de él. De lo contrario, puedes salir del diálogo y navegar en la página que está detrás sin ver dónde estás.

• ¿Tu foco siempre es visible?

La regla general es que cualquier control con el que los usuarios puedan interactuar o ingresar datos debe ser enfocables y mostrar un indicador de foco (por ejemplo, un contorno). Si un usuario de teclado no puede ver a qué apunta el foco, no podrá interactuar con la página.

• ¿Hay contenido que no es visible pero accesible con teclado?

Asegúrate de que no haya contenido que deba estar oculto pero que aún esté en el orden de tabulación.

• ¿Existen equivalentes accesibles para el contenido visible solo al pasar el cursor?

Usa el ratón para verificar si hay contenido visible solo al pasar el cursor al que no puedes acceder solo con teclado. El contenido visible al pasar el cursor debe tener una alternativa accesible. Esto es necesario no solo para usuarios que navegan con teclado, sino también para usuarios con controles táctiles.

• ¿Hay elementos enfocables que no deberían ser enfocables?

- El contenido no interactivo no debe ser enfocables. Si algo puede recibir foco, se espera que el usuario pueda interactuar con ello. Los usuarios pueden confundirse o frustrarse con contenido enfocables que no se puede controlar.

- No pongas atributos tabindex="0" en elementos a menos que el usuario deba interactuar con ellos.

- Agregar atributos tabindex innecesarios a elementos no interactivos también hace que la navegación sea más difícil.

• ¿El orden de tabulación es natural y lógico?

Si se modificó el tabindex o la disposición de la página se reorganizó respecto al flujo natural del DOM (Modelo de Objeto del Documento o elementos realmente escritos en el script), un usuario con discapacidad visual puede experimentar un flujo confuso al navegar por la página.

Verifica tus puntos de control

Después de hacer todas estas pruebas con teclado: aumenta el zoom del navegador hasta llegar a tu punto de control y repite todo de nuevo. Cualquiera que use niveles altos de zoom usará tu versión "tablet" o "teléfono" en su portátil. Los puntos de control móvil no son solo para usuarios con pantalla táctil.

Encabezados

Los encabezados son la base de tu contenido. Una buena estructura de encabezados refleja el contenido de la página, como el índice de un libro. Tener encabezados descriptivos y niveles significativos es importante porque algunos usuarios de lectores de pantalla los usan para navegar por el contenido de la página.

Si ya ejecutaste alguna de las herramientas automáticas de accesibilidad, probablemente ya hayas revisado la mayoría de las cuestiones relacionadas con encabezados.

Qué buscar

• ¿Hay solo un elemento H1 en la página?

Debe haber solo un elemento H1 en la página que describa de qué trata la página.

• ¿Los niveles de encabezados corresponden al contenido?

Es importante usar otros encabezados según su nivel, no solo por tamaño de fuente. No se deben omitir niveles de encabezado.

• ¿Son suficientemente descriptivos los encabezados?

Los textos de encabezados deben describir brevemente el contenido que sigue.

Color y contraste

Debe haber suficiente contraste de color

El contraste de color es la relación entre el color del primer plano (texto) y el color de fondo. El texto debe tener una relación de 4.5:1 o mayor con el fondo. Puedes usar una herramienta de comprobación de contraste para verificar si tus colores cumplen este requisito.

El color no debe ser el único medio para transmitir información visual

Aunque el color es un medio válido para transmitir información visual, no debe ser la única forma. Las personas con daltonismo pueden tener dificultades cuando un solo color se usa para transmitir información importante (y pueden pasarla por alto).

Si usas color para transmitir información, usa al menos uno de los siguientes métodos adicionales:

• Usa texto significativo para proporcionar información. Por ejemplo, "encendido" y "apagado" junto a un círculo que cambia de verde a rojo.
• Usa un icono significativo para que los usuarios puedan distinguir el significado por la forma.
• Para indicar errores en formularios, no digas solo "campos en rojo". Mejor nombra los campos y márcalos con un icono de error reconocible.

Otro ejemplo es marcar campos obligatorios con color rojo. Algunos usuarios no pueden distinguir el rojo de otros colores, y no tendrán suficiente información para completar el formulario. Esto se puede solucionar añadiendo un asterisco a la etiqueta del campo.

Los estados de foco no deben depender únicamente del color. Se necesita una forma adicional para indicar el foco. Normalmente, esto será un contorno extra alrededor del control interactivo que tiene el foco.

No solo por el ícono

Si un ícono representa una parte importante de la funcionalidad, debe ir acompañado de texto que describa su propósito. Asegúrate de que los elementos interactivos, como menús de navegación, estén etiquetados. No todos los usuarios entienden los íconos que para ti son obvios. La etiqueta también es necesaria para que el lector de pantalla pueda leer el elemento.

Audio y vídeo

Si la página usa audio o vídeo para transmitir información, asegúrate de que estén disponibles subtítulos o transcripciones. Más información en el artículo de WebAim sobre subtítulos, transcripciones y descripciones de audio.

• Si usas vídeo informativo con o sin sonido en una página web, tu vídeo también necesita transcripción para personas con discapacidad visual.
• Si usas vídeo informativo con sonido en una página web, tu vídeo debe incluir subtítulos ocultos para personas con discapacidad auditiva.
• Si usas vídeo informativo y complejo con sonido, puede que necesites proporcionar una descripción de audio que describa el contexto de escenas y acciones en el vídeo, normalmente no cubierto por subtítulos, para personas con discapacidad visual.
• Si usas vídeo en vivo, deben proporcionarse subtítulos para personas con discapacidad auditiva.
• Si usas audio en vivo, debe proveerse una alternativa textual para personas con discapacidad visual.

Esto corresponde a la Guía WCAG 1.2 sobre medios basados en tiempo.

Animaciones y reproducción automática de vídeo y audio

Las animaciones, vídeos y/o audios que se reproducen automáticamente sin control del usuario pueden distraer la atención hacia otras partes de la página. Incluso si la animación o vídeo están en una posición de la página que crees que no causará problemas, no puedes controlar cómo los usuarios ven la página.

Ejemplos de animaciones, vídeos y audios con reproducción automática:

• Animaciones: carrusel que recorre automáticamente una serie de imágenes;
• Reproducción automática de vídeo: vídeo de YouTube que comienza a reproducirse cuando se carga la página;
• Reproducción automática de audio: estación de radio que comienza a sonar al cargar la página.

Para reducir las distracciones en la página:

• Evita animaciones, vídeos y contenidos que se reproduzcan por más de 5 segundos automáticamente.
• Proporciona controles para que el usuario pueda detener, reproducir y pausar animaciones, vídeos y audios.

Contenido dinámico

JavaScript permite cambiar partes de la página dinámicamente sin recargarla completamente. Los usuarios que no puedan ver estos cambios deben ser notificados. Ejemplos de contenido dinámico son la actualización en vivo de listas de resultados de búsqueda o mostrar una notificación que no requiere interacción del usuario. El API Drupal.announce() permite anunciar estos cambios dinámicos a algunas tecnologías asistivas.

Drupal.announce() es una API basada en regiones ARIA en vivo. Algunos ejemplos de uso se encuentran en esta documentación sobre roles de regiones ARIA en vivo.

La mejor forma de probar contenido dinámico es con un lector de pantalla.

Pruebas con lector de pantalla

Ejecutar verificaciones automáticas de accesibilidad y navegar manualmente la página son pasos importantes. Si no estás familiarizado con el uso de un lector de pantalla, muchas de estas cuestiones pueden detectarse sin usar uno.

Qué buscar

• ¿Todos los controles tienen una etiqueta?

Todos los controles deben estar descritos con una etiqueta que explique su función. En la mayoría de los casos se usa un elemento label, pero en algunos casos complejos puede ser necesario usar el atributo aria-labelledby.

• ¿Hay controles personalizados? ¿Están descritos con el rol ARIA correcto y atributos obligatorios que indican su estado?

Los usuarios de tecnologías asistivas deben tener acceso a la misma información que los usuarios visuales reciben mediante indicaciones visuales como formato, estilo del cursor o posición. Los elementos nativos tienen esta semántica incorporada en el navegador, pero para controles personalizados debes usar ARIA para agregarla. Por ejemplo, un componente personalizado tipo deslizador puede usar el rol ARIA slider y atributos como aria-valuenow, aria-valuemin y aria-valuemax.

• ¿El flujo de información tiene sentido con lo que ves en pantalla?

El flujo de información puede ser alterado por CSS. ¿Tiene sentido el flujo y contenido para un lector de pantalla?

• ¿Los textos de los enlaces son claros?

La mayoría de los lectores de pantalla anuncian “enlace” antes de cada enlace. Por ejemplo, un enlace “productos” será leído como “enlace productos”. Por eso no debes incluir “enlace” en el texto del enlace, porque todos saben que es un enlace.

Navegar de enlace en enlace es una forma común de explorar contenido web con lectores de pantalla. Los enlaces deben tener sentido fuera de contexto. Frases como “haz clic aquí”, “más información”, “haz clic para detalles”, etc., son ambiguas fuera de contexto.

• ¿Todas las imágenes tienen texto alternativo adecuado?

Todas las imágenes deben tener un texto alternativo adecuado. La excepción es cuando las imágenes son principalmente decorativas y no parte esencial del contenido. Si una imagen debe ser ignorada por lectores de pantalla, el atributo alt debe establecerse en cadena vacía.

Pruebas manuales con lector de pantalla

Algunos problemas solo pueden descubrirse probando manualmente la aplicación con un lector de pantalla. Los lectores de pantalla más comunes son VoiceOver (Mac OS) y NVDA (Windows). Para comenzar con VoiceOver, puedes ver el video introductorio de VoiceOver y leer el tutorial WebAIM para VoiceOver. Para comenzar con NVDA, puedes ver el video introductorio de NVDA y leer sobre cómo usar NVDA y Firefox para probar tus páginas web por Marco Zehe.

Una vez familiarizado con el lector de pantalla y las principales combinaciones de teclado que necesitas, intenta apagar la pantalla y dejar de usar el ratón. Ten en cuenta que la pronunciación del lector de pantalla está fuera del alcance de esta prueba.

Si aún no eres usuario de lector de pantalla, probar con uno no es tan fácil como parece. Se requiere tiempo y práctica para dejar la navegación visual y aprender los atajos y técnicas disponibles para usuarios de lectores de pantalla. Además, todos los lectores funcionan un poco diferente, por lo que es importante probar con la mayor variedad posible, así como en diferentes navegadores y plataformas.