La accesibilidad web se trata como una casilla de cumplimiento legal o como un asunto que solo importa a una pequeña parte de los visitantes, y ambos planteamientos infravaloran lo que realmente está en juego. WCAG, el estándar de accesibilidad reconocido internacionalmente, cubre un rango amplio de necesidades, y una parte significativa de los visitantes de cualquier web se beneficia de al menos algunas de sus recomendaciones, se describan o no a sí mismos como personas con discapacidad.

Contraste de color: la corrección más fácil con el beneficio más amplio

El texto que no tiene suficiente contraste con su fondo es difícil de leer para personas con baja visión, y genuinamente más difícil de leer para cualquiera bajo luz solar directa o en una pantalla de peor calidad. El ratio mínimo de contraste de WCAG, 4,5 a 1 para texto normal, se puede comprobar con herramientas gratuitas en segundos y es uno de los fallos de accesibilidad más comunes en webs de empresa, normalmente introducido por una decisión de diseño que priorizó la sutileza estética por encima de la legibilidad.

Texto alternativo en imágenes: no es solo para accesibilidad

Un texto alternativo descriptivo permite que un lector de pantalla transmita lo que muestra una imagen a alguien que no puede verla, y también lo leen los buscadores intentando entender el contenido de la página. Una foto de producto con un texto alternativo tipo "IMG_4021.jpg" o dejado completamente en blanco no cumple ninguno de los dos propósitos. Escribir una descripción genuina y breve de lo que muestra realmente la imagen lleva segundos y sirve a la accesibilidad y al SEO a la vez.

Navegación por teclado: ¿se puede usar la web sin ratón en absoluto?

Algunos visitantes, ya sea por una discapacidad motriz o simplemente por preferencia, navegan enteramente con el teclado, moviéndose con Tab entre enlaces y botones en vez de hacer clic. Una web donde los estados de foco no son visibles, o donde un menú desplegable genuinamente no se puede abrir sin ratón, deja fuera a estos visitantes de una parte significativa de la experiencia. Probarlo lleva unos minutos: desconecta el ratón e intenta completar la acción de conversión principal de la web usando solo las teclas Tab e Intro.

Estructura de encabezados que describe la página de verdad, no solo estiliza texto

Los encabezados deberían seguir un orden lógico, H1 para el título de la página, H2 para secciones principales, H3 para subsecciones, no saltados por puro criterio visual de tamaño. Los usuarios de lectores de pantalla a menudo navegan una página saltando entre encabezados, y una estructura que no refleja la jerarquía real del contenido hace esa navegación genuinamente confusa, no solo visualmente inconsistente.

Etiquetas de formulario y mensajes de error realmente conectados a sus campos

Un campo de formulario sin una etiqueta correctamente asociada, o un mensaje de error que aparece sin estar enlazado de forma programática al campo al que se refiere, resulta confuso para un usuario de lector de pantalla de una forma que es invisible para un visitante vidente rellenando el mismo formulario. Es un hueco habitual incluso en webs por lo demás bien diseñadas, porque es fácil acertar visualmente y fallar en el código de fondo.

Un punto de partida realista, no una auditoría completa

Estas cinco comprobaciones (contraste, texto alternativo, navegación por teclado, estructura de encabezados y etiquetas de formulario) cubren una parte significativa de los fallos de accesibilidad habituales sin necesitar una auditoría formal para empezar a abordarlos. Una auditoría WCAG completa merece la pena eventualmente, sobre todo para webs grandes o de sectores regulados, pero estos fundamentos merece la pena integrarlos desde el principio en cada página nueva, que es exactamente cómo se manejan en cada proyecto de diseño web que hacemos, en vez de tratarse como una fase aparte y posterior.

Por qué tratar esto como requisito de lanzamiento funciona mejor que aplicarlo después

Corregir problemas de accesibilidad después de que una web ya se haya lanzado, una vez que existen decenas o cientos de páginas, es considerablemente más trabajo que integrar estas cinco comprobaciones en una plantilla desde el principio. Una única corrección de plantilla, aplicada una vez a nivel de componente, se propaga correctamente por cada página construida a partir de ella, mientras que aplicar la misma corrección página a página después del lanzamiento multiplica el esfuerzo por el número de páginas que existan.