Antes de contratar una auditoría de accesibilidad, la mayoría de las agencias necesita responder una pregunta más simple: ¿el sitio de mi cliente tiene problemas evidentes o no? Este checklist cubre los criterios de WCAG 2.1 nivel AA que fallan con más frecuencia en sitios WordPress, con instrucciones concretas para revisarlos sin herramientas especializadas.
No sustituye una auditoría técnica completa. Sirve para hacer un primer diagnóstico y decidir con datos si el sitio necesita remediación.
Contraste de color
El criterio 1.4.3 exige una ratio de contraste mínima de 4,5:1 entre texto y fondo para texto normal, y 3:1 para texto grande (24px o más, o 18,7px en negrita).
Cómo revisarlo: abre las DevTools de Chrome, selecciona un elemento de texto con el inspector, y el panel de estilos muestra la ratio de contraste calculada junto al valor del color. Si aparece un ícono de advertencia, el contraste no cumple.
Los errores más comunes en WordPress: texto gris claro sobre fondo blanco en textos secundarios, botones con texto blanco sobre colores de marca poco saturados, y placeholders de formulario usados como si fueran etiquetas visibles.
Navegación por teclado
El criterio 2.1.1 exige que toda la funcionalidad del sitio esté disponible sin ratón. El criterio 2.4.7 exige que el elemento con foco sea visible.
Cómo revisarlo: desconecta el ratón y navega el sitio completo con Tab, Shift+Tab y Enter. Verifica tres cosas: que el foco pase por todos los elementos interactivos en un orden lógico, que el indicador de foco sea visible en cada uno, y que ningún elemento atrape el foco sin dejar salir.
El error más común en temas de WordPress es el outline de foco eliminado por CSS (`outline: none`) sin un reemplazo visual. Sin ese indicador, un usuario que navega por teclado no sabe dónde está parado.
Formularios sin etiquetas
El criterio 1.3.1 y el 3.3.2 exigen que cada campo de formulario tenga una etiqueta programática asociada, no solo un placeholder o un texto visual cercano.
Cómo revisarlo: inspecciona el HTML de cada campo. Cada `input` necesita una etiqueta `label` con el atributo `for` apuntando al `id` del campo, o el atributo `aria-label`. Un placeholder no cuenta como etiqueta: desaparece al escribir y no lo leen todos los lectores de pantalla de la misma forma.
En WordPress esto falla con frecuencia en formularios de plugins de terceros configurados solo con placeholder, y en checkouts de WooCommerce personalizados donde se ocultó el label por diseño sin dejar la versión accesible.
Jerarquía de encabezados
El criterio 1.3.1 exige una estructura de encabezados coherente, sin saltos de nivel usados por estética en vez de por estructura.
Cómo revisarlo: instala la extensión HeadingsMap en Chrome o usa el inspector de accesibilidad de las DevTools. El sitio debe tener un único H1 por página, y los niveles siguientes (H2, H3) deben seguir un orden lógico sin saltar niveles.
El error más común: usar un H3 en vez de un H2 porque el H3 tiene el tamaño de letra que el diseño pide, en lugar de ajustar el CSS y mantener el H2 semánticamente correcto.
Texto alternativo en imágenes
El criterio 1.1.1 exige texto alternativo para toda imagen que transmita información. Las imágenes puramente decorativas deben tener `alt=»»` vacío, no ausente.
Cómo revisarlo: inspecciona el HTML de cada imagen relevante (logo, iconos con función, imágenes de producto, gráficos). Si el atributo `alt` no existe o describe el archivo en vez del contenido («imagen-1.jpg» en vez de «captura del panel de precios»), no cumple.
En WordPress, la biblioteca de medios permite cargar el texto alternativo al subir la imagen, pero rara vez se completa por defecto. Es el criterio que más rápido se corrige y el que más frecuentemente se ignora.
Qué hacer con los resultados
Si el checklist detecta uno o dos fallos puntuales, la corrección puede hacerse internamente con el equipo de desarrollo. Si aparecen fallos en varios de estos cinco puntos a la vez, el sitio probablemente tiene un problema estructural en el tema o en la configuración base, no errores aislados de contenido. En ese caso conviene una [auditoría técnica completa](https://kalymastudio.es/soluciones/accesibilidad-web/) antes de intentar corregir punto por punto, porque los errores estructurales suelen repetirse en todas las páginas que comparten header, footer y formularios.
El nivel AA verificado en este checklist es el mismo que exige el RD 1112/2018 y la Ley 11/2023 no hay margen de interpretación sobre el estándar técnico, solo cambia a quién obliga cada norma. Si el diagnóstico confirma que el sitio no cumple, el siguiente paso documental es la Declaración de Accesibilidad, que debe reflejar el estado real del sitio una vez corregido.
