Alguien ejecuta un escáner de accesibilidad en su sitio web. Este arroja una puntuación, o una marca de verificación verde, o una lista de once problemas. Es tentador tratar eso como la línea de meta.
Está más cerca de la mitad del trabajo, y la mitad que le falta es la que realmente evita que la gente use el sitio.
Las herramientas automatizadas encuentran entre el 30 y el 57 por ciento de los problemas
Dependiendo del estudio que lea, los escáneres automatizados detectan de manera confiable entre 30 y 57 por ciento de infracciones de accesibilidad. Ese es un aporte útil y vale la pena tenerlo. No es una declaración de conformidad.
Los escáneres son verdaderamente buenos en algunas cosas:
- Contraste de color, que es aritmética medible
- Faltan atributos alt
- ARIA no válido
- Campos de formulario sin etiqueta programática
Esos son errores reales y vale la pena solucionarlos. El contraste en particular es el error de accesibilidad más común en la web, por lo que un escáner se justifica solo por eso.
Lo que un escáner no puede juzgar
Una máquina puede decirte que una imagen tiene texto alternativo. No puede decirte que el texto alternativo es correcto. Una imagen de un directorio del personal descrita como “image1” pasa la verificación y no ayuda a nadie.
La lista de cosas que ningún escáner evalúa es más larga de lo que la mayoría de la gente espera:
- Orden del foco. Si la navegación con la tecla Tab se desplaza por la página en un orden que coincide con lo que se ve.
- Trampas de teclado. Si puedes salir de un menú o de un modal una vez que estás dentro.
- Si el texto alternativo es preciso, en lugar del presente.
- Alternativas de arrastre. Ya sea que un control deslizante o una lista reordenable se pueda operar con un solo toque.
- Ayuda constante. Si tu enlace de contacto se encuentra en el mismo lugar relativo en todas las páginas.
- Autenticación. Ya sea que iniciar sesión requiera memorizar o transcribir algo, sin ninguna alternativa.
- La experiencia del lector de pantalla, que es el objetivo principal y no se puede inferir solo a partir del marcado.
Una declaración de conformidad real requiere un escaneo, más prueba manual de teclado, más Prueba de lector de pantalla. Cualquiera que te venda un certificado basándose únicamente en un análisis te está vendiendo el treinta por ciento.
El pase manual que encuentra al resto
Esto es lo mínimo que vale la pena hacer en cada plantilla de página distinta. Toma menos de una hora una vez que conoces los pasos.
- Solo teclado. Guarda el ratón. Recorre toda la página usando la tecla Tab. Cada elemento interactivo debe ser accesible, el foco debe ser siempre visible, el orden del foco debe coincidir con el orden visual, no debe haber trampas de navegación y el encabezado fijo nunca debe cubrir el campo en el que te encuentras.
- Zoom del 200 por ciento y 320 píxeles de ancho. Sin desplazamiento horizontal, nada recortado.
- Espaciado de texto. Aumente la altura de línea, el espaciado entre letras y el espaciado entre palabras a los valores del criterio 1.4.12. Nada debe superponerse ni cortarse.
- Lector de pantalla. NVDA en Windows, VoiceOver en una Mac. Navegar por encabezado, luego por región, luego por enlace. Los encabezados deben formar un esquema sensato por sí mismos. Los campos de formulario deben anunciar su etiqueta y su error.
- Movimiento reducido activado a nivel de sistema operativo. Las animaciones y las transformaciones al pasar el cursor deben detenerse.
- Formularios. Todas las entradas etiquetadas. Errores descritos con palabras, anunciados y nunca indicados únicamente por el color.
Los fallos que surgen con más frecuencia
Los datos de auditoría agregados los sitúan aproximadamente en este orden, del más frecuente al menos frecuente:
- Contraste eso no cumple con la proporción mínima
- Texto alternativo faltante o inútil
- Controles personalizados construido a partir de divs, sin rol y sin nombre accesible
- Contornos de enfoque eliminados en CSS sin devolver nada
- Encabezados elegidos por tamaño en lugar de estructura y tablas sin celdas de encabezado
- Texto de ejemplo utilizado en lugar de una etiqueta
- Enfoque oculto detrás de un encabezado fijo, el criterio nuevo más común en las WCAG 2.2
Cuatro de esos siete son decisiones que se toman una sola vez en un sistema de diseño. Ese es el argumento a favor de hacer esto en tiempo de compilación en lugar de como un proyecto de corrección posterior.
Qué pedir
Si estás comprando una auditoría de accesibilidad, pregunta cuál de las tres partes estás obteniendo: el escaneo, la prueba de teclado, la prueba de lector de pantalla. Pregunta cuántas plantillas se cubren en lugar de cuántas páginas, porque las plantillas son lo que realmente se corrige.
Y pregunta qué pasa después. Una auditoría produce una lista. Alguien aún tiene que hacer el trabajo, y en la mayoría de los sitios las correcciones pertenecen al tema, no a doscientas páginas individuales.
Fuentes: W3C, Guía de referencia rápida sobre cómo cumplir con las WCAG; Análisis anual de accesibilidad web de WebAIM de las principales páginas de inicio.