HTML semántico primero: accesibilidad que no necesita ARIA

La mayor parte de los problemas de accesibilidad vienen del elemento equivocado, no de un atributo ARIA que falta. Un button recibe foco, funciona con el teclado y toma su propio nombre del texto. Una div con un manejador de clic no tiene nada de eso hasta que reconstruyes cada comportamiento a mano. El HTML semántico es la primera capa porque el navegador y el lector de pantalla ya coinciden en lo que esos elementos significan.

Por qué el HTML semántico es la primera capa

El navegador lee tu marcado y construye un árbol de accesibilidad. Cada elemento aporta un rol, un nombre y un estado a ese árbol. La tecnología asistiva lee el árbol, no los píxeles, así que el árbol es la única versión de tu página que recibe quien usa lector de pantalla.

La WCAG 2.2 (en inglés) es una Recomendación del W3C publicada el 12 de diciembre de 2024. Escribe el requisito como criterio de conformidad verificable. El Criterio de Conformidad 1.3.1, nivel A, pide que la estructura y las relaciones transmitidas por la presentación se determinen por programa. El Criterio de Conformidad 4.1.2, también nivel A, pide que el nombre y el rol de cada componente de interfaz se determinen por programa.

Ese segundo criterio (en inglés) lleva una nota que vale la pena leer dos veces. Dice que los controles HTML estándar ya cumplen el criterio cuando se usan según la especificación. El camino más barato hacia la conformidad es entonces elegir el elemento cuyo rol ya es el rol que quieres.

En la práctica eso significa nav para la navegación, main para el contenido principal y h1 a h6 para los títulos. También significa ul y ol para las listas, label ligado a su campo y fieldset con legend para controles agrupados. Nada de esto cuesta una línea de JavaScript.

Qué resuelve el elemento correcto y qué no resuelve ningún atributo

El elemento correcto llega con el comportamiento incorporado, y el navegador mantiene ese comportamiento por ti.

button trae foco, activación con Enter y Espacio, estado deshabilitado y nombre accesible tomado de su propio texto. La MDN lo describe como un elemento que se activa con ratón, teclado, dedo, comando de voz u otra tecnología asistiva.
a con href trae el rol de enlace, el foco y la navegación que maneja el navegador.
details con summary trae expandir y contraer sin script y sin ARIA.
dialog trae comportamiento modal, contención de foco y la tecla Escape.

Hay problemas que ningún atributo resuelve. Conviene saber cuáles son, para no perder tiempo buscando uno.

Ningún atributo da significado al contenido. ARIA puede nombrar un control. No decide que un párrafo es un título, ni que tres elementos son una lista.
Ningún atributo arregla el orden de lectura. El Criterio de Conformidad 1.3.2 pide que una secuencia de lectura correcta se determine por programa. Esa secuencia viene del orden de tu marcado.
Ningún atributo arregla el orden del foco después de un reordenamiento visual. El order de CSS mueve cajas en pantalla y deja la secuencia de tabulación donde estaba. La MDN advierte contra CSS que cambia el orden de los elementos enfocables.
Ningún atributo arregla el contraste, el tamaño del objetivo o el espaciado del texto. Son propiedades visuales, y los criterios que las cubren tratan de CSS.

Foco, teclado y orden de lectura

El foco es el cursor del teclado. Qué puede recibirlo, y en qué orden, decide si quien usa teclado logra terminar la tarea.

Algunos elementos son enfocables por defecto. La MDN los lista: a con href, area con href, button, input, select, textarea, summary, iframe, object y frame. Entran en la secuencia de tabulación en el orden del documento. Ese hecho solo explica el consejo más repetido de la referencia: escribe el documento con los elementos en secuencia lógica.

