Desde el 28 de junio de 2025, la accesibilidad web dejó de ser una opción. La European Accessibility Act obliga a un número creciente de empresas y administraciones a que sus webs y apps cumplan la norma WCAG 2.1 nivel AA. Pero, más allá de la obligación legal, una web accesible es una web que funciona mejor para todo el mundo.
En Databot hemos auditado webs institucionales y corporativas bajo este estándar, y hay un patrón que se repite: de los 50 criterios técnicos que evaluamos, los fallos casi siempre se concentran en los mismos 5. Aquí te explicamos cuáles son, cómo los detectamos y cómo se corrigen sin rehacer la web desde cero.
Qué revisamos en una auditoría de accesibilidad
Una auditoría WCAG 2.1 AA evalúa 50 criterios técnicos repartidos en cuatro principios: que el contenido sea perceptible, operable, comprensible y robusto. En la práctica, la mayoría de los fallos que encontramos se agrupan en cinco bloques.
01
Contraste de color
Texto y fondo deben tener una relación de contraste mínima de 4,5:1 en texto normal y 3:1 en texto grande o elementos de interfaz. Es el fallo más habitual: gris claro sobre blanco, texto sobre imágenes, botones con poco contraste.
02
Navegación por teclado
Cualquier persona debe poder moverse por la web sin ratón: con tabulador, flechas e intro. El fallo típico es que el foco, el indicador visual que muestra en qué elemento estás en cada momento, desaparece o no se ve al navegar así.
03
Texto alternativo en imágenes
Cada imagen con significado necesita un atributo alt que describa su contenido, para que un lector de pantalla pueda transmitirlo. El error habitual: alt="" en imágenes informativas, o directamente ausente.
04
Formularios y mensajes de error
Un formulario accesible no solo marca el campo con error: dice qué está mal y cómo solucionarlo, y lo asocia al campo mediante código (no solo con color). El fallo común: campos en rojo sin ningún texto que explique el problema.
05
Jerarquía de encabezados
Los encabezados (H1, H2, H3…) deben seguir un orden lógico, sin saltos, porque los lectores de pantalla los usan para navegar el contenido como un índice. El error frecuente: usar un H4 porque “queda mejor” visualmente, no porque le corresponda ese nivel.
Cómo se corrige, sin rehacer la web
La buena noticia es que ninguno de estos cinco fallos exige una reconstrucción completa:
- Contraste: se corrige a nivel de sistema de diseño, ajustando las variables de color que usa toda la web, no página a página.
- Foco de teclado: se soluciona con una regla CSS y algo de JavaScript, sin tocar el contenido.
- Texto alternativo: se completa por prioridad, empezando por las imágenes con más tráfico o más relevancia funcional (iconos de acción, imágenes de producto).
- Mensajes de error: se arreglan a nivel de componente, así se corrigen todos los formularios de la web a la vez.
- Jerarquía de encabezados: se revisa por plantilla, no artículo por artículo.
En la mayoría de los casos, corregir estos cinco bloques resuelve entre el 70 y el 80% de los problemas detectados en la auditoría completa. El 20-30% restante se reparte entre otros 45 criterios WCAG, como el idioma de la página, los subtítulos en vídeo, el orden de tabulación, los enlaces “saltar al contenido” o las tablas de datos accesibles. Por eso estos cinco no sustituyen una auditoría completa: la hacen mucho más abordable.
Por qué merece la pena hacerlo bien
La accesibilidad no es solo para personas con discapacidad. Más contraste ayuda a cualquiera que usa el móvil al sol. Un foco de teclado visible ayuda a quien navega con atajos por comodidad, no por necesidad. Una jerarquía de encabezados clara también ayuda al SEO, porque Google “lee” la web de forma parecida a un lector de pantalla.
Y desde junio de 2025, para muchas organizaciones ya es ley.
¿Sabes qué fallos tiene tu web?
Hacemos auditorías de accesibilidad WCAG 2.1 sobre webs institucionales y corporativas, con diagnóstico priorizado y plan de corrección.
