Adiós ARIA: Por Qué 2026 Es el Año del HTML Nativo y la Accesibilidad Web

Si tu sitio carga 200 KB de JavaScript solo para que un menú desplegable funcione con lectores de pantalla, 2026 es el año en que eso deja de ser aceptable. No por moda, sino porque los navegadores, las leyes y la industria coincidieron: el HTML nativo es el camino, y ARIA es el parche que ya no necesitamos.

A finales de junio de 2026, varios análisis técnicos especializados —incluyendo el reporte "Native HTML Accessibility: The 2026 Industry Shift" de WebAbility— documentaron un movimiento que venía gestándose desde 2024: desarrolladores y agencias están eliminando progresivamente widgets ARIA complejos en favor de elementos HTML nativos. No es una simplificación cosmética. Es un replanteamiento de cómo construimos la web accesible.

En Mintec lo hemos visto de primera mano. En los últimos 18 meses, tres proyectos grandes de migración de accesibilidad pasaron por nuestras manos. Los tres compartían un patrón común: frameworks que habían abusado de ARIA para suplir deficiencias del markup original. Y los tres terminaron con menos código, mejor performance y —lo más importante— una accesibilidad que realmente funcionaba.

El problema con ARIA no es ARIA. Es cómo lo usamos.

WAI-ARIA nació en 2014 para resolver un problema real: las aplicaciones web modernas construían widgets interactivos (tabs, sliders, trees, modales) que no existían como elementos HTML nativos. ARIA permitía etiquetar estos widgets con roles, estados y propiedades que los lectores de pantalla podían interpretar.

El problema es que ARIA se convirtió en un comodín. En lugar de escribir un <button>, los equipos escribían un <div role="button" tabindex="0" aria-pressed="false"> con 50 líneas de JavaScript para gestionar eventos de teclado, estados focus, y synchronización de aria-activedescendant. Y luego otro equipo llegaba y lo rompía sin querer.

La regla de oro de la accesibilidad web —que citamos siempre en nuestras auditorías— dice: "No uses ARIA si un elemento HTML nativo puede hacer el trabajo." En 2026, los navegadores finalmente cerraron esa brecha. Elementos como <dialog>, <details>, <summary>, <progress>, <meter> y <search> tienen soporte completo en todos los navegadores modernos. Ya no necesitas un role="dialog" con aria-modal="true" y 200 líneas de JavaScript. Escribes <dialog> y el navegador hace el resto.

Comparativa: HTML nativo vs. Patrones ARIA

Estos números no son teóricos. En nuestro proyecto de migración a Astro para un portal de documentación técnica, reemplazar tabs con divs+ARIA por tabs con <button> nativo y paneles con <section> identificada redujo el JavaScript en un 65% y mejoró el LCP de 3.4s a 1.6s.

Las leyes que están acelerando el cambio

Dos marcos regulatorios están forzando esta migración:

European Accessibility Act (EAA): Vigente desde junio de 2025, exige que todos los sitios web de servicios esenciales en la UE —banca, e-commerce, transporte, telecomunicaciones, servicios públicos— cumplan con WCAG 2.1 AA. El efecto dominó alcanza a cualquier empresa que haga negocios en Europa. Los sitios que dependen de patrones ARIA complejos y frágiles están fallando auditorías porque el markup es demasiado intrincado para mantenerlo accesible de forma consistente.

ADA Title II (EE.UU.): Aunque el Departamento de Justicia extendió recientemente los plazos de cumplimiento hasta 2027-2028, la dirección es clara: los sitios web de gobiernos estatales y locales, y por extensión las empresas que interactúan con ellos, deben alcanzar WCAG 2.1 AA. La extensión no es una relajación — es un reconocimiento de que la migración es compleja y necesita tiempo.

El mensaje conjunto es ineludible: el HTML semántico nativo ya no es una buena práctica opcional. Es un requisito de cumplimiento legal.

Lo que aprendimos migrando proyectos con ARIA excesivo

