Un ghid pentru dezvoltatori despre etichete ARIA care chiar ajută

Etichetele ARIA sunt pentru nume, nu pentru scuze

ARIA este utilă, dar este adesea folosită ca petic pentru HTML neclar. Acolo ajung echipele să aibă probleme.

Cel mai comun exemplu este aria-label. Pare inofensiv: adaugi un șir de text, mulțumești un linter și mergi mai departe. Dar un nume accesibil nu este decor. Este numele pe care multe tehnologii asistive îl expun utilizatorilor atunci când navighează după butoane, linkuri, câmpuri de formular, titluri, repere și controale.

Dacă acel nume este vag, duplicat, învechit sau diferit de eticheta vizibilă, interfața devine mai greu de folosit. Uneori mai rău: aria-label poate suprascrie un text mai bun care era deja prezent în DOM.

Scopul nu este să adăugăm mai mult ARIA. Scopul este să facem clare numele, rolul, starea și scopul fiecărui element de interfață.

Numele accesibil, pe înțelesul tuturor

Majoritatea elementelor interactive au un nume accesibil. Cititoarele de ecran folosesc acel nume pentru a anunța ce este elementul.

De exemplu:

<button>Save changes</button>

Un cititor de ecran poate anunța ceva de genul: „Save changes, buton.” Rolul vine de la elementul nativ button. Numele vine din textul din interiorul lui.

Acesta este cazul ideal: textul vizibil și numele accesibil se potrivesc.

Atributele ARIA de etichetare devin utile când interfața vizibilă nu oferă un nume complet sau când numele trebuie să vină din alt element. Principalele atribute sunt:

• aria-label: oferă un șir de text direct pe element.
• aria-labelledby: indică unul sau mai multe elemente al căror text devine numele.
• aria-describedby: indică un text descriptiv de sprijin, nu numele principal.

Aceste trei sunt înrudite, dar nu sunt interschimbabile.

Prima regulă: preferă HTML-ul nativ și etichetele vizibile

Dacă poți pune text vizibil pe control, fă asta mai întâi.

Aceasta este o variantă mai bună:

<button>Delete invoice</button>

Decât aceasta:

<button aria-label="Delete invoice">
  <svg aria-hidden="true" focusable="false">...</svg>
</button>

Al doilea tipar este valid pentru un buton doar cu pictogramă. Dar dacă designul poate tolera text vizibil, textul vizibil ajută pe toată lumea: utilizatorii de cititoare de ecran, utilizatorii de recunoaștere vocală, persoanele cu încărcare cognitivă, persoanele care scanează rapid și persoanele care folosesc instrumente de traducere.

Aceasta este o temă recurentă în munca de accesibilitate. HTML-ul nativ și indiciile vizibile rezolvă mai multe probleme decât metadatele ascunse. Același principiu se aplică mai larg semanticii butoanelor; dacă echipa ta auditează controale UI, lista noastră de verificare pentru butoane web accesibile este un bun companion pentru acest ghid.

Când aria-label este instrumentul potrivit

Folosește aria-label când un element are nevoie de un nume accesibil și nu există un text vizibil potrivit la care să faci referire.

Cazul clasic este un buton doar cu pictogramă:

<button aria-label="Search">
  <svg aria-hidden="true" focusable="false" viewBox="0 0 24 24">
    <!-- icon -->
  </svg>
</button>

Aceasta este o soluție rezonabilă. Pictograma vizibilă sugerează căutarea, dar calea SVG în sine nu oferă un nume fiabil. aria-label furnizează unul.

Alte cazuri bune includ:

• Un buton de închidere reprezentat doar de un „X”.
• Un reper de navigare care are nevoie de un nume mai specific, cum ar fi aria-label="Product".
• Un control repetat în care contextul vizibil nu face parte din textul butonului.

De exemplu:

<nav aria-label="Primary">
  ...
</nav>

<nav aria-label="Footer">
  ...
</nav>

Ambele sunt repere de navigare, dar etichetele lor îi ajută pe utilizatori să le distingă atunci când se deplasează după repere.

Când aria-label este instrumentul greșit

Nu adăuga aria-label doar pentru că un test spune că un element are nevoie de o etichetă. Repară mai întâi marcajul.

