La accesibilidad web consiste en diseñar y desarrollar sitios, contenidos y herramientas para que personas con distintas capacidades puedan percibirlos, comprenderlos, navegarlos e interactuar con ellos. WCAG 2.2 organiza criterios bajo cuatro principios: perceptible, operable, comprensible y robusto. La calidad se evalúa con herramientas y revisión humana; ninguna puntuación automática demuestra por sí sola conformidad.
La accesibilidad beneficia también a personas mayores, usuarios móviles, conexiones limitadas y situaciones temporales como una lesión o un ambiente ruidoso. Debe incorporarse desde investigación y diseño hasta desarrollo, contenido y mantenimiento.
Qué es accesibilidad web
Significa que la web no crea barreras evitables para personas con discapacidades visuales, auditivas, motrices, cognitivas, neurológicas o del habla. Incluye lectura, navegación, entrada de datos, comunicación y contribución.
No es un modo especial que se activa al final. Una estructura semántica, textos claros, controles flexibles y compatibilidad con tecnologías de asistencia forman parte del producto principal.
Qué son las WCAG
Las Web Content Accessibility Guidelines son recomendaciones internacionales del W3C. WCAG 2.2 contiene criterios verificables en niveles A, AA y AAA, acompañados por documentos de comprensión y técnicas. La conformidad exige revisar el conjunto aplicable, no seleccionar ejemplos convenientes.
Las técnicas pueden evolucionar y no todas son obligatorias si existe otra solución que satisface el criterio. Consulta siempre la versión oficial y los requisitos legales del país y sector; este artículo no sustituye asesoría jurídica.
Los cuatro principios POUR
Perceptible: la información se presenta de maneras detectables. Operable: controles y navegación pueden usarse. Comprensible: contenido y comportamiento son claros. Robusto: el código funciona con agentes y tecnologías de asistencia.
Un problema puede tocar varios principios. Un modal sin foco es inoperable; si tampoco anuncia su nombre, falla además la compatibilidad. Investiga el recorrido completo.
Imágenes y texto alternativo
Una imagen informativa necesita un equivalente que comunique su propósito. El texto alternativo depende del contexto: una gráfica resume la conclusión; un icono funcional nombra la acción; una imagen decorativa puede usar alt vacío para que el lector de pantalla la ignore.
No describas cada píxel ni rellenes keywords. Si la imagen contiene información compleja, explica los datos en el texto cercano o una descripción ampliada. Logos enlazados suelen comunicar organización y destino.
Encabezados, regiones y semántica
Usa HTML según significado: encabezados para secciones, listas para conjuntos, tablas para datos y botones para acciones. Las regiones como encabezado, navegación, principal y pie facilitan orientación. No uses un div clicable cuando existe un control nativo.
El orden del código debe conservar sentido sin estilos. Un H1 describe la página y los niveles siguientes organizan contenido; no elijas H3 solo por tamaño visual.
Navegación por teclado
Toda función debe poder operarse sin mouse. Recorre con Tab y Shift+Tab, activa con teclas esperadas y prueba flechas donde el patrón lo exige. El foco debe ser visible, lógico y no quedar atrapado.
Menús, modales, carruseles, autocompletados y editores requieren especial cuidado. Al cerrar un modal, devuelve foco al control que lo abrió. Un enlace “saltar al contenido” evita repetir navegación.
Color y contraste
WCAG define relaciones mínimas según tamaño y tipo de elemento. Verifica texto, iconos informativos, bordes de controles y estados de foco. El valor depende de colores finales, incluida transparencia y fondo.
No uses color como única señal. Añade texto, forma o icono: un error no puede identificarse solo con rojo. Prueba temas, hover, deshabilitados y imágenes con texto superpuesto.
Zoom, reflow y diseño adaptable
El contenido debe soportar ampliación y pantallas estrechas sin perder información ni exigir desplazamiento bidimensional innecesario. Evita alturas fijas, texto recortado y controles que se superponen al aumentar espaciado.
Las tablas complejas pueden desplazarse horizontalmente dentro de un contenedor con nombre, sin romper toda la página. Prioriza lectura y acción sobre preservar una composición rígida.
Formularios y errores
Cada campo necesita etiqueta persistente; placeholder no la reemplaza. Explica formato cuando sea necesario, asocia ayuda y marca requeridos de forma accesible. Agrupa opciones relacionadas con fieldset y legend.
Al fallar, identifica campos, describe el problema y sugiere corrección. Lleva foco o resumen de errores de manera predecible y conserva información válida. En decisiones legales o financieras, permite revisar y corregir.
Enlaces, botones y tamaño de objetivo
Un enlace navega; un botón ejecuta. El nombre accesible debe expresar propósito, preferiblemente desde el texto visible. “Haz clic aquí” repetido pierde contexto. Mantén identificación consistente para acciones equivalentes.
Los objetivos táctiles necesitan espacio y separación. WCAG 2.2 incorpora criterios de tamaño mínimo con excepciones; revisa el texto normativo. Evita acciones dependientes solo de arrastrar cuando pueda ofrecerse una alternativa.
Audio, video y movimiento
Proporciona subtítulos para contenido hablado y alternativas según el medio y nivel. Las transcripciones facilitan búsqueda y consulta; la audiodescripción comunica información visual relevante. Los controles deben ser accesibles.
No reproduzcas audio inesperado. Permite pausar movimiento y respeta preferencias de reducción de movimiento. Evita destellos que puedan provocar reacciones.
ARIA: cuándo usarla
ARIA comunica nombre, rol, estado y relaciones cuando HTML nativo no alcanza. No añade interacción automáticamente. Un elemento con role="button" sigue necesitando teclado, foco y eventos correctos.
Prefiere elementos nativos y patrones documentados. Mantén estados como expandido, seleccionado o inválido sincronizados con la interfaz. Un atributo desactualizado puede empeorar la experiencia.
Contenido comprensible
Declara idioma, usa frases directas, explica términos y estructura con títulos descriptivos. La lectura clara no significa simplificar de forma infantil; significa reducir ambigüedad y ayudar a encontrar información.
Los mensajes deben anticipar consecuencias. Un botón “Eliminar cuenta” es mejor que “Continuar”. Mantén navegación y ayuda en ubicaciones consistentes.
Autenticación accesible
Evita pruebas cognitivas sin alternativa. Permite gestores de contraseñas, pegar códigos y métodos compatibles. WCAG 2.2 incorpora criterios sobre autenticación accesible; evalúa el flujo completo, incluidos recuperación y segundo factor.
Seguridad y accesibilidad no son opuestas. Diseña opciones equivalentes y consulta riesgos con ambos equipos.
Cómo evaluar accesibilidad
- Define alcance, versión WCAG y nivel objetivo.
- Selecciona plantillas, estados y tareas críticas.
- Ejecuta herramientas automáticas.
- Navega solo con teclado.
- Prueba zoom, reflow y contraste.
- Usa lectores de pantalla relevantes.
- Revisa contenido y formularios.
- Incluye usuarios con discapacidad cuando sea posible.
- Documenta evidencia, impacto y corrección.
W3C señala que ninguna herramienta sola determina accesibilidad. La automatización encuentra patrones; la revisión experta decide significado y experiencia.
Cómo priorizar hallazgos
Prioriza bloqueos de tareas críticas, alcance por plantilla, severidad, frecuencia y personas afectadas. Un checkout imposible con teclado supera en urgencia a una advertencia aislada de una página secundaria.
Corrige componentes del sistema antes que instancias. Define criterio de aceptación y prueba de regresión. No marques “resuelto” porque cambió el código; verifica el recorrido.
Relación con SEO y conversión
Semántica, alternativas, títulos, enlaces y experiencia pueden ayudar a comprensión y uso, pero accesibilidad no es un truco de ranking. Su objetivo es acceso equitativo. Tampoco garantiza conversión: elimina barreras que impedían completar tareas.
Evalúa resultados por segmento con cuidado y no uses datos de discapacidad para perfilar sin una razón legítima. El servicio de diseño UX/UI puede integrar accesibilidad desde componentes.
Gobernanza y mantenimiento
Asigna responsabilidades a contenido, diseño, desarrollo y QA. Añade criterios a briefs, diseños, revisiones de código y definición de terminado. Mantén componentes accesibles y documentación de uso.
Audita en cada release y periódicamente. Capacita equipos y ofrece un canal accesible para reportar barreras. Publicar una declaración no sustituye resolver problemas.
Accesibilidad en móvil y entradas diversas
Prueba orientación, zoom, lector de pantalla móvil, tamaño de objetivos y gestos. No obligues a rotar el dispositivo ni dependas de movimientos complejos. Una acción por arrastre debe tener alternativa simple cuando aplique; un control debe tolerar toque impreciso.
Teclado no es la única entrada. Voz, interruptores, stylus y tecnologías de asistencia pueden generar eventos equivalentes. Evita detectar capacidad desde el dispositivo y retirar funciones; construye controles que respondan a estándares.
Accesibilidad en el sistema de diseño
Documenta variantes de botones, enlaces, campos, menús, modales, avisos y tablas con comportamiento de teclado, nombre, rol, estado y contraste. Incluye ejemplos correctos y usos prohibidos. Así cada equipo no vuelve a resolver el mismo patrón.
Los tokens de color pueden indicar combinaciones aprobadas, pero deben probarse en contextos reales. Un componente accesible puede volverse inaccesible al recibir una etiqueta vacía, orden incorrecto o contenido demasiado largo. Define contratos de contenido y pruebas automáticas.
Documentos, correos y contenido descargable
La experiencia no termina en HTML. PDF, hojas, presentaciones y correos necesitan estructura, orden de lectura, contraste, alternativas y enlaces claros. Si un trámite depende de un documento inaccesible, el flujo completo conserva la barrera.
Prioriza formatos web cuando faciliten adaptación y mantén el archivo como alternativa cuando sea necesario. Prueba lectores y exportaciones; un documento que se ve bien puede perder encabezados y etiquetas al convertirse.
Compras y proveedores
Incluye requisitos de accesibilidad en selección, contrato y aceptación. Pide evidencia por criterio y tareas, no una declaración genérica. Evalúa componentes de terceros como chat, pagos, mapas, reservas y CAPTCHA porque pueden bloquear el recorrido aunque el sitio principal esté bien.
Define qué ocurre cuando un proveedor no corrige: alternativa accesible, plazo o sustitución. Conserva versiones y cambios. La responsabilidad de experiencia no desaparece al incorporar un servicio externo.
Durante una renovación, repite tareas críticas con la versión actual. Un informe antiguo no cubre nuevas interfaces ni integraciones. Registra excepciones, impacto, compensación temporal, responsable y fecha comprometida; las excepciones permanentes tienden a convertirse en barreras olvidadas que luego resultan mucho más costosas de reparar.
Errores frecuentes
- Confiar solo en una puntuación.
- Instalar un overlay como solución total.
- Quitar el indicador de foco.
- Usar ARIA sobre HTML incorrecto.
- Confundir placeholder con etiqueta.
- Depender solo del color.
- Publicar video sin alternativas.
- Corregir páginas sin sistema.
Checklist inicial
Prueba título e idioma, jerarquía, landmarks, teclado, foco, contraste, zoom, alternativas, formularios, mensajes, multimedia, modales y autenticación. Hazlo en plantillas y estados reales, incluido error y sin datos.
Para evaluar diseño y desarrollo puedes contactar a SEOMOS. Un diagnóstico serio debe declarar alcance, estándar, herramientas y limitaciones.
Fuentes consultadas
Documentación consultada el 10 de septiembre de 2026.
- W3C WAI: introducción a accesibilidad web.
- W3C WAI: referencia rápida WCAG 2.2.
- W3C WAI: pruebas y evaluación.
Preguntas frecuentes sobre accesibilidad web
¿Qué es accesibilidad web?
Es diseñar y desarrollar para que personas con distintas capacidades puedan percibir, comprender, navegar e interactuar.
¿Qué significa WCAG?
Web Content Accessibility Guidelines, pautas del W3C con criterios verificables de accesibilidad.
¿Una herramienta confirma cumplimiento?
No. La evaluación automática cubre una parte; se necesita revisión humana informada.
¿Accesibilidad mejora SEO?
Varias prácticas también favorecen comprensión y uso, pero accesibilidad no debe reducirse a una táctica SEO.
¿Qué se corrige primero?
Barreras que bloquean tareas críticas y componentes que afectan muchas páginas.
¿Es un proyecto de una sola vez?
No. Debe integrarse a contenido, diseño, desarrollo, QA y mantenimiento continuo.
