Diseñar y desarrollar componentes UI accesibles no va de “cumplir WCAG para pasar una auditoría”. Va de algo mucho más práctico: hacer que tu interfaz sea operable, predecible y entendible para más gente, en más contextos (teclado, lector de pantalla, zoom, baja visión, movilidad reducida, fatiga, distracciones, etc.). Eso es a11y aplicada al desarrollo web.
Y aquí viene la parte que suele doler: un componente “bonito” puede ser una máquina de carga cognitiva. Y uno “funcional” puede disparar el tiempo de decisión. En accesibilidad web (y, en particular, en accesibilidad visual), tu trabajo consiste en equilibrar ambas:
- Tiempo de decisión: ¿cuánto tarda una persona en entender qué opciones tiene y cuál elegir?
- Carga cognitiva: ¿cuánta energía mental cuesta orientarse, recordar estados, y mantener el contexto mientras interactúa?
Un modal mal hecho rompe el contexto (sube carga cognitiva). Un carrusel que se mueve solo pelea por la atención (sube carga cognitiva). Un dropdown custom para elegir país con 200 opciones puede reducir tiempo de decisión (si permite búsqueda) o multiplicarlo (si es un infierno de teclado). Lo accesible no es “más ARIA”; es mejores decisiones de interacción + semántica sólida.
Antes de tocar ARIA: cuatro reglas que te ahorran bugs (y tickets)
1) Semántica primero, ARIA después
Si puedes resolverlo con HTML nativo, hazlo. La semántica correcta hace que la estructura y relaciones sean “detectables” por tecnologías de asistencia, en línea con el espíritu de WCAG sobre información y relaciones.
2) No crees trampas de teclado
Si alguien puede “entrar” a un componente con Tab, debe poder salir sin magia ni ratón. Esto es especialmente crítico en modales, menús y widgets compuestos.
3) El foco debe contar una historia lógica
El orden de foco tiene que preservar significado y operabilidad: primero lo importante, después lo secundario, y siempre coherente con el flujo real de la tarea.
4) Los cambios de estado deben anunciarse sin interrumpir
Las notificaciones y mensajes de estado existen para informar sin robar foco. WCAG trata esto explícitamente en “status messages”.
Traducción práctica: si “arreglas” la accesibilidad metiendo
roleyaria-*a lo loco, pero rompes foco, teclado y estados, has empeorado la UX y la a11y a la vez.
Modales accesibles: checklist completo (focus trap, aria, escape, scroll)
Los modales son el ejemplo perfecto del choque tiempo de decisión vs carga cognitiva: te obligan a decidir ahora, pero a cambio te sacan del flujo. Por eso, el primer criterio de accesibilidad de un modal… es no usarlo si no hace falta.
Cuándo sí (y cuándo no)
Sí:
- Confirmaciones destructivas (“Eliminar proyecto”).
- Flujos breves con dependencia (“Aceptar cookies con opciones avanzadas”).
- Formularios cortos que no ameritan navegación a otra página.
No (mejor alternativa):
- Información extensa → mejor página, panel lateral o sección expandible.
- Errores o avisos → mejor toast/status + foco en el campo problemático.
- Menús de navegación → mejor navegación real, no modal.
Estructura y ARIA mínima (la que de verdad importa)
Patrón recomendado: modal dialog (no “div flotante”). El patrón del APG define que el diálogo modal debe contener su propia secuencia de tabulación (Tab/Shift+Tab no deberían salir del modal mientras esté abierto).
Requisitos:
- Contenedor con
role="dialog"(orole="alertdialog"si es una decisión crítica inmediata). aria-modal="true"cuando es modal.- Etiqueta accesible:
aria-labelledbyapuntando al título. - Descripción opcional:
aria-describedbyapuntando a un texto breve (no a un párrafo eterno).
<button id="open">Abrir</button>
<div
role="dialog"
aria-modal="true"
aria-labelledby="dialog-title"
aria-describedby="dialog-desc"
hidden
>
<h2 id="dialog-title">Eliminar proyecto</h2>
<p id="dialog-desc">Esta acción no se puede deshacer.</p>
<button>Cancelar</button>
<button>Eliminar</button>
</div>
Nota: el APG explica que
aria-modalpuede reemplazar la técnica de “ocultar” el fondo conaria-hiddenpara indicar que el contenido exterior queda inerte.
Focus trap y restauración de foco (la parte que casi siempre se rompe)
Un modal accesible hace cuatro cosas, siempre:
- Guarda el elemento que tenía foco antes de abrir.
- Mueve foco dentro del modal (ideal: título o primer control significativo).
- Atrapa el foco dentro (Tab y Shift+Tab ciclan).
- Restauras el foco al cerrarlo (vuelves al botón “Abrir”, por ejemplo).
Esto además evita caer en “trampa de teclado” en el sentido de WCAG: si el modal no ofrece una forma clara de salir (p. ej. Escape y botón cerrar), estás creando un problema serio.
Interacciones de teclado esperadas
Escapecierra (salvo casos muy justificados).- Tab/Shift+Tab no sale del modal (cicla dentro).
Scroll: el enemigo silencioso
Los modales suelen fallar en tres escenarios:
- Contenido largo + viewport pequeño (móvil, zoom 200%).
- Fondo que sigue haciendo scroll (pierdes contexto).
- Modal sin región de scroll clara (la gente “se queda atrapada”).
Buenas prácticas:
- Bloquea scroll del fondo mientras está abierto (sin impedir scroll dentro).
- Si el contenido es largo, define un área scrollable dentro del modal y asegúrate de que el foco sigue siendo visible al navegar.
- Evita “modales infinitos”: si el contenido pasa de “microtarea” a “lectura”, probablemente no es un modal.
Checklist express de modal (para pegar en tu PR)
- Semántica:
role="dialog",aria-modal="true",aria-labelledby(yaria-describedbysi aplica). - Foco: mover foco al abrir + restaurar al cerrar.
- Teclado: Tab atrapado dentro;
Escapecierra. - Salida clara: botón cerrar visible y accesible.
- Scroll: fondo bloqueado, contenido del modal usable con zoom.
Accordions accesibles: cómo hacerlo sin romper la UX
Un accordion reduce carga visual (menos contenido en pantalla), pero puede aumentar tiempo de decisión (hay que descubrir qué hay dentro). Bien usado, es oro para contenidos secundarios; mal usado, se convierte en “contenido escondido para siempre”.
El patrón correcto (y por qué “div clickable” no vale)
En el APG, la interacción base del accordion es simple:
- El encabezado es un control (normalmente un
<button>). EnteroSpaceexpanden/colapsan.- Todo lo enfocables del accordion participan del orden natural de Tab (no inventes un “sub-tabindex hell”).
Ejemplo:
<h3>
<button aria-expanded="false" aria-controls="panel-faq-1" id="acc-faq-1">
¿Qué incluye el plan?
</button>
</h3>
<div id="panel-faq-1" role="region" aria-labelledby="acc-faq-1" hidden>
<p>Incluye soporte, actualizaciones y…</p>
</div>
UX que no castiga a nadie
- Pistas visuales claras: icono + estado (rotación/flecha) + animación suave.
- No cambies el foco al abrir/cerrar: que el usuario mantenga el control.
- Si permites “solo un panel abierto”, hazlo por un motivo real (en móvil puede ayudar). Si no, deja abrir varios: reduce “memoria de trabajo” (menos carga cognitiva).
Checklist del accordion
- Encabezado con
<button>+aria-expanded+aria-controls. - Panel asociado con
idcorrecto (yrole="region"+aria-labelledbysi el contenido lo justifica). - Teclado:
EnterySpacefuncionan siempre. - Estado visible (no solo color; piensa en accesibilidad visual).
Tabs accesibles: el patrón ARIA bien aplicado
Las tabs pueden bajar tiempo de decisión (organizan contenido en categorías), pero también pueden subir carga cognitiva si:
- hay demasiadas,
- cambian el contenido de forma inesperada,
- o están implementadas como links/botones sin patrón consistente.
El APG define claramente los roles y relaciones:
role="tablist"para el contenedor.role="tab"para cada pestaña.role="tabpanel"para el panel.aria-controlsdesde tab → panel, yaria-labelledbydesde panel → tab.
Ejemplo mínimo:
<div role="tablist" aria-label="Ajustes">
<button role="tab" aria-selected="true" aria-controls="panel-1" id="tab-1">
Perfil
</button>
<button role="tab" aria-selected="false" aria-controls="panel-2" id="tab-2" tabindex="-1">
Seguridad
</button>
</div>
<section role="tabpanel" id="panel-1" aria-labelledby="tab-1">
...
</section>
<section role="tabpanel" id="panel-2" aria-labelledby="tab-2" hidden>
...
</section>
Detalle importante: suele esperarse que solo la tab activa esté en el orden de tabulación (las demás con
tabindex="-1"), y que el cambio entre tabs sea con flechas (izquierda/derecha). Este enfoque aparece en guías y análisis de soporte de a11y para tabs.
Consejos de UX para tabs (sin romper accesibilidad)
- Máximo razonable: 4–7 tabs (más que eso suele ser un “menú disfrazado”).
- Evita que cada tab sea una “pantalla entera” si el contenido requiere scroll largo: ahí mejor navegación real o accordion/secciones.
- Mantén el foco en la tab (no lo saltes al panel automáticamente) salvo que el caso de uso lo pida.
Checklist de tabs
- Roles correctos (
tablist,tab,tabpanel) y relaciones (aria-controls,aria-labelledby). aria-selectedsiempre coherente (una activa, el resto no).- Navegación por flechas + Home/End (si lo implementas, que sea consistente).
- Panels ocultos realmente no enfocables (cuidado con elementos tabulables dentro).
Dropdowns vs Select: cuándo uno es un problema de accesibilidad
Aquí hay una regla que te ahorra discusiones eternas: si estás eligiendo un valor de formulario simple, usa <select> nativo. Es robusto, soporta teclado, lector de pantalla y UX móvil de forma casi perfecta.
Entonces, ¿cuándo aparece el dropdown custom (o combobox)?
El combobox (dropdown “con cerebro”) tiene un patrón… y es complejo
El APG define el combobox como un input (o botón) que controla un popup (listbox, grid, etc.).
MDN remarca que puede ser editable o “select-only” (sin texto libre), pero sigue siendo un widget compuesto.
Y el propio APG muestra ejemplos “select-only” que imitan a <select>, precisamente para casos donde necesitas comportamiento extra.
Traducción práctica: si no necesitas búsqueda, virtualización, agrupaciones ricas o async, el dropdown custom normalmente aumenta carga cognitiva (para usuario) y carga de mantenimiento (para ti). Y ahí la accesibilidad web sufre.
“Dropdown” no siempre significa lo mismo
- Select (valor): el usuario elige un valor para un campo.
- Menu button (acciones): el usuario elige una acción (“Duplicar”, “Archivar”, “Eliminar”).
El APG separa claramente el patrón de menu button (botón que abre un menú de acciones).
Si usas role="menu" para navegación o para seleccionar valores, es fácil terminar con un comportamiento de teclado tipo “aplicación de escritorio” que no encaja con la web. (Y sí, se nota en UX.)
Mini matriz de decisión (rápida y útil)
Usa <select> si:
- Lista corta/mediana.
- No necesitas búsqueda.
- Prioridad: accesibilidad + UX móvil + simplicidad.
Usa combobox si:
- Lista enorme (50–500+).
- Necesitas búsqueda/filtrado.
- Opciones asíncronas (API).
- Necesitas mostrar metadata en cada opción (pero ojo con recargar).
Usa menu button si:
- Son acciones, no valores.
Toasts y notificaciones: cómo anunciar cambios sin molestar
Las toasts existen para comunicar cambios sin interrumpir. WCAG lo aborda con el criterio de status messages: informar cambios relevantes que no reciben foco, sin cortar el trabajo del usuario.
¿Qué rol uso: status o alert?
role="status"/aria-live="polite": confirmaciones no urgentes (“Guardado”, “Añadido al carrito”).role="alert"/aria-live="assertive": cosas urgentes (“Error al pagar”, “Sesión caducada”).
MDN describe role="alert" como un mensaje importante y sensible al tiempo, tratado como live region “atómica”.
Y la guía de live regions de MDN explica cuándo usar anuncios “polite” para evitar ser molestos.
Ejemplo “no invasivo”:
<div aria-live="polite" aria-atomic="true" class="sr-only" id="live-region"></div>
<!-- Visual -->
<div class="toast" role="status" aria-atomic="true">
Guardado correctamente.
<button aria-label="Cerrar notificación">×</button>
</div>
Reglas de oro (para no generar odio)
- No robes foco para una toast normal.
- Si auto-desaparece, da tiempo suficiente y ofrece cerrar manualmente.
- No apiles 6 mensajes: agrupa (“3 cambios guardados”).
- Si un mensaje requiere acción, probablemente no es toast, es un banner persistente o un diálogo.
Técnica relacionada: WAI describe el uso de live regions para notificar errores sin mover foco.
Carousels accesibles: la dura verdad (y alternativas mejores)
Vamos a decirlo claro: muchos carousels existen por estética, no por necesidad, y suelen empeorar accesibilidad visual y a11y (movimiento, distracción, controles pequeños, lectura fragmentada).
Dicho eso: si tu producto realmente necesita un carrusel (p. ej., galería, stories, destacados), el APG tiene un patrón específico.
El problema grande: movimiento automático
Si el carrusel se mueve solo y dura más de 5 segundos, necesitas un mecanismo para pausar, detener u ocultar. Esto está alineado con WCAG “Pause, Stop, Hide”, que busca evitar distracciones durante la interacción.
Además, hay ejemplos de carrusel auto-rotativo que detienen la rotación cuando el usuario enfoca controles o interactúa, como medida esencial de accesibilidad.
Si aun así lo implementas, que sea “control-first”
- Botones Prev/Next grandes, con labels claros.
- Indicadores (puntos) accesibles y operables por teclado.
- Pausa/Reproducir visible si hay auto-rotación.
- Respeta
prefers-reduced-motion(reduce o elimina animaciones). - No cambies de slide si el usuario está leyendo/interactuando.
Alternativas mejores (casi siempre)
- Grid de tarjetas con “Ver más”.
- Lista horizontal con scroll (tipo “cards”) + botones opcionales.
- Destacados estáticos con buena jerarquía (un hero + 3 links).
Incluso navegadores y guías modernas están empujando a carousels más “declarativos” y menos frágiles, reduciendo problemas típicos de a11y cuando se construyen con scroll en lugar de “slides” artificiales.
Preguntas frecuentes (FAQs)
1) ¿“Cumplir” ARIA significa que mi componente ya es accesible?
No. ARIA describe roles y estados, pero no arregla problemas de foco, teclado, orden lógico o anuncios de estado. Piensa ARIA como una parte del contrato, no como el producto final. El APG existe precisamente para unir semántica + comportamiento + ejemplos.
2) ¿Puedo usar librerías de componentes y olvidarme del tema?
Puedes apoyarte, pero no “olvidarte”. Una librería puede implementar el patrón (bien), pero tú sigues decidiendo: contenido, jerarquía, densidad, textos, timing de toasts, cuándo usar modal, etc. Y esas decisiones afectan directamente a carga cognitiva y tiempo de decisión.
3) ¿Cómo testeo rápido estos componentes sin montar un laboratorio?
Checklist mínima:
- Solo teclado (Tab/Shift+Tab/Enter/Escape/flechas).
- Zoom al 200% y 400% (¿se rompe el layout? ¿se pierde el foco?).
prefers-reduced-motionactivado.- Un lector de pantalla (aunque sea básico) para comprobar: ¿se anuncia el título del modal? ¿se anuncia la toast?
Para mensajes de estado, ten presente el objetivo de WCAG: informar cambios sin interrumpir ni mover el foco.
Accesibilidad es diseñar el “camino fácil”
Cuando un componente UI es accesible, normalmente ocurre algo bonito: baja el tiempo de decisión y baja la carga cognitiva. No porque “le pusiste ARIA”, sino porque el componente:
- tiene un propósito claro,
- no esconde la información importante,
- respeta expectativas de teclado,
- y anuncia cambios sin invadir.
La accesibilidad web, en el fondo, es ingeniería de la atención: hacer que la interfaz no le pida a la persona más memoria, más precisión o más paciencia de la necesaria. Y eso, además de a11y, es simplemente buen desarrollo web.
