Accesibilidad

¿Qué es?

Accesibilidad web (a11y) es la práctica de hacer que los productos digitales sean usables por todas las personas, independientemente de sus capacidades. No es un feature opcional — es un requisito fundamental de calidad y, en muchas jurisdicciones, un requisito legal.

Aproximadamente el 16% de la población mundial vive con alguna forma de discapacidad (OMS). Diseñar sin considerar accesibilidad excluye activamente a una de cada seis personas.

WCAG 2.2 — el estándar actual

Las Web Content Accessibility Guidelines (WCAG) son el estándar internacional publicado por el W3C. La versión 2.2, publicada en octubre de 2023, añade 9 nuevos criterios de éxito sobre la versión 2.1, enfocados en accesibilidad cognitiva, usabilidad móvil y autenticación.

Tres niveles de conformidad:

• A: mínimo (contraste básico, texto alternativo)
• AA: recomendado y requerido legalmente en la mayoría de regulaciones (contraste 4.5:1, navegación completa por teclado)
• AAA: óptimo (contraste 7:1, lenguaje simple)

Criterios nuevos en WCAG 2.2

La mayoría de regulaciones (ADA en EE.UU., EN 301 549 en Europa, Ley Europea de Accesibilidad vigente desde junio 2025) exigen nivel AA como mínimo.

Principios POUR

Los cuatro principios que organizan todos los criterios WCAG:

1. Perceivable: contenido perceptible por al menos un sentido — texto alternativo, contraste suficiente, captions en video
2. Operable: navegable por teclado, sin trampas de foco, tiempo suficiente para interactuar
3. Understandable: lenguaje claro, comportamiento predecible, ayuda para errores de entrada
4. Robust: compatible con tecnologías asistivas actuales y futuras

Patrones ARIA en la práctica

HTML semántico es siempre la primera opción. ARIA (Accessible Rich Internet Applications) se usa cuando HTML nativo no puede expresar el rol o estado de un componente.

Reglas de ARIA

1. Si puedes usar HTML nativo, úsalo — <button> en lugar de <div role="button">
2. No cambies la semántica nativa — no pongas role="heading" en un <button>
3. Todo control interactivo debe ser operable por teclado
4. No uses role="presentation" o aria-hidden="true" en elementos focusables
5. Todo elemento interactivo debe tener un nombre accesible

Ejemplo: tabs accesibles

function Tabs({ tabs, activeTab, onChange }: TabsProps) {
  return (
    <div>
      <div role="tablist" aria-label="Secciones">
        {tabs.map((tab, i) => (
          <button
            key={tab.id}
            role="tab"
            id={`tab-${tab.id}`}
            aria-selected={activeTab === tab.id}
            aria-controls={`panel-${tab.id}`}
            tabIndex={activeTab === tab.id ? 0 : -1}
            onClick={() => onChange(tab.id)}
            onKeyDown={(e) => {
              if (e.key === 'ArrowRight') onChange(tabs[(i + 1) % tabs.length].id);
              if (e.key === 'ArrowLeft') onChange(tabs[(i - 1 + tabs.length) % tabs.length].id);
            }}
          >
            {tab.label}
          </button>
        ))}
      </div>
      {tabs.map((tab) => (
        <div
          key={tab.id}
          role="tabpanel"
          id={`panel-${tab.id}`}
          aria-labelledby={`tab-${tab.id}`}
          hidden={activeTab !== tab.id}
        >
          {tab.content}
        </div>
      ))}
    </div>
  );
}

Puntos clave: role="tablist" agrupa los tabs, aria-selected indica el activo, aria-controls conecta tab con panel, y las flechas permiten navegación por teclado sin Tab.

Testing automatizado vs manual

Las herramientas automatizadas detectan entre el 30% y el 40% de los problemas de accesibilidad — los que son verificables por análisis de código (contraste, alt text faltante, roles ARIA inválidos). El 60-70% restante requiere juicio humano: ¿el texto alternativo es significativo? ¿El orden de lectura tiene sentido? ¿La navegación por teclado es lógica?

La estrategia efectiva combina ambos: automatizado en CI/CD para prevenir regresiones, manual antes de cada release para validar la experiencia real.

Integración de axe-core en CI

axe-core de Deque es el motor de testing de accesibilidad más usado. Se integra con Playwright, Cypress, Jest y como GitHub Action.

Con Playwright

import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';
 
test('homepage has no accessibility violations', async ({ page }) => {
  await page.goto('/');
  const results = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa', 'wcag22aa'])
    .analyze();
  expect(results.violations).toEqual([]);
});

Con eslint-plugin-jsx-a11y

{
  "extends": ["plugin:jsx-a11y/recommended"],
  "rules": {
    "jsx-a11y/anchor-is-valid": "error",
    "jsx-a11y/no-autofocus": "warn",
    "jsx-a11y/label-has-associated-control": "error"
  }
}

Este plugin detecta problemas en tiempo de desarrollo — antes de que el código llegue al navegador. Combinado con axe-core en CI, cubre la capa automatizada completa.

Flujo de testing con screen reader

Para testing manual, VoiceOver (macOS/iOS) y NVDA (Windows) son los screen readers más usados:

1. Activar el screen reader — VoiceOver: Cmd + F5 en macOS
2. Navegar por headings — verificar que la jerarquía h1 → h2 → h3 es lógica
3. Recorrer con Tab — verificar que todos los elementos interactivos son alcanzables y el orden es lógico
4. Verificar formularios — cada input debe anunciar su label, errores deben ser comunicados
5. Probar componentes dinámicos — modales, dropdowns, tabs deben anunciar cambios de estado con aria-live o gestión de foco

¿Por qué importa?

La accesibilidad no es un nice-to-have — es un requisito legal en la mayoría de mercados (ADA, Ley Europea de Accesibilidad, EN 301 549) y una práctica de ingeniería que mejora la calidad para todos los usuarios. Un sitio accesible funciona mejor con teclados, conexiones lentas, pantallas pequeñas y dispositivos diversos.

Desde la perspectiva de arquitectura, la accesibilidad es más barata cuando se diseña desde el inicio. Retrofitting accesibilidad en un sistema de diseño existente puede requerir reescribir componentes completos. Integrar axe-core en CI/CD y usar eslint-plugin-jsx-a11y en desarrollo previene regresiones sin esfuerzo manual — pero solo cubre el 30-40% de los criterios. El testing manual con screen readers sigue siendo necesario antes de cada release.

Referencias

• WCAG 2.2 — W3C, 2023. Estándar internacional de accesibilidad web, versión actual.
• WAI-ARIA Authoring Practices Guide — W3C. Patrones de diseño y widgets accesibles con ejemplos de código.
• What's new in WCAG 2.2 — TetraLogical, 2023. Resumen de los 9 nuevos criterios de éxito.
• axe-core — Deque Systems. Motor de testing de accesibilidad open-source, base de la mayoría de herramientas automatizadas.
• A11y Project — Comunidad. Recursos prácticos, checklist y patrones de accesibilidad.
• Evaluating Web Accessibility — W3C WAI. Guía oficial para evaluar accesibilidad web.
• Learn Accessibility — Google web.dev. Curso completo de accesibilidad web.