Los toasts (o “snackbars”, avisos flotantes, notificaciones breves) son ese tipo de UI que parece inocente… hasta que te das cuenta de que puede convertirse en una máquina de interrumpir personas. Si los haces mal, suben la carga cognitiva, rompen el foco, saturan lectores de pantalla y, en el peor caso, hacen que el usuario pierda confianza: “¿Qué ha pasado? ¿Se guardó? ¿Falló? ¿Dónde miro ahora?”

La gracia está en el equilibrio: anunciar lo importante sin convertir cada micro-evento del sistema en un megáfono. Aquí entra aria-live, pero no como “ponlo y listo”, sino como una herramienta que hay que diseñar: qué se anuncia, cuándo, con qué prioridad, con qué texto y con qué interacción.

En este artículo vamos a bajar a tierra decisiones reales: role, aria-live, duración, cola de mensajes, acciones, foco, patrones UI y ejemplos de implementación. Y, sí, vamos a comparar algo clave: tiempo de decisión vs. carga cognitiva (porque los toasts influyen en ambos).

Qué es un toast (y por qué la accesibilidad aquí no es “extra”)

Un toast es una notificación breve que suele aparecer en una esquina o borde de la pantalla, se mantiene unos segundos y desaparece. Lo usamos para:

• Confirmaciones: “Guardado”, “Copiado”, “Añadido a favoritos”.
• Errores: “No se pudo guardar”, “Conexión perdida”.
• Estados: “Sincronizando…”, “Modo offline”.
• Acciones rápidas: “Elemento eliminado — Deshacer”.

El problema: no todos los usuarios “ven” un toast. Algunas personas usan lector de pantalla, otras tienen baja visión, otras están en móvil con el pulgar tapando media pantalla, otras van con prisa, cansancio o estrés. Si tu toast solo existe “en lo visual”, estás dejando fuera a una parte de tu audiencia (y, además, estás haciendo UX más frágil para todos).

Aquí entra el objetivo real:

• UX: que el usuario entienda qué pasó y qué hacer.
• A11y: que esa información sea perceptible y operable sin depender de la vista ni del timing.

Tiempo de decisión vs. carga cognitiva: el coste oculto de un toast mal hecho

Dos métricas mentales que se disparan con notificaciones mal diseñadas:

Tiempo de decisión

Es el tiempo que tardas en responder mentalmente: “¿Esto requiere algo de mí?”. Si tu toast es ambiguo (“Error”), el usuario necesita más tiempo para decidir.

Carga cognitiva

Es el esfuerzo total para entender y gestionar lo que ocurre. Si tus toasts aparecen cada 2 segundos (o narran cosas irrelevantes), el usuario se fatiga, pierde el hilo y comete más errores.

Un toast accesible y bien diseñado reduce ambas:

• Texto claro → baja tiempo de decisión.
• Prioridad correcta + frecuencia controlada → baja carga cognitiva.
• Acciones coherentes (“Deshacer”) → menos fricción.

aria-live explicado como si lo fueras a usar mañana

Las live regions (regiones en vivo) permiten que un lector de pantalla anuncie cambios dinámicos sin que el usuario tenga que mover el foco.

Conceptos que debes conocer (sí o sí)

aria-live

Define la urgencia del anuncio.

• polite: el lector de pantalla anuncia cuando puede, sin interrumpir.
• assertive: interrumpe para anunciar inmediatamente (úsalo con pinzas).

role

Algunos roles ya implican comportamientos típicos:

• role="status" suele equivaler a anuncio polite.
• role="alert" suele equivaler a anuncio assertive.

Regla práctica: status para confirmaciones y estados, alert para errores graves o bloqueantes.

aria-atomic="true"

Hace que se anuncie el mensaje completo cuando cambia (en lugar de solo el fragmento modificado). Para toasts, suele ser buena idea.

aria-relevant

