Fejlesztői útmutató az ARIA-címkékhez, amelyek valóban segítenek

Az ARIA-címkék nevek, nem bocsánatkérések

Az ARIA hasznos, de gyakran a nem egyértelmű HTML foltozására használják. A csapatok itt kerülnek bajba.

A leggyakoribb példa az aria-label. Ártalmatlannak tűnik: hozzáadunk egy sztringet, kielégítünk egy lintert, és megyünk tovább. De az akadálymentes név nem dekoráció. Ez az a név, amelyet sok kisegítő technológia megmutat a felhasználóknak, amikor gombok, hivatkozások, űrlapmezők, címsorok, landmarkok és vezérlők között navigálnak.

Ha ez a név homályos, ismétlődő, elavult, vagy eltér a látható címkétől, a felület nehezebben használhatóvá válik. Néha még rosszabb: az aria-label felülírhat olyan jobb szöveget is, amely már jelen volt a DOM-ban.

A cél nem az, hogy több ARIA-t adjunk hozzá. A cél az, hogy minden felületi elem neve, szerepe, állapota és célja egyértelmű legyen.

Az akadálymentes név, közérthetően

A legtöbb interaktív elemnek van akadálymentes neve. A képernyőolvasók ezt a nevet használják annak bemondására, hogy mi az adott elem.

Például:

<button>Save changes</button>

Egy képernyőolvasó valami ilyesmit mondhat be: „Save changes, gomb.” A szerep a natív button elemből származik. A név a benne lévő szövegből jön.

Ez az ideális eset: a látható szöveg és az akadálymentes név megegyezik.

Az ARIA-címkézési attribútumok akkor válnak hasznossá, amikor a látható felület nem ad teljes nevet, vagy amikor a névnek egy másik elemből kell származnia. A fő attribútumok:

• aria-label: közvetlenül az elemen ad meg egy sztringet.
• aria-labelledby: egy vagy több elemre mutat, amelyek szövege lesz a név.
• aria-describedby: kiegészítő leíró szövegre mutat, nem a fő névre.

Ez a három összefügg, de nem felcserélhető.

Első szabály: részesítsük előnyben a natív HTML-t és a látható címkéket

Ha látható szöveget tudunk tenni a vezérlőre, először tegyük azt.

Ez jobb:

<button>Delete invoice</button>

Mint ez:

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

A második minta érvényes egy csak ikont tartalmazó gomb esetén. De ha a dizájn elbírja a látható szöveget, az mindenkinek segít: a képernyőolvasót használóknak, a beszédfelismerést használóknak, a kognitív terheléssel küzdőknek, a gyorsan pásztázó felhasználóknak és a fordítóeszközöket használóknak.

Ez visszatérő téma az akadálymentesítési munkában. A natív HTML és a látható affordanciák több problémát oldanak meg, mint a rejtett metaadatok. Ugyanez az elv tágabban is érvényes a gombok szemantikájára; ha a csapatod UI-vezérlőket auditál, az akadálymentes webes gombokhoz készült ellenőrzőlistánk jó kiegészítője ennek az útmutatónak.

Amikor az aria-label a megfelelő eszköz

Használjunk aria-label attribútumot, amikor egy elemnek akadálymentes névre van szüksége, és nincs megfelelő látható szöveg, amelyre hivatkozhatnánk.

A klasszikus eset a csak ikont tartalmazó gomb:

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

Ez ésszerű. A látható ikon keresést sugall, de maga az SVG path nem ad megbízható nevet. Az aria-label biztosítja azt.

További jó esetek:

• Bezárás gomb, amelyet csak egy „X” jelöl.
• Navigációs landmark, amelynek pontosabb névre van szüksége, például aria-label="Product".
• Ismétlődő vezérlő, ahol a látható kontextus nem része a gomb szövegének.

Például:

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

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

Mindkettő navigációs landmark, de a címkéik segítenek a felhasználóknak megkülönböztetni őket, amikor landmarkok szerint mozognak.

