Resumen: La accesibilidad web no es una lista de comprobación que se ejecuta justo antes de publicar. Funciona mejor cuando forma parte de la planificación, la arquitectura de información, el diseño de interfaz, el desarrollo, la operación de contenidos y la verificación. WCAG 2.2 pone atención en aspectos muy prácticos de la calidad de una interfaz: el foco no debe quedar oculto, debe haber alternativas al arrastre, los objetivos táctiles deben ser utilizables, no conviene pedir la misma información varias veces y los procesos de autenticación no deben crear barreras innecesarias.
Si necesitas una base previa, consulta nuestras guías relacionadas sobre operación de accesibilidad web después de publicar y diseño de alternativas para imágenes, video e información no textual. Este artículo se centra en cómo clientes y equipos de producción pueden convertir la accesibilidad en trabajo repetible.
Por qué corregir al final aumenta el riesgo
La accesibilidad suele parecer difícil porque se aborda demasiado tarde. Cuando un equipo intenta corregir contraste, estructura de encabezados, etiquetas de formularios, comportamiento con teclado y textos alternativos justo antes del lanzamiento, el trabajo puede volver al diseño visual, las plantillas del CMS, el comportamiento de JavaScript y las reglas editoriales. En ese momento ya no es una simple revisión de calidad, sino un cambio estructural tardío.
Cuando la accesibilidad se trata como requisito desde el inicio, las decisiones son más claras. Los botones se definen no solo por su apariencia, sino también por su nombre, estado y forma de operación. Las imágenes se clasifican como decorativas o informativas durante la planificación de contenidos. Los formularios incluyen mensajes de error y recuperación en la especificación. Estas pequeñas decisiones mejoran la usabilidad para los visitantes y la mantenibilidad para el equipo.
En Japón, la ley modificada para eliminar la discriminación contra las personas con discapacidad entró en vigor el 1 de abril de 2024 e hizo obligatoria la provisión de ajustes razonables para las empresas. Esto no significa que todos los sitios web deban cumplir automáticamente un nivel específico de WCAG en cualquier contexto. Sí significa que las organizaciones deben poder responder a barreras y mejorar de forma continua el acceso a la información y a los procedimientos digitales.
Usa WCAG 2.2 como base y luego prioriza
WCAG 2.2 es un estándar técnico internacional para hacer que el contenido web sea más accesible. W3C explica que WCAG 2.2 amplía WCAG 2.1 y está diseñado para que el contenido conforme con WCAG 2.2 también sea conforme con WCAG 2.0 y 2.1. La traducción japonesa de WAIC resume nuevos criterios de conformidad como foco no oculto, movimientos de arrastre, tamaño del objetivo, entrada redundante y autenticación accesible.
| Área | Qué revisar | Problema común |
|---|---|---|
| Perceptible | No depender solo del color, mantener contraste, admitir aumento de texto | Texto demasiado claro, texto dentro de imágenes, vistas móviles comprimidas |
| Operable | Uso con teclado, foco visible, tamaño de objetivos, alternativas al arrastre | El usuario no puede salir de menús o modales, o no ve dónde está el foco |
| Comprensible | Encabezados, etiquetas, mensajes de error, ayuda, reutilización de datos introducidos | Los formularios no explican qué corregir o piden la misma información repetidamente |
| Robusto | HTML semántico, nombres y estados para tecnologías de asistencia, reglas de CMS | La página se ve bien, pero su estructura no se comunica a las herramientas de asistencia |
No es necesario resolver todo de una vez. Empieza por los flujos de conversión principales, formularios, artículos con mucho tráfico, plantillas centrales y páginas que los usuarios necesitan para completar tareas importantes.
Qué definir antes de encargar el trabajo
Antes de empezar diseño o desarrollo, el cliente debe definir responsabilidades de accesibilidad junto con dirección visual y requisitos funcionales. Si no se hace, diseño, ingeniería, contenido y operación pueden asumir que otra persona está revisando la experiencia completa.
- Objetivo: Decide si el proyecto tomará como referencia WCAG 2.2 A o AA, y qué alcance es realista para un sitio existente.
- Alcance de páginas: Prioriza inicio, páginas de campaña, formularios, plantillas de artículos, pantallas de cuenta y otras áreas de alto impacto.
- Verificación: Acuerda pruebas automáticas, revisión con teclado, lector de pantalla, dispositivos reales y revisión experta cuando sea necesario.
- Entregables: Conserva especificaciones de componentes, reglas de texto alternativo, reglas de entrada en CMS y registros de prueba, no solo pantallas corregidas.
- Operación: Asegúrate de que las personas que agregan artículos, banners y campos de formulario puedan mantener la calidad después del lanzamiento.
La guía de la Agencia Digital de Japón está pensada para ayudar a principiantes, incluidos equipos administrativos y de servicios, a comunicarse sobre accesibilidad en contratación y entrega. Ese enfoque sirve también fuera del sector público: la accesibilidad debe traducirse a un lenguaje que puedan usar planificación, comunicación, atención al cliente, área legal y operaciones.
Puntos prioritarios para diseño e implementación
1. Empieza por encabezados y regiones
Si la estructura de la página es confusa, algunos usuarios pueden escanearla visualmente, pero las tecnologías de asistencia quizá no comuniquen bien la relación entre secciones. Mantén el orden de H2 y H3, define navegación, contenido principal, áreas complementarias y pie de página, y evita que los autores del CMS usen encabezados solo como decoración.
2. Completa la tarea con teclado
Las interfaces dependientes del ratón suelen fallar en modales, menús desplegables, carruseles, selectores de fecha y widgets de chat. Confirma que se pueda avanzar con Tab en un orden lógico, ver el foco actual, cerrar capas superpuestas y evitar quedar atrapado. La visibilidad del foco merece diseño explícito, no solo el estilo por defecto del navegador.
3. Diseña la recuperación de formularios, no solo los campos
En formularios de contacto, reserva, compra o solicitud, especifica etiquetas, campos obligatorios, ejemplos, mensajes de error, movimiento hacia los errores, pasos de confirmación y preservación de datos introducidos. Los errores indicados solo con color, los mensajes vagos en la parte superior o la eliminación de datos tras un fallo aumentan el abandono.
4. Decide si imágenes y videos son decorativos o informativos
Si una imagen es decorativa, no debe crear ruido para las tecnologías de asistencia. Si transmite información, el texto alternativo o el texto cercano debe permitir tomar la misma decisión sin verla. En video, revisa subtítulos, información visual relevante que no aparece en el audio y controles de reproducción accesibles.
5. Trata móvil como un contexto de revisión propio
Una página que funciona en escritorio puede fallar en móvil porque los objetivos son demasiado pequeños, las cabeceras fijas ocultan el foco, los campos quedan fuera de vista o el zoom produce desplazamiento horizontal. Varias incorporaciones de WCAG 2.2 están ligadas a estos fallos prácticos de interfaz.
Las pruebas automáticas son la entrada, no el juicio final
Las herramientas automáticas de accesibilidad son útiles para detectar textos alternativos ausentes, campos sin etiqueta, fallos de contraste y problemas estructurales de HTML. No pueden juzgar por completo si el texto se entiende, si el texto del enlace encaja con el contexto, si el orden del foco resulta natural, si una descripción de imagen es significativa o si el usuario puede completar una tarea clave sin confusión.
Una secuencia práctica consiste en eliminar fallos evidentes con pruebas automáticas, probar manualmente la operación con teclado y los flujos centrales, y añadir revisión experta o pruebas con usuarios cuando el riesgo lo justifique. La accesibilidad no es una auditoría única; es un hábito operativo respaldado por mejoras documentadas.
Reglas para proteger la calidad después del lanzamiento
Muchos sitios pierden calidad de accesibilidad después de la construcción inicial. Los autores usan encabezados como decoración, las campañas dependen de texto dentro de banners, se publican nuevos campos de formulario sin etiquetas o el contenido incrustado se vuelve difícil de navegar. Son problemas operativos, no solo de desarrollo.
Una lista breve de publicación ayuda: antes de publicar, revisa orden de encabezados, texto de enlaces, tratamiento de imágenes, encabezados de tablas, subtítulos, errores de formularios y visualización móvil. Corrige pequeños problemas cada mes en lugar de esperar a un rediseño mayor. Con el tiempo, la accesibilidad se convierte en calidad editorial y de desarrollo normal.
Preguntas frecuentes
¿La accesibilidad ayuda al SEO?
No garantiza posiciones, pero la estructura de encabezados, enlaces descriptivos, textos alternativos, contenido legible y formularios fáciles de completar mejoran la experiencia después de que llega el tráfico de búsqueda. Conviene tratar la accesibilidad como diseño de información para personas, no solo como táctica de búsqueda.
¿Los sitios pequeños también deberían ocuparse?
Sí. No necesitan resolver todo de una vez, pero deberían mejorar rutas importantes como contacto, reserva, compra y solicitud de documentos. Como suelen tener menos plantillas, corregir la estructura puede mejorar muchas páginas a la vez.
¿Por dónde empezar?
Elige una página clave y revisa encabezados, enlaces, imágenes, formularios, operación con teclado y comportamiento móvil. Después usa lo aprendido para mejorar plantillas compartidas y reglas del CMS, de modo que las futuras actualizaciones aprovechen las mismas correcciones.