Какво е ARIA? Роли, ориентири и live региони

Какво е ARIA — и какво не е

ARIA означава Accessible Rich Internet Applications (достъпни богати интернет приложения). Това е набор от атрибути, дефинирани от инициативата за уеб достъпност (WAI) на W3C, който позволява на разработчиците да съобщават значението и състоянието на елементите от потребителския интерфейс на помощни технологии като екранните четци.

Най-важното правило за ARIA е и това, което най-често се пренебрегва: не използвайте ARIA, когато нативният HTML може да свърши работата. Елементът <button> вече се обявява като бутон и реагира на клавиатурни събития. Елементът <nav> вече съобщава навигационен ориентир на екранните четци. Добавянето на role="button" към един <div> и последващото програмиране на поведението му е по-трудно за поддръжка, по-лесно за счупване и обикновено по-лошо за достъпността, отколкото просто да използвате правилния елемент още от самото начало.

ARIA не:

• Прави съдържанието видимо или интерактивно — тя променя единствено какво обявява помощната технология
• Поправя счупен достъп с клавиатура — все още се нуждаете от tabindex и обработчици на събития
• Замества добре структурирания семантичен HTML

Там, където ARIA наистина помага, е когато нативният HTML няма елемент за това, което изграждате: избирач на дата, банер за живи известия, персонализиран комбиниран списък, дървовиден изглед. В тези случаи ARIA ви позволява да съобщите семантиката, която HTML не може.

ARIA роли

Една роля казва на помощната технология с какъв вид елемент си има работа. Всеки интерактивен елемент има подразбираща се роля, произтичаща от неговия HTML таг. Елементът <a> има ролята link. Елементът <input type="checkbox"> има ролята checkbox. Елементът <h2> има ролята heading.

Когато изграждате персонализиран елемент без HTML еквивалент, му задавате изрична роля:

<!-- Персонализиран превключвател, изграден от div -->
<div
  role="switch"
  aria-checked="false"
  tabindex="0"
>
  Тъмен режим
</div>

Екранният четец вече ще обяви това като превключвател и ще изговори състоянието му. Без ролята елементът би бил обявен като обикновен текст и потребителят нямаше да има представа, че е интерактивен.

Често използвани роли и кога да ги прилагате

Ролите за джаджи описват интерактивни контроли:

Роля	Използвайте, когато
button	Персонализиран елемент за щракане без по-подходящ HTML таг
checkbox	Персонализиран превключвател с множествен избор
combobox	Текстово поле, комбинирано с падащ списък
dialog	Модално наслагване (само когато не използвате нативния елемент <dialog>)
listbox	Персонализиран падащ списък
slider	Персонализирана контрола за диапазон
switch	Превключвател включено/изключено
tab, tablist, tabpanel	Интерфейс с раздели
tooltip	Кратко описание, показвано при посочване или фокус

Ролите за структура на документа описват неинтерактивно съдържание:

• article — самостоятелна част от съдържанието
• figure — изображение с надпис
• list, listitem — когато семантиката на списък е нужна върху елементи, които не са списък
• presentation / none — премахва подразбиращата се роля на елемента (използвайте рядко и внимателно)

Критична грешка: добавяне на роли без поведение

Всяка роля носи договор, който екранните четци и потребителите на клавиатура очакват да бъде спазен. Роля role="button" трябва да реагира и на Enter, и на интервал. Роля role="checkbox" трябва да се превключва с интервал. Роля role="link" трябва да навигира с Enter.

Ако добавите ролята, но не и съответното поведение, вие активно заблуждавате потребителите на помощни технологии. Те чуват обявена контрола, опитват се да взаимодействат с нея чрез очакваната клавишна комбинация и не се случва нищо. Това е по-лошо, отколкото изобщо да няма ARIA.

ARIA ориентири

Ориентирите са навигационният скелет на страницата. Те позволяват на потребителите на екранни четци да прескачат между основните региони, без да четат всичко помежду им — еквивалентът на това зрящ потребител да обхване оформлението на страницата с един поглед.

HTML5 въведе семантични елементи, които се съотнасят директно към роли на ориентири. Използвайте ги и ориентирите идват безплатно:

