## Коли ARIA шкодить ARIA шкодить, коли вона: ### 1. Дублює нативний HTML Погано: ```html ``` `button` уже є кнопкою. `role="button"` тут не потрібен. Погано: ```html ``` `nav` уже має navigation-семантику. --- ### 2. Бреше про поведінку Погано: ```html

Submit

``` Скрінрідер скаже "button", але елемент може не працювати як кнопка з клавіатури. Краще: ```html ``` --- ### 3. Ховає важливий контент Погано: ```html ``` Візуально помилка є, але для скрінрідера її немає. `aria-hidden="true"` треба використовувати обережно - для декоративних або дубльованих елементів, не для важливої інформації. --- ### 4. Конфліктує з реальним станом UI Погано: ```html

... ``` Користувач бачить відкрите меню, а скрінрідер отримує стан "collapsed". ARIA має синхронізуватися зі станом компонента. --- ### 5. Використовується замість нормальної розмітки Погано: ```html

Page title

``` Краще: ```html

Page title

``` Погано: ```html

Item 1

Item 2

``` Краще: ```html

Item 1
Item 2

``` --- ## Практичний приклад: кнопка-іконка Погано: ```html ``` Краще: ```html ``` Що тут відбувається: ```html aria-label="Close modal" ``` Дає кнопці зрозумілу назву. ```html aria-hidden="true" ``` Ховає декоративну SVG-іконку від скрінрідера. ```html focusable="false" ``` Допомагає уникнути зайвого фокусу на SVG у деяких середовищах. --- ## Практичний приклад: accordion ```html ``` Коли відкриваємо: ```html

Delivery usually takes 3–5 business days.

``` Тут: * `aria-expanded` показує стан; * `aria-controls` зв'язує кнопку з панеллю; * `aria-labelledby` каже, що панель названа цією кнопкою; * `hidden` реально приховує або показує контент. --- ## Практичний приклад: форма Погано: ```html ``` Це не катастрофа, але краще мати видимий label. Краще: ```html Email ``` З помилкою: ```html Email

Please enter a valid email address.

``` Тут: * `aria-invalid="true"` каже, що поле має помилку; * `aria-describedby` підключає текст помилки до input. --- ## Чекліст перед тим, як додавати ARIA Перед тим як писати `aria-*`, запитай себе: 1. Чи є нативний HTML-елемент для цього? 2. Чи ARIA не дублює вже існуючу семантику? 3. Чи елемент працює з клавіатури? 4. Чи ARIA-стан відповідає реальному стану UI? 5. Чи я не сховав важливий контент через `aria-hidden`? 6. Чи я протестував це хоча б клавіатурою? 7. Чи зрозуміло це буде скрінрідеру? [ARIA Authoring Practices Guide (APG)](https://www.w3.org/WAI/ARIA/apg/) від W3C містить патерни й приклади для складних компонентів на кшталт dialogs, tabs, accordions, comboboxes і menus. --- ## Головна думка ARIA - це не магічний accessibility fix. Вона не робить поганий HTML хорошим автоматично. Найкраща accessibility-стратегія: ```text semantic HTML → keyboard support → visible labels → ARIA only when needed ``` Або простіше: > Спочатку HTML. Потім поведінка. І тільки потім ARIA. ARIA корисна, коли ти будуєш складний кастомний UI. ARIA шкідлива, коли ти використовуєш її замість нормального HTML або коли вона бреше про реальний стан інтерфейсу.