Controla qué cambios se anuncian (añadidos, removidos, texto). En toasts, normalmente no necesitas tocarlo si actualizas el texto entero.

Elegir el patrón correcto: ¿toast, banner, diálogo o inline?

Antes de tocar ARIA, pregunta esto:

¿El usuario necesita actuar ahora?

• Si sí, quizá no es un toast. Puede ser:
  • Inline error junto al campo (ideal en formularios).
  • Banner persistente arriba (“Hay errores en el formulario”).
  • Diálogo si bloquea la tarea (con moderación).

¿Es solo informativo y no bloquea?

• Toast funciona bien: “Guardado”, “Copiado”, “Añadido…”.

¿Es un error crítico?

• Toast puede valer si además ofreces ruta clara (“Reintentar”, “Ver detalles”) o si duplicas el mensaje en un lugar persistente.

Antipatrón clásico: usar toast para errores de validación en campos. Eso sube el tiempo de decisión (“¿qué campo?”) y la carga cognitiva (“tengo que buscar dónde falló”).

Diseñar el mensaje: microcopy que se entiende en 1 segundo

Tu texto tiene que ser “escaneable”, porque un toast es breve y el usuario no está “leyendo”, está haciendo otra cosa.

Fórmula útil

Qué pasó + dónde/qué afecta + qué puedo hacer

Ejemplos mejores:

• ✅ “Ruta guardada en Favoritos.”
• ✅ “No se pudo guardar la ruta. Reintenta.”
• ✅ “Conexión perdida. Estás en modo offline.”
• ✅ “Foto eliminada. Deshacer.”

Ejemplos peores:

• ❌ “Error”
• ❌ “Operación realizada”
• ❌ “Algo salió mal”

Longitud y tono

• Evita tecnicismos (“HTTP 500”) salvo en herramientas para usuarios técnicos.
• Si hay acción, ponla en verbo claro: Reintentar, Deshacer, Ver.

Implementación accesible: estructura y ARIA que no molestan

Aquí está la clave: no todo toast merece ser anunciado.

Prioridad de anuncios (guía práctica)

1) Confirmaciones suaves → role="status" / aria-live="polite"

• “Guardado”
• “Copiado”
• “Añadido”

2) Errores importantes → role="alert" (con moderación)

• “No se pudo pagar”
• “Sesión caducada”
• “Permiso denegado”

3) Ruido → NO se anuncia

• “Sincronizando… 1%… 2%… 3%…”
• “Auto-guardado cada 5s”
• “Actualizando lista…”

Si algo se actualiza continuamente, anúncialo solo al inicio y al final, o muévelo a un estado visible persistente (ej. barra de estado).

Evitar el “lector de pantalla ametralladora”: colas, deduplicación y throttling

Si tu app dispara muchos eventos, necesitas control.

Estrategias reales que funcionan

Cola de mensajes

Muestra y anuncia uno a la vez. Si hay 5, no los sueltes juntos. En cola:

• Anuncia el actual.
• Cuando desaparece, pasa al siguiente.

Deduplicación

Si llega el mismo mensaje varias veces (“Guardado”), agrúpalo:

• “Guardado (x3)” o
• No repitas si ocurrió hace < 2–3 segundos.

Throttling por tipo

• Estados “suaves”: máximo 1 cada X segundos.
• Errores: siempre, pero con copy útil y acción.

Esto reduce carga cognitiva para todos y, especialmente, para usuarios con lector de pantalla.

Duración, pausa y control: el toast no puede ser una bomba de tiempo

Duración recomendada

• Confirmaciones: 3–5s.
• Mensajes con acción (Deshacer): 6–10s (o persistente hasta interacción si es crítico).
• Errores: considera persistencia o que el usuario pueda cerrarlo manualmente.

¿Debe ser “cerrable”?

• Si es polite y no crítico, no siempre hace falta.
• Si interrumpe, contiene acción o puede tapar contenido: sí, botón “Cerrar”.