El tabindex cambia ese valor por defecto y es fácil equivocarse con él. tabindex="0" pone el elemento en la secuencia de tabulación en la posición donde está en el código. tabindex="-1" deja el elemento enfocable desde script y fuera de la secuencia de tabulación. Un valor positivo lanza el elemento delante del orden del documento, y por eso la MDN recomienda usar solo 0 y -1.

El Criterio de Conformidad 2.4.3, nivel A, pide que los componentes enfocables reciban foco en un orden que preserve significado y operabilidad. El Criterio de Conformidad 2.4.7, nivel AA, pide un indicador de foco visible. La WCAG 2.2 añadió el Criterio de Conformidad 2.4.11 (en inglés), Foco No Obscurecido en el nivel mínimo, que cubre el encabezado fijo que tapa el campo al que acabas de tabular. El estado de interacción y el foco visible son el tema de estado e interacción.

El orden de lectura es un eje distinto del orden del foco, y quien usa lector de pantalla lo recorre por la estructura. Salta de título en título, de lista en lista, de región en región. La MDN observa que navegar por títulos es una técnica común y que saltarse un nivel deja a la persona preguntándose dónde quedó el título que falta. Un h1 por página, después h2, después h3, sin huecos. La idea antigua de que un section reiniciaba el esquema de títulos nunca se implementó y hoy no es conforme.

Cuándo hace falta ARIA y cuándo empeora

ARIA no es el enemigo. Es la herramienta para los casos que el HTML no cubre, y esos casos son reales.

La Primera Regla del Uso de ARIA (en inglés) enuncia el principio y después lista las excepciones. Prefiere un elemento o atributo nativo que ya cargue la semántica y el comportamiento que necesitas. Usa ARIA en cuatro casos. El recurso no está implementado en HTML, falta soporte de la tecnología asistiva para el elemento nativo, el diseño visual descarta el elemento nativo, o HTML no tiene ese recurso.

Casos concretos donde ARIA es la respuesta correcta:

Regiones activas. Un filtro cambia y la página debe anunciar que quedan tres resultados. role="status" o aria-live hacen eso, y HTML no tiene un elemento que anuncie por su cuenta. El Criterio de Conformidad 4.1.3, Mensajes de Estado en el nivel AA, existe justo para esto, y pide un mensaje que llegue a la tecnología asistiva sin recibir foco.
aria-expanded en un control de apertura personalizado, para que el estado se pueda leer, además de ver.
aria-current="page" en el enlace activo de la navegación, un estado que HTML no expresa.
aria-labelledby apuntando una región a un título que ya existe, en vez de copiar el texto en una segunda etiqueta.

Donde ARIA empeora:

role="button" en una div con manejador de clic. El rol anuncia un botón y no agrega el resto. No agrega foco y no agrega activación por teclado. La Tercera Regla del Uso de ARIA (en inglés) exige que todo control interactivo con ARIA sea utilizable con el teclado, y nombra el deber concreto: el elemento debe recibir foco y responder a Enter y a Espacio. Ese deber ahora es tuyo.
aria-hidden="true" en un elemento enfocable. La Cuarta Regla del Uso de ARIA (en inglés) lo prohíbe, porque el resultado es una persona enfocando la nada. La misma regla vale para ancestros, ya que ocultar un contenedor oculta los hijos interactivos que están dentro.
Un rol que no corresponde al comportamiento. Falla en silencio y le dice al lector de pantalla algo falso, lo que es peor que no decir nada.

Una advertencia para quien quiera citar las reglas. El W3C hoy lista el documento Using ARIA como Borrador Descontinuado, fechado el 24 de febrero de 2026, y conserva las cuatro reglas como referencia. La fuente actual para patrones de componentes es la ARIA Authoring Practices Guide (en inglés). La propia WAI-ARIA 1.2 sigue siendo una Recomendación del W3C (en inglés) del 6 de junio de 2023.

El error común de usar ARIA para arreglar marcado equivocado

