Průvodce pro vývojáře k popiskům ARIA, které skutečně pomáhají
Popisky ARIA nejsou kouzelná vrstva přístupnosti. Když se používají dobře, dělají ovládací prvky srozumitelnými. Když se používají ledabyle, skrývají užitečný text a vytvářejí matoucí rozhraní.
Obsah
- Popisky ARIA slouží k pojmenování, ne k omluvám
- Přístupný název jednoduše
- První pravidlo: upřednostněte nativní HTML a viditelné popisky
- Kdy je `aria-label` správný nástroj
- Kdy je `aria-label` špatný nástroj
- Sáhněte po `aria-labelledby`, když viditelný text už existuje
- Používejte `aria-describedby` pro nápovědu, ne pro název
- Opakované ovládací prvky potřebují jedinečné názvy
- Nepopisujte všechno
- Kontrolujte vypočítaný název, nejen kód
- Praktický kontrolní seznam pro revizi
- Tichá disciplína dobré ARIA
Popisky ARIA slouží k pojmenování, ne k omluvám
ARIA je užitečná, ale často se používá jako záplata na nejasné HTML. Právě tam se týmy dostávají do potíží.
Nejběžnějším příkladem je aria-label. Vypadá neškodně: přidat řetězec, uspokojit linter a jít dál. Přístupný název ale není dekorace. Je to název, který mnoho asistivních technologií předává uživatelům při navigaci po tlačítkách, odkazech, formulářových polích, nadpisech, landmarcích a ovládacích prvcích.
Pokud je tento název vágní, duplicitní, zastaralý nebo odlišný od viditelného popisku, rozhraní se používá hůře. Někdy i podstatně hůře: aria-label může přepsat lepší text, který už v DOM existoval.
Cílem není přidat více ARIA. Cílem je zpřehlednit název, roli, stav a účel každého prvku rozhraní.
Přístupný název jednoduše
Většina interaktivních prvků má přístupný název. Čtečky obrazovky tento název používají k oznámení toho, čím prvek je.
Například:
<button>Save changes</button>
Čtečka obrazovky může oznámit něco jako: „Save changes, button.“ Role pochází z nativního prvku button. Název pochází z textu uvnitř něj.
To je ideální případ: viditelný text a přístupný název se shodují.
Atributy ARIA pro popisování se hodí ve chvíli, kdy viditelné rozhraní neposkytuje úplný název, nebo když má název pocházet z jiného prvku. Hlavní atributy jsou:
aria-label: poskytuje řetězec přímo na prvku.aria-labelledby: odkazuje na jeden nebo více prvků, jejichž text se stane názvem.aria-describedby: odkazuje na podpůrný popisný text, nikoli na hlavní název.
Tyto tři atributy spolu souvisejí, ale nejsou zaměnitelné.
První pravidlo: upřednostněte nativní HTML a viditelné popisky
Pokud můžete na ovládací prvek umístit viditelný text, udělejte nejdříve to.
Toto je lepší:
<button>Delete invoice</button>
Než toto:
<button aria-label="Delete invoice">
<svg aria-hidden="true" focusable="false">...</svg>
</button>
Druhý vzor je platný pro tlačítko tvořené pouze ikonou. Pokud ale návrh snese viditelný text, viditelný text pomáhá všem: uživatelům čteček obrazovky, uživatelům hlasového ovládání, lidem pod kognitivní zátěží, lidem, kteří rychle skenují stránku, i lidem používajícím překladové nástroje.
To je v práci na přístupnosti opakující se motiv. Nativní HTML a viditelné affordance řeší více problémů než skrytá metadata. Stejný princip platí šířeji i pro sémantiku tlačítek; pokud váš tým audituje ovládací prvky UI, náš kontrolní seznam pro přístupná webová tlačítka je dobrým doplňkem k tomuto průvodci.
Kdy je aria-label správný nástroj
Použijte aria-label, když prvek potřebuje přístupný název a neexistuje vhodný viditelný text, na který by šlo odkázat.
Klasickým případem je tlačítko tvořené pouze ikonou:
<button aria-label="Search">
<svg aria-hidden="true" focusable="false" viewBox="0 0 24 24">
<!-- icon -->
</svg>
</button>
To je rozumné. Viditelná ikona naznačuje vyhledávání, ale samotná SVG cesta neposkytuje spolehlivý název. aria-label jej doplní.
Mezi další dobré případy patří:
- Tlačítko pro zavření reprezentované pouze znakem „X“.
- Navigační landmark, který potřebuje konkrétnější název, například
aria-label="Product". - Opakovaný ovládací prvek, u kterého viditelný kontext není součástí textu tlačítka.
Například:
<nav aria-label="Primary">
...
</nav>
<nav aria-label="Footer">
...
</nav>
Oba prvky jsou navigační landmarky, ale jejich popisky pomáhají uživatelům odlišit je při pohybu podle landmarků.
Kdy je aria-label špatný nástroj
Nepřidávejte aria-label jen proto, že test říká, že prvek potřebuje popisek. Nejprve opravte markup.
Špatně:
<div role="button" tabindex="0" aria-label="Submit">Submit</div>
Lépe:
<button>Submit</button>
První příklad vytváří zbytečnou práci. Musíte znovu vytvořit chování klávesnice, zakázané stavy, formulářové chování a očekávání, která nativní tlačítka už poskytují.
Vyhněte se také použití aria-label k přejmenování viditelného textu způsobem, který mění význam.
<button aria-label="Delete invoice">Remove</button>
Vypadá to jako drobnost, ale může to mást uživatele, kteří spoléhají na hlasové zadávání. Pokud viditelné tlačítko říká „Remove“, ale jeho přístupný název je „Delete invoice“, uživatel, který se pokusí říct „click Remove“, nemusí dostat očekávaný výsledek. Požadavek WCAG „label in name“ existuje právě z tohoto důvodu: viditelný text by měl být obecně obsažen v přístupném názvu.
Lepší verze:
<button aria-label="Remove invoice">Remove</button>
Často ještě lépe:
<button>Remove invoice</button>
Sáhněte po aria-labelledby, když viditelný text už existuje
Pokud je text popisku už na stránce, aria-labelledby je obvykle lepší než aria-label.
Příklad:
<h2 id="billing-title">Billing address</h2>
<section aria-labelledby="billing-title">
...
</section>
Přístupný název sekce nyní pochází z viditelného nadpisu. Vyhnete se duplikaci řetězců, což snižuje počet chyb v překladu a zastaralých popisků.
To je obzvlášť užitečné u skupin formulářových polí:
<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>
V mnoha případech stačí nativní legend bez ARIA. Jde o to, že viditelné popisky by měly vést. ARIA má propojovat existující význam, ne vytvářet jeho druhou soukromou verzi.
Používejte aria-describedby pro nápovědu, ne pro název
Popis není popisek.
Zvažte toto pole:
<label for="password">Password</label>
<input id="password" type="password" aria-describedby="password-help">
<p id="password-help">Use at least 12 characters.</p>
Přístupný název je „Password“. Popis je „Use at least 12 characters.“ Čtečka obrazovky může oznámit obojí, ale každé slouží jinému účelu.
Nedělejte toto:
<input type="password" aria-label="Use at least 12 characters">
Tím pojmenujete pole podle instrukce, ne podle konceptu. Uživatel, který prochází formulářem, chce nejdříve vědět, co pole je, a teprve potom jaká omezení platí.
Toto rozlišení je důležité i u chybových stavů:
<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>
Popisek zůstává stabilní. Chybová zpráva se stává podpůrným kontextem.
Opakované ovládací prvky potřebují jedinečné názvy
Seznamy a karty jsou místa, kde jsou popisky ARIA často potřeba.
Špatně:
<button>Delete</button>
<button>Delete</button>
<button>Delete</button>
Uživatel čtečky obrazovky, který se pohybuje po tlačítkách, může třikrát slyšet „Delete, button“ bez jakéhokoli kontextu.
Dobře:
<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>
To je legitimní použití aria-label: viditelný text zůstává stručný, zatímco přístupný název obsahuje objekt.
Tento vzor ale používejte opatrně. Pokud je název objektu viditelný poblíž, aria-labelledby může být lépe udržovatelné:
<article>
<h3 id="report-q4">Q4 revenue</h3>
<button aria-labelledby="delete-q4 report-q4" id="delete-q4">Delete</button>
</article>
Přístupný název se stane „Delete Q4 revenue“. Tím se vyhnete duplikaci názvu reportu v atributu.
Nepopisujte všechno
Ne každý prvek potřebuje popisek ARIA.
Statický text ho obvykle nepotřebuje. Dekorativní ikony také ne. Kontejnery také ne, pokud nemají významnou roli landmarku nebo widgetu. Nadměrné popisování může stránku zahlcovat a ztěžovat navigaci.
U obrázků používejte model určený pro obrázky: významové obrázky potřebují užitečný alt; dekorativní obrázky potřebují prázdný alt="". Nepoužívejte popisky ARIA jako náhradu za dobrý text obrázku. Pokud váš tým tyto koncepty směšuje, vraťte se k pragmatickému alt textu obrázků a oddělte alternativy obrázků od názvů ovládacích prvků.
Častou chybou je dávat každému SVG aria-label. Pokud je SVG uvnitř tlačítka a tlačítko už má název, ikona by měla být před asistivními technologiemi obvykle skrytá:
<button aria-label="Open menu">
<svg aria-hidden="true" focusable="false">...</svg>
</button>
Jinak může uživatel slyšet redundantní nebo zvláštní oznámení v závislosti na kombinaci prohlížeče a asistivní technologie.
Kontrolujte vypočítaný název, nejen kód
Chyby v přístupnosti často přežijí code review, protože markup vypadá uvěřitelně.
Moderní vývojářské nástroje prohlížečů umí zobrazit vypočítaný strom přístupnosti. V Chrome, Edge, Firefox a Safari prvek prozkoumejte a hledejte informace o přístupnosti, jako je role, název a popis. Kontrolujete tři věci:
- Je role taková, jakou očekáváte?
- Je přístupný název jasný a konkrétní?
- Je popis užitečný, aniž by nahrazoval název?
Poté otestujte několik průchodů se skutečnou čtečkou obrazovky. Nemusíte se stát specialistou na asistivní technologie na plný úvazek, abyste zachytili základy. Na macOS je VoiceOver vestavěný. Na Windows je NVDA široce používaná a zdarma. Na mobilních zařízeních testujte tam, kde je to relevantní, s VoiceOver na iOS a TalkBack na Android.
Automatizované nástroje jsou užitečné, ale nedokážou spolehlivě říct, zda je „Open“, „Read more“ nebo „Delete“ dostatečně kontextové. Berte automatizaci jako síť, ne jako soudce. Je to podobné jako u auditů výkonu: report vás může nasměrovat na podezřelá místa, ale dopad musíte stále interpretovat vy. Stejný klidný přístup, který doporučujeme při čtení reportu Lighthouse bez paniky, platí i zde.
Praktický kontrolní seznam pro revizi
Před nasazením popisků ARIA se zeptejte:
- Mohlo by to místo toho být nativní HTML?
- Existuje viditelný text, který by měl být použit jako popisek?
- Pokud viditelný text existuje, obsahuje ho přístupný název?
- Jsou opakované ovládací prvky jedinečné při navigaci mimo vizuální kontext?
- Je nápověda připojena pomocí
aria-describedby, a ne vtlačená do popisku? - Jsou dekorativní ikony skryté před asistivními technologiemi?
- Zkontroloval někdo vypočítaný přístupný název ve vývojářských nástrojích prohlížeče?
- Proběhl u kritického toku alespoň jeden průchod se skutečnou čtečkou obrazovky?
Tento kontrolní seznam zachytí většinu problémů s popisky dříve, než se stanou problémy uživatelů.
Tichá disciplína dobré ARIA
Dobrá práce s ARIA bývá málokdy dramatická. Většinou je to zdrženlivost.
Používejte skutečná tlačítka. Používejte skutečné popisky. Udržujte viditelné a přístupné názvy sladěné. Přidávejte aria-label jen tehdy, když neexistuje lepší viditelný zdroj. Používejte aria-labelledby, když stránka už obsahuje správný text. Používejte aria-describedby pro podpůrné instrukce a chyby.
Webová platforma dává vývojářům mnoho věcí zdarma, když ji používáme přímo. ARIA je tu pro mezery. Dovednost spočívá v tom poznat, kdy mezera skutečně existuje.