Amikor az aria-label nem megfelelő eszköz

Ne adjunk hozzá aria-label attribútumot csak azért, mert egy teszt azt mondja, hogy egy elemnek címkére van szüksége. Először javítsuk a jelölést.

Rossz:

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

Jobb:

<button>Submit</button>

Az első példa felesleges munkát teremt. Innentől nekünk kell újraalkotni a billentyűzetes viselkedést, a letiltott állapotokat, az űrlapviselkedést és azokat az elvárásokat, amelyeket a natív gombok már eleve biztosítanak.

Kerüljük azt is, hogy az aria-label attribútummal a látható szöveget olyan módon nevezzük át, amely megváltoztatja a jelentést.

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

Ez apróságnak tűnik, de összezavarhatja a beszédalapú bevitelt használó felhasználókat. Ha egy látható gombon az áll, hogy „Remove”, de az akadálymentes neve „Delete invoice”, akkor a „click Remove” parancsot mondó felhasználó nem biztos, hogy a várt eredményt kapja. A WCAG „label in name” követelménye pontosan ezért létezik: a látható szövegnek általában szerepelnie kell az akadálymentes névben.

Jobb változat:

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

Gyakran még jobb:

<button>Remove invoice</button>

Nyúljunk az aria-labelledby attribútumhoz, ha a látható szöveg már létezik

Ha a címkeszöveg már az oldalon van, az aria-labelledby általában jobb, mint az aria-label.

Példa:

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

A szakasz akadálymentes neve most a látható címsorból származik. Elkerüljük a sztringek duplikálását, ami csökkenti a fordítási hibákat és az elavult címkéket.

Ez különösen hasznos űrlapcsoportoknál:

<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>

Sok esetben a natív legend önmagában is elég ARIA nélkül. A lényeg az, hogy a látható címkék vezessenek. Az ARIA-nak a meglévő jelentést kell összekötnie, nem egy második, privát változatot létrehoznia belőle.

Az aria-describedby súgószöveghez való, nem névnek

A leírás nem címke.

Vegyük ezt a mezőt:

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

Az akadálymentes név „Password”. A leírás: „Use at least 12 characters.” A képernyőolvasó mindkettőt bemondhatja, de különböző célt szolgálnak.

Ezt ne tegyük:

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

Ez a mezőt az utasításról nevezi el, nem a fogalomról. Egy űrlapon navigáló felhasználó először azt szeretné tudni, hogy mi a mező, és csak utána azt, hogy milyen korlátozások vonatkoznak rá.

Ez a különbség hibaállapotokban is számít:

<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>

A címke stabil marad. A hibaüzenet kiegészítő kontextussá válik.

Az ismétlődő vezérlőknek egyedi nevekre van szükségük

A listák és kártyák azok a helyek, ahol az ARIA-címkék gyakran szükségessé válnak.

Rossz:

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

Egy gombok szerint navigáló képernyőolvasó-felhasználó háromszor is azt hallhatja, hogy „Delete, gomb”, kontextus nélkül.

Jó:

<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>

Ez az aria-label jogos használata: a látható szöveg tömör marad, miközben az akadálymentes név tartalmazza az objektumot.

De ezt a mintát óvatosan használjuk. Ha az objektum neve a közelben látható, az aria-labelledby karbantarthatóbb lehet:

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

Az akadálymentes név „Delete Q4 revenue” lesz. Így elkerüljük, hogy a jelentés címét egy attribútumban duplikáljuk.

Ne címkézzünk fel mindent

Nem minden elemnek van szüksége ARIA-címkére.

A statikus szövegnek általában nincs. A dekoratív ikonoknak nincs. A konténereknek sincs, hacsak nincs értelmes landmark- vagy widget-szerepük. A túlzott címkézés zajossá teheti az oldalt, és megnehezítheti a navigációt.

