Cómo hacer su propia auditoría inicial de accesibilidad

La versión breve: ejecuta un escáner automatizado (axe, WAVE, Lighthouse), que detecta aproximadamente entre un cuarto y un tercio de los problemas de WCAG, y luego haz lo que este no puede hacer: navega solo con el teclado, haz una verificación puntual con un lector de pantalla, comprueba el contraste en 4,5:1 para texto, 3:1 para texto grande y elementos de interfaz, y lee el texto alternativo y las etiquetas como lo haría un desconocido. Una primera revisión real, no un certificado.

Déjame guiarte por el proceso tal como lo haría si estuviéramos sentados frente a tu pantalla juntos, porque una tarde dedicada a hacerlo bien te enseña más que cualquier informe que yo pudiera entregarte.

¿Qué comprueba realmente una primera auditoría de accesibilidad?

Una primera auditoría tiene dos mitades, y la mayoría de las personas solo hace la primera. La primera mitad es automatizada: un escáner señala lo que una máquina puede verificar con certeza, como un atributo alt faltante. La segunda mitad es manual: una persona comprueba lo que requiere criterio, como si ese texto alt realmente describe la imagen, o si el orden de tabulación tiene sentido para alguien que no puede ver la página.

Si te saltas la segunda mitad, no has auditado tu sitio. Has ejecutado un corrector ortográfico y lo has llamado una edición.

¿Por qué los escáneres automatizados detectan solo entre un cuarto y un tercio de tus problemas?

Aquí está la cifra que debería recalibrar cuánta confianza depositas en una marca de verificación en verde. Deque, la empresa detrás del motor de código abierto axe-core que impulsa la mayoría de los escáneres, afirma sin rodeos que la industria de la accesibilidad lleva mucho tiempo considerando que la cobertura automatizada se sitúa entre el 20 y el 30 por ciento (Deque, a reverificar). Un análisis independiente de los propios criterios llega a una conclusión muy similar: solo cerca del 30 por ciento de los criterios de éxito de WCAG 2.1 Nivel AA, unos 15 a 16 de ellos, pueden someterse a una prueba significativa por parte de una máquina (TestParty, a reverificar). Todo lo demás necesita a una persona.

Una advertencia rápida para que leas el marketing de las herramientas como un profesional: un estudio más reciente de la propia Deque, sobre más de 2.000 auditorías y casi 300.000 problemas, encontró que las pruebas automatizadas detectan el 57 por ciento de los problemas cuando se cuenta por volumen en lugar de por criterio (Deque, a reverificar). Ambas cifras son ciertas, simplemente miden cosas distintas. Si cuentas por regla, la automatización cubre menos de un tercio del reglamento. Si cuentas cuántas veces aparece cada problema en una página, el panorama mejora, porque un puñado de problemas de alta frecuencia, el contraste en especial, infla el total. De cualquier manera, una parte considerable de los problemas reales necesita que una persona los encuentre.

Nada de esto es una crítica a axe, WAVE o Lighthouse. Ejecuta uno hoy mismo. Axe DevTools y WAVE son extensiones de navegador gratuitas, Lighthouse viene integrado en las DevTools de Chrome, y cada uno te entrega defectos corregibles en minutos: etiquetas faltantes, orden de encabezados incorrecto, fallos de contraste, IDs duplicados. Son los diez minutos más rentables de progreso en accesibilidad que conseguirás en toda la semana. Solo no confundas un escaneo limpio con un sitio limpio. Ninguno de los tres puede decirte si tu texto alternativo tiene sentido, o si un visitante que solo usa el teclado puede completar tu proceso de compra (David Mello, a reverificar). Esa es la mitad manual, y ahí es donde vive la auditoría real.

¿Qué debo probar manualmente, y en qué orden?

Cinco comprobaciones, en el orden en que las realizo. Cada una toma entre quince y treinta minutos en una página típica, y juntas revelan más defectos reales que cualquier escáner por sí solo.

¿Puedes alcanzar y operar todo usando solo el teclado?

Deja el ratón a un lado. Usa Tab para avanzar, Shift+Tab para retroceder, Enter o Espacio para activar, y las flechas dentro de menús y widgets personalizados. Hazte tres preguntas mientras avanzas. Puedes alcanzar cada enlace, botón y campo de formulario. Hay siempre un indicador de foco visible que muestra exactamente dónde estás. Y puedes salir de todo lo que abriste, un modal, un menú, un selector de fecha, sin quedar atrapado. Una trampa de teclado, donde el foco entra en un componente y no puede salir, es uno de los defectos más incapacitantes que puede tener un sitio: no incomoda a un usuario de teclado, lo detiene por completo.

