Accname: el algoritmo detrás del nombre accesible

Cuando pensamos en un elemento interactivo, como un campo de formulario, un botón o un enlace, solemos identificarlo por el texto que vemos en pantalla. Sin embargo, las tecnologías de asistencia no siempre utilizan esa misma información para identificarlo.

En algunos casos, el nombre accesible coincide con el texto visible, pero en otros puede obtenerse a partir de una etiqueta asociada, un atributo HTML o incluso una propiedad ARIA. Entonces, ¿cómo determina el navegador qué información debe exponer a las tecnologías de asistencia?

La respuesta se encuentra en la especificación Accessible Name and Description Computation 1.1 del W3C, también conocida como Accname.

¿Qué es el nombre accesible?

La especificación Accname lo define de una forma muy simple: “El nombre accesible es el nombre de un elemento de la interfaz de usuario.”

En otras palabras, el nombre accesible es la etiqueta textual que representa a un elemento dentro del árbol de accesibilidad y que las tecnologías de asistencia utilizan para identificarlo e interactuar con él, determinando, por ejemplo, qué anuncia un lector de pantalla cuando el foco llega a un botón o qué frase debe pronunciar un usuario de reconocimiento de voz para activarlo.

En el caso más sencillo, el nombre accesible coincide directamente con el texto visible:

Ejemplo: Enlace volver a inicio.

<a href="https://www.weaaare.com">Volver a inicio</a>

Resultado mediante lector de pantalla:

Sin embargo, el nombre accesible no tiene por qué provenir de un contenido visible. En una imagen, por ejemplo, lo proporciona el atributo alt:

Ejemplo: Icono de cierre.

<img src="close.svg" alt="Cerrar" />

Aunque el texto "Cerrar" no aparezca en pantalla, es la información que recibirán las tecnologías de asistencia.

Resultado mediante lector de pantalla:

Sin embargo, no siempre existe una única fuente de información para calcular el nombre accesible. Si se añade un aria-label a la imagen anterior, existirán dos candidatos potenciales:

Ejemplo: Icono de cierre.

<img
  src="close.svg"
  alt="Cerrar"
  aria-label="Cerrar operativa" />

La presencia de múltiples fuentes potenciales no implica que todas participen en el cálculo del nombre accesible. El navegador aplica un orden de prioridad para determinar cuál debe utilizarse, y dicho orden es precisamente el que define el algoritmo.

Resultado mediante lector de pantalla:

El algoritmo detrás del nombre accesible

Accname define un orden de evaluación estricto mediante el cual el navegador recorre las posibles fuentes de información y se detiene en cuanto encuentra una válida, ignorando el resto. De forma simplificada, la secuencia es la siguiente:

• ¿El elemento tiene un aria-labelledby válido?
• En caso contrario, ¿tiene un aria-label?
• En caso contrario, ¿existe algún mecanismo nativo de HTML que proporcione un nombre?
• En caso contrario, ¿puede obtenerse un nombre a partir del contenido textual del elemento?

Veamos cada uno en detalle.

1. Aria-labelledby

aria-labelledby tiene la mayor prioridad dentro del algoritmo y permite asociar un elemento con el contenido textual de otro nodo del DOM mediante su id, de forma que ese contenido externo se convierte en el nombre accesible.

Por ejemplo, en un switch que activa o desactiva una funcionalidad, el texto descriptivo puede encontrarse visualmente junto al control sin existir una relación semántica nativa entre ambos.

Ejemplo: Switch.

<span id="notifications-label">
  Notificaciones por correo
</span>
<button
  role="switch"
  aria-checked="false"
  aria-labelledby="notifications-label"></button>

Aunque el botón no contiene ningún texto en su interior, el algoritmo encuentra el aria-labelledby, resuelve la referencia al elemento con id="notifications-label" y utiliza su contenido textual como nombre accesible.

Resultado mediante lector de pantalla:

2. Aria-label

Si no existe un aria-labelledby, el algoritmo comprueba si el elemento dispone de un aria-label. A diferencia del mecanismo anterior, no se establece ninguna referencia a otro nodo del DOM, sino que el propio valor del atributo se utiliza directamente como nombre accesible.

Ejemplo: Botón.

<button aria-label="Descargar documento PDF">
  Descargar documento
  <svg aria-hidden="true">...</svg>
</button>

En este caso, el nombre accesible será "Descargar documento PDF", ya que el algoritmo encuentra el aria-label y utiliza su valor, ignorando tanto el texto visible del botón como cualquier otro contenido accesible que pudiera existir en su interior.

Resultado mediante lector de pantalla:

3. Mecanismos nativos de HTML

Cuando no existe ningún atributo ARIA, el navegador recurre a los mecanismos de nombrado que proporciona el propio HTML. Dependiendo del elemento, el nombre accesible puede obtenerse de distintas fuentes nativas, como un <label> asociado a un campo de formulario o un <caption> en una tabla.

Ejemplo: Campo de formulario.

<label for="campo-de-correo">Correo electrónico</label>
<input id="campo-de-correo" type="email" />

Resultado mediante lector de pantalla:

Ejemplo: Tabla.

<table>
  <caption>Comparativa de planes</caption>
  ...
</table>

Resultado mediante lector de pantalla:

