Mi az az ARIA? Szerepek, landmarkok és élő régiók

Mi az ARIA — és mi nem

Az ARIA az Accessible Rich Internet Applications rövidítése. Attribútumok olyan halmaza, amelyet a W3C Web Accessibility Initiative (WAI) kezdeményezése definiál, és amellyel a fejlesztők közölhetik a felhasználói felület elemeinek jelentését és állapotát a segítő technológiákkal, például a képernyőolvasókkal.

Az ARIA legfontosabb szabálya egyben az is, amelyet a leggyakrabban figyelmen kívül hagynak: ne használjunk ARIA-t, ha a natív HTML is elvégzi a feladatot. Egy <button> elem már magától gombként jelenti be magát, és reagál a billentyűzeteseményekre. Egy <nav> elem már magától közli a navigációs landmarkot a képernyőolvasókkal. Ha egy <div> elemhez role="button" attribútumot adunk, majd szkripteljük a viselkedését, azt nehezebb karbantartani, könnyebb elrontani, és általában rosszabb az akadálymentesség szempontjából, mintha eleve a megfelelő elemet használnánk.

Az ARIA nem:

• Teszi láthatóvá vagy interaktívvá a tartalmat — csak azt változtatja meg, mit jelent be a segítő technológia
• Javítja meg a hibás billentyűzetes hozzáférést — továbbra is szükség van a tabindex attribútumra és az eseményfigyelőkre
• Helyettesíti a jól strukturált szemantikus HTML-t

Az ARIA ott segít igazán, ahol a natív HTML-nek nincs eleme arra, amit építünk: dátumválasztó, élő értesítési sáv, egyedi kombinált beviteli mező, fastruktúra-nézet. Ezekben az esetekben az ARIA lehetővé teszi olyan szemantika közlését, amelyre a HTML nem képes.

ARIA-szerepek

A szerep (role) elmondja a segítő technológiának, milyen elemmel van dolga. Minden interaktív elem rendelkezik implicit szereppel, amely a HTML-címkéjéből származik. Az <a> elem szerepe link. Az <input type="checkbox"> elem szerepe checkbox. A <h2> elem szerepe heading.

Ha olyan egyedi elemet építünk, amelynek nincs HTML-megfelelője, explicit szerepet rendelünk hozzá:

<!-- Egyedi kapcsoló, div elemből építve -->
<div
  role="switch"
  aria-checked="false"
  tabindex="0"
>
  Sötét mód
</div>

A képernyőolvasó ezt mostantól kapcsolóvezérlőként jelenti be, és felolvassa a bekapcsolt állapotát. A szerep nélkül egyszerű szövegként jelentené be, és a felhasználónak fogalma sem lenne arról, hogy az elem interaktív.

Gyakori szerepek és mikor használjuk őket

A widgetszerepek interaktív vezérlőket írnak le:

Szerep	Mikor használjuk
button	Egyedi kattintható elem, amelyhez nincs jobb HTML-címke
checkbox	Egyedi többszörös választást lehetővé tevő kapcsoló
combobox	Szövegbeviteli mező listamező-legördülővel kombinálva
dialog	Modális fedőréteg (csak akkor, ha nem a natív <dialog> elemet használjuk)
listbox	Egyedi legördülő lista
slider	Egyedi tartományvezérlő
switch	Be/ki kapcsoló
tab, tablist, tabpanel	Füles felület
tooltip	Rövid leírás, amely rámutatáskor vagy fókuszáláskor jelenik meg

A dokumentumstruktúra-szerepek nem interaktív tartalmat írnak le:

• article — önmagában is értelmes tartalomegység
• figure — kép képaláírással
• list, listitem — ha listaszemantikára van szükség nem lista típusú elemeken
• presentation / none — eltávolítja az elem implicit szerepét (ritkán és óvatosan használjuk)

Kritikus hiba: szerepek hozzáadása viselkedés nélkül

