Accesibilidad web para empresas: guía práctica con WCAG 2.2

La accesibilidad web consiste en diseñar y construir sitios que puedan ser percibidos, entendidos y utilizados por personas con distintas capacidades, dispositivos y formas de interacción. Incluye a quienes navegan con lector de pantalla, teclado, ampliación, control por voz o configuraciones personalizadas de color y tamaño.

No es una función aislada ni un botón que se agrega al final. Depende de decisiones de contenido, diseño, código y operación: títulos claros, formularios comprensibles, controles identificables, videos con alternativas y procesos que no exijan una única forma de interactuar.

Una mejora de accesibilidad puede beneficiar también a personas con una lesión temporal, mala iluminación, conexión limitada o una pantalla pequeña. El objetivo es eliminar barreras sin crear una versión separada del sitio.

Las Web Content Accessibility Guidelines —WCAG— del W3C organizan la accesibilidad alrededor de cuatro principios: perceptible, operable, comprensible y robusto. WCAG 2.2 fue publicada como Recomendación del W3C el 5 de octubre de 2023 y continúa siendo una referencia técnica vigente para evaluar contenido web.

Perceptible significa que la información no depende de un solo sentido; operable, que los controles pueden utilizarse con distintas entradas; comprensible, que contenido e interacción son claros; y robusto, que el código puede ser interpretado de manera confiable por navegadores y tecnologías de asistencia.

Las pautas ayudan a definir requisitos y pruebas, pero aplicarlas no consiste en marcar una lista de forma mecánica. Es necesario entender el propósito de cada página y comprobar si una persona puede completar la tarea real.

Los problemas suelen aparecer en componentes cotidianos: menú, formulario de contacto, buscador, cotizador, carrito, modal o selector de idioma. Una página puede verse correcta con mouse y pantalla grande, pero fallar cuando se amplía el contenido o se navega únicamente con teclado.

Revisa primero las rutas que generan valor: conocer un servicio, solicitar información, comprar, reservar, descargar un documento o iniciar sesión. Si una barrera impide completar esas tareas, su prioridad es mayor que la de un error aislado en una página secundaria.

• Imágenes informativas sin texto alternativo útil.
• Texto o controles con contraste insuficiente respecto del fondo.
• Campos sin etiquetas visibles o mensajes de error poco claros.
• Botones que solo muestran un icono sin nombre accesible.
• Menús, modales o calendarios que no funcionan con teclado.
• Enfoque invisible o recorrido de tabulación desordenado.
• Encabezados elegidos por tamaño visual y no por estructura.
• Videos sin subtítulos o instrucciones que dependen únicamente del color.

Utiliza títulos descriptivos y una jerarquía de encabezados coherente. Los enlaces deben indicar su destino sin depender de frases repetidas como “haz clic aquí”. Divide instrucciones extensas en pasos y coloca la información necesaria cerca de la acción correspondiente.

El color no debería ser la única forma de comunicar un estado. Si un campo incorrecto tiene borde rojo, agrega también un mensaje que explique el problema. Mantén contraste suficiente y verifica estados normales, activos, visitados, deshabilitados y de enfoque, no solamente el texto principal.

Permite ampliar el contenido sin que botones, textos o columnas se superpongan. Evita fijar alturas cuando el contenido puede crecer y comprueba el sitio con zoom. Una versión móvil limpia no garantiza por sí sola que la interfaz responda bien a ampliación o configuraciones de texto diferentes.

Una persona debe poder llegar a controles y operarlos sin mouse. Recorre cada página con Tab y Shift+Tab, activa botones con teclado y confirma que el foco siempre sea visible. El orden debe seguir la secuencia lógica del contenido.

Cuando se abre un modal, el foco debe moverse al diálogo, permanecer dentro mientras esté abierto y regresar al control que lo activó al cerrar. Los menús desplegables, pestañas y acordeones necesitan comportamiento predecible y nombres que las tecnologías de asistencia puedan interpretar.

Prefiere elementos HTML nativos como button, input, label y nav. Si un elemento visual se convierte en control mediante código personalizado, el equipo debe reproducir nombre, rol, estado, teclado y foco que el componente nativo ya ofrece.

Cada campo necesita una etiqueta asociada que permanezca comprensible aunque el usuario ya haya escrito. Un placeholder puede mostrar un ejemplo, pero no debería sustituir la etiqueta. Agrupa opciones relacionadas y explica los formatos requeridos antes de que ocurra el error.

Cuando una validación falla, identifica el campo, describe qué debe corregirse y conserva la información válida. Lleva el foco al resumen de errores o al primer problema de forma predecible. No dependas únicamente de color, animación o un mensaje que desaparece rápido.

Revisa especialmente contacto, registro, pago, búsqueda y carga de archivos. Prueba tiempos límite, confirmaciones y recuperación ante errores. Una persona debe poder saber qué ocurrió y qué hacer después.

El texto alternativo debe comunicar la función o información relevante de una imagen dentro de su contexto. Una fotografía decorativa puede tener alternativa vacía; una gráfica necesita explicar la conclusión o proporcionar los datos equivalentes; un icono usado como botón requiere un nombre de acción.

Los videos necesitan alternativas acordes con su contenido, como subtítulos y, cuando sea necesario, descripción de información visual. Evita reproducir audio inesperadamente y proporciona controles que se puedan localizar y operar.

Los archivos descargables también forman parte de la experiencia. Un PDF o presentación inaccesible puede interrumpir el proceso aunque la página esté bien construida. Evalúa si la información puede publicarse como HTML y revisa estructura, lectura y formularios de los documentos indispensables.

Las herramientas automáticas pueden detectar problemas como atributos faltantes, relaciones incorrectas y ciertas combinaciones de contraste. Son útiles para revisar muchas páginas y evitar regresiones, pero no pueden decidir por sí solas si un texto alternativo explica la imagen, si el orden de lectura tiene sentido o si una tarea es comprensible.

El W3C advierte que ninguna herramienta puede determinar automáticamente todos los aspectos de accesibilidad y que la evaluación requiere juicio humano. Combina análisis automático con navegación por teclado, revisión de contenido, lector de pantalla y pruebas de los flujos principales.

Un puntaje alto no equivale a ausencia de barreras. Registra cada hallazgo con página, componente, impacto, criterio relacionado, evidencia y recomendación. Prioriza problemas que bloquean tareas y componentes reutilizados que afectan muchas rutas.

Empieza con un inventario de plantillas, componentes, documentos y procesos críticos. Evalúa una muestra representativa y crea una lista priorizada. Corrige primero la base compartida —encabezado, navegación, botones, formularios y estilos— para que las mejoras alcancen más páginas.

Integra criterios de accesibilidad en diseño, desarrollo y publicación de contenido. Define pruebas para cada componente, capacita a quien sube imágenes o documentos y agrega revisiones al proceso antes de publicar. Monitorea cambios y vuelve a probar cuando se modifica una ruta crítica.

MTORI puede ayudarte a revisar la experiencia, corregir componentes y convertir la accesibilidad en parte del mantenimiento continuo. La evaluación técnica no sustituye asesoría legal sobre obligaciones aplicables; si necesitas determinar requisitos normativos, consulta a un especialista competente en tu jurisdicción.