HTML елемент	Роля на ориентир	Предназначение
<header>	banner	Хедър за целия сайт (само когато е хедърът от най-високо ниво, а не вътре в <article>)
<nav>	navigation	Навигационно меню
<main>	main	Основното съдържание на страницата
<aside>	complementary	Второстепенно съдържание, свързано с основното
<footer>	contentinfo	Футър за целия сайт
<form>	form	Формуляр (само когато има достъпно име)
<section>	region	Именуван раздел (само когато има достъпно име чрез aria-label или aria-labelledby)

Не е нужно да добавяте role="main" към елемент <main> — това е излишно. ARIA ролите за ориентири са необходими само когато не можете да използвате семантичния HTML елемент, например в наследена кодова база, генерираща <div class="sidebar">:

<div class="sidebar" role="complementary" aria-label="Свързани статии">
  <!-- съдържание на страничната лента -->
</div>

Етикетиране на ориентирите, когато имате повече от един

Когато страницата има няколко екземпляра на един и същ ориентир — два елемента <nav>, два елемента <section> с role="region" — всеки от тях трябва да има уникално достъпно име, за да могат потребителите да ги различават:

<nav aria-label="Основна навигация">...</nav>
<nav aria-label="Навигация във футъра">...</nav>

Без етикети екранният четец обявява и двата просто като „навигация“. С етикети потребителите чуват „Основна навигация, ориентир за навигация“ и „Навигация във футъра, ориентир за навигация“ и могат да изберат правилния от списъка с ориентири.

ARIA live региони

Live регионът е област от страницата, чието съдържание се обновява динамично и чиито обновявания трябва автоматично да бъдат обявявани на потребителите на екранни четци, без да е необходимо те да местят фокуса.

Основният атрибут е aria-live. Той приема три стойности:

• off — обновяванията не се обявяват (стойността по подразбиране за всички елементи)
• polite — обновяванията се обявяват, след като потребителят приключи текущата си задача
• assertive — обновяванията прекъсват незабавно това, което екранният четец изговаря

<!-- Област за съобщение за състояние, попълвана след изпращане на формуляр -->
<div aria-live="polite" id="status-message"></div>

<script>
  document.getElementById('status-message').textContent =
    'Съобщението ви беше изпратено.';
</script>

Когато текстовото съдържание се промени, екранен четец с aria-live="polite" изчаква пауза в речта и след това обявява новото съдържание. Използвайте polite за огромното мнозинство динамични обновявания. Запазете assertive само за критични проблеми — грешка при плащане, предупреждение за изтичане на сесията — където информацията е достатъчно спешна, за да оправдае прекъсването на потребителя.

Съкратени роли за live региони

Две роли обединяват семантиката на aria-live в един-единствен атрибут:

• role="status" — еквивалент на aria-live="polite". Използвайте за съобщения за успех, състояния на зареждане и неспешни обновявания.
• role="alert" — еквивалент на aria-live="assertive" и освен това подразбира aria-atomic="true". Използвайте за съобщения за грешки и критични проблеми.

<!-- Грешка, обявена незабавно, прекъсваща текущата реч -->
<div role="alert" id="payment-error"></div>

<!-- Обновяване на състоянието, обявено учтиво след текущата реч -->
<div role="status" id="cart-count">3 артикула в количката</div>

Често срещани грешки при live региони

Добавяне на съдържание, преди елементът да е в DOM. Браузърът регистрира live региона, когато елементът бъде обработен за първи път. Ако вмъкнете елемента и зададете текстовото му съдържание едновременно, някои екранни четци пропускат обявяването изцяло. Винаги включвайте контейнера на live региона в първоначалния HTML и обновявайте съдържанието му чрез JavaScript по-късно.

Използване на assertive за всичко. Assertive live регионите прекъсват каквото и да прави потребителят, включително други обявявания. Брой резултати от търсене, който се обновява, докато потребителят пише, не оправдава role="alert". Прекомерната употреба на assertive създава враждебно изживяване за потребителите на екранни четци.

Прекалено често обновяване на live региона. Ако индикатор за напредък обновява своя live регион на всеки 100 милисекунди, речевата опашка прелива и потребителите не чуват нищо полезно. Обновявайте живия текст само при смислени етапи — 25%, 50%, 75%, готово — или прилагайте забавяне на обновяванията с таймер.