Minden szerep egy szerződést hordoz, amelynek betartását a képernyőolvasók és a billentyűzetet használók elvárják. A role="button" elemnek reagálnia kell az Enterre és a szóközre is. A role="checkbox" elemnek szóközre kell váltania. A role="link" elemnek Enterre kell navigálnia.

Ha hozzáadjuk a szerepet, de a hozzá tartozó viselkedést nem, azzal aktívan félrevezetjük a segítő technológiát használókat. Hallják, hogy egy vezérlőt bejelentenek, megpróbálnak interakcióba lépni vele a várt billentyűparanccsal, és nem történik semmi. Ez rosszabb, mintha egyáltalán nem lenne ARIA.

ARIA-landmarkok

A landmarkok (tájékozódási pontok) az oldal navigációs vázát alkotják. Lehetővé teszik, hogy a képernyőolvasót használók a főbb régiók között ugráljanak anélkül, hogy elolvasnák a köztük lévő mindent — ez a látó felhasználó azon képességének megfelelője, hogy egy pillantással átfutja az oldal elrendezését.

A HTML5 olyan szemantikus elemeket vezetett be, amelyek közvetlenül megfeleltethetők a landmarkszerepeknek. Ha ezeket használjuk, a landmarkok ingyen járnak:

HTML-elem	Landmarkszerep	Rendeltetés
<header>	banner	Az oldal egészére vonatkozó fejléc (csak akkor, ha ez a legfelső szintű fejléc, nem <article> elemen belül)
<nav>	navigation	Navigációs menü
<main>	main	Az oldal elsődleges tartalma
<aside>	complementary	A fő tartalomhoz kapcsolódó másodlagos tartalom
<footer>	contentinfo	Az oldal egészére vonatkozó lábléc
<form>	form	Űrlap (csak akkor, ha van hozzáférhető neve)
<section>	region	Elnevezett szakasz (csak akkor, ha aria-label vagy aria-labelledby révén van hozzáférhető neve)

Nem kell role="main" attribútumot adni egy <main> elemhez — ez felesleges. Az ARIA-landmarkszerepekre csak akkor van szükség, ha nem használható a szemantikus HTML-elem, például egy örökölt kódbázisban, amely <div class="sidebar"> elemeket generál:

<div class="sidebar" role="complementary" aria-label="Kapcsolódó cikkek">
  <!-- oldalsáv tartalma -->
</div>

Landmarkok címkézése, ha egynél több van belőlük

Ha egy oldalon ugyanabból a landmarkból több példány is szerepel — két <nav> elem, két <section> elem role="region" szereppel —, mindegyiknek egyedi hozzáférhető névvel kell rendelkeznie, hogy a felhasználók meg tudják különböztetni őket:

<nav aria-label="Fő navigáció">...</nav>
<nav aria-label="Lábléc navigáció">...</nav>

Címkék nélkül a képernyőolvasó mindkettőt csak „navigáció” néven jelenti be. Címkékkel a felhasználók azt hallják, hogy „Fő navigáció, navigációs landmark” és „Lábléc navigáció, navigációs landmark”, és a landmarklistából ki tudják választani a megfelelőt.

ARIA élő régiók

Az élő régió (live region) az oldal olyan területe, amelynek tartalma dinamikusan frissül, és ahol ezeket a frissítéseket automatikusan be kell jelenteni a képernyőolvasót használóknak anélkül, hogy oda kellene mozgatniuk a fókuszt.

Az alapvető attribútum az aria-live. Három értéket vesz fel:

• off — a frissítéseket nem jelenti be (ez az alapértelmezés minden elemnél)
• polite — a frissítéseket azután jelenti be, hogy a felhasználó befejezte az aktuális feladatát
• assertive — a frissítések azonnal megszakítják azt, amit a képernyőolvasó éppen mond

<!-- Állapotüzenet-terület, amely űrlapbeküldés után töltődik fel -->
<div aria-live="polite" id="status-message"></div>

<script>
  document.getElementById('status-message').textContent =
    'Az üzenetét elküldtük.';
</script>