Accesibilidad del autocierre

Si el usuario necesita actuar (ej. “Deshacer”), no lo cierres demasiado rápido. Y cuidado: un toast que desaparece antes de que el lector de pantalla lo termine de anunciar es frustrante.

Foco: cuándo NO debes moverlo (casi siempre)

Un toast, por defecto, no debería robar foco. Si lo hace:

• Rompe el flujo de teclado.
• Aumenta tiempo de decisión (“¿dónde estoy?”).
• Multiplica carga cognitiva.

Excepciones

• Si el toast realmente es un “diálogo disfrazado” porque exige decisión inmediata, entonces no es toast: usa un diálogo accesible con foco gestionado (y probablemente un overlay).

Ejemplos de implementación

Ejemplo 1: Región live global (recomendada) + visual toast independiente

La idea: separas la capa “anuncio accesible” de la capa visual. Así controlas mejor qué se anuncia y cuándo, sin depender del DOM del componente visual.

<!-- Live region (puede estar cerca del root) -->
<div id="live-region"
     role="status"
     aria-live="polite"
     aria-atomic="true"
     class="sr-only">
</div>

<!-- Contenedor visual de toasts -->
<div class="toast-stack" aria-label="Notificaciones">
  <!-- Cada toast visual NO necesita aria-live -->
</div>

Cuando ocurre un evento que quieras anunciar, actualizas el texto de #live-region.

Ejemplo 2: Error crítico con role="alert"

<div id="live-error"
     role="alert"
     aria-atomic="true"
     class="sr-only">
</div>

Úsalo para fallos importantes. Y si hay acción, ponla cerca del lugar donde el usuario pueda actuar (no solo en el toast).

Diseño e interacción: patrones de toasts que no rompen la UX

Patrón recomendado: “Acción reversible”

Cuando el usuario elimina algo:

• Toast: “Elemento eliminado. Deshacer.”
• Acción real: retrasas el borrado definitivo unos segundos, o guardas un snapshot para revertir.

Esto reduce ansiedad y mejora decisión.

Patrón recomendado: “Error + siguiente paso”

En lugar de “Error al guardar”:

• “No se pudo guardar. Reintentar.”
• “No se pudo guardar. Comprueba tu conexión.”
• “No se pudo guardar. Vuelve a iniciar sesión.”

Menos tiempo de decisión, menos carga cognitiva.

Patrón recomendado: “Estados persistentes para procesos largos”

En vez de 20 toasts:

• Una zona de estado: “Subiendo 3 archivos…”
• Y toast solo al final: “Subida completada.”

Testing: cómo saber si tu solución funciona de verdad

Checklist rápido

Con teclado

• ¿Puedes seguir trabajando sin que el toast te saque del foco?
• ¿El botón “Cerrar” es alcanzable si existe?
• ¿La acción “Deshacer” es accesible por teclado?

Con lector de pantalla

• ¿Se anuncia lo importante y solo lo importante?
• ¿No se cortan mensajes por updates rápidos?
• ¿No se repiten confirmaciones sin sentido?

En móvil

• ¿No tapa botones críticos?
• ¿No queda debajo de elementos sticky?
• ¿Se puede cerrar fácilmente?

Detalle importante

Si tu toast aparece en el DOM, se re-renderiza, cambia de orden o se destruye demasiado rápido, el lector de pantalla puede:

• anunciarlo tarde,
• no anunciarlo,
• o anunciarlo incompleto.

Por eso, muchas veces conviene la estrategia de live region global.

Errores típicos (y cómo evitarlos)

1) Convertir todo en assertive

Esto es el “modo sirena”. El usuario acaba saturado, y con lector de pantalla es directamente agresivo.

Solución: polite por defecto, alert solo en lo crítico.

2) Toast para validación de formularios

El usuario escucha “Hay un error”, pero no sabe dónde.

Solución: error inline + resumen arriba (banner) + foco al primer error si envía el formulario.

