# ARIA
## Що це таке
ARIA — це специфікація W3C, набір атрибутів HTML, які повідомляють допоміжним технологіям, чим є
елемент сторінки, як він називається і в якому стані перебуває, коли самого HTML для цього замало.
Абревіатура розшифровується як Accessible Rich Internet Applications, а повна назва специфікації,
WAI-ARIA, додає до неї Web Accessibility Initiative, ініціативу W3C з вебдоступності. Чинна
рекомендація W3C має версію 1.2.
Атрибут `role` каже, що це за річ: віджет на кшталт `button` чи `tab`, структурна частина на кшталт
`list`, одна з восьми ролей-орієнтирів, як-от `navigation` або `main`, чи жива область (live region)
на кшталт `status`, зміни в якій зчитувач екрана озвучує сам, без запиту. Решта атрибутів `aria-*`
поділяється на властивості, наприклад `aria-labelledby`, і стани, наприклад `aria-expanded`, які
змінюються разом із діями користувача. Браузер переносить усе це в API доступності операційної
системи, а вже звідти інформацію бере зчитувач екрана чи програма голосового керування.
ARIA змінює лише те, що буде озвучено. Зчитувач назве `div` з `role="button"` кнопкою, проте фокус
на такий елемент не потрапляє, а Enter і пробіл нічого не роблять, доки `tabindex` і скрипт не
додадуть одне й друге. Тому перше правило використання ARIA в посібнику W3C Using ARIA звучить так:
якщо вже існує вбудований елемент чи атрибут HTML із потрібними семантикою та поведінкою,
використовуйте його, а не перепрофільовуйте інший елемент, додаючи до нього ARIA.
```html
Send
```
Друга половина — доступна назва, тобто слова, якими зчитувач екрана називає елемент керування.
Специфікація Accessible Name and Description Computation 1.2 задає порядок: спершу
`aria-labelledby`, далі `aria-label`, потім власна мітка мови розмітки (елемент `label`, атрибут
`alt`, `title` у SVG), потім текстовий вміст елемента для ролей, які беруть назву з нього, і
наостанок атрибут `title`. Отже, `aria-label` на кнопці замінює видимі слова, а не доповнює їх.
## Чому це важливо
ARIA ставить перед командою вибір: будувати самим чи взяти готове. Критерій успішності 4.1.2 у WCAG
2.2, Name, Role, Value, вимагає, щоб кожен компонент інтерфейсу відкривав програмам свою назву й
роль, дозволяв програмно встановлювати стани та значення, які змінює користувач, і повідомляв про
їхні зміни. Вбудовані `button`, `select` чи `details` виконують цю вимогу одразу. Власна смуга
вкладок, комбінований список чи дерево виконують її лише завдяки ARIA і скрипту, який тримає
атрибути в згоді з дійсністю.
Тож власний віджет — це постійні витрати: обробка клавіатури, керування фокусом, стани, що
відстежують кожну дію, і тестування з кількома зчитувачами екрана після кожного редизайну. Оцінюючи
бібліотеку компонентів, з'ясуйте, за яким шаблоном з ARIA Authoring Practices Guide від W3C зроблено
кожен віджет і чи працює клавіатурна поведінка цього шаблону, коли мишу відкладено.
Юридичний тиск тепер сягає й приватних компаній. Директива про доступність вебсайтів, (ЄС)
2016/2102, охоплює сайти й мобільні застосунки органів публічного сектору. Директива (ЄС) 2019/882,
відома як European Accessibility Act, застосовується з 28 червня 2025 року до низки споживчих
продуктів і послуг, серед них електронна комерція та банківські послуги для споживачів, а
мікропідприємства, що надають послуги, звільнені від її вимог. Обидві спираються на гармонізований
стандарт EN 301 549, чиї вимоги до вебу — це WCAG рівня AA. Name, Role, Value стоїть на рівні A, тож
елемент керування, чия назва чи роль лишається прихованою від зчитувача екрана, провалює найнижчий
рівень, який перевіряє аудитор.
## Як це виглядає на практиці
Шаблони цього сайту вдаються до ARIA ощадливо. Верхня панель на кожній внутрішній сторінці — це
`div` з `role="banner"`, а не звичний елемент `header`. Коментар у шаблоні пояснює чому: таблиця
стилів оформлює голий `header` як великий вступний блок головної сторінки на всю висоту екрана, тож
елемент переніс би цю геометрію на кожну внутрішню сторінку, а роль дає орієнтир і більше нічого.
Саме роль вміщує знак бренду, тобто посилання на головну, всередину орієнтира. Це якраз той вузький
випадок, який перше правило допускає. Меню сайту йде протилежним шляхом: це пара `details` і
`summary`, яка лишає браузерові стан відкриття, семантику кнопки та `aria-expanded`. Елементи `nav`
меню і футера мають різні значення `aria-label`, бо два навігаційні орієнтири з однією назвою
порушують правило унікальності в рушії перевірок, а перевірка доступності сайту вимагає нуля
зауважень. Фільтр у портфоліо повідомляє кількість записів через область `role="status"`, яка
мовчить, доки читач не почне вводити текст.
Опис того, як
[сайт довели до WCAG 2.2 рівня AA](/uk/portfolio/took-wcag-2-2-level-aa-across-the-whole-site-130/),
дописує другу половину історії верхньої панелі: щойно в рушії перевірок увімкнули правила найкращих
практик, одне з них одразу дало збій, бо на кожній внутрішній сторінці знак бренду лишався за межами
всіх орієнтирів. Та сама сторінка серед обмежень, які вона публікує, називає відсутність тестування
з реальними допоміжними технологіями.
Розбір
[одинадцяти дефектів, які браузер визнав справними](/uk/portfolio/fixed-11-accessibility-defects-the-browser-called-healthy-131/),
показує, як далеко розмітка від того, що відчуває користувач. Усі одинадцять жили в тому, як
сторінка малювалася на екрані, а не в тому, що оголошувала розмітка, а розмітка — це все, чого
торкається ARIA. Вісім посилань у футері й далі були досяжні клавішею Tab, хоча стиль вимкнув для
них взаємодію з вказівником і більше нічого не змінив. Це та сама схема, що й `aria-hidden` на
елементі, здатному отримати фокус: зчитувач екрана елемент втрачає, а клавіатура досі до нього веде.
До того ж у рушії було ввімкнено лише 70 правил зі 105, і правило, що мало б помітити відсутній
орієнтир, опинилося серед вимкнених.
Остання сторінка показує ту саму проблему на платформі, де ARIA немає зовсім.
[Усі сімнадцять іконок інтерфейсу отримали назви для зчитувачів екрана](/uk/portfolio/named-all-seventeen-interface-icons-for-screen-readers-159/)
— це історія застосунку на SwiftUI, де немає ні HTML, ні жодного атрибута `aria-`. Мітка доступності
там належить самому SwiftUI: це вбудований відповідник `aria-label`, а не його різновид. Елементи
керування, намальовані системними символами, зачитувалися внутрішньою назвою символу, тож кнопка
надсилання звучала як «стрілка вгору коло, кнопка», а сімнадцять елементів керування з самою іконкою
описували свій малюнок замість своєї функції. Кожен отримав мітку, що називає дію і там, де це
важливо, стежить за станом, а лінтер тепер відхиляє елемент керування з іконкою, якщо мітки немає в
межах восьми рядків від місця, де його створено, тож вісімнадцятий потрапить у застосунок лише з
міткою. Сторінка сама називає межу, і вона стосується й `aria-label`: перевірка підтверджує, що
якась мітка стоїть поблизу, а чи вона правильна, може вирішити лише людина, яка її слухає.
## Де виникають проблеми
**Роль обіцяє віджет, до якого клавіатура не дістає.** Елемент `div` отримує `role="button"` і
обробник кліку. Зчитувач екрана каже «кнопка», але Tab його проминає, а Enter нічого не робить.
Третє правило використання ARIA вимагає, щоб кожен інтерактивний елемент керування з ARIA працював
із клавіатури. Візьміть вбудований елемент або побудуйте всю клавіатурну модель шаблону з APG і
тестуйте з від'єднаною мишею.
**Фокус потрапляє на те, що зчитувач екрана вважає відсутнім.** Атрибут `aria-hidden="true"` стоїть
на елементі, здатному отримати фокус, або на його предкові, наприклад на висувній панелі за межами
екрана. Tab і далі веде туди, а користувач чує тишу. Четверте правило використання ARIA прямо це
виключає. Прибирайте прихований вміст і з порядку табуляції за допомогою `hidden`, `display: none`
або `inert`, а `aria-hidden` лишайте для оздоблення, яке ніколи не отримує фокусу.
**Назва потрапляє туди, де елемент її не приймає.** Атрибут `aria-label` на `div`, `span` чи `p` мав
би щось пояснити, але WAI-ARIA 1.2 забороняє давати назву ролям `generic` і `paragraph`, тож
зчитувачі екрана її ігнорують або читають непослідовно. На елементі керування мітка замінює видимі
слова, і коли вони розходяться, користувач голосового керування промахується, вимовляючи те, що
бачить на екрані. Давайте назви лише елементам, які можуть її мати, і починайте кожен `aria-label` з
видимих слів, як вимагає WCAG 2.5.3, Label in Name.
**Дві ролі суперечать одна одній.** Явна роль замінює власну роль елемента. Посилання з
`role="button"` озвучується як кнопка, але пробіл на ньому прокручує сторінку; `role="tab"` на `h2`
прибирає його зі списку заголовків; `role="navigation"` на `ul` позбавляє його ролі списку й
кількості пунктів. Друге правило використання ARIA — змінювати вбудовану семантику лише тоді, коли
без цього не обійтися, а ARIA in HTML перелічує, які ролі може мати кожен елемент.
**Жива область говорить без упину.** Атрибут `aria-live="assertive"` або `role="alert"` стоїть на
лічильнику результатів чи зворотному відліку, що змінюється з кожним натисканням клавіші чи
щосекунди, і зчитувач екрана перебиває користувача на кожному новому значенні. Використовуйте
ввічливі оголошення (`polite`), які `role="status"` дає за визначенням, озвучуйте результат, коли
введення вщухне, і тримайте область тихою під час завантаження сторінки.
## Що почитати далі
- [WAI-ARIA 1.2](https://www.w3.org/TR/wai-aria-1.2/) — усі ролі, стани й властивості, які атрибути
підтримує кожна роль і яким ролям не можна давати назву.
- [ARIA in HTML](https://www.w3.org/TR/html-aria/) — які ролі й атрибути може мати кожен елемент
HTML і які з них зайві.
- [Using ARIA](https://www.w3.org/TR/using-aria/) — практичний посібник W3C із правилами
використання ARIA і прикладом до кожного.
- [Accessible Name and Description Computation 1.2](https://www.w3.org/TR/accname-1.2/) — алгоритм,
що визначає, як зчитувач екрана назве елемент керування.
- [Understanding Name, Role, Value](https://www.w3.org/WAI/WCAG22/Understanding/name-role-value.html)
— чого критерій успішності 4.1.2 у WCAG 2.2 вимагає від кожного компонента, з техніками й типовими
помилками.
- [ARIA Authoring Practices Guide](https://www.w3.org/WAI/ARIA/apg/) — розмітка й клавіатурна
поведінка для кожного поширеного шаблону віджета, з робочими прикладами.