¿A qué suena tu página con un lector de pantalla?

No necesitas volverte experto. Necesitas treinta minutos honestos con la herramienta que tus usuarios probablemente usan. NVDA es gratuito y de código abierto en Windows, y VoiceOver viene integrado en cada Mac e iPhone, así que ninguno de los dos te cuesta nada probar. Esa cobertura importa: la encuesta más reciente de WebAIM sobre usuarios de lectores de pantalla encontró que NVDA y JAWS están casi empatados como los principales lectores de pantalla de escritorio, con 38 y 41 por ciento, y NVDA a la cabeza en cuanto se cuenta a todos los que lo usan de alguna forma (WebAIM, a reverificar). Enciende uno, cierra los ojos, e intenta completar la tarea más importante de tu sitio, enviar un formulario, leer un artículo de principio a fin. Anota cada momento de confusión. Esa confusión es tu lista de pendientes.

¿Tu texto y tus controles cumplen los mínimos de contraste?

Esta es la única comprobación con una cifra exacta, no un juicio de valor. El criterio de Contraste (mínimo) de WCAG exige al menos 4,5:1 para texto normal contra su fondo, bajando a 3:1 para texto grande, aproximadamente 18 puntos, o 14 puntos en negrita, en adelante (W3C). Un criterio hermano, Contraste no textual, extiende ese mismo mínimo de 3:1 a las partes visuales de los componentes de interfaz que un usuario necesita identificar y operar: bordes de campos de entrada, botones de icono, estados de alternancia (W3C). Revisa esto con cuidado, porque es, con diferencia, el fallo más común en la web. El análisis más reciente de WebAIM sobre el primer millón de páginas de inicio encontró texto con bajo contraste en el 83,9 por ciento de ellas, con un promedio de 34 instancias por página (WebAIM, a reverificar). Cualquier selector de color del navegador o extensión de contraste te da la proporción en segundos. Revisa el texto del cuerpo, los enlaces, el texto de marcador de posición y los bordes de los botones, no solo el titular.

¿Tendría sentido tu texto alternativo leído en voz alta, sin la imagen a la vista?

Cubre la imagen y lee solo el texto alternativo en voz alta. Transmite la misma información que recibe un visitante que sí puede ver. "Foto de una laptop" no le dice nada a un usuario de lector de pantalla. "Panel que muestra un aumento de ingresos del 12 por ciento respecto al trimestre anterior" sí cumple su función. Las imágenes decorativas deben tener texto alternativo vacío (alt="") para que los lectores de pantalla las omitan en silencio en lugar de anunciar un nombre de archivo. Esto importa más de lo que la mayoría de los dueños de sitios suponen: el texto alternativo faltante o inútil apareció en el 53,1 por ciento de las páginas de inicio de ese mismo análisis de WebAIM, y casi la mitad de esas eran imágenes enlazadas, lo cual rompe la navegación por completo para un usuario de lector de pantalla, no solo la comprensión (WebAIM, a reverificar).

¿Tus formularios etiquetan todo, y explican los errores con palabras?

Entra en cada campo usando solo Tab y un lector de pantalla activo. Anuncia una etiqueta real, "Dirección de correo electrónico," no silencio, no un marcador de posición que desaparece en cuanto empiezas a escribir. Envía el formulario con algo incorrecto a propósito. El error indica qué está mal y cómo corregirlo, en texto, no solo con un borde rojo, que no comunica nada a alguien que no puede ver el rojo ni el borde en absoluto. Esto no es un detalle menor: las etiquetas de campo de formulario faltantes aparecieron en el 51 por ciento de las páginas de inicio (WebAIM, a reverificar), lo que significa que uno de cada dos sitios hace que la mitad de sus visitantes adivine.

¿Qué añadió WCAG 2.2 que la mayoría de los dueños de sitios nunca ha oído mencionar?

WCAG 2.2 añadió nueve nuevos criterios de éxito sobre los de 2.1, y cuatro de ellos son los que veo pasados por alto constantemente, porque la mayoría de las listas de verificación existentes se escribieron antes de que se publicara 2.2 y nunca se actualizaron (W3C).

Tamaño del objetivo, 2.5.8. Los objetivos interactivos, botones, enlaces, iconos que tocas, necesitan medir al menos 24 por 24 píxeles CSS, o tener suficiente espacio alrededor para que un círculo de 24 píxeles centrado en cada uno no toque al vecino (W3C). Esto existe para cualquier persona con control motor fino limitado, y para cada uno de nosotros mientras sostiene un teléfono en un autobús en movimiento.