3) Mensajes ambiguos

“Operación completada” no significa nada.

Solución: explica qué se completó y qué implica.

4) Autocierre demasiado rápido con acción

Si hay “Deshacer”, 2 segundos no sirven.

Solución: más tiempo o persistente hasta interacción.

Checklist final para “toasts accesibles de verdad”

Semántica y ARIA

• Usa role="status" + aria-live="polite" para confirmaciones.
• Usa role="alert" solo para errores importantes.
• Añade aria-atomic="true" si actualizas texto.
• Considera una live region global para anuncios.

UX

• Mensaje claro: qué pasó + impacto + siguiente paso.
• No robes foco.
• Controla frecuencia (cola/deduplicación).
• Si hay acción, da tiempo suficiente.

Diseño

• No tapes CTAs importantes.
• Respeta responsive y barras sticky.
• Mantén jerarquía visual: error ≠ confirmación.

Preguntas frecuentes (FAQs)

¿Es mejor role="alert" o aria-live="assertive" para errores?

En la práctica, role="alert" suele ser la opción directa para errores urgentes porque ya está pensado para avisos importantes. Pero lo clave no es el atributo: es cuándo lo usas. Si todo es “urgente”, nada lo es. Reserva alert/assertive para casos donde el usuario realmente necesita enterarse ya (fallo de pago, sesión caducada, bloqueo de acción).

¿Un toast debería ser “cerrable” siempre?

No siempre. Si es una confirmación leve (“Copiado”), puede autocerrarse sin botón. Pero si el toast:

• tapa contenido,
• incluye una acción (“Deshacer”),
• o es un error que el usuario puede querer revisar,
  entonces sí, añade “Cerrar” (y que sea accesible por teclado).

¿Dónde coloco la live region para que funcione bien?

Idealmente, cerca del root de tu app (layout principal), para que sea estable y no se destruya con cambios de ruta. Lo importante es que:

• exista siempre,
• se actualice solo cuando corresponde,
• y no reciba “spam” de mensajes.

---

La accesibilidad es “diseño de interrupciones”

Los toasts son, literalmente, una interrupción. Y diseñar interrupciones bien es un acto de respeto: respeto por el foco, por el tiempo del usuario y por su energía mental.

Un toast accesible no es “poner aria-live”. Es decidir con criterio qué merece ser anunciado, escribir un mensaje que se entiende al vuelo y crear un comportamiento que no secuestra la atención. Cuando lo haces bien, bajas el tiempo de decisión (“entiendo qué pasó”) y reduces la carga cognitiva (“no me saturas con ruido”).

Así que la próxima vez que quieras notificar algo, prueba esta pregunta simple: “¿Esto ayuda al usuario a avanzar… o solo me ayuda a mí a sentir que el sistema está hablando?”
Si ayuda a avanzar, anúncialo. Si es ruido, guárdatelo. El mejor toast, muchas veces, es el que no molesta.

Los iconos accesibles en HTML no dependen solo de si un icono se ve bonito o encaja visualmente en la interfaz. La clave está en entender si ese icono es decorativo, informativo o funcional, porque cada caso necesita un tratamiento distinto en accesibilidad web.

Un icono decorativo puede ocultarse a las tecnologías de asistencia con aria-hidden="true" cuando no aporta información nueva. En cambio, un icono funcional, como un botón de búsqueda, favoritos o cerrar ventana, necesita un nombre accesible que explique claramente qué acción realiza.

El problema aparece cuando usamos iconos sin texto visible y damos por hecho que todas las personas van a entenderlos igual. Para una persona que navega con lector de pantalla, teclado o tecnologías de asistencia, un icono sin nombre puede convertirse en un botón mudo, ambiguo o directamente inútil.

En este artículo vamos a ver cómo crear iconos accesibles en HTML, cuándo usar aria-hidden, cuándo añadir aria-label o texto oculto, y qué errores conviene evitar cuando trabajas con iconos decorativos, enlaces, botones e interfaces sin texto visible.