Amikor a szöveges tartalom megváltozik, az aria-live="polite" beállítású régiónál a képernyőolvasó megvárja a beszédszünetet, majd bejelenti az új tartalmat. A dinamikus frissítések túlnyomó többségéhez a polite értéket használjuk. Az assertive értéket tartsuk fenn kizárólag a kritikus hibákra — fizetési hibára, munkamenet-időtúllépési figyelmeztetésre —, ahol az információ elég sürgős ahhoz, hogy indokolja a felhasználó megszakítását.

Szerep-rövidítések élő régiókhoz

Két szerep egyetlen attribútumba csomagolja az aria-live szemantikáját:

• role="status" — az aria-live="polite" megfelelője. Sikerüzenetekhez, töltési állapotokhoz és nem sürgős frissítésekhez használjuk.
• role="alert" — az aria-live="assertive" megfelelője, és egyben aria-atomic="true" értéket is magában foglal. Hibaüzenetekhez és kritikus meghibásodásokhoz használjuk.

<!-- A hibát azonnal bejelenti, megszakítva az aktuális felolvasást -->
<div role="alert" id="payment-error"></div>

<!-- Az állapotfrissítést udvariasan, az aktuális felolvasás után jelenti be -->
<div role="status" id="cart-count">3 tétel a kosárban</div>

Gyakori hibák az élő régióknál

Tartalom hozzáadása azelőtt, hogy az elem a DOM-ba kerülne. A böngésző akkor regisztrálja az élő régiót, amikor az elemet először feldolgozza. Ha az elemet és a szöveges tartalmát egyszerre szúrjuk be, néhány képernyőolvasó teljesen lemarad a bejelentésről. Az élő régió tárolóját mindig szerepeltessük a kezdeti HTML-ben, és a tartalmát később, JavaScripttel frissítsük.

Az assertive használata mindenre. Az assertive élő régiók megszakítják azt, amit a felhasználó éppen csinál, beleértve a többi bejelentést is. Egy találatszám, amely gépelés közben frissül, nem indokolja a role="alert" használatát. Az assertive túlzott használata ellenséges élményt teremt a képernyőolvasót használóknak.

Az élő régió túl gyakori frissítése. Ha egy folyamatjelző 100 milliszekundumonként frissíti az élő régióját, a beszédsor túlcsordul, és a felhasználók semmi hasznosat nem hallanak. Az élő szöveget csak értelmes mérföldköveknél frissítsük — 25%, 50%, 75%, kész —, vagy időzítővel korlátozzuk a frissítések gyakoriságát.

Az aria-atomic elfelejtése. Alapértelmezés szerint az élő régión belül csak a megváltozott szövegcsomópontot jelenti be a rendszer. Ha azt szeretnénk, hogy a teljes régiót olvassa fel újra (ne csak a megváltozott töredéket), adjuk hozzá az aria-atomic="true" attribútumot:

<div aria-live="polite" aria-atomic="true">
  <span id="count">2</span> tétel van hátra
</div>

Az aria-atomic nélkül a képernyőolvasó csak annyit jelenthet be, hogy „2”, amikor a szám 3-ról 2-re változik. Vele a teljes „2 tétel van hátra” mondat hangzik el, ami szinte mindig ez a kívánt viselkedés.

További alapvető ARIA-attribútumok

aria-label — hozzáférhető nevet ad, ha nincs megfelelő látható szöveg:

<button aria-label="Párbeszédablak bezárása">✕</button>

aria-labelledby — egy másik elemre mutat, amelynek szövege a hozzáférhető névként szolgál. Előnyben részesítendő az aria-label helyett, ha a címkeszöveg már látható az oldalon:

<h2 id="billing-heading">Számlázási cím</h2>
<form aria-labelledby="billing-heading">...</form>

aria-describedby — kiegészítő szövegre mutat, amely a néven túl leírja az elemet:

<input type="password" aria-describedby="pwd-hint">
<p id="pwd-hint">Legalább 12 karakter hosszú legyen, és tartalmazzon egy szimbólumot.</p>

