Un sitio que algunos visitantes no pueden usar es un sitio que rechaza clientes en silencio. Tratamos el nivel AA de WCAG 2.2 como el piso de ingeniería de cada construcción, y lo verificamos por medición en lugar de afirmarlo en un folleto.
Por qué importa
La regulación de accesibilidad no deja de ampliarse: normas para el sector público, legislación de discapacidad aplicada a la web y requisitos de consumo en más y más mercados. Somos ingenieros, no abogados, y no damos asesoría legal. Lo que sí podemos decir con claridad es que un sitio construido y verificado según WCAG 2.2 AA se apoya en el estándar que esos regímenes citan, y un sitio que lo ignora carga con un riesgo que no presupuestaste.
La misma estructura que sirve a un lector de pantalla sirve a un rastreador de búsqueda: encabezados reales y en orden, controles etiquetados, texto descriptivo en las imágenes, enlaces que dicen adónde van. El trabajo de accesibilidad y el de búsqueda se refuerzan entre sí, y por eso los tratamos como una sola disciplina y no como dos facturas.
Un contraste cómodo, objetivos táctiles generosos, una página que se maneja con teclado, movimiento que respeta tu configuración: los visitantes rara vez nombran estas cosas, pero las sienten como cuidado. Su ausencia se lee como baratura, justo en la página donde pides que confíen en ti.
En la práctica
El estándar suena abstracto hasta que se aplica. Esto es lo que significa, en concreto, en cada sitio que publicamos.
Verificación
Cada página compilada se audita contra WCAG 2.2 AA en anchos de teléfono, tableta y escritorio, en esquema claro y oscuro, en cada cambio. Una violación no produce un informe que alguien quizá lea: rompe la compilación, y una compilación rota no puede desplegarse. Las regresiones de accesibilidad se atrapan antes de que un visitante pueda encontrárselas.
Las razones de contraste se calculan, los tamaños de objetivo se miden en píxeles, el orden de los encabezados se analiza, y las mismas verificaciones corren en cada versión de idioma de cada página. Lo que una lista de control afirma, la batería de pruebas lo demuestra.
Las verificaciones automáticas detectan mucho, pero no todo. Antes de publicar un sitio, además lo usamos como lo haría un visitante real con necesidades de acceso: lo recorremos completo con el teclado, lo leemos con el texto ampliado y repasamos los formularios pensando en los anuncios del lector de pantalla.
Integrada
Adaptar la accesibilidad al final es la forma cara de conseguirla: recolorear una paleta de marca que nunca superó el contraste, reconstruir componentes que no pueden recibir foco, reescribir páginas cuyos encabezados eran decoración. Nosotros tomamos el camino contrario. El sistema de diseño se verifica por contraste en ambos esquemas antes de componer una sola página, los componentes interactivos se construyen primero para el teclado, y la auditoría corre desde el primer despliegue del proyecto, no desde el último. Al lanzar, la accesibilidad no es una tarea en una lista; es una propiedad del código que las pruebas mantienen verdadera.
Todo lo que incluye un proyecto de sitio web Accesible en cada idioma, incluido el RTL Cómo funciona un proyecto
Pregúntanos lo que quieras sobre el estándar, o pídenos revisar tu sitio actual. Escríbenos por el formulario de contacto o a sales@wwi.dev.