Robust: 4.1.2 Nom, funció i valor i 4.1.3 Missatges d'estat (4.1.1 eliminat)

El principi Robust garanteix que el contingut pugui ser interpretat per una gran varietat d'agents d'usuari i tecnologies de suport, avui i en el futur. A les WCAG 2.2 es redueix a dos criteris operatius, el 4.1.2 i el 4.1.3, però tots dos són enormes: el primer és el criteri que s'incompleix en gairebé tots els components personalitzats mal construïts, i el segon determina si les persones usuàries de lector de pantalla s'assabenten del que passa sense veure-ho. Aquesta lliçó explica com avaluar-los i per què el 4.1.1 ha deixat d'existir; la lliçó 7 la completa amb una taula de referència per patró i els escenaris dinàmics més habituals.

Què ha passat amb el 4.1.1 Processament

El criteri 4.1.1 exigia que el marcatge tingués etiquetes d'inici i de fi completes, una imbricació correcta, sense id duplicats i sense atributs duplicats. Va néixer el 2008 per evitar que un marcatge mal format trenqués les tecnologies de suport, que llavors analitzaven l'HTML directament. Avui els navegadors reparen l'HTML i construeixen un DOM i un arbre d'accessibilitat coherents; les tecnologies de suport llegeixen aquest arbre. Per això les WCAG 2.2 van eliminar el 4.1.1 i el W3C va publicar una errata per a la 2.0 i la 2.1 que el considera sempre satisfet en contingut HTML o XML. Un id duplicat només és una fallada si repercuteix en un altre criteri: si trenca un label for (1.3.1, 4.1.2) o una referència aria-describedby (3.3.1). A l'informe, no citis el 4.1.1; redirigeix al criteri afectat.

4.1.2 Nom, funció i valor (A)

Per a tots els components d'interfície (enllaços, camps, botons, controls generats per script), el nom i la funció (rol) es poden determinar programàticament; els estats, propietats i valors que l'usuari pot establir es poden determinar i establir programàticament; i la notificació dels seus canvis està disponible per a les tecnologies de suport. Amb HTML natiu ben fet servir es compleix sol; el criteri s'incompleix sobretot en components personalitzats.

Nom

El nom accessible es calcula segons l'algorisme de l'especificació Accessible Name and Description Computation: primer aria-labelledby, després aria-label, després el mecanisme natiu (label, contingut del botó, alt, legend) i després title. Fallades: botons d'icona sense nom («botó» i prou); enllaços amb imatge sense alt; camps sense etiqueta associada; aria-labelledby que apunta a un id inexistent; noms iguals per a controls diferents («Elimina» ×20 en una taula, sense context accessible); noms que no contenen l'etiqueta visible (també 2.5.3).

Funció (rol)

El rol indica què és l'element: botó, enllaç, casella, pestanya, quadre de diàleg. Fallades: div i span clicables sense rol; enllaços (<a href="#">) que fan de botons; role="button" en un enllaç que navega; rols inventats o mal escrits; rols ARIA sense els fills requerits (tablist sense tab, menu sense menuitem).

Estat i valor

Desplegat/plegat (aria-expanded), seleccionat (aria-selected), marcat (aria-checked), premut (aria-pressed), deshabilitat, invàlid, valor actual d'un control lliscant (aria-valuenow, aria-valuetext), pàgina actual (aria-current="page"). Fallades: acordions i menús sense aria-expanded o amb el valor sense actualitzar; pestanyes sense aria-selected; interruptors personalitzats sense aria-checked; estats comunicats només amb una classe CSS.

<!-- Incorrecte: sense rol, sense nom útil, sense estat -->
<div class="acordeon-cab activo" onclick="toggle(this)">
  <span class="icono-flecha"></span> Requisits
</div>

<!-- Correcte: botó natiu amb estat i relació amb el tauler -->
<h3>
  <button type="button" aria-expanded="true" aria-controls="panel-req">
    Requisits
  </button>
</h3>
<div id="panel-req">…</div>

Com avaluar-lo

1. Inventari de components interactius de la pàgina i dels seus estats.
2. Per a cadascun, consulta l'arbre d'accessibilitat (tauler Accessibility de Chrome, Inspector d'accessibilitat de Firefox) i anota el nom, el rol i els estats calculats.
3. Fes funcionar el component amb teclat i comprova que els estats canvien a l'arbre.
4. Escolta amb NVDA i amb un altre lector de la línia base: s'anuncien el nom, el rol i l'estat? I el canvi d'estat?
5. Contrasta-ho amb el patró de l'ARIA Authoring Practices Guide corresponent.

4.1.3 Missatges d'estat (AA)

Un missatge d'estat és el que informa l'usuari del resultat o l'estat d'una acció, d'un procés en curs o d'un error, sense rebre el focus i sense suposar un canvi de context. El criteri exigeix que es pugui determinar programàticament mitjançant un rol o propietats, perquè les tecnologies de suport el presentin sense que l'usuari l'hagi de buscar. Exemples: «S'han trobat 12 resultats», «Producte afegit al carretó», «S'està desant…», «3 errors al formulari» (quan el focus no es mou), comptadors de caràcters.

Tècniques: role="status" (equival a aria-live="polite") per a confirmacions i resultats; role="alert" (aria-live="assertive") per a errors urgents; role="log" per a xats; role="progressbar" amb valors per al progrés. El contenidor ha d'existir al DOM abans que s'hi insereixi el missatge; inserir el contenidor amb el missatge ja a dins sol no anunciar-se. Què no és el 4.1.3: si el missatge rep el focus (un modal de confirmació, un resum d'errors al qual es mou el focus), el criteri no s'aplica, perquè el focus ja l'anuncia; si el canvi és de context (pàgina nova), tampoc.

Fallades: resultats de filtres que s'actualitzen en silenci; «afegit al carretó» només visual; toasts sense regió viva; indicador de càrrega sense anunci (l'usuari de lector no sap si ha passat res); comptador de caràcters sense aria-live (o amb assertive, que interromp a cada tecla); ús excessiu d'aria-live="assertive".

Proves combinades i documentació

Les fallades del 4.1.2 solen anar acompanyades del 2.1.1 (si el component no és natiu, rarament té teclat) i de l'1.3.1; les del 4.1.3, del 3.3.1 quan es tracta d'errors. A la troballa, indica el nom, el rol i l'estat observats a l'arbre d'accessibilitat respecte als esperats, l'anunci literal del lector i el patró APG (s'obre en una finestra nova) que s'hauria de seguir. Per al 4.1.3, documenta l'acció, el missatge visual i el que va anunciar (o no) el lector, juntament amb el fragment de DOM del contenidor.

Resum

• El 4.1.1 s'ha eliminat a les WCAG 2.2 (i s'ha declarat sempre satisfet a la 2.0 i la 2.1); els errors de marcatge només són troballa si afecten un altre criteri.
• 4.1.2: tot component té nom, rol i estats determinables i actualitzats; s'avalua amb l'arbre d'accessibilitat, el teclat i el lector, respecte als patrons de l'APG.
• El nom accessible segueix un algorisme de prioritat (aria-labelledby, aria-label, natiu, title); els botons d'icona sense nom són la fallada més comuna.
• 4.1.3: els missatges d'estat que no reben el focus es comuniquen amb role="status", alert, log o progressbar, en contenidors presents per endavant.
• Ni massa poc ni massa: sense anuncis l'usuari no sap què passa; amb regions vives en excés, no pot fer servir la pàgina.