Képek esetén használjuk a képekre vonatkozó modellt: a jelentéssel bíró képeknek hasznos alt szövegre van szükségük; a dekoratív képeknek üres alt="" kell. Ne használjuk az ARIA-címkéket a jó képszöveg helyettesítésére. Ha a csapatod keveri ezeket a fogalmakat, érdemes újra áttekinteni a pragmatikus képi alt szövegeket, és különválasztani a képalternatívákat a vezérlők neveitől.

Gyakori hiba, hogy minden SVG kap egy aria-label attribútumot. Ha az SVG egy gombon belül van, és a gombnak már van neve, az ikont általában el kell rejteni a kisegítő technológiák elől:

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

Ellenkező esetben a felhasználó redundáns vagy furcsa bemondásokat hallhat, a böngésző és a kisegítő technológia kombinációjától függően.

Az eredő nevet ellenőrizzük, ne csak a kódot

Az akadálymentesítési hibák gyakran túlélik a kódellenőrzést, mert a jelölés hihetőnek tűnik.

A modern böngészői fejlesztői eszközök meg tudják mutatni az eredő akadálymentesítési fát. Chrome, Edge, Firefox és Safari böngészőben vizsgáljuk meg az elemet, és keressük az akadálymentesítési információkat, például a szerepet, a nevet és a leírást. Három dolgot ellenőrzünk:

1. A szerep az, amire számítunk?
2. Az akadálymentes név világos és konkrét?
3. A leírás hasznos anélkül, hogy lecserélné a nevet?

Ezután teszteljünk néhány folyamatot valódi képernyőolvasóval. Nem kell főállású kisegítőtechnológia-szakértővé válni ahhoz, hogy az alapokat elkapjuk. macOS-en a VoiceOver beépített. Windows rendszeren az NVDA széles körben használt és ingyenes. Mobilon, ahol releváns, teszteljünk VoiceOverrel iOS-en és TalkBackkel Androidon.

Az automatizált eszközök hasznosak, de nem tudják megbízhatóan megmondani, hogy az „Open”, „Read more” vagy „Delete” elég kontextuális-e. Az automatizációra hálóként tekintsünk, ne bíróként. Ez hasonló a teljesítményauditokhoz: egy jelentés rámutathat gyanús területekre, de a hatást továbbra is nekünk kell értelmeznünk. Ugyanaz a higgadt megközelítés, amelyet a Lighthouse-jelentés pánik nélküli olvasásához ajánlunk, itt is érvényes.

Gyakorlati ellenőrzőlista átnézéshez

Az ARIA-címkék kiadása előtt kérdezzük meg:

• Lehetne ez inkább natív HTML?
• Van látható szöveg, amelyet címkeként kellene használni?
• Ha van látható szöveg, az akadálymentes név tartalmazza azt?
• Az ismétlődő vezérlők egyediek, ha a vizuális kontextusból kiragadva navigálnak hozzájuk?
• A súgószöveg aria-describedby attribútummal van összekötve, és nincs belekényszerítve a címkébe?
• A dekoratív ikonok el vannak rejtve a kisegítő technológiák elől?
• Ellenőrizte valaki az eredő akadálymentes nevet a böngésző fejlesztői eszközeiben?
• A kritikus folyamaton végigment legalább egy valódi képernyőolvasós teszt?

Ez az ellenőrzőlista a legtöbb címkézési problémát elkapja, mielőtt felhasználói problémává válnának.

A jó ARIA csendes fegyelme

A jó ARIA-munka ritkán látványos. Többnyire önmérséklet.

Használjunk valódi gombokat. Használjunk valódi címkéket. Tartsuk összhangban a látható és az akadálymentes neveket. Csak akkor adjunk hozzá aria-label attribútumot, ha nincs jobb látható forrás. Használjunk aria-labelledby attribútumot, amikor az oldal már tartalmazza a megfelelő szöveget. Használjunk aria-describedby attribútumot a kiegészítő utasításokhoz és hibákhoz.

A webplatform sok mindent ingyen ad a fejlesztőknek, ha közvetlenül használjuk. Az ARIA a hiányosságok áthidalására való. A készség abban áll, hogy felismerjük, mikor van valóban hiányosság.