Забравяне на aria-atomic. По подразбиране се обявява само промененият текстов възел вътре в live региона. Ако искате целият регион да бъде прочетен отново (а не само промененият фрагмент), добавете aria-atomic="true":

<div aria-live="polite" aria-atomic="true">
  Остават <span id="count">2</span> артикула
</div>

Без aria-atomic екранният четец може да обяви само „2“, когато броят се промени от 3 на 2. С него се изговаря цялата фраза „Остават 2 артикула“, което почти винаги е това, което искате.

Други съществени ARIA атрибути

aria-label — предоставя достъпно име, когато видим текст не е подходящ:

<button aria-label="Затвори диалога">✕</button>

aria-labelledby — сочи към друг елемент, чийто текст служи за достъпно име. Предпочита се пред aria-label, когато текстът на етикета вече е видим на страницата:

<h2 id="billing-heading">Адрес за фактуриране</h2>
<form aria-labelledby="billing-heading">...</form>

aria-describedby — сочи към допълнителен текст, който описва елемента отвъд името му:

<input type="password" aria-describedby="pwd-hint">
<p id="pwd-hint">Трябва да е поне 12 знака и да включва един символ.</p>

aria-expanded — указва дали сгъваем елемент (падащо меню, акордеон, меню) е отворен или затворен. Обновявайте го в JavaScript при всяка промяна на състоянието:

<button aria-expanded="false" aria-controls="nav-menu">Меню</button>
<ul id="nav-menu" hidden>...</ul>

aria-hidden="true" — премахва елемент от дървото на достъпността. Използвайте за декоративни икони, дублиран текст или визуални елементи, които биха добавили шум за потребителите на екранни четци:

<span aria-hidden="true">★★★★☆</span>
<span class="sr-only">4 от 5 звезди</span>

aria-disabled="true" — маркира контрола като деактивирана, без да я премахва от реда на фокуса. Полезно е, когато искате потребителите да открият, че контролата съществува, и да разберат защо не е налична, вместо тя да бъде мълчаливо прескочена:

<button aria-disabled="true">Изпрати (първо попълнете всички полета)</button>

Тестване на ARIA на практика

Писането на ARIA атрибути е лесно. Правилното им прилагане изисква тестване. Автоматичните скенери улавят явно счупените шаблони — role="button" без достъпно име, aria-labelledby, сочещ към несъществуващ идентификатор, live регион с невалидна стойност на aria-live. Те не могат да ви кажат дали обявеният текст има смисъл в контекста или дали сложна персонализирана джаджа се държи правилно, когато се навигира само с клавиатура.

За реално тестване комбинирайте поне две двойки екранен четец и браузър:

• NVDA + Chrome под Windows — безплатен, широко използван, близък до реалната картина на употреба на екранни четци
• VoiceOver + Safari под macOS или iOS — вграден, съществен за тестване на мобилната достъпност
• JAWS + Chrome или Edge под Windows — платен, но най-широко използваният екранен четец в корпоративна среда

Навигирайте през интерактивните си компоненти само с клавиатурата. Слушайте внимателно какво се обявява, когато отворите меню, изпратите формуляр с грешка при валидация или задействате обновяване на live регион. Ако обявяването е двусмислено или подвеждащо, реализацията на ARIA е грешна — независимо какво отчита който и да е автоматичен инструмент.

Правилото, което обхваща всичко

Спецификацията на ARIA включва пет правила за разработчици. Първото е най-важното:

Ако можете да използвате нативен HTML елемент или атрибут, в който семантиката и поведението, от които се нуждаете, вече са вградени, вместо да преизползвате елемент и да добавяте ARIA роля, състояние или свойство, за да го направите достъпен, направете го.

Изграждайте със семантичен HTML. Посягайте към ARIA само когато HTML свърши. Тествайте с реален екранен четец. Това покрива почти всяка ситуация, с която ще се сблъскате.

За практическа проверка как ARIA атрибутите са реализирани в целия ви сайт, нашите ръчни одити на достъпността включват тестване с екранни четци от хора, които използват помощни технологии всеки ден и могат да забележат фини проблеми с ARIA, които автоматичните инструменти пропускат.