Método
Cómo auditamos la accesibilidad de tu web y qué hay que corregir
Tres fases. En cada una verás lo que hacemos de verdad y lo que queda en manos de tu equipo. La norma técnica de referencia es la UNE-EN 301 549, y trabajamos con WCAG 2.2 nivel AA.
Fase 1
Auditoría: el motor prueba, una persona verifica
Empezamos con el análisis automático de axe-core sobre las reglas de WCAG 2.2 AA. Es rápido y objetivo, pero solo detecta una parte: en la prueba del Gobierno británico con 142 barreras conocidas, la mejor herramienta automática encontró el 40 %.
El resto no sale de un catálogo de reglas: sale de usar la web. Nuestro motor abre cada plantilla crítica (portada, listado, ficha, carrito, pago, formularios) en un navegador de verdad y la maneja:
- Recorre el proceso solo con el teclado, y comprueba dónde queda el foco al abrir ventanas y menús.
- Lee el árbol de accesibilidad que el navegador entrega a un lector de pantalla, que es lo que se anuncia de verdad, no lo que aparenta el HTML.
- Amplía al 200 % y al 400 % para ver si el contenido se reorganiza sin perder nada.
- Mide el contraste de textos, iconos y controles.
- Envía los formularios vacíos para ver si los errores se entienden y se anuncian. Nunca completa pagos, subidas ni acciones que escriban en tu web.
- Compara las páginas entre sí: menú, nombres de destino y ayuda en el mismo sitio, y que no se pida dos veces el mismo dato.
Cada prueba deja constancia del resultado, salga bien o mal, con su captura. Después una persona revisa ese expediente: comprueba la evidencia, resuelve lo que una máquina no puede juzgar —si unos subtítulos sirven, si un texto alternativo describe de verdad la imagen— y firma el informe. Hasta que no está firmado, no se entrega.
Lo que no se ha podido comprobar se dice. Un criterio sin evaluar aparece como sin evaluar, y uno que no le aplica a tu web —subtítulos si no hay vídeo— aparece como no aplicable. Nunca como cumplido.
Cada incumplimiento sale con su criterio WCAG, a quién deja fuera, dónde está y cómo se arregla.
Fuente: Government Digital Service (Reino Unido), What we found when we tested tools on the world's least-accessible webpage · 24 feb 2017
Fase 2
Guía de corrección: qué debe cambiar tu equipo en el código
No tocamos tu web. El informe incluye una guía priorizada, plantilla por plantilla y en tu plataforma, para que la aplique tu equipo técnico o tu agencia sin rehacer nada: primero lo que bloquea compras y tiene más riesgo legal. Estas son las correcciones más habituales, con ejemplos de código para quien las implemente.
HTML semántico
WCAG 1.3.1 y 4.1.2
A quién ayuda: Quien usa lector de pantalla navega por encabezados, regiones y listas, y necesita saber qué es cada cosa.
Sustituir los div que hacen de botón o de enlace por elementos reales, ordenar los encabezados y marcar las regiones de la página.
Antes <div class="btn" onclick="comprar()">Comprar</div>Después <button type="button" onclick="comprar()">Comprar</button>Contraste de 4,5:1
WCAG 1.4.3 y 1.4.11
A quién ayuda: Personas con baja visión, mayores o cualquiera con el móvil al sol.
Cada pareja de colores de texto y fondo, medida con una herramienta y no a ojo. El texto normal necesita al menos 4,5:1; el texto grande y los bordes de los controles, 3:1.
Antes .precio { color: #9ca3af; } /* 2,5:1 sobre blanco */Después .precio { color: #4b5563; } /* 7,6:1 sobre blanco */Foco visible
WCAG 2.4.7 y 2.4.11
A quién ayuda: Quien navega con teclado necesita ver en todo momento dónde está, igual que tú ves el puntero del ratón.
Quitar los outline: none que borran el foco y poner un indicador grueso y con contraste. Comprobar que ninguna cabecera fija lo tape.
Antes *:focus { outline: none; }Después :focus-visible { outline: 3px solid #0b2a8a; outline-offset: 3px; }Objetivos de al menos 24 × 24 px
WCAG 2.5.8
A quién ayuda: Personas con temblor, con poca precisión en las manos o con dedos grandes en una pantalla pequeña.
Ampliar el área pulsable de iconos, botones de cantidad y enlaces sueltos, o darles separación suficiente.
Antes .cantidad button { width: 16px; height: 16px; }Después .cantidad button { min-width: 44px; min-height: 44px; }Formularios etiquetados y errores anunciados
WCAG 1.3.1, 3.3.1, 3.3.2 y 4.1.3
A quién ayuda: Quien no ve el formulario necesita saber qué pide cada campo y qué ha fallado al enviarlo.
Asociar cada campo a su etiqueta, escribir los errores en texto (no solo en rojo), unirlos al campo y hacer que el lector de pantalla los anuncie.
Antes <input placeholder="Email"> <span class="rojo">*</span>Después <label for="email">Correo electrónico</label> <input id="email" type="email" autocomplete="email" aria-invalid="true" aria-describedby="error-email"> <p id="error-email" role="alert">Falta la @ en el correo.</p>Orden de tabulación y teclado
WCAG 2.1.1, 2.1.2 y 2.4.3
A quién ayuda: Quien no usa ratón tiene que poder hacer todo, en un orden que tenga sentido, sin quedarse atrapado.
Que el proceso de compra se complete solo con teclado: sin tabindex positivos, con menús y selectores operables y sin trampas de foco en ventanas emergentes.
Antes <span tabindex="3" onclick="abrirMenu()">Tallas</span>Después <button type="button" aria-expanded="false" aria-controls="tallas">Tallas</button>
Fase 3
Vigilancia: que siga cumpliendo mañana
La accesibilidad se rompe con el uso normal de una web: un banner de campaña, un plugin nuevo, un cambio en el carrito. La ley pide procedimientos para que el servicio siga siendo conforme cuando cambia (artículo 13.5 de la Ley 11/2023).
Con la vigilancia analizamos tus páginas críticas de forma periódica, te avisamos cuando aparece una barrera crítica nueva con la corrección que tiene que aplicar tu equipo.
Fuente: BOE, Ley 11/2023, de 8 de mayo (título I: accesibilidad de productos y servicios), art. 13.5 · 9 may 2023
Empieza por la fase cero
Antes de hablar de auditorías, mira cuánto incumple tu web con el análisis automático. Es gratis y no pide registro.
Analizar mi web gratis