¿Advertencias de accesibilidad en Austria? Lo que las empresas europeas deben saber ahora mismo
Leer historiaaria-label en HTML: Cómo usarlo correctamente
![]()
aria-label: Código pequeño, gran impacto
Imagina que visitas una tienda online y solo ves el icono del carrito de la compra. Los usuarios videntes entienden inmediatamente la función de compra. Pero para los usuarios que utilizan lectores de pantalla, el botón sigue sin estar claro. Solo con una etiqueta aria como «Añadir al carrito» se describe con claridad y se vuelve accesible.
La accesibilidad digital comienza en el código. El HTML semántico es la base, mientras que la etiqueta aria-label solo complementa cuando los elementos estándar no son suficientes. Esto beneficia no solo a las instituciones, sino también a las empresas, especialmente a las tiendas en línea, donde los botones y campos de formulario claros garantizan un proceso de compra fluido.
¿Qué es una etiqueta aria?
El atributo aria-label forma parte de la especificación ARIA (Aplicaciones de Internet Enriquecidas Accesibles) del W3C (Consorcio World Wide Web). El W3C es el organismo internacional que desarrolla estándares web abiertos, incluyendo Pautas de accesibilidad para el contenido web (WCAG) .
aria-label añade etiquetas invisibles a los elementos HTML, que los lectores de pantalla anuncian cuando faltan etiquetas visibles o estas no son claras. Esto reduce la brecha entre el diseño y la accesibilidad técnica, haciendo que las interfaces sean comprensibles para todos.
Por qué son importantes los atributos ARIA
Los atributos ARIA se desarrollaron para garantizar la accesibilidad allí donde HTML alcanza sus límites. Los sitios web modernos con contenido dinámico —como elementos JavaScript, widgets personalizados o diseños visuales complejos— presentan sus propios desafíos. En estos casos, un atributo ARIA como `aria-label` garantiza que incluso estas interfaces sean interpretadas correctamente por los lectores de pantalla.
Diferencia con las etiquetas visibles en la interfaz de usuario.
Una diferencia clave entre aria-label y las etiquetas visibles radica en su público objetivo: las etiquetas visibles están disponibles para todos los usuarios, mientras que aria-label es exclusivamente para tecnologías de asistencia.
Las etiquetas visibles son las descripciones de texto estándar que se muestran en la interfaz; por ejemplo, el texto "Dirección de correo electrónico" encima o al lado de un campo de entrada:
<label for="email">Dirección de correo electrónico</label>
<input type="email" id="email" name="email">
Todos los usuarios reconocen inmediatamente qué deben introducir en el campo, y los lectores de pantalla también leen el texto en voz alta. Si no se dispone de una etiqueta visible, se puede utilizar una etiqueta aria en su lugar. Esta añade de forma invisible una descripción que solo los lectores de pantalla pueden detectar.
<input type="email" id="email" name="email" aria-label="Dirección de correo electrónico">
De esta forma, el campo sigue siendo comprensible y accesible, incluso sin una etiqueta visible.

