Accesibilidad web: diez arreglos básicos que puedes hacer esta semana
La accesibilidad web no es un proyecto de meses ni un extra para cumplir expediente. Diez arreglos concretos —contraste, foco, alt, etiquetas, teclado— que mejoran la web para todos y se hacen en pocas horas.
La accesibilidad web tiene un problema de imagen: se presenta como un trámite legal o como un proyecto enorme. En realidad, la mayor parte del impacto está en diez detalles que se arreglan en pocas horas y que mejoran la experiencia de todos, no solo de quien usa un lector de pantalla.
Y no es un tema menor. Una web que no se puede usar con el teclado, que tiene texto gris sobre blanco o que pierde el foco al navegar excluye a una parte real de tus clientes: personas mayores, gente con el móvil al sol, quien se rompe un brazo o quien simplemente va con prisa.
Accesibilidad web es que cualquier persona pueda usar tu sitio en cualquier circunstancia. No es “hacer una versión especial”: es quitar barreras del sitio que ya tienes.
No es solo para personas ciegas. Afecta a quien tiene baja visión, a quien no puede usar el ratón, a quien escucha un vídeo sin sonido en el metro y a quien lee en una pantalla pequeña con reflejos. Cuando arreglas accesibilidad, sueles arreglar también usabilidad y SEO: mismo HTML, mismas etiquetas, mismo orden lógico.
- Contraste suficiente. Texto normal con ratio 4,5:1 o más. El gris claro sobre blanco es el fallo más habitual y el más fácil de corregir.
- Foco visible. Quien navega con teclado necesita ver dónde está. No elimines el
outlinesin poner un sustituto claro. - Texto alternativo con sentido.
alt="zapato rojo de piel, vista lateral"; noalt="imagen"ni el nombre del fichero. - Formularios con etiqueta. Cada campo necesita un
<label>asociado. El placeholder no es una etiqueta: desaparece al escribir. - Errores que explican. “Revisa el campo email: falta la @” ayuda; “Error 422” no. Y avisa con texto, no solo con color.
- Un solo H1 por página y jerarquía de encabezados sin saltos. Ayuda a lectores de pantalla y a los buscadores.
- Enlaces descriptivos. “Ver precios de reformas” en lugar de “clic aquí”. Fuera de contexto, un lector de pantalla lee una lista de “clic aquí”.
- Botones que son botones. Un
<div>cononclickno se puede activar con el teclado. Usa<button>. - Vídeos con subtítulos y sin reproducción automática con sonido.
- Zoom y texto ampliado. La web tiene que seguir funcionando al 200 % de zoom y con la tipografía del sistema más grande.
Ninguno requiere rehacer el diseño. La mayoría son etiquetas y estilos.
- Más gente puede comprar. Un formulario que se entiende y se puede enviar con teclado convierte mejor en todos los dispositivos.
- Mejor SEO. HTML semántico, encabezados ordenados y enlaces con texto útil es exactamente lo que pide un buscador.
- Menos soporte. Si la web explica los errores, llegan menos correos preguntando qué ha pasado.
- Menos riesgo legal. La normativa europea y española empuja a cumplir WCAG en muchos sectores, incluidos los sitios que prestan servicios al público.
Un enlace descriptivo es, además, el mismo trabajo que un buen copywriting web: un texto que dice a dónde lleva y por qué merece el clic. Y un formulario accesible es un formulario que convierte mejor en cualquier dispositivo, con teclado o con el pulgar.
Y hay un efecto secundario agradable: las mismas decisiones mejoran el móvil. Un formulario accesible con etiquetas visibles y botones grandes es un formulario que se rellena con una mano. Lo desarrollamos en diseño web móvil.
No necesitas una auditoría completa para empezar. Estas pruebas detectan la mayoría de los problemas:
- Navega solo con Tab. Recorre la portada y un formulario. Si pierdes el foco o no puedes enviar, tienes trabajo.
- Amplía al 200 %. Si el contenido se solapa o desaparece, el diseño no es robusto.
- Pasa el ratón por los controles. El contraste se mide con herramientas gratuitas; el ojo engaña.
- Escucha la página. En macOS o Windows hay lectores de pantalla integrados. Diez minutos bastan para entender el caos de un formulario sin etiquetas.
- Revisa con una herramienta automática y no te fíes del 100 %: detecta la mitad. La otra mitad se ve usando la web.
Para el detalle normativo, la referencia es la guía rápida de WCAG 2.2 del W3C. No hace falta leerla entera: con los criterios de nivel A y AA tienes el 90 % del trabajo.
- Añadir un widget que promete cumplimiento. Suelen tapar el problema, no resolverlo, y a veces empeoran la navegación.
- Poner
aria-labela todo. Si el HTML ya es semántico, sobra la mitad. El ARIA mal usado estorba. - Ocultar el foco porque “queda feo”. Es el error que más gente deja fuera de la web.
- Texto alternativo automático. Genera frases genéricas que no describen nada útil.
- Arreglar solo la portada. El 404, el blog y el checkout también se usan.
Para muchas Administraciones y empresas que prestan servicios públicos, sí, por normativa europea traspuesta. Para el resto es una recomendación que también protege frente a reclamaciones y mejora la conversión.
Para empezar, no. Con las pruebas de teclado, zoom y contraste detectas lo urgente. Una auditoría tiene sentido cuando la web es grande o cuando hay que certificar el cumplimiento.
Si el diseño está bien construido, unos cientos de euros en ajustes. Si hay que rehacer componentes, más. Lo caro es ignorarlo y tener que rehacerlo con prisa.
Indirectamente, sí. Un HTML semántico, encabezados claros, enlaces descriptivos y buen rendimiento son criterios que Google valora. No hay una “nota de accesibilidad” en el ranking, pero ayuda.