El patrón es conocido. La tarjeta debe ser clicable, así que el desarrollador pone role="button" y tabindex="0" en una div. Después un aria-label para dar el nombre. Después un manejador de teclado para Enter y un segundo para Espacio, porque el primero no se disparó. Cuarenta líneas reemplazan un <button>.

La Segunda Regla del Uso de ARIA (en inglés) nombra esto directo. No cambies la semántica nativa salvo que de verdad lo necesites, y el ejemplo de la propia especificación es un título convertido en pestaña. El arreglo es el elemento que debiste usar, no un atributo mejor.

La señal es la acumulación. Cuando una div necesita rol, tabindex, manejador de teclado y etiqueta para actuar como control, el elemento es el error. Cambia el elemento y borra los atributos.

Hay otra señal, en sentido contrario. Cuando ARIA repite lo que el elemento ya dice, es ruido. role="navigation" en un nav no agrega nada. role="list" en un ul no agrega nada. El ARIA redundante cuesta mantenimiento y puede salir de sincronía con el elemento.

Cómo verificar, sin herramientas de pago

La mayor parte del trabajo es verificable con teclado, navegador y paciencia.

Suelta el ratón y tabula por la página desde la barra de direcciones. Si el foco desaparece o se salta un control, encontraste un defecto y no una preferencia. Los Criterios de Conformidad 2.4.7 (en inglés) y 2.4.11 (en inglés) tratan de esto.
Compara el orden de tabulación con el orden visual. Cuando los dos no coinciden, el orden del DOM es el que sigue el teclado, y el order de CSS es el primer sospechoso.
Abre el árbol de accesibilidad en las herramientas de desarrollo del navegador y lee el rol y el nombre calculados de cada control. Es la misma información que recibe el lector de pantalla.
Apaga el CSS y lee la página. Los títulos, listas y etiquetas que sobreviven son los que marcaste bien.
Aplica 200 por ciento de zoom y comprueba que nada queda cortado, porque el reflow es criterio y no cuestión de gusto.
Revisa que el esquema de títulos no tenga huecos, porque la lista de títulos es como mucha gente que usa lector de pantalla hojea una página.

Pero esto tiene un límite. Los verificadores automáticos capturan una parte de los defectos y ninguno de los significados. La herramienta dice que la imagen tiene texto alternativo. No dice que el texto alternativo está mal. Una sesión real de lector de pantalla y una persona real son la única prueba para eso, y ningún script gratuito reemplaza a las dos. Las comprobaciones que se sostienen antes de que alguien abra la página están en accesibilidad verificable.

El orden del trabajo es fijo. Elige el elemento que ya significa lo que quieres decir. Mantén el orden del DOM igual al orden visual. Mantén el foco visible. Recurre a ARIA solo donde HTML no tiene respuesta, y entonces escribe lo mínimo posible de él. El ARIA que conservas es el ARIA que todavía puedes acertar dentro de un año.

Un argumento parecido sobre heredar trabajo en vez de repetirlo está en el texto sobre Material Design.

Donde Nielsen Norman Group no coincide

Nielsen Norman Group no mide la accesibilidad por conformidad. El texto sobre que la accesibilidad no basta (en inglés) afirma que tratar la accesibilidad como una puntuación no ayuda a quien tiene discapacidad. Una lista de verificación tampoco enseña a escribir texto alternativo. El texto sobre diseño inclusivo (en inglés) pone el listón más allá del cumplimiento. Este post mantiene un criterio de conformidad de la WCAG como listón verificable, que es una tesis más estrecha.

Una preferencia va contra el resto del post. El texto sobre acceso directo frente a acceso secuencial (en inglés) prefiere el acceso directo. La orientación de este texto, en cambio, trata del camino secuencial de la tecla Tab y del salto de título en título.

Los otros dos textos no se contradicen. Cómo leen las personas en la web (en inglés) trata del escaneo, y el texto sobre navegación por teclado (en inglés) trata de la operación. Canales distintos, tesis distintas.