Cómo se anuncia un campo: nombre accesible, estados y 2.5.3 Etiqueta en el nombre

En la lección anterior aprendimos a asociar etiquetas, grupos y ayudas con <label>, <fieldset> y aria-describedby. Ahora miramos el resultado desde el otro lado: qué recibe de verdad la tecnología de apoyo. Como vimos en el curso N3-C1, el navegador construye un árbol de accesibilidad y, para cada campo, expone un rol, un nombre, una descripción, unos estados y un valor. Si entiendes cómo se calcula cada uno, depurarás en minutos fallos que parecen misteriosos y cumplirás dos criterios que se incumplen a menudo sin que nadie lo note: 4.1.2 Nombre, función, valor (A) y 2.5.3 Etiqueta en el nombre (A).

Qué anuncia un lector de pantalla al llegar a un campo

Cuando el foco entra en un campo, el lector compone su anuncio con las propiedades que le entrega el navegador. El orden y la redacción cambian entre NVDA, JAWS, VoiceOver y TalkBack, pero los ingredientes son los mismos.

Sin nombre, el lector solo dice «cuadro de edición». Con un nombre equivocado, la persona escribe con toda confianza el dato que no es. Ambos casos incumplen 4.1.2, y el segundo es más traicionero porque nadie lo detecta mirando la pantalla.

Cómo calcula el navegador el nombre

El cálculo lo definen dos especificaciones del W3C: Accessible Name and Description Computation (el algoritmo general) y HTML Accessibility API Mappings (cómo se aplica a cada elemento HTML). Para un campo de texto, el navegador prueba las fuentes en un orden fijo y se queda con la primera que da un texto no vacío. Las demás se descartan: no se suman.

aria-labelledby sustituye, no añade

aria-labelledby gana a todo, incluido el <label> visible. Es útil para componer el nombre con varios textos de la página, pero usado a la ligera borra la etiqueta original.

<h2 id="sec-solicitante">Datos del solicitante</h2>
<label for="dni">DNI o NIE</label>
<input id="dni" name="dni" aria-labelledby="sec-solicitante">

<th id="col-cantidad" scope="col">Cantidad</th>
…
<th id="prod-3" scope="row">Mochila escolar azul</th>
<td><input type="text" inputmode="numeric"
           aria-labelledby="col-cantidad prod-3"></td>
<!-- Nombre calculado: «Cantidad Mochila escolar azul» -->

aria-label pisa la etiqueta visible

aria-label va segundo. Si un campo tiene a la vez un <label> visible y un aria-label, el lector anuncia el aria-label y la etiqueta que ve la persona deja de usarse como nombre del campo. Es la causa más común de incumplimiento de 2.5.3, como veremos enseguida.

title y placeholder: los últimos recursos

Solo cuando no hay nada de lo anterior se recurre a title y, en último lugar, al placeholder. Que el navegador los use como nombre no los convierte en buenas etiquetas: title solo se ve al pasar el ratón (nunca con teclado ni en pantallas táctiles) y el placeholder desaparece al escribir, como vimos en la lección anterior.

2.5.3 Etiqueta en el nombre: lo que se ve es lo que se dice

Quien usa control por voz (Voice Control en macOS e iOS, Voice Access en Android, Dragon en Windows) activa los controles diciendo su nombre: ve un botón que pone «Enviar solicitud» y lo dice en voz alta. Si el nombre accesible de ese botón es otro, el programa no lo encuentra. Por eso 2.5.3 exige que, en los componentes que tienen una etiqueta visible con texto, el nombre accesible contenga ese texto. La técnica recomendada es que el nombre empiece por el texto visible.

• Visible «Enviar solicitud» y aria-label="Enviar solicitud de ayuda escolar": cumple, porque lo contiene y empieza igual.
• Visible «Enviar solicitud» y aria-label="Tramitar": incumple.
• Visible «Código postal» y aria-label="CP": incumple, y además el lector anuncia una sigla que la persona no ha visto.
• Visible «Nombre:» con nombre accesible «Nombre»: cumple; la puntuación y las mayúsculas no se consideran relevantes para este criterio.

Los botones que solo tienen un icono (una lupa, una papelera) no tienen etiqueta visible con texto, así que 2.5.3 no se aplica, pero siguen necesitando un nombre por 4.1.2. Elige el que diría cualquiera al verlo: «Buscar», «Eliminar».

Modo formulario: por qué se pierden las instrucciones

Los lectores de pantalla de escritorio tienen dos formas de trabajar. En el modo de navegación (o exploración), la persona recorre todo el contenido con flechas y atajos. Al entrar en un campo de texto pasan al modo de foco (NVDA) o de formularios (JAWS) para que las teclas escriban en lugar de navegar. En ese modo, y siempre que se avanza con Tab, solo se oye lo que pertenece al control enfocado: nombre, rol, estados y descripción.

Consecuencia directa: un párrafo suelto entre dos campos («La contraseña debe tener al menos 8 caracteres») no se oye si nadie lo asocia al campo. La persona no lo sabrá hasta que el formulario la rechace. Lo mismo ocurre con las instrucciones colocadas después del botón de enviar o en una columna lateral.

• Lo imprescindible para rellenar el campo va en su nombre o en su descripción.
• El nombre, corto y estable: «Contraseña nueva». El formato y las reglas, en la descripción.
• Las instrucciones generales del formulario, antes del primer campo, para que se lean en el modo de navegación antes de empezar.

Estados que también se anuncian

Los estados completan el anuncio y tienen sus propias trampas:

• required expone el estado «obligatorio» y activa la validación nativa; aria-required="true" solo expone el estado. Usa el primero: aunque desactives las burbujas nativas con novalidate, required sigue exponiendo el estado «obligatorio»; aria-required queda para controles personalizados que no admiten required.
• aria-invalid="true" se pone solo después de validar y solo en los campos que fallan. Un formulario que nace con todos los campos «no válidos» resta credibilidad al estado.
• disabled saca el campo del orden de tabulación: quien navega con Tab no lo oye. Si un dato precargado importa (el NIF del titular que no se puede cambiar), usa readonly, que se puede enfocar y leer.

Cómo inspeccionarlo

No hace falta adivinar: el navegador muestra el resultado del cálculo. En las herramientas para desarrolladores de Chrome y Edge, pestaña Elements, panel Accessibility, el apartado de propiedades calculadas indica el rol, el nombre y de qué fuente ha salido cada parte (aria-labelledby, aria-label, label, title o placeholder), además de la descripción y los estados. Firefox tiene su propio inspector de accesibilidad. Después, escucha el campo con un lector de pantalla real: es lo que oirá la persona.

Resumen

• El lector anuncia rol, nombre, estados, descripción y valor; todos salen del código, no de la pantalla.
• El nombre se toma de la primera fuente disponible: aria-labelledby, aria-label, <label>, title y placeholder, en ese orden; no se suman.
• 2.5.3 exige que el nombre contenga el texto visible, idealmente al principio: si hay texto visible, no añadas aria-label.
• En modo formulario solo se oye lo asociado al campo: las instrucciones sueltas entre campos se pierden.
• Comprueba el nombre calculado en el panel de accesibilidad del navegador y escúchalo con un lector de pantalla.