Accesibilidad Web y WCAG: Guía Completa de Diseño Inclusivo en 2025

Todo lo que necesitas saber sobre accesibilidad web. Estándares WCAG, técnicas de implementación, beneficios legales y de negocio, y herramientas de prueba.

¿Qué Es la Accesibilidad Web?

La accesibilidad web significa que los sitios web, aplicaciones y tecnologías digitales están diseñados y desarrollados para que las personas con discapacidades puedan utilizarlos. Esto incluye personas con discapacidades visuales, auditivas, motoras o cognitivas.

Por Qué Importa

1. Tamaño de la Audiencia

  • El 15% de la población mundial tiene alguna forma de discapacidad
  • Representa más de 1.000 millones de personas
  • Poder adquisitivo de 8 billones de dólares a nivel global
  • 2. Requisitos Legales

  • En la UE: European Accessibility Act (2025)
  • En EE.UU.: ADA y Section 508
  • Multas significativas por incumplimiento
  • 3. Beneficios SEO

  • Muchas prácticas de accesibilidad mejoran el SEO
  • Texto alternativo, estructura semántica, navegación clara
  • Google favorece los sitios accesibles
  • 4. Mejor UX para Todos

  • El diseño accesible beneficia a todos
  • Discapacidades situacionales (manos ocupadas, luz intensa)
  • Usuarios mayores
  • Entendiendo WCAG

    ¿Qué Son los Estándares WCAG?

    Las Web Content Accessibility Guidelines (WCAG) son estándares internacionales desarrollados por el W3C para la accesibilidad web.

    Versiones:

  • WCAG 2.0 (2008)
  • WCAG 2.1 (2018) - incluye móvil
  • WCAG 2.2 (2023) - la más reciente
  • WCAG 3.0 - en desarrollo
  • Los 4 Principios POUR

    1. Perceivable (Perceptible)

    La información debe presentarse de formas que los usuarios puedan percibir.

    2. Operable

    La interfaz debe ser operable por todos los usuarios.

    3. Understandable (Comprensible)

    El contenido y la operación deben ser comprensibles.

    4. Robust (Robusto)

    El contenido debe ser suficientemente robusto para diversas tecnologías.

    Niveles de Conformidad

    Nivel A (Mínimo)

  • Requisitos básicos
  • Eliminación de barreras críticas
  • Mínimo necesario
  • Nivel AA (Recomendado)

  • Estándar para la mayoría de organizaciones
  • Requerido por muchas regulaciones
  • Equilibrio entre accesibilidad y esfuerzo
  • Nivel AAA (Óptimo)

  • Nivel más alto
  • No siempre posible para todo el contenido
  • Objetivo para contenido crítico
  • Guía de Implementación

    1. Contenido de Texto y Alternativas

    Texto Alternativo para Imágenes:

  • Bien: Texto descriptivo con contexto - "Gráfico que muestra un crecimiento de ventas del 45% en el Q4 2024"
  • Mal: Texto genérico o ausente - "imagen" o nada
  • Imágenes decorativas: Alt vacío y role="presentation" para ser ignoradas por lectores de pantalla
  • Video y Audio:

  • Subtítulos para video
  • Transcripciones para audio
  • Audiodescripción para video
  • Lengua de señas para contenido crítico
  • 2. Estructura y Semántica

    Encabezados Correctos:

  • La jerarquía de encabezados debe ser lógica: H1 → H2 → H3
  • No saltar niveles (de H1 directamente a H4)
  • Cada página debería tener un único H1
  • Regiones Landmark:

    Usa elementos semánticos HTML5 para regiones:

  • header para encabezado
  • nav para navegación
  • main para contenido principal
  • aside para contenido secundario
  • footer para pie de página
  • Listas:

  • Usa ul/ol y li para listas, no divs con viñetas visuales
  • Los lectores de pantalla anuncian el número de elementos en la lista
  • 3. Navegación con Teclado

    Todas las Funciones Accesibles:

  • Tab para navegación entre elementos
  • Enter/Espacio para activación
  • Teclas de flecha para menús
  • Escape para cerrar modales
  • Foco Visible:

  • Nunca ocultes el foco completamente con outline: none
  • Usa un outline visible de al menos 2px
  • focus-visible permite estilizar solo para navegación con teclado
  • Skip Links:

  • Añade un enlace "Saltar al contenido principal" al inicio de la página
  • Oculto visualmente pero disponible para lectores de pantalla
  • Se hace visible cuando recibe el foco
  • Permite a los usuarios saltar la navegación repetitiva
  • 4. Formularios Accesibles

    Labels e Instrucciones:

  • Cada campo debe tener un label asociado mediante el atributo for
  • Indica los campos obligatorios en el label
  • Añade pistas (ej: "Ejemplo: usuario@dominio.com") con aria-describedby
  • Para errores, usa aria-invalid="true" y role="alert"
  • Agrupación de Campos:

  • Usa fieldset y legend para agrupar campos relacionados
  • Ej: "Dirección de envío" como legend para el grupo de campos de dirección
  • Ayuda a los usuarios a entender el contexto de los campos
  • 5. Color y Contraste

    Ratio de Contraste Mínimo:

  • Texto normal: 4.5:1 (AA)
  • Texto grande (18pt+): 3:1 (AA)
  • Componentes UI: 3:1
  • Herramientas de Verificación:

  • WebAIM Contrast Checker
  • Color Contrast Analyzer
  • Browser DevTools
  • No Solo Color:

  • Mal: Indicador de error solo mediante borde rojo
  • Bien: Color + icono ⚠ + texto "Campo obligatorio"
  • Asegúrate de que la información se transmita por otros medios además del color
  • 6. ARIA (Accessible Rich Internet Applications)

    Cuándo Usar ARIA:

  • Cuando el HTML semántico no es suficiente
  • Para componentes interactivos personalizados
  • Para regiones en vivo
  • Ejemplos ARIA:

  • role="button" para elementos que se comportan como botones pero no son etiquetas button
  • tabindex="0" para hacer el elemento enfocable
  • aria-pressed para botones de alternancia
  • role="tablist", role="tab", role="tabpanel" para interfaces de pestañas
  • aria-selected para indicar la pestaña activa
  • aria-live="polite" para regiones que anuncian actualizaciones (ej: "Producto añadido al carrito")
  • Regla de Oro:

    "Ningún ARIA es mejor que un mal ARIA"

  • Prefiere HTML semántico
  • Prueba con lectores de pantalla
  • Componentes Comunes

    Modal Accesible

    Requisitos para modal:

  • Usa role="dialog" y aria-modal="true"
  • Título del modal vinculado con aria-labelledby
  • Atrapa el foco en el modal (el usuario no puede navegar fuera)
  • Devuelve el foco al elemento disparador al cerrar
  • Cierre con tecla Escape
  • Dropdown/Menú Accesible

    Requisitos para menús desplegables:

  • El botón disparador tiene aria-haspopup="true"
  • aria-expanded indica si el menú está abierto o cerrado
  • La lista tiene role="menu", las opciones role="menuitem"
  • Navegación con flechas arriba/abajo entre opciones
  • Acordeón Accesible

    Requisitos para acordeón:

  • Los botones tienen aria-expanded para indicar el estado
  • aria-controls vincula el botón con el panel que controla
  • El panel oculto tiene el atributo hidden
  • Navegación con Enter/Espacio para abrir/cerrar secciones
  • Carrusel Accesible

    Requisitos para carrusel:

  • Contenedor con role="region" y aria-label descriptivo
  • Botones de navegación con aria-label claro ("Diapositiva anterior", "Diapositiva siguiente")
  • aria-live="polite" para anunciar el cambio de diapositiva
  • Imágenes con texto alt descriptivo
  • Indicador de posición (ej: "Diapositiva 1 de 5")
  • Pruebas de Accesibilidad

    Pruebas Automatizadas

    Herramientas:

  • axe DevTools: Extensión de navegador, integración CI/CD
  • WAVE: Visualización gráfica de problemas
  • Lighthouse: Integrado en Chrome
  • Pa11y: Herramienta CLI para CI/CD
  • Limitaciones:

  • Encuentran solo el 30-50% de los problemas
  • No reemplazan las pruebas manuales
  • Falsos positivos/negativos
  • Pruebas Manuales

    Pruebas de Teclado:

    1. Navega sin ratón

    2. Verifica el foco visible

    3. Prueba todas las funciones

    4. Verifica el orden de tabulación lógico

    Pruebas con Lector de Pantalla:

  • NVDA (Windows, gratuito)
  • JAWS (Windows, de pago)
  • VoiceOver (Mac/iOS, integrado)
  • TalkBack (Android, integrado)
  • Pruebas de Zoom:

  • Zoom del navegador al 200%
  • Verifica el reflujo del texto
  • No pierdas funcionalidad
  • Lista de Verificación de Pruebas

    Percepción:

  • [ ] Todas las imágenes tienen texto alt
  • [ ] El video tiene subtítulos
  • [ ] Contraste suficiente
  • [ ] No solo color para información
  • Operabilidad:

  • [ ] Navegable solo con teclado
  • [ ] Foco visible
  • [ ] Skip links funcionales
  • [ ] Sin trampas de foco
  • Comprensión:

  • [ ] Idioma declarado
  • [ ] Labels en formularios
  • [ ] Errores claramente identificados
  • [ ] Comportamiento predecible
  • Robustez:

  • [ ] HTML válido
  • [ ] ARIA correctamente usado
  • [ ] Funciona en varios navegadores
  • Implementación en la Práctica

    Flujo de Trabajo de Desarrollo

    1. Fase de Diseño:

  • Contraste de color en el sistema de diseño
  • Estados de foco en componentes
  • Anotaciones para lectores de pantalla
  • 2. Desarrollo:

  • HTML semántico primero
  • ARIA cuando sea necesario
  • Manejo de teclado
  • 3. Revisión de Código:

  • Lista de verificación de accesibilidad
  • Linting automatizado (eslint-plugin-jsx-a11y)
  • 4. Pruebas:

  • Escaneos automatizados en CI/CD
  • Pruebas manuales periódicas
  • Pruebas de usuario con personas con discapacidades
  • Para WordPress

    Temas Accesibles:

  • Busca la etiqueta "accessibility-ready"
  • Datos de Theme Unit Test
  • Plugins:

  • WP Accessibility
  • Access Monitor
  • One Click Accessibility
  • Creación de Contenido:

  • Texto alt en todas las imágenes
  • Jerarquía de encabezados
  • Texto de enlace descriptivo
  • Para React/Vue

    React:

  • Usa eslint-plugin-jsx-a11y para linting automático
  • Bibliotecas con componentes accesibles integrados: Radix UI, Reach UI, Chakra UI, Headless UI
  • Estas bibliotecas manejan automáticamente ARIA, gestión de foco y navegación con teclado
  • Vue:

  • Usa eslint-plugin-vuejs-accessibility para linting
  • Asegúrate de que los manejadores de clic tengan equivalentes de teclado (Enter/Espacio)
  • Usa componentes de bibliotecas como Vuetify que tienen soporte de accesibilidad
  • Aspectos Legales

    European Accessibility Act (EAA)

    Cronología:

  • Entrada en vigor: 28 de Junio de 2025
  • Afecta: E-commerce, servicios bancarios, transporte
  • Requisitos:

  • Productos y servicios digitales accesibles
  • Conformidad WCAG 2.1 AA
  • Documentación de accesibilidad
  • Otras Regulaciones

    España:

  • Real Decreto 1112/2018 sobre accesibilidad de sitios web
  • Alineación con directivas de la UE
  • EE.UU.:

  • ADA (Americans with Disabilities Act)
  • Section 508 para gobierno
  • Demandas en aumento
  • Reino Unido:

  • Public Sector Bodies Accessibility Regulations
  • Equality Act 2010
  • Declaración de Accesibilidad

    Qué Incluir:

  • Nivel de conformidad
  • Limitaciones conocidas
  • Mecanismo de feedback
  • Datos de contacto
  • Fecha de última revisión
  • Caso de Negocio

    ROI de la Accesibilidad

    Beneficios Directos:

  • Acceso al 15%+ del mercado
  • Evitar multas y demandas
  • Mejora del SEO
  • Beneficios Indirectos:

  • Percepción positiva de marca
  • Motor de innovación
  • Satisfacción de empleados
  • Costo vs Beneficio

    Costo de implementación:

  • Mínimo si se integra desde el inicio
  • Mayor para remediación
  • Formación y herramientas
  • Ahorros:

  • Evitar litigios ($$$)
  • Reducción de llamadas de soporte
  • Aumento de conversiones
  • Lista de Verificación Final

    Para el Lanzamiento

    Crítico:

  • [ ] Saltar al contenido principal
  • [ ] Navegación con teclado completamente funcional
  • [ ] Texto alt en imágenes
  • [ ] Labels en formularios
  • [ ] Contraste 4.5:1
  • [ ] Mensajes de error claros
  • Importante:

  • [ ] Estilizado de foco visible
  • [ ] Jerarquía de encabezados correcta
  • [ ] ARIA landmarks
  • [ ] Atributo de idioma
  • Deseable:

  • [ ] Modo oscuro
  • [ ] Opción de movimiento reducido
  • [ ] Modo de alto contraste
  • Conclusión

    La accesibilidad web no es opcional en 2025. Es un requisito legal, una ventaja competitiva y simplemente lo correcto.

    Principios a recordar:

  • Empezar con HTML semántico
  • Probar temprano y a menudo
  • Incluir usuarios con discapacidades
  • Continuo, no puntual

Pasos de implementación:

1. Auditoría actual con herramientas automatizadas

2. Priorizar problemas críticos

3. Integrar en el flujo de trabajo

4. Formación del equipo

5. Monitorización continua

---

El equipo DGI ofrece servicios de auditoría e implementación de accesibilidad web. Contáctanos para una evaluación de tu sitio.

Compartir artículo:
Volver al Blog