aria-expanded — jelzi, hogy egy összecsukható elem (legördülő menü, harmonika, menü) nyitva van-e vagy zárva. JavaScriptben frissíteni kell minden állapotváltozáskor:

<button aria-expanded="false" aria-controls="nav-menu">Menü</button>
<ul id="nav-menu" hidden>...</ul>

aria-hidden="true" — eltávolítja az elemet az akadálymentességi fából. Dekoratív ikonokhoz, ismétlődő szöveghez vagy olyan vizuális elemekhez használjuk, amelyek csak zajt jelentenének a képernyőolvasót használóknak:

<span aria-hidden="true">★★★★☆</span>
<span class="sr-only">5-ből 4 csillag</span>

aria-disabled="true" — letiltottként jelöl meg egy vezérlőt anélkül, hogy kivenné a fókuszsorrendből. Akkor hasznos, ha azt szeretnénk, hogy a felhasználók felfedezzék a vezérlő létezését, és megértsék, miért nem elérhető, ahelyett hogy némán átugranák:

<button aria-disabled="true">Beküldés (előbb töltse ki az összes mezőt)</button>

Az ARIA tesztelése a gyakorlatban

ARIA-attribútumokat írni egyszerű. Jól megírni tesztelést igényel. Az automatizált vizsgálók elkapják a nyilvánvalóan hibás mintákat — egy hozzáférhető név nélküli role="button" elemet, egy nem létező azonosítóra hivatkozó aria-labelledby attribútumot, egy érvénytelen aria-live értékkel rendelkező élő régiót. Azt viszont nem tudják megmondani, hogy a bejelentett szöveg értelmes-e az adott kontextusban, vagy hogy egy összetett egyedi widget helyesen viselkedik-e, ha kizárólag billentyűzettel navigálnak rajta.

A valós tesztelésnél legalább két képernyőolvasó-böngésző párost érdemes kombinálni:

• NVDA + Chrome Windowson — ingyenes, széles körben használt, közel áll a valós képernyőolvasó-felhasználói bázishoz
• VoiceOver + Safari macOS vagy iOS rendszeren — beépített, elengedhetetlen a mobilos akadálymentességi teszteléshez
• JAWS + Chrome vagy Edge Windowson — fizetős, de vállalati környezetben ez a legszélesebb körben használt képernyőolvasó

Az interaktív komponenseken kizárólag billentyűzettel navigáljunk. Figyeljünk oda, mit jelent be a rendszer, amikor megnyitunk egy menüt, beküldünk egy űrlapot érvényesítési hibával, vagy kiváltunk egy élő régió frissítést. Ha a bejelentés kétértelmű vagy félrevezető, akkor az ARIA-megvalósítás hibás — függetlenül attól, mit jelez bármelyik automatizált eszköz.

Az a szabály, amely mindent lefed

Az ARIA specifikációja öt szerzői szabályt tartalmaz. Az első a legfontosabb:

Ha használható olyan natív HTML-elem vagy attribútum, amelybe a szükséges szemantika és viselkedés már be van építve, ahelyett hogy egy elemet más célra használnánk fel, és ARIA-szerepet, -állapotot vagy -tulajdonságot adnánk hozzá az akadálymentesítés érdekében, akkor azt tegyük.

Építkezzünk szemantikus HTML-lel. Csak akkor nyúljunk az ARIA-hoz, amikor a HTML kifogy a lehetőségekből. Teszteljünk valódi képernyőolvasóval. Ez szinte minden előforduló helyzetet lefed.

Ha gyakorlati képet szeretne arról, hogyan valósulnak meg az ARIA-attribútumok az oldalán, a manuális akadálymentességi auditjaink képernyőolvasós tesztelést is tartalmaznak, olyan emberek közreműködésével, akik nap mint nap segítő technológiát használnak, és észreveszik azokat a finom ARIA-problémákat is, amelyeket az automatizált eszközök kihagynak.