Accesibilidad

Accesibilidad en WordPress Enterprise, integrada en los bloques con los que publica tu equipo

WCAG 2.1 AA es una disciplina de diseño, desarrollo y QA, no un plugin que se activa. Construimos componentes semánticos y operables por teclado, escaneamos cada build de staging y probamos a mano lo que un escáner no puede ver.

Qué dejamos resuelto desde el inicio

Las decisiones de accesibilidad que salen más baratas al principio que como retrofit

La mayor parte de la deuda de accesibilidad en un sitio WordPress enterprise es estructural: viene de los componentes, no del contenido. Corregirla después del lanzamiento implica tocar todas las páginas que los usan.

Un estándar escrito, acordado antes de construir

WCAG 2.1 AA declarado como objetivo en los criterios de aceptación de cada componente, o un nivel más alto donde haga falta. Si queda implícito, termina siendo una discusión sobre si algo cuenta como defecto, ya con el componente en producción.

Contraste y jerarquía validados en diseño

Combinaciones de color verificadas contra los ratios de contraste de WCAG en Figma con el WebAIM Contrast Checker, mientras el diseño todavía se puede editar. Jerarquía de encabezados, landmarks y orden de tabulación documentados antes de construir nada.

HTML semántico en cada bloque

Encabezados que avanzan de a un nivel por vez, elementos button y link reales en lugar de divs clickeables, regiones landmark por las que un lector de pantalla pueda desplazarse, y ARIA solo donde la semántica nativa no alcanza.

Comportamiento de teclado especificado por componente

Menús, modales, sliders y acordeones salen con un orden de foco definido, un estado de foco visible y una salida con Escape que funciona, especificados durante el diseño y no descubiertos en QA, cuando cambiarlos implica rehacerlos.

Formularios que se explican solos

Cada campo lleva una etiqueta programática, el texto de ayuda se asocia con aria-describedby y los errores de validación se anuncian a la tecnología asistiva en vez de comunicarse únicamente pintando un borde de rojo.

Cómo funciona

La accesibilidad se controla en cuatro puntos de la entrega

Cada etapa detecta una clase de problema que la siguiente ya no puede resolver barato.

1

Diseño

Ratios de contraste validados, jerarquía de encabezados y landmarks acordados, y comportamiento de teclado para menús, modales y sliders escrito como requisito.

2

Desarrollo

Markup semántico y manejo de foco aplicados bloque por bloque contra nuestra guía interna de accesibilidad, con los elementos interactivos exponiendo su estado de forma programática.

3

QA

axe DevTools y Lighthouse en staging, una pasada solo con teclado por las páginas clave, escaneos con Accessibility Checker Pro y notas sobre cada hallazgo.

4

Salida a producción y después

Un informe con lo resuelto y lo que queda abierto, un checklist para tus editores y una revisión una vez que usuarios reales usaron el sitio.

Qué afirmamos y qué no

Un escaneo automático prueba menos de lo que la mayoría de los proveedores insinúa

Las herramientas automáticas reportan violaciones de reglas, y las reglas son solo una parte de WCAG. Esa diferencia es la que separa un sitio que pasa un escaneo de un sitio que la gente puede usar.

Lo que un escáner detecta

Fallas verificables por máquina: atributos alt faltantes, contraste por debajo del umbral, controles de formulario sin etiqueta, orden de encabezados roto, roles landmark duplicados. Vale la pena corregirlas en cada build, y esta es la capa que automatizamos.

Lo que no puede detectar

Si el texto alternativo describe la imagen. Si el orden de foco sigue al orden visual. Si una etiqueta ARIA dice lo que el control realmente hace. Si un mensaje de error explica cómo resolver el problema. Los cuatro pasan un escaneo y le fallan a una persona.

Qué hacemos con esa brecha

Navegación solo con teclado y pruebas base con lector de pantalla sobre los flujos que importan, más una entrega que separa lo verificado automáticamente de lo verificado a mano, y lo que sigue abierto.

Lo que los equipos enterprise nos preguntan sobre accesibilidad en WordPress

Vale la pena leerlo aunque nunca nos contrates.

Contenido relacionado

Seguí leyendo sobre accesibilidad y compliance

Por qué la accesibilidad importa a escala enterprise, y dónde se ubica dentro de un programa de compliance más amplio.

Da el siguiente paso

Pedí una revisión WCAG 2.1 AA de tu sitio

Escaneamos tus plantillas clave, hacemos una pasada con teclado y lector de pantalla sobre los flujos que importan, y te enviamos los hallazgos con las verificaciones manuales listadas por separado de las automáticas.

Pedir una revisión de accesibilidad Hablar con un especialista en accesibilidad