Foco no oculto, 2.4.11. Cuando algo recibe el foco del teclado, un encabezado fijo, un aviso de cookies o un widget de chat no debe ocultarlo por completo. Si no puedes ver dónde está el foco, no puedes usar el teclado con confianza, y los encabezados fijos están por todas partes ahora.

Entrada redundante, 3.3.7. Si un usuario ya te dio un dato antes en un proceso, no le hagas escribirlo de nuevo en la misma sesión, a menos que lo autocompletes o lo ofrezcas como una opción seleccionable. Los procesos de pago en varios pasos y las solicitudes largas son los culpables habituales.

Autenticación accesible, 3.3.8. Iniciar sesión no debería exigir resolver un rompecabezas, transcribir una imagen distorsionada, o recordar algo sin alternativa. Los gestores de contraseñas, la opción de "enviarme un enlace por correo" y la biometría cumplen con esto. Un CAPTCHA sin una vía alternativa no lo cumple.

Ninguno de estos cuatro aparece de forma fiable en un escaneo automatizado. Los cuatro son cosas que compruebas tú mismo, a mano, en menos de diez minutos por página.

Encontraste veinte problemas. ¿En qué orden los corriges?

No trabajes de arriba hacia abajo. Trabaja según cuántas personas ayuda una corrección frente a cuánto tiempo toma.

Empieza por el puñado de tipos de error que aparecen constantemente, porque corregir un patrón una sola vez suele resolverlo en todos los lugares donde se repite. La investigación de WebAIM encontró que solo seis categorías de error, texto con bajo contraste, texto alternativo faltante, etiquetas de formulario faltantes, enlaces vacíos, botones vacíos, e idioma de documento faltante, representan el 96 por ciento de todos los errores detectados en el primer millón de páginas de inicio (WebAIM, a reverificar). Eso rara vez son seis tareas separadas. Suele ser un token de diseño, un componente y una corrección de plantilla cada uno, repetido en todo tu sitio en el momento en que lo aplicas.

Una forma simple de priorizar lo que encontraste:

1. Bloquea una tarea por completo. Una trampa de teclado, un campo obligatorio sin etiquetar, un inicio de sesión que un usuario de lector de pantalla no puede completar. Corrige esto primero, siempre.
2. Afecta a la mayoría de las páginas por una sola causa raíz. Un token de contraste global, un componente de botón, una plantilla de encabezado. Un solo cambio elimina docenas de instancias.
3. Afecta a una sola página o a una ruta poco frecuente. Un pie de foto aislado, una página de aterrizaje antigua que nadie enlaza. Corrígelo la próxima vez que toques esa página.
4. Retoque cosmético o de nivel AAA. Genuinamente de menor prioridad, está bien dejarlo en cola detrás de los tres primeros.

Lo que una primera auditoría no es

Quiero ser directo contigo aquí, porque prometer de más es lo único que no haré en este sitio. Una autoauditoría de primera pasada no es una certificación. No es un VPAT (Voluntary Product Accessibility Template, por sus siglas en inglés), no es una defensa legal, y no reemplazará las pruebas con personas reales con discapacidades, quienes encuentran cosas que ninguna lista de verificación predice, porque usan tecnología de asistencia en condiciones reales que tú y yo no podemos simular por completo desde un escritorio. La propia guía de evaluación de accesibilidad del W3C lo dice sin rodeos: ninguna herramienta por sí sola puede determinar si un sitio cumple con los estándares de accesibilidad, y se requiere una evaluación humana experta para tomar esa decisión (W3C). Una tarde con las comprobaciones anteriores te da una primera revisión real y honesta: los problemas más evidentes encontrados y corregidos, y una idea más clara de dónde probablemente están las brechas más profundas. Vale la pena hacerlo hoy. No es la línea de meta.

La revisión que aplico en cada página

La rutina, para que la copies:

• Ejecuta un escaneo automatizado. Corrige cada problema señalado; no cuesta nada.
• Desconecta el ratón. Recorre la página con Tab y anota todo lo que sea inalcanzable, invisible o quede atrapado.
• Activa NVDA o VoiceOver y realiza tu tarea más importante con los ojos cerrados.
• Revisa el contraste en el texto del cuerpo, los enlaces, los marcadores de posición y los bordes de los botones.
• Lee en voz alta tu texto alternativo y las etiquetas de formulario, como si vieras la página por primera vez.
• Revisa a mano las cuatro adiciones de WCAG 2.2: tamaño del objetivo, foco oculto, entrada redundante, autenticación accesible.
• Clasifica lo que encontraste según a cuántas personas bloquea, no según en qué página está.
• Corrige primero los patrones que causan más daño, luego sigue bajando.

Haz esto una vez, correctamente, y leerás tu propio sitio de forma diferente para siempre.