¿Qué es aria-label y cómo mejora la accesibilidad de tu código web?

Si diriges un proyecto digital, sabes que un botón sin etiqueta puede convertirse en una barrera infranqueable para una persona usuaria de lector de pantalla. Aquí entra aria-label: un atributo HTML pensado para dar un nombre accesible a elementos que, de otro modo, quedarían “mudos” para las tecnologías de asistencia. 

En este artículo te explicamos qué es, cuándo usarlo, cuándo no, y cómo encaja en un flujo de desarrollo accesible serio. Y si no sabes por dónde empezar cuando hablamos de desarrollo accesible, echa un vistazo a nuestros inSuit Services™.

Qué es aria-label y para qué sirve en accesibilidad web

El atributo aria-label es una propiedad del estándar WAI-ARIA, desarrollado por el W3C, que asigna un nombre accesible a un elemento del DOM. Ese nombre lo “leen” los lectores de pantalla (NVDA, JAWS, VoiceOver, TalkBack) cuando el usuario llega al elemento. Si un icono de lupa no lleva texto visible, aria-label permite anunciarlo como “Buscar”.

Su utilidad principal es cubrir tres escenarios concretos donde el HTML semántico no basta por sí solo:

• Elementos interactivos sin texto visible, como botones que solo contienen un icono SVG.
• Componentes personalizados (divs convertidos en botones o pestañas) que carecen de semántica nativa.
• Enlaces ambiguos del tipo “Leer más” que se repiten varias veces en la página.

La propia W3C insiste en algo clave: ARIA nunca sustituye al HTML semántico. Usa primero las etiquetas nativas y reserva las etiquetas aria para los casos que no se pueden resolver de otra forma para mantener la accesibilidad en WordPress.

Diferencia entre aria-label, aria-labelledby y aria-describedby

Estas tres propiedades parecen sinónimos, pero cumplen funciones distintas. Conocer la diferencia evita errores que penalizan en auditoría:

• aria-label: define un nombre accesible mediante una cadena de texto literal escrita en el propio atributo.
• aria-labelledby: toma el nombre accesible del contenido textual de uno o varios elementos referenciados por su ID.
• aria-describedby: añade una descripción complementaria a partir de uno o varios elementos referenciados por su ID. No sustituye al nombre; se anuncia después de él (textos de ayuda, instrucciones o errores).

Cuándo usar aria-label (y cuándo NO usarlo)

En la práctica, aria describedby vs aria label se resuelve así: el primero describe, el segundo nombra. Si la información ya aparece visible en la página y es la etiqueta principal del elemento, usa aria-labelledby. Si solo está disponible en el atributo, usa aria-label. 

En general, usa aria-label cuando se cumplan estas condiciones:

1. El elemento es interactivo: botón, enlace, input, control personalizado.
2. No tiene texto visible (icono, imagen sin texto, contenedor genérico convertido en control).
3. Ningún otro elemento del DOM contiene el nombre accesible apropiado.

No uses aria-label en estos casos:

• Elementos no interactivos como párrafos, divs decorativos o spans estáticos.
• Cuando ya existe un label visible asociado correctamente con for/id.
• Para asignar un texto distinto al texto visible. Rompe la coherencia entre nombre accesible y nombre visible (criterio WCAG 2.5.3). El aria-label debe contener el texto visible.
• En idiomas distintos al de la página sin declarar lang. El lector de pantalla lo leerá con la pronunciación incorrecta.

Ejemplos prácticos en HTML con atributo aria-label

Tres ejemplos que aparecen casi en cualquier proyecto:

1. Botón con icono solo (lupa de búsqueda):

<button aria-label=”Buscar”><svg …></svg></button>

2. Enlace ambiguo “Leer más” en un listado de tarjetas:

<a href=”/post-1″ aria-label=”Leer más sobre la EAA en España”>Leer más</a>

3. Región del documento navegable con landmarks:

<nav aria-label=”Navegación principal”>…</nav>

También existe la variante html aria-labelledby cuando el nombre accesible ya está en otro elemento del DOM:

<section aria-labelledby=”titulo-seccion”><h2 id=”titulo-seccion”>Cumplimiento normativo</h2>…</section>

¿Aún no acabas de entender para qué sirve aria-labelledby exactamente? Sirve para evitar duplicar texto cuando el nombre ya está visible en pantalla. Es preferible a aria-label en esos casos porque mantiene una única fuente de verdad.