Iconos accesibles en HTML: reglas básicas

Antes de tocar ARIA, conviene separar tres tipos de iconos. Esta clasificación ayuda a decidir si el icono debe ocultarse, describirse o convertirse en parte del nombre accesible del componente.

En accesibilidad web, un icono sin texto puede ser:

• ruido, si es decorativo y el lector de pantalla lo anuncia sin aportar nada;
• una barrera, si es un control interactivo y no tiene nombre accesible;
• una trampa de UX, si obliga a la persona a “adivinar” qué hace.

La clave no es poner aria-hidden porque sí ni añadir aria-label a todo. La clave es entender qué papel cumple ese icono y qué necesita el árbol de accesibilidad para que la experiencia sea coherente.

Qué “ve” la accesibilidad cuando tú ves un icono

Visualmente, un icono puede parecer evidente. Una lupa suele representar buscar, una papelera eliminar y una equis cerrar. Pero esa interpretación depende del contexto, de la experiencia previa y de la capacidad de ver el icono.

Para un lector de pantalla, lo importante no es la forma visual, sino el nombre accesible del elemento. Si un botón solo contiene un SVG sin texto, puede terminar anunciándose como “botón” sin más información. Y un botón que solo dice “botón” no ayuda a tomar decisiones.

Esto también afecta a la navegación con teclado. Si un control recibe foco, la persona usuaria necesita saber qué acción activa antes de pulsar Enter o Espacio. Por eso, cuando hablamos de focus visible y navegación con teclado, también hablamos de nombres accesibles claros.

Iconos accesibles en HTML: cuándo usar aria-hidden

aria-hidden="true" sirve para ocultar un elemento del árbol de accesibilidad. Es útil cuando el icono es puramente decorativo o cuando repite una información que ya aparece como texto visible.

Un caso típico sería un botón que tiene texto visible y un icono de apoyo:

<button type="button">
  <svg aria-hidden="true" focusable="false">
    ...
  </svg>
  Guardar cambios
</button>

En este ejemplo, el icono no necesita anunciarse porque el texto “Guardar cambios” ya comunica la acción. El SVG acompaña visualmente, pero no añade información nueva.

También puedes usar aria-hidden="true" en iconos decorativos dentro de enlaces, tarjetas o mensajes de estado, siempre que el contenido importante esté disponible como texto.

Cuándo no deberías usar aria-hidden

No uses aria-hidden="true" en elementos interactivos ni en elementos que puedan recibir foco. Si ocultas un botón, un enlace o un control de formulario del árbol de accesibilidad, puedes crear una experiencia confusa: el elemento puede seguir siendo visible o incluso enfocable, pero quedar sin significado para tecnologías de asistencia.

Como referencia técnica, puedes consultar la documentación de MDN sobre aria-hidden, donde se explica que este atributo debe reservarse para contenido no interactivo o redundante.

Cuándo necesitas un nombre accesible

Un icono necesita nombre accesible cuando representa una acción, un destino o una información que no aparece escrita en pantalla. Esto ocurre mucho en botones de interfaz, barras de herramientas, cards, navegación móvil o acciones rápidas.

Por ejemplo, este botón no es suficiente:

<button type="button">
  <svg>
    ...
  </svg>
</button>

Visualmente puede parecer un botón de búsqueda, pero para algunas tecnologías de asistencia no hay una acción clara. Una opción mejor sería:

<button type="button" aria-label="Buscar">
  <svg aria-hidden="true" focusable="false">
    ...
  </svg>
</button>

En este caso, el botón tiene un nombre accesible claro: “Buscar”. El icono se oculta porque no necesita anunciarse por separado.

