ARIA vs HTML Semántico: La Regla de Oro

Entienda la diferencia entre el HTML semántico nativo y los atributos ARIA, y aprenda por qué la primera regla de la accesibilidad es no usar ARIA si existe una alternativa nativa.

info Definición Rápida
El HTML Semántico utiliza las etiquetas nativas del navegador (como <button>, <input>, <nav>) que ya traen accesibilidad y comportamiento integrados. ARIA (Accessible Rich Internet Applications) es un conjunto de atributos que se añaden al código para “parchear” o explicar elementos personalizados que el navegador no entiende por defecto.

La Primera Regla de ARIA

Si hay una cosa que todo diseñador y desarrollador debe recordar es la Primer Regla de ARIA:

“Si puedes usar un elemento nativo de HTML o un atributo con la semántica y el comportamiento que ya necesitas incorporados, entonces hazlo.”

En otras palabras: No construyas un botón con un <div> y un montón de atributos ARIA para que “parezca” un botón. Usa una etiqueta <button> nativa. Es más rápido, más seguro y funciona mejor en todos los dispositivos.

1. El Poder de la Semántica Nativa

El HTML nativo es un contrato con el sistema operativo y con las tecnologías asistivas. Cuando usas un elemento nativo, obtienes “gratis”:

  • Accesibilidad por Teclado: El botón es seleccionable con el Tabulador y se activa con Espacio/Enter.
  • Roles y Estados en el Árbol de Accesibilidad: El lector de pantalla ya sabe qué es y si está pulsado o no.
  • Experiencia de Usuario Predecible: El usuario sabe cómo interactuar con él porque se comporta igual en toda la web.

2. Cuándo SÍ es Necesario ARIA

ARIA no es malo; es un salvavidas cuando las etiquetas nativas se quedan cortas. Debe usarse en componentes complejos que no existen en el HTML estándar:

  • Tabs (Pestañas): No existe una etiqueta <tabs> nativa, por lo que usamos ARIA para explicar la relación entre la pestaña y su contenido (role="tablist", role="tabpanel").
  • Tooltips y Ayudas Táctiles: Para conectar visualmente un icono de ayuda con su descripción de texto (aria-describedby).
  • Live Regions (Áreas Vivas): Para avisar a una persona ciega de que el contenido de una parte de la pantalla ha cambiado (ej. un mensaje de error que aparece de repente) sin que tenga que mover su foco allí (aria-live).
  • Menús de Navegación Complejos: Para indicar que un botón despliega un menú lateral (aria-expanded="true/false").

Comparativa: ¿Cuál Elegir?

CaracterísticaHTML SemánticoAtributos ARIA
ComplejidadBaja (Nativo del Navegador).Alta (Requiere JS para que funcione).
SoporteUniversal y robusto.Puede variar según el lector de pantalla.
MantenibilidadFácil (Menos código).Difícil (Muchos atributos manuales).
Uso IdealElementos estándar (Botones, Links, Títulos).Componentes personalizados (Modales, Acordeones).

Malas Prácticas Comunes de ARIA (Diseño y Código)

  • ARIA Redundante: Poner role="button" a un <button>. Ya es un botón, no le grites al navegador.
  • Signifiers Falsos: Usar ARIA para que un elemento “parezca” algo que no se comporta como tal. Si dices que es un checkbox, el usuario esperará poder marcarlo y desmarcarlo.
  • Olvidar al Usuario de Teclado: ARIA ayuda a los lectores de pantalla a entender, pero no ayuda al usuario a moverse. Seguirás necesitando JavaScript para que las teclas funcionen correctamente.

Consejos de Mentor

  • No asumas el rol de ARIA: Antes de pedirle a un desarrollador que cree un componente complejo desde cero con ARIA, revisa si hay una solución nativa (ej. la etiqueta <details> y <summary> para acordeones).
  • Documenta la Intención: En tus especificaciones de diseño, indica: “Este elemento debe ser un botón nativo” o “Este es un componente de pestañas que necesitará lógica ARIA”.
  • Realiza Pruebas de Usuario: La accesibilidad no termina en el código. Prueba tu componente con un lector de pantalla para verificar que ARIA está comunicando lo que tú querías expresar visualmente.

Recursos y Herramientas

accessibility-tree focus-management screen-reader-testing identidad-roles-estados