¿Cómo funciona aria-label en HTML?
Los lectores de pantalla determinan el nombre accesible de un elemento en un orden fijo:
aria-etiquetado por – hace referencia al texto visible en el código
aria-label – etiqueta invisible
visible <etiqueta> – para campos de formulario
contenido de texto – p. ej., texto del botón
atributo de título – último recurso
No se reconoce un botón de icono de búsqueda sin una descripción adicional. Con aria-label="Buscar" El lector de pantalla lee "Buscar" en voz alta, de forma clara y utilizable.
Ejemplo:
Un botón con un icono de lupa para buscar no tiene texto visible. Sin información adicional, no tendría sentido para los lectores de pantalla. Sin embargo, si agrega aria-label="Buscar" El lector de pantalla anuncia "Buscar" e ignora todas las demás fuentes posibles.
Ejemplos de aria-label para botones y enlaces
Un caso de uso común para aria-label son los botones que solo contienen un icono. Para los usuarios videntes, una lupa se entiende inmediatamente como una función de búsqueda, pero para los lectores de pantalla no tiene ningún significado. Con aria-label, el botón también resulta comprensible para las tecnologías de asistencia.
<button aria-label="Iniciar búsqueda">
<svg aria-hidden="true" width="24" height="24">…</svg>
</button>
Otro ejemplo práctico son las listas. Muchas tiendas en línea utilizan listas basadas en iconos, como listas de categorías con símbolos. Los lectores de pantalla solo anunciarían "Lista con 5 elementos". Con aria-label="Categorías de productos" Queda claro lo que contiene la lista.
Los enlaces, a su vez, deben describir claramente a dónde conducen. Una frase vaga como «Más información» no es accesible, ya que no queda clara sin contexto. aria-label puede mejorar esto:
<a href="/article/accessibility"
aria-label="Leer artículo sobre accesibilidad digital">
Lea el artículo sobre accesibilidad digital.
</a>
aria-label para elementos de formulario
Los formularios son una parte fundamental de casi todos los sitios web. Para que sean accesibles, cada campo del formulario debe tener un nombre claro. Normalmente, esto se hace con un elemento visible. <etiqueta> elemento:
<label for="email">Dirección de correo electrónico</label>
<input type="email" id="email" name="email">
La ventaja: Todos los usuarios ven la etiqueta "Dirección de correo electrónico" y los lectores de pantalla la leen en voz alta. Además, los usuarios pueden hacer clic en la etiqueta para enfocar automáticamente el campo.
En ocasiones, por motivos de diseño, no se utiliza ninguna etiqueta visible; por ejemplo, cuando solo aparece un marcador de posición dentro del campo. Para los usuarios de lectores de pantalla, esto resulta problemático, ya que los marcadores de posición no se consideran etiquetas oficiales. Aquí es donde aria-label resulta útil:
<input type="email"
aria-label="Dirección de correo electrónico"
marcador de posición="ejemplo@dominio.com">
Los usuarios videntes ven el campo como de costumbre, pero los usuarios de lectores de pantalla oyen «Dirección de correo electrónico». Esto garantiza que el campo siga siendo comprensible incluso sin una etiqueta visible.
Otro ejemplo son los campos de entrada que requieren instrucciones adicionales —como los campos de contraseña. Aquí, una simple etiqueta no es suficiente. Con aria-descrita por , el campo puede vincularse a información adicional:
<input type="password"
aria-label="Contraseña"
aria-describedby="pwd-help">
<div id="pwd-help">Al menos 8 caracteres, incluyendo un número</div>
En este caso, el lector de pantalla primero lee "Contraseña", seguido de "Al menos 8 caracteres, incluyendo un número".
Importante: aria-label en los formularios generalmente debe permanecer el excepción . Un visible <etiqueta> Es casi siempre la mejor solución: es clara para todos, más fácil de usar y requiere menos lógica adicional. aria-label debería servir principalmente como alternativa cuando las etiquetas se ocultan por motivos de diseño o maquetación.
Funciones ARIA y su interacción con las etiquetas
Los roles ARIA describen la función de un elemento, mientras que aria-label define su nombre. Esta combinación es especialmente importante para los widgets personalizados que van más allá de la semántica estándar de HTML:
<div role="button" aria-label="Suscribirse al boletín" tabindex="0">
<svg>...</svg>
Inscribirse
</div>
Para widgets interactivos como menús, son relevantes atributos adicionales. aria-expandida indica si un menú está expandido, mientras que aria-haspopup señales que indican que un elemento activa una ventana emergente o un menú:
<button aria-label="Abrir menú principal"
aria-expanded="false"
aria-haspopup="true"
aria-controls="main-menu">
☰
</button>
<ul id="main-menu" role="menu" hidden>
<li role="menuitem"><a href="#home">Inicio</a></li>
<li role="menuitem"><a href="#about">Sobre nosotros</a></li>
</ul>
Sin embargo, se aplica la primera regla de ARIA: Utilice HTML nativo siempre que sea posible. Un verdadero <botón> un elemento siempre es preferible a un <div role="button"> , puesto que ya incluye todas las funcionalidades necesarias.