En los iconos accesibles en HTML, el nombre accesible debe describir la acción, no la forma del dibujo. No escribas “lupa” si la acción real es “Buscar”. No escribas “corazón” si la acción real es “Añadir a favoritos”. No escribas “equis” si la acción real es “Cerrar”.

Ejemplos de buenos nombres accesibles

• aria-label="Buscar"
• aria-label="Cerrar menú"
• aria-label="Eliminar producto"
• aria-label="Añadir a favoritos"
• aria-label="Abrir opciones de usuario"

La guía de WAI sobre imágenes funcionales también insiste en esta idea: cuando una imagen o icono inicia una acción, el texto alternativo debe comunicar esa acción.

Aria-label, texto oculto o texto visible: qué elegir

Hay varias formas de dar nombre accesible a un icono funcional. La mejor opción depende del diseño y del contexto.

Opción 1: texto visible

Siempre que puedas, el texto visible suele ser la opción más clara. Beneficia a todo el mundo: personas que usan lector de pantalla, personas con baja visión, personas con dificultades cognitivas y personas que simplemente no reconocen el icono.

<button type="button">
  <svg aria-hidden="true" focusable="false">
    ...
  </svg>
  Eliminar
</button>

Esta opción es especialmente recomendable en acciones delicadas, como eliminar, cancelar, pagar o enviar información.

Opción 2: aria-label

aria-label puede ser útil cuando el diseño solo permite mostrar un icono. Es habitual en botones compactos, barras de herramientas o controles repetidos.

<button type="button" aria-label="Cerrar ventana">
  <svg aria-hidden="true" focusable="false">
    ...
  </svg>
</button>

Eso sí: úsalo con intención. El valor de aria-label debe ser claro, breve y específico.

Opción 3: texto oculto visualmente

Otra opción es incluir texto real en el HTML y ocultarlo visualmente con una clase de utilidad. Esta técnica puede ser muy útil cuando quieres mantener una etiqueta textual en el marcado.

<button type="button">
  <svg aria-hidden="true" focusable="false">
    ...
  </svg>
  <span class="sr-only">Abrir menú</span>
</button>

.sr-only {
  position: absolute;
  width: 1px;
  height: 1px;
  padding: 0;
  margin: -1px;
  overflow: hidden;
  clip: rect(0, 0, 0, 0);
  white-space: nowrap;
  border: 0;
}

Este enfoque funciona bien cuando quieres conservar contenido textual sin cambiar el diseño visual.

Checklist de decisión: aria-hidden vs nombre accesible

Cuando tengas dudas, puedes usar esta pequeña checklist antes de implementar un icono:

• ¿El icono solo decora y no añade información? Usa aria-hidden="true".
• ¿El icono repite un texto visible cercano? Normalmente puedes ocultarlo con aria-hidden="true".
• ¿El icono representa una acción? Necesita nombre accesible.
• ¿El icono está dentro de un botón o enlace sin texto visible? Necesita nombre accesible.
• ¿El icono comunica estado o información importante? No lo ocultes sin ofrecer alternativa textual.
• ¿El elemento recibe foco? No lo escondas con aria-hidden.

Esta checklist te ayudará a crear iconos accesibles en HTML sin caer en dos errores habituales: anunciar iconos decorativos que no aportan nada u ocultar iconos funcionales que sí necesitan explicación.

Casos comunes donde se rompe la accesibilidad

Los problemas con iconos sin texto suelen aparecer en componentes muy cotidianos. Precisamente por eso conviene revisarlos con lupa.

Botón de cerrar

Un botón de cerrar con una equis visual necesita un nombre accesible:

<button type="button" aria-label="Cerrar modal">
  <svg aria-hidden="true" focusable="false">
    ...
  </svg>
</button>

No basta con que el icono “parezca” una equis. La acción debe estar disponible de forma programática.

Botón de favoritos

En un botón de favoritos, el nombre accesible debería reflejar el estado o la acción disponible:

<button type="button" aria-label="Añadir a favoritos">
  <svg aria-hidden="true" focusable="false">
    ...
  </svg>
