Com s'anuncia un camp: nom accessible, estats i 2.5.3 Etiqueta en el nom

A la lliçó anterior vam aprendre a associar etiquetes, grups i ajudes amb <label>, <fieldset> i aria-describedby. Ara mirem el resultat des de l'altre costat: què rep de debò la tecnologia de suport. Com vam veure al curs N3-C1, el navegador construeix un arbre d'accessibilitat i, per a cada camp, exposa un rol, un nom, una descripció, uns estats i un valor. Si entens com es calcula cadascun, depuraràs en minuts errades que semblen misterioses i compliràs dos criteris que s'incompleixen sovint sense que ningú se n'adoni: el 4.1.2 Nom, funció, valor (A) i el 2.5.3 Etiqueta en el nom (A).

Què anuncia un lector de pantalla en arribar a un camp

Quan el focus entra en un camp, el lector compon el seu anunci amb les propietats que li lliura el navegador. L'ordre i la redacció canvien entre NVDA, JAWS, VoiceOver i TalkBack, però els ingredients són els mateixos.

Sense nom, el lector només diu «quadre d'edició». Amb un nom equivocat, la persona escriu amb tota confiança la dada que no és. Tots dos casos incompleixen el 4.1.2, i el segon és més traïdor perquè ningú no el detecta mirant la pantalla.

Com calcula el navegador el nom

El càlcul el defineixen dues especificacions del W3C: Accessible Name and Description Computation (l'algorisme general) i HTML Accessibility API Mappings (com s'aplica a cada element HTML). Per a un camp de text, el navegador prova les fonts en un ordre fix i es queda amb la primera que dona un text no buit. Les altres es descarten: no se sumen.

aria-labelledby substitueix, no afegeix

aria-labelledby guanya a tot, inclòs el <label> visible. És útil per compondre el nom amb diversos textos de la pàgina, però fet servir a la lleugera esborra l'etiqueta original.

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

<th id="col-cantidad" scope="col">Quantitat</th>
…
<th id="prod-3" scope="row">Motxilla escolar blava</th>
<td><input type="text" inputmode="numeric"
           aria-labelledby="col-cantidad prod-3"></td>
<!-- Nom calculat: «Quantitat Motxilla escolar blava» -->

aria-label trepitja l'etiqueta visible

aria-label va segon. Si un camp té alhora un <label> visible i un aria-label, el lector anuncia l'aria-label i l'etiqueta que veu la persona deixa de fer-se servir com a nom del camp. És la causa més comuna d'incompliment del 2.5.3, com veurem de seguida.

title i placeholder: els últims recursos

Només quan no hi ha res de l'anterior es recorre a title i, en últim lloc, al placeholder. Que el navegador els faci servir com a nom no els converteix en bones etiquetes: title només es veu en passar el ratolí (mai amb teclat ni a les pantalles tàctils) i el placeholder desapareix en escriure, com vam veure a la lliçó anterior.

2.5.3 Etiqueta en el nom: el que es veu és el que es diu

Qui fa servir control per veu (Voice Control a macOS i iOS, Voice Access a Android, Dragon a Windows) activa els controls dient-ne el nom: veu un botó que diu «Envia la sol·licitud» i ho diu en veu alta. Si el nom accessible d'aquest botó és un altre, el programa no el troba. Per això el 2.5.3 exigeix que, als components que tenen una etiqueta visible amb text, el nom accessible contingui aquest text. La tècnica recomanada és que el nom comenci pel text visible.

• Visible «Envia la sol·licitud» i aria-label="Envia la sol·licitud d'ajuda escolar": compleix, perquè el conté i comença igual.
• Visible «Envia la sol·licitud» i aria-label="Tramita": incompleix.
• Visible «Codi postal» i aria-label="CP": incompleix, i a més el lector anuncia una sigla que la persona no ha vist.
• Visible «Nom:» amb el nom accessible «Nom»: compleix; la puntuació i les majúscules no es consideren rellevants per a aquest criteri.

Els botons que només tenen una icona (una lupa, una paperera) no tenen etiqueta visible amb text, així que el 2.5.3 no s'hi aplica, però continuen necessitant un nom pel 4.1.2. Tria el que diria qualsevol persona en veure'l: «Cerca», «Elimina».

Mode formulari: per què es perden les instruccions

Els lectors de pantalla d'escriptori tenen dues maneres de treballar. En el mode de navegació (o exploració), la persona recorre tot el contingut amb fletxes i dreceres. En entrar en un camp de text passen al mode de focus (NVDA) o de formularis (JAWS) perquè les tecles escriguin en lloc de navegar. En aquest mode, i sempre que s'avança amb Tab, només se sent el que pertany al control enfocat: nom, rol, estats i descripció.

Conseqüència directa: un paràgraf solt entre dos camps («La contrasenya ha de tenir almenys 8 caràcters») no se sent si ningú no l'associa al camp. La persona no ho sabrà fins que el formulari la rebutgi. El mateix passa amb les instruccions col·locades després del botó d'enviar o en una columna lateral.

• L'imprescindible per emplenar el camp va al seu nom o a la seva descripció.
• El nom, curt i estable: «Contrasenya nova». El format i les regles, a la descripció.
• Les instruccions generals del formulari, abans del primer camp, perquè es llegeixin en el mode de navegació abans de començar.

Estats que també s'anuncien

Els estats completen l'anunci i tenen els seus propis paranys:

• required exposa l'estat «obligatori» i activa la validació nativa; aria-required="true" només exposa l'estat. Fes servir el primer: encara que desactivis les bombolles natives amb novalidate, required continua exposant l'estat «obligatori»; aria-required queda per a controls personalitzats que no admeten required.
• aria-invalid="true" es posa només després de validar i només als camps que fallen. Un formulari que neix amb tots els camps «no vàlids» resta credibilitat a l'estat.
• disabled treu el camp de l'ordre de tabulació: qui navega amb Tab no el sent. Si una dada precarregada importa (el NIF del titular que no es pot canviar), fes servir readonly, que es pot enfocar i llegir.

Com inspeccionar-ho

No cal endevinar: el navegador mostra el resultat del càlcul. A les eines per a desenvolupadors de Chrome i Edge, pestanya Elements, tauler Accessibility, l'apartat de propietats calculades indica el rol, el nom i de quina font ha sortit cada part (aria-labelledby, aria-label, label, title o placeholder), a més de la descripció i els estats. Firefox té el seu propi inspector d'accessibilitat. Després, escolta el camp amb un lector de pantalla real: és el que sentirà la persona.

Resum

• El lector anuncia rol, nom, estats, descripció i valor; tot surt del codi, no de la pantalla.
• El nom s'agafa de la primera font disponible: aria-labelledby, aria-label, <label>, title i placeholder, en aquest ordre; no se sumen.
• El 2.5.3 exigeix que el nom contingui el text visible, idealment al principi: si hi ha text visible, no hi afegeixis aria-label.
• En mode formulari només se sent el que està associat al camp: les instruccions soltes entre camps es perden.
• Comprova el nom calculat al tauler d'accessibilitat del navegador i escolta'l amb un lector de pantalla.