Para complementar el diseño visual sin afectar al nombre accesible se puede ocultar con CSS el elemento referenciado por aria-labelledby, usando una clase tipo .sr-only que lo mantiene disponible para los lectores de pantalla. Conviene evitar display:none en estos casos.

Cómo usar aria-label en React y otros frameworks

En frameworks modernos, el atributo aria-label se aplica como cualquier otra prop. La sintaxis es la que cambia.

En React la sintaxis del atributo aria-label no sufre ninguna modificación, se escribe con el guión intermedio, es decir que es una excepción a la regla de que los atributos deben escribirse en camelCase:

<button aria-label=”Cerrar modal” onClick={handleClose}><IconClose /></button>

En Vue, Angular y Svelte se conserva el nombre HTML original con guión, aunque la sintaxis de enlace dinámico varía según el framework:

• En Vue, mediante v-bind (forma corta): <button :aria-label=”labelText”>…</button>
• En Svelte, de forma directa: <button aria-label={labelText}>…</button>
• En Angular, con el prefijo attr., ya que ARIA se enlaza como atributo y no como propiedad del DOM: <button [attr.aria-label]=”labelText”>…</button>

Cuatro recomendaciones para no comprometer la accesibilidad en aplicaciones SPA:

1. Internacionaliza los valores: nunca dejes cadenas hardcodeadas en inglés si tu app es multidioma.
2. Actualiza el aria-label cuando cambie el estado del componente (un botón “play” pasa a “pause”).
3. Usa librerías como react-aria o Headless UI antes de reinventar componentes accesibles.
4. Audita el resultado renderizado, no solo el código fuente. Es donde fallan la mayoría de SPAs.

Para profundizar en cómo la IA puede ayudar (o estorbar) en esta tarea, te recomendamos nuestro post sobre IA para generar código accesible.

Errores comunes con etiquetas aria y cómo detectarlos con inSuit

Los errores más recurrentes con aria labeling no son técnicos en sentido estricto. Son errores de criterio: equipos que aplican ARIA por defecto, por costumbre, o porque “así sale el lighthouse en verde”. El resultado suele ser una experiencia peor de la que había antes de tocar el código.

Los fallos más vistos en auditorías:

• aria-label distinto al texto visible y rompiendo el criterio WCAG 2.5.3 (Label in Name).
• Uso de aria-label en elementos no interactivos (divs decorativos, párrafos).
• Etiquetas obsoletas que ya no reflejan el estado del componente tras una interacción.
• Cadenas de aria-label en inglés sobre una web en español sin declarar lang del elemento.
• Sobreuso de ARIA como sustituto de HTML semántico (button vs div con role=”button” y aria-label).

Para detectar este tipo de errores y ponerles fin, puedes usar herramientas de apoyo que automatizan el proceso por ti en 2 pasos:

Paso 1 — Detecta problemas con etiquetas aria usando inSuit Auditor™

inSuit Auditor™ realiza auditorías manuales guiadas según la metodología de la norma EN 301 549 y las WCAG 2.2. Permite revisar de forma estructurada los criterios que no se pueden validar con herramientas automáticas: claridad de instrucciones, orden lógico de lectura, foco visible y, sobre todo, estructura semántica y nombres accesibles. 

Es la herramienta que utilizan nuestros equipos para detectar incoherencias entre nombre visible y nombre accesible, etiquetas ARIA mal aplicadas o ausentes en componentes interactivos personalizados.

Paso 2 — Corrige sin modificar el código con inSuit Remedy™

Una vez identificados los errores, inSuit Remedy™ aplica las correcciones en tiempo real, desde la nube, sin tocar el código fuente original.

Tras una auditoría experta, nuestro equipo configura los ajustes avanzados de la solución que insertan o corrigen atributos ARIA, mejoran nombres accesibles y resuelven barreras conforme a las WCAG 2.2 nivel AA y la norma EN 301 549. Es la salida más rápida para sitios en producción que necesitan cumplir la normativa antes de la próxima auditoría.

Un uso correcto del atributo aria label es una decisión de diseño que se toma en cada componente. Integrar esa decisión en tu ciclo de desarrollo evita que la accesibilidad se quede en el último sprint, cuando ya no hay tiempo de corregir. 

¿Quieres conocer más acerca de nuestras soluciones de accesibilidad digital? En inSuit, te ofreceremos toda la información que necesites sobre nuestros servicios. ¡No dudes en contactarnos!