A diferencia de los atributos ARIA, estos mecanismos forman parte de la semántica nativa de HTML, por lo que suelen ofrecer un comportamiento más consistente entre navegadores y tecnologías de asistencia. Por este motivo, siempre que exista una solución nativa adecuada, será preferible utilizarla antes que recurrir a ARIA.

4. Contenido textual

Si ninguno de los mecanismos anteriores está presente, el algoritmo recurre al contenido textual del propio elemento para calcular su nombre accesible. Este es el comportamiento habitual en botones y enlaces que contienen texto explícito:

Ejemplo: Botón guardar.

<button>Guardar</button>

Resultado mediante lector de pantalla:

Aunque se trata del mecanismo con menor prioridad dentro del algoritmo, en muchos casos también es el más sencillo y robusto, ya que el nombre accesible coincide de forma natural con el contenido visible sin necesidad de añadir atributos o asociaciones adicionales.

Aplicando Accname en escenarios reales

Los ejemplos anteriores muestran cada mecanismo de forma aislada, pero en una auditoría real es habitual encontrar elementos donde varias fuentes intervienen simultáneamente. En estos casos, conocer el orden de evaluación definido por Accname permite anticipar el resultado sin necesidad de recurrir al ensayo y error.

Ejemplo 1: Múltiples fuentes ARIA

<span id="increase-label">Aumentar cantidad</span>
<button
  aria-labelledby="increase-label"
  aria-label="Aumentar">
  <img src="./img/plus-icon.svg" alt="Sumar producto" />
  Aumentar
</button>

Este botón dispone de cuatro posibles fuentes de nombre accesible: el aria-labelledby, el aria-label, el alt de la imagen y el texto visible. Sin embargo, el nombre accesible resultante será "Aumentar cantidad", obtenido a partir del elemento referenciado por aria-labelledby.

Resultado mediante lector de pantalla:

El aria-label, el alt de la imagen y el texto visible del botón quedan excluidos del cálculo. Por este motivo, añadir múltiples mecanismos de nombrado rara vez aporta beneficios y, en muchos casos, solo incrementa la complejidad del componente.

Ejemplo 2: Acumulación de contenido textual

Hasta ahora hemos visto ejemplos en los que el algoritmo encuentra una fuente prioritaria y detiene la evaluación. Sin embargo, cuando no existe ningún atributo ARIA ni mecanismo nativo que proporcione un nombre accesible, el comportamiento es diferente.

<a href="./resources/report.pdf" download>
  <img src="./img/download-icon.svg" alt="Descargar" />
  <span class="visually-hidden">
    Descargar informe completo
  </span>
  Descargar informe
</a>

.visually-hidden {
  clip: rect(0 0 0 0);
  clip-path: inset(50%);
  height: 1px;
  overflow: hidden;
  position: absolute;
  white-space: nowrap;
  width: 1px;
}

Este enlace no dispone de aria-labelledby, aria-label ni de ningún mecanismo nativo específico para proporcionar un nombre accesible. Como consecuencia, el algoritmo recurre al contenido del propio elemento y utiliza toda la información accesible presente en su interior.

Dado que todo el contenido permanece expuesto al árbol de accesibilidad, el algoritmo incorpora tanto el texto alternativo de la imagen como el contenido oculto visualmente y el texto visible del enlace, concatenando todas estas fuentes para generar el nombre accesible.

Resultado mediante lector de pantalla:

Aunque técnicamente el resultado es correcto, el nombre accesible obtenido es redundante y más largo de lo necesario. En situaciones como esta, suele ser recomendable simplificar las fuentes que intervienen en el cálculo, por ejemplo, marcando la imagen como decorativa mediante alt="" o revisando si el contenido oculto aporta información realmente necesaria, de forma que el nombre resultante sea fácil de comprender.

Mirada hacia el futuro

Desde la publicación de Accessible Name and Description Computation 1.1, la plataforma web ha evolucionado e incorporado nuevas tecnologías y patrones de desarrollo que han hecho necesario revisar y ampliar determinados aspectos de la especificación.

Como respuesta a esta evolución, el W3C está desarrollando actualmente Accessible Name and Description Computation 1.2, una versión que, aunque a fecha de publicación de este artículo continúa en fase de borrador, se encuentra en un estado avanzado de desarrollo.

Entre las novedades más destacadas se encuentran las aclaraciones relacionadas con el cálculo de nombres accesibles en componentes basados en Shadow DOM y elementos <slot>, así como la incorporación de soporte para aria-description, una propiedad definida en el borrador de WAI-ARIA 1.3 para proporcionar descripciones accesibles de forma explícita.

Conclusión

Comprender el algoritmo Accname permite dejar de tratar el comportamiento de las tecnologías de asistencia como una caja negra.

Cuando entiendes las reglas que utiliza el navegador para calcular un nombre accesible, puedes anticipar el resultado, detectar problemas con mayor facilidad y realizar recomendaciones de remediación más precisas.

La próxima vez que te encuentres con un nombre accesible inesperado, no olvides que las tecnologías de asistencia solo pueden transmitir la información que reciben. Aunque cada una la interprete y la presente con sus propios matices, la respuesta suele encontrarse en qué contenido ha tomado Accname para construir ese nombre accesible.