Greșit:

<div role="button" tabindex="0" aria-label="Submit">Submit</div>

Mai bine:

<button>Submit</button>

Primul exemplu creează muncă inutilă. Acum trebuie să recreezi comportamentul la tastatură, stările dezactivate, comportamentul de formular și așteptările pe care butoanele native le oferă deja.

Evită, de asemenea, să folosești aria-label pentru a redenumi textul vizibil într-un mod care schimbă sensul.

<button aria-label="Delete invoice">Remove</button>

Pare minor, dar poate deruta utilizatorii care se bazează pe introducere vocală. Dacă un buton vizibil spune „Remove”, dar numele său accesibil este „Delete invoice”, un utilizator care încearcă să spună „click Remove” poate să nu obțină rezultatul așteptat. Cerința WCAG „label in name” există exact din acest motiv: textul vizibil ar trebui, în general, să fie conținut în numele accesibil.

O versiune mai bună:

<button aria-label="Remove invoice">Remove</button>

Adesea, și mai bine:

<button>Remove invoice</button>

Alege aria-labelledby când textul vizibil există deja

Dacă textul etichetei este deja pe pagină, aria-labelledby este de obicei mai bun decât aria-label.

Exemplu:

<h2 id="billing-title">Billing address</h2>
<section aria-labelledby="billing-title">
  ...
</section>

Numele accesibil al secțiunii vine acum din titlul vizibil. Eviți duplicarea șirurilor de text, ceea ce reduce greșelile de traducere și etichetele învechite.

Acest lucru este deosebit de util pentru grupurile de formular:

<fieldset aria-labelledby="shipping-speed-title">
  <legend id="shipping-speed-title">Shipping speed</legend>

  <label>
    <input type="radio" name="shipping" value="standard">
    Standard
  </label>

  <label>
    <input type="radio" name="shipping" value="express">
    Express
  </label>
</fieldset>

În multe cazuri, legend nativ este suficient fără ARIA. Ideea este că etichetele vizibile ar trebui să conducă. ARIA ar trebui să conecteze sensul existent, nu să creeze o a doua versiune privată a lui.

Folosește aria-describedby pentru text de ajutor, nu pentru nume

O descriere nu este o etichetă.

Ia în considerare acest câmp:

<label for="password">Password</label>
<input id="password" type="password" aria-describedby="password-help">
<p id="password-help">Use at least 12 characters.</p>

Numele accesibil este „Password.” Descrierea este „Use at least 12 characters.” Un cititor de ecran le poate anunța pe amândouă, dar ele servesc scopuri diferite.

Nu face asta:

<input type="password" aria-label="Use at least 12 characters">

Aceasta numește câmpul după instrucțiune, nu după concept. Un utilizator care navighează într-un formular vrea să știe mai întâi ce este câmpul, apoi ce constrângeri se aplică.

Această distincție contează și în stările de eroare:

<label for="email">Email</label>
<input
  id="email"
  type="email"
  aria-invalid="true"
  aria-describedby="email-error"
>
<p id="email-error">Enter an email address in the format [email protected].</p>

Eticheta rămâne stabilă. Mesajul de eroare devine context de sprijin.

Controalele repetate au nevoie de nume unice

Listele și cardurile sunt locurile în care etichetele ARIA devin adesea necesare.

Greșit:

<button>Delete</button>
<button>Delete</button>
<button>Delete</button>

Un utilizator de cititor de ecran care navighează după butoane poate auzi „Delete, buton” de trei ori, fără context.

Bine:

<button aria-label="Delete report: Q4 revenue">Delete</button>
<button aria-label="Delete report: Hiring plan">Delete</button>
<button aria-label="Delete report: Vendor list">Delete</button>

Aceasta este o utilizare legitimă a aria-label: textul vizibil rămâne concis, în timp ce numele accesibil include obiectul.

Dar folosește acest tipar cu atenție. Dacă numele obiectului este vizibil în apropiere, aria-labelledby poate fi mai ușor de întreținut:

<article>
  <h3 id="report-q4">Q4 revenue</h3>
  <button aria-labelledby="delete-q4 report-q4" id="delete-q4">Delete</button>
</article>

