Los labels ARIA son una de las herramientas mas malinterpretadas en accesibilidad web. El reflejo de muchos desarrolladores es poner un aria-label en cuanto un elemento necesita un nombre accesible. Y en muchos casos, ese reflejo causa mas problemas de los que resuelve. Segun el analisis anual de WebAIM, las paginas que usan ARIA promedian un 41 por ciento mas de errores de accesibilidad detectados que las que no lo usan. Esta estadistica no dice que ARIA sea malo. Dice que la mayoria de los desarrolladores lo usan incorrectamente. Esta guia repasa cada atributo ARIA de etiquetado, explica cuando cada uno es la eleccion correcta, cubre los errores que atrapan incluso a perfiles experimentados, y proporciona patrones de codigo aplicables inmediatamente. Ya sea que estes corrigiendo un sitio existente para cumplir con la Directiva Europea de Accesibilidad (EAA) o construyendo una nueva aplicacion desde cero, dominar los labels ARIA es fundamental para pasar cualquier auditoria WCAG 2.2.
Que hacen realmente los labels ARIA (y que no hacen)
ARIA significa Accessible Rich Internet Applications. La especificacion WAI-ARIA, mantenida por el W3C, proporciona un conjunto de atributos que modifican como aparecen los elementos en el arbol de accesibilidad del navegador. Ese arbol es lo que usan los lectores de pantalla, el software de control por voz y otras tecnologias de asistencia.
Un label ARIA le da a un elemento su nombre accesible. Cuando un lector de pantalla encuentra un boton, anuncia este nombre para que el usuario sepa que hace el boton. Si ese nombre es incorrecto, falta o es confuso, el usuario no puede operar la interfaz.
Tres atributos manejan la mayor parte del trabajo de etiquetado ARIA: aria-label, aria-labelledby y aria-describedby. Cada uno se comporta diferente, y elegir el incorrecto es uno de los errores de accesibilidad mas frecuentes que nuestro verificador detecta en miles de sitios escaneados.
Punto importante: los labels ARIA no cambian nada visualmente. Agregar aria-label a un boton no agrega texto visible. Solo cambia lo que la tecnologia de asistencia anuncia.
Las cinco reglas de ARIA que debes conocer
Antes de entrar en los atributos especificos, estas cinco reglas del W3C gobiernan todo uso de ARIA.
Regla uno: si puedes usar un elemento HTML nativo con la semantica y el comportamiento necesarios, hazlo en lugar de agregar ARIA. Un elemento button nativo ya tiene un rol implicito, responde a eventos de teclado y obtiene su nombre accesible de su contenido de texto. Un div con role button y aria-label requiere replicar todo eso manualmente.
Regla dos: no cambies la semantica nativa sin razon justificada. Agregar role presentation a un encabezado elimina su semantica del arbol de accesibilidad.
Regla tres: todos los controles ARIA interactivos deben ser usables con teclado. Si creas un checkbox personalizado con role checkbox, debes manejar la barra espaciadora, la gestion del foco y el estado aria-checked.
Regla cuatro: no pongas role presentation o aria-hidden true en un elemento enfocable. Un elemento que puede recibir foco pero esta oculto del arbol de accesibilidad crea un control fantasma.
Regla cinco: todo elemento interactivo debe tener un nombre accesible.
aria-label: cuando y como usarlo correctamente
El atributo aria-label proporciona una cadena de texto como nombre accesible para un elemento. Los lectores de pantalla anuncian esta cadena en lugar de cualquier otro contenido de texto.
Usa aria-label cuando un elemento interactivo no tiene texto visible y ningun otro mecanismo proporciona un nombre accesible. El ejemplo clasico es el boton con icono. Un boton de cerrar que solo contiene un icono X necesita aria-label="Cerrar".
Otro caso valido: distinguir landmarks de navegacion repetidos. Si tu pagina tiene dos elementos nav, agregar aria-label="Navegacion principal" y aria-label="Migas de pan" permite a los usuarios de lectores de pantalla saltar al correcto.
Donde los desarrolladores se equivocan: no uses aria-label en elementos que ya tienen texto visible. Bajo el criterio WCAG 2.2 2.5.3 Etiqueta en el nombre, el nombre accesible debe contener el texto visible. Los usuarios de control por voz que dicen clic en enviar no podran activar un boton cuyo nombre accesible es enviar formulario.
Limitacion critica: aria-label no se traduce por las herramientas de traduccion del navegador. Chrome, Edge y Firefox omiten los valores aria-label al traducir una pagina. En Espana, la Ley 11/2023 de accesibilidad (transposicion del EAA) preve multas de hasta 300.000 euros. Para sitios multilingues, usa texto visible o aria-labelledby referenciando texto visible.
aria-labelledby: la alternativa preferida
El atributo aria-labelledby establece el nombre accesible referenciando el id de uno o mas elementos cuyo contenido de texto sirve como nombre. Es mas robusto que aria-label por varias razones.
Primero, como aria-labelledby referencia texto visible en la pagina, las herramientas de traduccion del navegador traducen el texto referenciado automaticamente.
Segundo, aria-labelledby sincroniza automaticamente el texto visible y los nombres accesibles. Si alguien actualiza el texto de un titulo, el nombre accesible se actualiza con el.
Tercero, aria-labelledby puede concatenar texto de multiples elementos listando varios IDs separados por espacios.
Usa aria-labelledby cuando ya existe texto visible que podria servir como nombre accesible. Patrones comunes incluyen etiquetar secciones con sus encabezados, etiquetar dialogos modales con su titulo y etiquetar grupos de formularios.
Comportamiento de prioridad importante: aria-labelledby tiene prioridad sobre aria-label y sobre mecanismos nativos como el elemento label. Usa solo un mecanismo de etiquetado por elemento.
aria-describedby: agregar contexto sin cambiar el nombre
El atributo aria-describedby se confunde a menudo con aria-labelledby pero cumple un proposito diferente. No establece el nombre accesible. Agrega una descripcion que los lectores de pantalla anuncian despues del nombre.
Cuando un lector de pantalla encuentra un campo con la etiqueta Contrasena y un aria-describedby apuntando al texto Debe contener al menos 8 caracteres incluyendo un numero, el anuncio es: Contrasena, campo de texto, Debe contener al menos 8 caracteres incluyendo un numero.
Usa aria-describedby para instrucciones de campos de formulario, requisitos de formato, mensajes de error vinculados a campos especificos e informacion complementaria.
Patron comun para validacion de formularios: cuando el usuario envia un formulario con errores, cada campo invalido recibe aria-describedby apuntando a su mensaje de error.
No uses aria-describedby como sustituto de aria-label o aria-labelledby. Un elemento sin nombre accesible pero con aria-describedby sigue sin nombre. Las listas de navegacion de los lectores de pantalla solo muestran nombres accesibles, no descripciones.
Errores ARIA comunes y como corregirlos
Despues de escanear mas de diez mil sitios web, ciertos errores ARIA aparecen repetidamente.
Error uno: aria-label en elementos que ya tienen texto visible. Un enlace con texto Saber mas y aria-label="Saber mas sobre nuestros precios" crea una discrepancia. Correccion: haz el texto visible suficientemente descriptivo o elimina el aria-label.
Error dos: aria-label en un div o span sin rol. Un div con aria-label pero sin atributo role tiene ese label ignorado. Correccion: agrega un rol apropiado o usa un elemento semantico.
Error tres: duplicar contenido entre aria-label y texto visible. Un boton con texto Buscar y aria-label="Buscar" es redundante.
Error cuatro: usar aria-label en lugar de un elemento label para campos de formulario. Un input con aria-label="Email" pero sin label visible. Correccion: usa un elemento label con el atributo for.
Error cinco: referencias aria-labelledby rotas. Un aria-labelledby apuntando a un id inexistente no produce nombre accesible. Nuestro verificador de accesibilidad detecta automaticamente las referencias rotas.
Error seis: usar aria-label en landmarks sin hacerlos unicos. Tres elementos nav con aria-label="Navegacion" identico impiden distinguirlos.
Patrones ARIA practicos para componentes comunes
La teoria esta bien. Los patrones funcionales son mejores.
Botones con icono. Cada boton que solo contiene un icono necesita un nombre accesible. El enfoque mas robusto es incluir texto visualmente oculto dentro del boton, como un span con clase visually-hidden. Este texto se traduce, funciona con control por voz y proporciona el nombre accesible sin aria-label.
Dialogos modales. Dale al dialogo role dialog y aria-labelledby apuntando a su encabezado. Agrega aria-modal true. Gestiona el foco: muevelo al primer elemento enfocable al abrir, atrapalo dentro del dialogo y devuelvelo al elemento que lo activo al cerrar.
Landmarks de navegacion. Usa el elemento nav nativo. Si tienes varios, etiqueta cada uno con aria-label unico. El menu principal recibe aria-label="Navegacion principal".
Grupos de formulario. Usa fieldset y legend para controles relacionados. No reemplaces este patron con div y aria-label.
Tablas de datos. Usa el elemento caption o aria-labelledby para nombrar la tabla.
Regiones en vivo. Usa aria-live polite para actualizaciones no urgentes y aria-live assertive para mensajes urgentes.
Interfaces de pestanas. El contenedor recibe role tablist, cada pestana role tab con aria-selected, y el panel role tabpanel con aria-labelledby.
Probar tus labels ARIA
Escribir ARIA correcto es la mitad del trabajo. Verificar que funciona es la otra mitad.
Empieza con un escaneo automatizado. Pasa tus paginas por nuestro verificador de accesibilidad gratuito en web-accessibility-checker.com. Detecta nombres accesibles faltantes, referencias aria-labelledby rotas y otros problemas ARIA.
Luego abre el arbol de accesibilidad del navegador. En Chrome DevTools, el tab Accessibility muestra el nombre accesible calculado y de donde proviene.
Prueba con un lector de pantalla. NVDA en Windows y VoiceOver en macOS son gratuitos. Navega la pagina y escucha los anuncios.
Verifica la navegacion por teclado. Cada elemento con un label ARIA debe ser alcanzable por teclado.
Prueba con multiples lectores de pantalla. NVDA, JAWS, VoiceOver y TalkBack interpretan ARIA de forma ligeramente diferente.
En Espana, la Ley 11/2023 transpone la Directiva Europea de Accesibilidad y preve multas de hasta 300.000 euros por incumplimiento. Un testeo ARIA riguroso es parte de cualquier auditoria conforme.