HTML
Por qué los elementos HTML nativos deben ser la primera opción antes de añadir roles ARIA o reconstruir comportamientos con div y JavaScript.
ARIA complementa la semántica cuando HTML nativo no puede expresar un patrón. No reemplaza automáticamente los elementos, estados y comportamientos que ya ofrece la plataforma.
<button type="button">Guardar</button>suele ser mejor que:
<div role="button" tabindex="0">Guardar</div>Cuando existe un elemento nativo con la semántica y comportamiento necesarios, utilízalo.
acción → button
navegación → a con href
encabezado → h1–h6
lista → ul/ol + li
campo → input/select/textarea + label
tabla → table/th/tdMuchos elementos ya exponen roles:
<nav>...</nav>
<main>...</main>
<button>...</button>Añadir roles redundantes no suele aportar:
<nav role="navigation">...</nav>
<button role="button">...</button>Puede aumentar ruido y crear incompatibilidades si el role contradice el elemento.
<a role="button" href="/delete">Eliminar</a>El role puede cambiar cómo se anuncia, pero el elemento conserva comportamiento de enlace. La combinación puede confundir teclado y navegación.
Usa un button para la acción.
<div aria-expanded="true">Contenido</div>El estado no tiene sentido sin un control o patrón que pueda expandirse.
ARIA incorrecto puede ocultar semántica nativa, crear nombres erróneos o anunciar estados inexistentes.
ARIA aporta cuando JavaScript mantiene un componente:
<button
type="button"
aria-expanded="false"
aria-controls="filters"
>
Filtros
</button>
<section id="filters" hidden>...</section>Al abrir:
aria-expanded="true"
hidden eliminadoAmbos estados deben permanecer sincronizados.
<svg aria-hidden="true">...</svg>Oculta contenido del árbol accesible, no necesariamente de la pantalla.
No lo uses sobre:
Un elemento visible pero aria-hidden puede crear una experiencia distinta para usuarios.
<table role="presentation">...</table>Elimina semántica estructural cuando el elemento se usa solo para layout heredado.
No lo uses en una tabla de datos: perdería encabezados y relaciones.
Algunos roles de la especificación sirven como categorías y no deben asignarse directamente. Utiliza roles concretos documentados para autoría.
Un tablist necesita tabs y tabpanels relacionados; un menu ARIA requiere navegación y comportamiento de aplicación.
<div role="menu">...</div>no crea automáticamente:
Para navegación de sitio, una lista de enlaces suele ser mejor que un menu ARIA.
<button aria-label="Cerrar">
<svg aria-hidden="true">...</svg>
</button>Es útil en icon buttons. En un botón con texto visible, deja que el texto proporcione el nombre salvo una razón clara.
Añade descripción; no cambia función ni comportamiento.
<button aria-describedby="delete-warning">
Eliminar proyecto
</button>
<p id="delete-warning">Esta acción no se puede deshacer.</p>Antes de construir uno, pregunta:
<button class="unstyled">Guardar</button>Puede conservar semántica, pero si CSS elimina foco, contraste o tamaño de objetivo, la experiencia sigue siendo inaccesible.
Nativo es una base, no una garantía automática.
Componentes pueden ocultar el elemento final:
<Tabs />
<Select />
<Dialog />Inspecciona:
<button
type="button"
aria-expanded="false"
aria-controls="project-details"
>
Ver detalles
</button>
<div id="project-details" hidden>
...
</div>El button aporta activación; ARIA comunica el estado de una relación dinámica.
¿Por qué role="button" no convierte completamente un div en botón?
Porque solo modifica la semántica expuesta; no añade activación con Enter/Espacio, foco, disabled, envío de formularios ni otros comportamientos nativos.
Nombres y descripciones accesibles explica cómo se calcula la identidad de elementos y controles.