En nuestro último proyecto de accesibilidad para un SaaS B2B, el challenge era representativo. El sitio tenía 47 componentes que usaban ARIA de forma intensiva, desde menús desplegables hasta un sistema de tabs anidados de tres niveles. Auditamos con axe-core y WAVE: 34 violaciones de accesibilidad, la mayoría por estados ARIA incorrectos o faltantes.

Nuestra estrategia fue simple pero efectiva:

Paso 1: Identificar cada patrón ARIA y preguntar "¿existe un elemento HTML que haga esto?" Para tabs, sí (botones + secciones). Para modales, sí (<dialog>). Para menús desplegables, sí (<details> + <summary>). Para tooltips personalizados, no — ahí ARIA sigue siendo necesario.

Paso 2: Reemplazar los patrones donde existía alternativa nativa. Esto eliminó el 70% del ARIA del sitio. El JavaScript de accesibilidad se redujo de 180 KB a 45 KB.

Paso 3: Para el 30% restante (widgets personalizados sin equivalente nativo), documentar roles, estados y propiedades ARIA como parte del design system, con tests automatizados usando axe-core en CI/CD.

Los resultados: LCP pasó de 3.8s a 1.9s. Violaciones de accesibilidad: de 34 a 2 (ambas falsos positivos por un tooltip personalizado). Y el equipo de desarrollo reportó que los nuevos componentes eran "significativamente más fáciles de mantener."

¿Qué queda para ARIA en 2026?

ARIA no desaparece. Roles como alert, alertdialog, treegrid y ciertos patrones de combobox no tienen equivalentes HTML nativos — y probablemente no los tendrán pronto. ARIA para widgets personalizados complejos sigue siendo necesario y correcto.

Pero la tendencia es clara: ARIA como muleta para suplir HTML mal escrito es un antipatrón que 2026 está enterrando. La industria se está moviendo hacia un enfoque que llamamos "HTML-first accessibility": escribir HTML semántico correcto primero, y solo añadir ARIA cuando el elemento nativo no existe.

Esto tiene implicaciones directas para cómo construimos sitios. Si estás usando un framework que genera <div> tras <div> con roles ARIA para crear componentes de interfaz, ese framework te está mintiendo sobre su accesibilidad. La accesibilidad real no está en los atributos ARIA — está en el árbol de accesibilidad que el navegador construye a partir de tu HTML.

Cómo empezar la migración hoy

Evaluar si tu sitio depende de ARIA en exceso es sencillo:

1. Audita con axe-core — corre una auditoría automatizada y cuenta cuántas reglas de ARIA viola tu sitio. Más de 10 violaciones ARIA es señal de dependencia excesiva.
2. Inspecciona el árbol de accesibilidad — en DevTools, ve a la pestaña Accessibility y verifica si los roles que esperas están siendo expuestos por el navegador o por ARIA. Los roles expuestos por HTML nativo son más estables.
3. Mide tu JavaScript — si tienes más de 50 KB de código dedicado a gestionar estados de accesibilidad (focus management, aria-expanded, aria-selected), tienes margen de simplificación.

Hemos cubierto estrategias de migración similares en nuestros artículos sobre arquitectura web composable y rendimiento con Server Islands, donde el patrón es el mismo: la solución más simple y nativa suele ser la más robusta.

El costo de ignorar el cambio

Una empresa de e-commerce que auditamos en Q1 2026 tenía un carrito de compras construido enteramente con div y ARIA. El carrito era funcional — para usuarios sin discapacidad. Para un usuario de lector de pantalla, era inutilizable: los estados de los productos (agregado, removido, actualizado) no se anunciaban porque el aria-live estaba mal configurado. La empresa enfrentaba una demanda por incumplimiento de la EAA.

El costo de migrar a HTML nativo fue de aproximadamente 40 horas de desarrollo. El costo de no haberlo hecho era potencialmente cientos de miles de euros en multas y daño reputacional.

En 2026, la accesibilidad web ya no es un extra de calidad. Es un requisito legal, una ventaja competitiva y —cada vez más— una cuestión de arquitectura de software. Y resulta que la solución más simple también es la más accesible.