Llegir l'especificació: la fitxa de cada rol, ARIA in HTML i l'APG

Molts dels errors que catalogarem a l'última lliçó de teoria s'eviten amb una consulta de dos minuts abans d'escriure un atribut. El dubte «puc posar aria-label aquí?» o «què necessita un role="tab" per funcionar?» té una resposta exacta i pública. A la lliçó anterior vas veure el vocabulari de rols, estats i propietats; en aquesta aprendràs a llegir els documents que el defineixen, perquè deixis de dependre de fragments copiats i de respostes de fòrums.

El mapa de documents

Sota el nom genèric d'«ARIA» hi conviuen diversos documents del W3C amb funcions diferents. Saber quin cal consultar en cada cas estalvia molt de temps:

En el dia a dia n'hi ha prou amb tres: WAI-ARIA (què és cada cosa), ARIA in HTML (on la pots posar) i l'APG (com es comporta un patró complet).

Anatomia de la fitxa d'un rol

Cada rol de WAI-ARIA 1.2 té una definició en prosa seguida d'una taula de característiques. La taula està en anglès i és molt compacta, però cada fila respon a una pregunta pràctica:

• Is Abstract (rol abstracte). Rols com widget, structure, landmark, input, command, composite, section, select, range o window només existeixen per ordenar la taxonomia. No s'escriuen mai a l'atribut role: role="widget" no significa res per al navegador.
• Superclass Role / Subclass Roles (herència). switch és subclasse de checkbox i per això hereta aria-checked; searchbox és subclasse de textbox. L'herència explica quins atributs té un rol encara que no apareguin a la seva pròpia llista.
• Base Concept / Related Concepts (equivalents). Indiquen l'element HTML o el concepte en què s'inspira el rol: el de checkbox remet a <input type="checkbox">. Si hi ha un equivalent natiu, la regla 1 et diu que el facis servir.
• Required Context Role (context obligatori). On ha d'estar el rol: tab dins de tablist, option dins de listbox (o d'un group dins seu), listitem dins de list.
• Required Owned Elements (fills obligatoris). El que el rol ha de contenir: tablist conté tab, list conté listitem, listbox conté option.
• Required States and Properties (atributs obligatoris). Sense ells el component està incomplet: checkbox i switch exigeixen aria-checked; slider, aria-valuenow; heading, aria-level.
• Supported / Inherited States and Properties (atributs admesos). Tot el que el rol accepta, propi o heretat. El que no apareix aquí ni entre els atributs globals no té efecte en aquest rol.
• Prohibited States and Properties (atributs prohibits). Per exemple, el rol generic (el de <div> i <span>) prohibeix aria-label i aria-labelledby. És l'explicació formal del que vam veure a la lliçó anterior: un aria-label en un <div> sense rol no serveix.
• Name From (origen del nom). contents si el nom pot sortir del text interior (botons, enllaços, pestanyes); author si l'ha de donar qui desenvolupa amb aria-label, aria-labelledby o un <label> (camps, diàlegs, llistes d'opcions); prohibited si el rol no admet nom.
• Accessible Name Required (nom obligatori). Si és True, un element amb aquest rol sense nom és un error de 4.1.2.
• Children Presentational (fills presentacionals). Si és True, el contingut s'aplana, com vas veure a la lliçó sobre l'arbre d'accessibilitat.
• Implicit Value for Role (valors per defecte). Per exemple, a slider el mínim implícit és 0 i el màxim 100 si no indiques aria-valuemin i aria-valuemax.

ARIA in HTML: el que pots posar a cada element

L'especificació WAI-ARIA defineix els rols en abstracte; ARIA in HTML porta aquestes regles a l'HTML. Per a cada element n'indica el rol implícit, quins rols se li poden assignar i quins atributs aria-* admet. Algunes conseqüències que convé conèixer:

• Hi ha elements que no admeten cap rol, com <label> o <input type="password">. D'altres n'admeten pocs: una imatge amb alt="" només pot portar role="none" o role="presentation", i cap atribut ARIA llevat d'aria-hidden.
• No dupliquis l'estat natiu. En un <input type="checkbox"> no s'ha de fer servir aria-checked: l'estat el dona la propietat checked. De la mateixa manera, si un camp té required o disabled, l'equivalent ARIA sobra, i contradir-lo (required amb aria-required="false") és un error.
• Els rols redundants es desaconsellen: <nav role="navigation"> o <button role="button"> no aporten res.
• Permès no vol dir recomanable. ARIA in HTML permet, per exemple, posar role="tab" en un <h2>, però fer-ho destrueix l'encapçalament. La regla 2 de la primera lliçó continua manant.

<input type="checkbox" id="lopd" aria-checked="true">
<label for="lopd" role="button">Accepto la política de privadesa</label>
<img src="separador.png" alt="" aria-label="Separador">

L'APG: guia, no norma

L'ARIA Authoring Practices Guide descriu desenes de patrons (acordió, diàleg, pestanyes, combobox, arbre, control lliscant…). Cada patró inclou una taula d'interacció amb el teclat, una altra de rols, estats i propietats, i exemples funcionals. És la referència més útil per construir components, i la farem servir a fons al curs N3-C5. Quan la consultis, tingues presents tres precaucions:

• No és normativa. No forma part de WCAG ni de l'EN 301 549 (PDF, s'obre en una finestra nova). Un component pot complir 4.1.2 sense seguir l'APG al peu de la lletra, i un que la copiï pot incomplir si s'adapta malament.
• Els seus exemples demostren patrons, no són codi de producció. La mateixa guia adverteix que el suport en navegadors i lectors varia i que cal provar.
• Tria el patró per la funció, no per l'aspecte. El patró de menú està pensat per a menús d'aplicació; la navegació d'un lloc no és un menu encara que visualment es desplegui.

L'APG inclou també pàgines de pràctiques transversals, com les dedicades als noms i les descripcions accessibles o a la interfície de teclat.

Un mètode de consulta en cinc minuts

1. Hi ha un element HTML? Mira el concepte base del rol i la taula d'ARIA in HTML. Si existeix, fes-lo servir i potser no necessitaràs ARIA.
2. Llegeix la fitxa del rol: context obligatori, fills obligatoris, atributs obligatoris, origen del nom i fills presentacionals.
3. Comprova ARIA in HTML: es permet aquest rol a l'element on el posaràs?
4. Obre el patró de l'APG: teclat esperat i estats que cal actualitzar.
5. Prova'n el suport amb els lectors de pantalla del teu públic, com vam veure a la lliçó sobre l'arbre d'accessibilitat.

Referències: WAI-ARIA 1.2, ARIA in HTML i ARIA Authoring Practices Guide.

Resum

• WAI-ARIA 1.2 defineix què és cada rol i atribut; ARIA in HTML, on es pot fer servir; l'APG, com s'implementa cada patró.
• La fitxa d'un rol respon a les preguntes clau: context i fills obligatoris, atributs obligatoris, admesos i prohibits, origen del nom i fills presentacionals.
• No dupliquis ni contradiguis l'estat natiu amb ARIA, i recorda que «permès» no equival a «recomanable».
• L'APG és informativa: una guia excel·lent, però no és norma ni codi a punt per a producció.
• Abans d'escriure un atribut, segueix el mètode: HTML natiu, fitxa del rol, ARIA in HTML, APG i prova real.