Numele accesibil devine „Delete Q4 revenue.” Aceasta evită duplicarea titlului raportului într-un atribut.

Nu eticheta totul

Nu fiecare element are nevoie de o etichetă ARIA.

Textul static, de obicei, nu are nevoie. Pictogramele decorative nu au nevoie. Containerele nu au nevoie, decât dacă au un rol semnificativ de reper sau widget. Supraetichetarea poate face o pagină zgomotoasă și mai greu de navigat.

Pentru imagini, folosește modelul specific imaginilor: imaginile semnificative au nevoie de alt util; imaginile decorative au nevoie de alt="" gol. Nu folosi etichetele ARIA ca substitut pentru un text bun al imaginii. Dacă echipa ta amestecă aceste concepte, revizitează textul alt pragmatic pentru imagini și separă alternativele pentru imagini de numele controalelor.

O greșeală comună este să dai fiecărui SVG un aria-label. Dacă SVG-ul este în interiorul unui buton și butonul are deja un nume, pictograma ar trebui de obicei ascunsă de tehnologiile asistive:

<button aria-label="Open menu">
  <svg aria-hidden="true" focusable="false">...</svg>
</button>

Altfel, utilizatorul poate auzi anunțuri redundante sau ciudate, în funcție de combinația dintre browser și tehnologia asistivă.

Verifică numele calculat, nu doar codul

Bugurile de accesibilitate supraviețuiesc adesea revizuirii codului deoarece marcajul pare plauzibil.

Instrumentele moderne pentru dezvoltatori din browsere pot afișa arborele de accesibilitate calculat. În Chrome, Edge, Firefox și Safari, inspectează elementul și caută informații de accesibilitate precum rolul, numele și descrierea. Verifici trei lucruri:

1. Este rolul cel la care te aștepți?
2. Este numele accesibil clar și specific?
3. Este descrierea utilă fără să înlocuiască numele?

Apoi testează câteva fluxuri cu un cititor de ecran real. Nu trebuie să devii expert cu normă întreagă în tehnologii asistive ca să prinzi lucrurile de bază. Pe macOS, VoiceOver este integrat. Pe Windows, NVDA este folosit pe scară largă și gratuit. Pe mobil, testează cu VoiceOver pe iOS și TalkBack pe Android, acolo unde este relevant.

Instrumentele automate sunt utile, dar nu pot spune în mod fiabil dacă „Open”, „Read more” sau „Delete” au suficient context. Tratează automatizarea ca pe o plasă, nu ca pe un judecător. Este similar cu auditarea performanței: un raport îți poate indica zone suspecte, dar tot trebuie să interpretezi impactul. Aceeași abordare calmă pe care o recomandăm pentru citirea unui raport Lighthouse fără panică se aplică și aici.

O listă practică de verificare pentru review

Înainte de a livra etichete ARIA, întreabă:

• Ar putea fi acesta HTML nativ în schimb?
• Există text vizibil care ar trebui folosit ca etichetă?
• Dacă există text vizibil, numele accesibil îl include?
• Sunt controalele repetate unice atunci când sunt navigate în afara contextului vizual?
• Este textul de ajutor conectat cu aria-describedby, nu forțat în etichetă?
• Sunt pictogramele decorative ascunse de tehnologia asistivă?
• A verificat cineva numele de accesibilitate calculat în instrumentele de dezvoltare ale browserului?
• A fost făcută cel puțin o trecere cu un cititor de ecran real pentru fluxul critic?

Această listă de verificare prinde cele mai multe probleme de etichetare înainte ca ele să devină probleme pentru utilizatori.

Disciplina discretă a unui ARIA bun

Munca bună cu ARIA este rareori dramatică. Este, în cea mai mare parte, reținere.

Folosește butoane reale. Folosește etichete reale. Menține aliniate numele vizibile și cele accesibile. Adaugă aria-label doar când nu există o sursă vizibilă mai bună. Folosește aria-labelledby când pagina conține deja textul potrivit. Folosește aria-describedby pentru instrucțiuni și erori de sprijin.

Platforma web le oferă dezvoltatorilor multe lucruri gratuit atunci când o folosim direct. ARIA există pentru goluri. Abilitatea este să știi când există cu adevărat un gol.