Desarrollo web accesible
Cómo construir sitios web que funcionen para todos, sin excepción
La accesibilidad web (a11y) no es un extra opcional: es un requisito técnico, legal y ético. Más de mil millones de personas en el mundo viven con alguna forma de discapacidad, y un porcentaje significativo interactúa con la web a través de tecnologías asistivas como lectores de pantalla, teclados especiales o dispositivos de entrada alternativos.
Construir sitios accesibles no significa sacrificar diseño ni complejidad. Significa escribir código semántico, respetar patrones de interacción estándar y verificar que la experiencia funciona para todos los usuarios. Las webs accesibles son, además, más fáciles de mantener, mejor indexadas por buscadores y más usables para todos.
HTML semántico: la base de la accesibilidad
El HTML semántico es el pilar fundamental de la accesibilidad. Utilizar las etiquetas correctas (<nav>, <main>, <article>, <button>, <label>) permite que los lectores de pantalla entiendan la estructura de la página y ofrezcan una navegación lógica al usuario.
El error más común es usar <div> y <span> para todo y compensar con ARIA. Un <div onclick> nunca será equivalente a un <button>: carece de focus nativo, no responde al teclado y los lectores de pantalla no lo anuncian como elemento interactivo.
- Usa <button> para acciones, <a> para navegación, <input> para formularios
- Estructura el contenido con <header>, <nav>, <main>, <aside>, <footer>
- Los encabezados (<h1>-<h6>) deben seguir una jerarquía lógica, sin saltar niveles
- Las imágenes informativas llevan alt descriptivo; las decorativas llevan alt=""
ARIA: cuándo y cómo usarlo
WAI-ARIA (Accessible Rich Internet Applications) añade atributos semánticos a elementos que el HTML nativo no puede describir completamente. Es esencial para componentes interactivos como modales, tabs, acordeones, menús desplegables y autocompletados.
La primera regla de ARIA es: no uses ARIA si puedes conseguir lo mismo con HTML nativo. ARIA no añade comportamiento, solo semántica. Un role="button" en un <div> anuncia el elemento como botón, pero no lo hace focusable ni responde al Enter o Space.
- aria-label y aria-labelledby: proporcionan nombres accesibles a elementos sin texto visible
- aria-expanded, aria-selected, aria-checked: comunican el estado de componentes interactivos
- aria-live: anuncia cambios dinámicos de contenido (notificaciones, resultados de búsqueda)
- role: define el propósito de un elemento cuando el HTML nativo no lo comunica
Lectores de pantalla y testing
Los lectores de pantalla (NVDA, JAWS, VoiceOver, TalkBack) convierten el contenido de la página en voz sintetizada o braille. Interpretan el DOM, no la pantalla visual, por lo que la estructura del HTML y los atributos ARIA determinan completamente la experiencia.
Probar con un lector de pantalla real es insustituible. Las herramientas automáticas detectan entre el 30% y el 50% de los problemas de accesibilidad. El resto requiere testing manual: ¿se anuncia correctamente el propósito de cada elemento? ¿La navegación tiene sentido sin ver la pantalla?
- VoiceOver (macOS/iOS): integrado, activar con Cmd + F5
- NVDA (Windows): gratuito y el más usado en el mercado
- TalkBack (Android): integrado en dispositivos Android
- Prueba la navegación completa sin usar el ratón al menos una vez por sprint
Herramientas de testing automatizado
Las herramientas automatizadas son el primer filtro para detectar problemas de accesibilidad. No sustituyen el testing manual, pero capturan errores comunes como falta de alt text, contraste insuficiente, labels ausentes o jerarquía de encabezados rota.
- axe DevTools: extensión de navegador que audita la página con reglas WCAG 2.1/2.2
- Lighthouse (pestaña Accessibility): incluido en Chrome DevTools, auditoría rápida con puntuación
- eslint-plugin-jsx-a11y: linting de accesibilidad en componentes React durante el desarrollo
- Pa11y: herramienta CLI para integrar testing de accesibilidad en pipelines de CI/CD
- Contrast Checker: verifica que las combinaciones de color cumplen los ratios WCAG (4.5:1 para texto normal)
Cumplimiento normativo y legal
La accesibilidad web no es solo buena práctica: es un requisito legal en muchos países. La European Accessibility Act (EAA) exige que los servicios digitales sean accesibles a partir de junio de 2025. En Estados Unidos, la ADA se aplica regularmente a sitios web, con más de 4.000 demandas anuales relacionadas con accesibilidad digital.
El estándar técnico de referencia es WCAG 2.2 (Web Content Accessibility Guidelines), con tres niveles de conformidad: A (mínimo), AA (estándar recomendado para la mayoría de sitios) y AAA (máximo). La mayoría de legislaciones exigen nivel AA.
- WCAG 2.2 nivel AA: el estándar que la mayoría de regulaciones exigen
- European Accessibility Act (EAA): obligatoria para servicios digitales en la UE desde 2025
- ADA (EE.UU.): se aplica a sitios web de empresas abiertas al público
- EN 301 549: norma técnica europea que referencia WCAG 2.1 como requisito
Puntos clave
- El HTML semántico es la base: usa las etiquetas correctas antes de recurrir a ARIA
- Toda la funcionalidad debe ser accesible por teclado con indicador de foco visible
- Las herramientas automáticas detectan solo el 30-50% de los problemas: el testing manual es imprescindible
- WCAG 2.2 nivel AA es el estándar mínimo recomendado y legalmente exigido en muchas jurisdicciones
- La accesibilidad mejora el SEO, la usabilidad general y reduce el riesgo legal
¿Tu web es accesible para todos los usuarios?
Auditamos la accesibilidad de tu sitio, identificamos las barreras y te ayudamos a cumplir WCAG 2.2 con un plan de mejora práctico.