Components complexos i contingut dinàmic: auditar el 4.1.2 i el 4.1.3 patró a patró

La lliçó 6 et va donar el mètode per avaluar el 4.1.2 i el 4.1.3: inventari, arbre d'accessibilitat, teclat i lector. Per aplicar-lo amb soltesa has de saber quins valors esperar en cada component i en quins escenaris dinàmics solen faltar els anuncis. Aquesta lliçó és la teva taula de referència: els patrons més freqüents de l'ARIA Authoring Practices Guide (s'obre en una finestra nova) (APG) amb el seu rol i els seus estats, els casos frontera del nom accessible i els missatges d'estat que més s'obliden en webs reals.

Què cal esperar en cada patró

Amb la taula següent pots comparar el que mostra l'arbre d'accessibilitat amb el que s'espera. Recorda que l'element natiu, quan existeix, ja aporta rol i estat: un <button> o un <input type="checkbox"> no necessiten ARIA.

Dos matisos. A ARIA 1.2 el patró de quadre combinat va canviar: el rol combobox va al mateix camp de text, no en un contenidor que l'embolcalla, i els components construïts amb el patró antic donen resultats irregulars segons el lector. I el rol menu promet la interacció d'un menú d'aplicació (fletxes, focus gestionat); aplicat a un menú de navegació corrent, el rol anunciat no correspon a com es fa servir, cosa que sol generar fallades del 4.1.2 i del 2.1.1 alhora. Consulta cada patró a l'APG abans de dictaminar.

Casos frontera del nom accessible

L'algorisme de l'especificació Accessible Name and Description Computation té conseqüències que convé conèixer en auditar:

• aria-labelledby pot concatenar i apuntar a text ocult. Serveix per donar context a botons repetits sense canviar el que es veu.
• aria-label no serveix en qualsevol element. ARIA 1.2 prohibeix anomenar elements genèrics (div o span sense rol) i alguns altres rols; els navegadors i els lectors el poden ignorar. Un <div aria-label="Menú"> clicable continua sense rol ni nom fiable.
• El contingut generat per CSS compta. El text de ::before i ::after entra en el càlcul del nom. Les fonts d'icones que insereixen caràcters d'ús privat poden produir noms il·legibles.
• title i placeholder són l'últim recurs. Donen nom, però fràgil; si és l'únic que hi ha, revisa també el 3.3.2 i el 2.5.3.
• Les referències per id no travessen el shadow DOM (el DOM encapsulat dels components web). Un aria-labelledby que apunta fora de la seva arrel no funciona encara que l'id existeixi.

<!-- Incorrecte: vint botons amb el mateix nom «Elimina» -->
<tr><td>Certificat d'empadronament</td>
  <td><button>Elimina</button></td></tr>

<!-- Correcte: nom «Elimina Certificat d'empadronament» -->
<tr><td id="doc-17">Certificat d'empadronament</td>
  <td><button id="del-17" aria-labelledby="del-17 doc-17">Elimina</button></td></tr>

Valors i estats que estableix l'usuari

El 4.1.2 no es limita a llegir: els estats i els valors que l'usuari pot establir s'han de poder establir programàticament, i se n'han de notificar els canvis. En un selector personalitzat, el valor triat ha de figurar a l'arbre (no només pintat en un span); en un control lliscant, aria-valuenow ha de canviar en moure'l; en un grup de caselles amb «Selecciona-ho tot», l'estat mixt s'expressa amb aria-checked="mixed". La descripció (aria-describedby), en canvi, no l'exigeix el 4.1.2: la seva absència pot afectar l'1.3.1 o el 3.3.2, no aquest criteri.

Missatges d'estat en escenaris dinàmics

Recorre aquests escenaris a cada auditoria; són els que més sovint es queden en silenci:

• Emplenament automàtic: «5 suggeriments disponibles» quan apareix la llista, si es mostra a la pantalla un recompte o un avís equivalent.
• Carretó i preferits: «Producte afegit a la cistella» sense moure el focus.
• Desament automàtic: «Esborrany desat», amb polite i sense repetir-lo cada pocs segons.
• Càrrega i progrés: «S'estan carregant els resultats…» i el seu final; per a un progrés mesurable, role="progressbar" amb valors.
• Desplaçament infinit: «S'han carregat 20 productes més».
• Validació en sortir del camp: l'error en línia és un missatge d'estat si el focus no s'hi mou.
• Avisos emergents (toasts) amb acció: el text s'anuncia i l'acció («Desfés») és accessible amb teclat; si desapareix sola, revisa també el 2.2.1 Temps ajustable.

<!-- La regió existeix buida des de la càrrega de la pàgina -->
<div id="aviso" role="status"></div>

<script>
  // En afegir el producte, només es canvia el text
  document.getElementById('aviso').textContent =
    'Producte afegit a la cistella. Total: 3 articles.';
</script>

Amb role="status" o aria-live, inserir el contenidor ja emplenat sol no anunciar-se; role="alert" es comporta millor en aquest cas, però no convé dependre'n. Escriure dues vegades el mateix text tampoc no garanteix un segon anunci: si el missatge es repeteix, buida la regió abans o afegeix-hi una dada que canviï.

Com verificar el que s'anuncia

No n'hi ha prou de veure l'atribut al codi: cal comprovar l'anunci a la línia base. A NVDA, el Visor de veu (menú de NVDA, Eines) mostra per escrit tot el que diu el lector, cosa que et dona una evidència literal per a l'informe. A VoiceOver de macOS, el tauler de subtítols fa la mateixa funció. A les eines de desenvolupament, comprova que el contenidor amb role o aria-live és al DOM abans de l'acció, i que no es crea amb ella.

Resum

• Cada patró té un rol i uns estats esperats; compara'ls amb l'arbre d'accessibilitat i fes servir l'APG com a referència de la solució, no com a requisit normatiu.
• El nom accessible té paranys: aria-label en elements genèrics, contingut generat per CSS, title com a únic nom i referències que no travessen el shadow DOM.
• El 4.1.2 inclou establir i notificar valors i estats, no la descripció.
• Emplenaments automàtics, carretons, desaments, càrregues, desplaçament infinit, validació en línia i toasts són els missatges d'estat que més s'obliden.
• Verifica els anuncis amb el Visor de veu de NVDA o el tauler de subtítols de VoiceOver, i comprova que la regió viva existeix abans del canvi.