aria-label vs. texto alternativo
Un error común es confundir aria-label con alt text. Ambos sirven para la accesibilidad, pero tienen propósitos diferentes:
Texto alternativo Está específicamente diseñado para imágenes, describiendo el contenido visual. Aparece cuando la imagen no se puede cargar y los lectores de pantalla lo leen en voz alta.
etiqueta aria Por otro lado, se puede aplicar a casi todos los elementos HTML y proporciona a los lectores de pantalla información adicional sobre la función o el significado de un elemento.
<!-- Corrección: Texto alternativo para imágenes -->
<img src="product.jpg"
alt="Portátil con pantalla abierta">
<!-- Correcto: aria-label para botón sin texto -->
<button aria-label="Añadir al carrito">
<svg aria-hidden="true">...</svg>
</button>
Para las imágenes, el cálculo del nombre accesible sigue una jerarquía: aria-etiquetado por anulaciones etiqueta aria , que a su vez anula el alt atributo. Pero usando aria-label="Texto alternativo" en lugar de un alt No se recomienda este atributo. alt Siempre debería ser la primera opción para gráficos.
Al utilizar iconos SVG, se debe prestar especial atención:
Iconos decorativos debería ocultarse de los lectores de pantalla con aria-oculta="verdadera" .
Iconos funcionales Necesita una etiqueta aria significativa.
Buenas prácticas para usar aria-label
El uso eficaz de aria-label sigue directrices claras para garantizar tanto la accesibilidad como el mantenimiento del código. Los desarrolladores deben tener en cuenta varios factores para evitar confusiones a los usuarios:
Utilice aria-label con moderación: Úselo únicamente cuando los elementos HTML nativos o las etiquetas visibles no sean suficientes. Los elementos que ya tienen un nombre descriptivo mediante contenido de texto o atributos no necesitan una etiqueta aria adicional.
Escriba descripciones claras y concisas: La etiqueta aria debe ser autoexplicativa y describir con precisión la finalidad del elemento. Evite términos técnicos o nombres internos que no resulten significativos para los usuarios finales.
Combinar con HTML semántico: ARIA complementa HTML pero no lo reemplaza. Utilice elementos semánticos como <botón> , <nav> , o <principal> como base y ampliarlas con atributos ARIA cuando sea necesario.
<!-- INCORRECTO: aria-label redundante -->
<button aria-label="Iniciar sesión">Iniciar sesión</button>
<!-- DERECHA: no se necesita etiqueta aria -->
<button>Iniciar sesión</button>
Considere la gestión del enfoque: Para los widgets interactivos, es fundamental gestionar correctamente el foco. Las ventanas emergentes y los diálogos deben establecer el foco inicial en el primer elemento enfocable y devolverlo al elemento que los activó al cerrarse.
Errores comunes en el etiquetado ARIA
Los errores de implementación más frecuentes surgen de la falta de comprensión de la jerarquía ARIA y del uso incorrecto:
Etiquetas contradictorias: Si la etiqueta aria-label no coincide con el texto visible, los usuarios de software de entrada de voz se confunden. Por ejemplo, una persona ve "Vorname" como etiqueta, pero el lector de pantalla anuncia "First Name". En ese caso, los comandos de voz fallan.
Uso excesivo de ARIA: Agregar la etiqueta aria-label a cada elemento reduce la accesibilidad. Los usuarios de lectores de pantalla se ven sobrecargados de información redundante en lugar de alcanzar su objetivo más rápidamente.
Error al actualizar el contenido dinámico: Para los elementos controlados por JavaScript, es fundamental garantizar que los valores de aria-label se actualicen cuando cambien los estados. Esto es especialmente importante para los widgets con estados dinámicos.
Etiquetas inexactas: Las etiquetas que ya no reflejan la función actual del elemento crean expectativas falsas y dificultan la navegación.
Lista de verificación para desarrolladores y diseñadores
Comprobar necesidad: ¿Realmente necesita el elemento una etiqueta aria-label, o basta con HTML semántico?
Prueba con lectores de pantalla: Utilice NVDA (Windows), VoiceOver (Mac) u otros lectores de pantalla para la verificación.
Validar el cálculo del nombre accesible: Utilice las herramientas para desarrolladores del navegador para comprobar qué nombre se calcula realmente.
Garantizar la coherencia: Utilice una redacción coherente para elementos similares en todo el sitio web.
Documentar las implementaciones de ARIA: Explique en el código por qué y cómo se utilizan los atributos ARIA.
Considere todos los métodos de entrada: Asegúrese de que los widgets se puedan operar tanto mediante el teclado como mediante la pantalla táctil.
Revisar listas y navegación: Utilice etiquetas HTML semánticas para listas y enlaces de navegación, añadiendo atributos ARIA donde sea necesario.
Conclusión: Cómo usar aria-label de forma eficaz
El atributo aria-label es una herramienta valiosa para sitios web accesibles, pero requiere una implementación cuidadosa. Sirve de puente entre el diseño visual y la accesibilidad semántica, pero siempre debe considerarse un complemento del HTML semántico, no un sustituto.
La eficacia de aria-label se hace más evidente en botones con iconos, widgets personalizados y casos donde las etiquetas visibles alterarían el diseño visual. Al mismo tiempo, requisitos legales como BFSG y WCAG 2.1 exigen un enfoque sistemático para las etiquetas ARIA.
La clave para una implementación exitosa de ARIA reside en comprender que la accesibilidad web es un paso importante hacia la inclusión digital de todas las personas, independientemente de sus capacidades o limitaciones individuales.
Preguntas frecuentes
¿Debería utilizarse siempre aria-label, o solo cuando sea necesario?
La etiqueta aria-label solo debe aplicarse cuando los elementos HTML nativos o las etiquetas visibles no sean suficientes. Su uso excesivo genera información redundante y una peor experiencia de usuario para quienes utilizan lectores de pantalla.
¿Cómo puedo comprobar si mi etiqueta aria funciona?
Para realizar pruebas realistas, utilice lectores de pantalla como NVDA (Windows) o VoiceOver (Mac/iOS). Las herramientas para desarrolladores del navegador muestran las propiedades calculadas y el nombre accesible real en la pestaña Accesibilidad.
¿Qué lectores de pantalla son compatibles con aria-label?
Los lectores de pantalla modernos, como NVDA, JAWS, VoiceOver y TalkBack, ofrecen una amplia compatibilidad con aria-label. Sin embargo, la compatibilidad puede variar según el navegador y la versión, por lo que se recomienda realizar pruebas en diferentes configuraciones.
¿Qué sucede si un elemento no tiene etiqueta aria?
Los lectores de pantalla recurren al siguiente nombre disponible en la jerarquía de Cálculo de Nombres Accesibles: aria-labelledby, contenido de texto visible o el atributo title. Sin ninguna etiqueta, los elementos interactivos pueden resultar incomprensibles para las tecnologías de asistencia.
La accesibilidad comienza en el código: con Eye-Able, puede comprobar que sus sitios web y aplicaciones tengan las etiquetas ARIA correctas y otras barreras, de forma legalmente conforme y eficiente.
Filtro
Un año de la EAA: Dónde la mayoría de las empresas siguen fallando
Leer historia:no_upscale())
No, un overlay tool no hace que un sitio web sea accesible automáticamente
Leer historiaPor qué los datos de producto accesibles mejoran la experiencia de usuario en eCommerce
Leer historia¿Se aplica la EAA al sector B2B?
Leer historia¿Cómo reconocer un sitio web realmente accesible?
Leer historia:no_upscale():format(png))
:no_upscale():format(png))