</button>

Si el elemento ya está guardado, podrías cambiar el nombre a “Quitar de favoritos”.

Iconos en formularios

Los iconos dentro de campos de formulario también pueden generar confusión. Un icono de error no debería ser la única pista de que algo ha fallado. El mensaje debe estar escrito, ser claro y estar asociado correctamente al campo.

Si estás trabajando este tema, te recomiendo complementar este post con la guía sobre formularios accesibles, labels, errores y validación.

Iconos en menús, dropdowns y combobox

En componentes desplegables, los iconos suelen indicar apertura, cierre, estado o selección. Pero no deberían sustituir a una semántica correcta ni a un patrón bien elegido.

Si tienes dudas entre menú, select o combobox, puedes revisar la guía sobre dropdown, select y combobox accesibles, porque cada patrón tiene un comportamiento y unas expectativas diferentes.

Errores comunes al crear iconos accesibles en HTML

Estos son algunos errores que conviene evitar cuando trabajas con iconos accesibles en HTML:

• Usar aria-hidden="true" en un botón o enlace interactivo.
• Dejar un botón de solo icono sin aria-label ni texto oculto.
• Describir la forma del icono en lugar de la acción.
• Usar el mismo aria-label para acciones diferentes.
• Confiar solo en el color o en el icono para comunicar estados.
• Ocultar información importante sin ofrecer alternativa textual.

Muchos de estos errores no se ven a simple vista. La interfaz puede parecer correcta en diseño, pero fallar cuando se navega con teclado, lector de pantalla o herramientas de auditoría.

Cómo testear iconos accesibles sin complicarte

Para revisar si tus iconos están bien planteados, puedes hacer varias pruebas sencillas:

1. Navega solo con teclado y comprueba si todos los controles se entienden al recibir foco.
2. Usa el inspector de accesibilidad del navegador para revisar el nombre accesible de cada botón.
3. Prueba con VoiceOver, NVDA o el lector de pantalla que tengas disponible.
4. Revisa si los iconos decorativos aparecen innecesariamente en el árbol de accesibilidad.
5. Comprueba que los botones de solo icono anuncian una acción clara.

Si un botón solo se anuncia como “botón”, algo falta. Si un icono decorativo se anuncia como “imagen” sin aportar información, probablemente sobra en el árbol de accesibilidad.

Preguntas frecuentes sobre iconos accesibles en HTML

¿Todos los iconos necesitan aria-label?

No. Los iconos decorativos no necesitan aria-label. De hecho, muchas veces es mejor ocultarlos con aria-hidden="true". Solo los iconos que comunican una acción, un estado o una información importante necesitan una alternativa textual.

¿Es mejor usar aria-label o texto oculto?

Depende del caso. aria-label es práctico en botones de solo icono. El texto oculto visualmente puede ser más flexible cuando quieres conservar texto real dentro del HTML. Si puedes mostrar texto visible, normalmente será la opción más clara.

¿Puedo usar title para explicar un icono?

No lo usaría como solución principal. El atributo title no siempre se anuncia de forma consistente y no funciona igual en dispositivos táctiles. Para botones de solo icono, es mejor usar texto visible, texto oculto o aria-label.

Cuando lo bonito sale caro

Los iconos pueden mejorar una interfaz, hacerla más escaneable y reducir ruido visual. Pero también pueden crear barreras si sustituyen a textos necesarios o si se implementan sin pensar en accesibilidad.

Crear iconos accesibles en HTML no significa llenar todo de ARIA. Significa tomar mejores decisiones: ocultar lo decorativo, nombrar lo funcional y asegurarse de que cada persona pueda entender qué está pasando y qué acción puede realizar.

La próxima vez que añadas un icono sin texto, no te preguntes solo si queda bien. Pregúntate también si se entiende, si se anuncia correctamente y si ayuda de verdad dentro del flujo completo.