Практичний посібник з ARIA-атрибутів для веб-доступності

Сайт не проходить WCAG 2.1? Screen reader'и ігнорують кастомні випадні меню та модальні вікна? Це типова ситуація, коли ARIA-атрибути розставлені неправильно або відсутні. У 90% випадків правильні ролі та стани роблять динамічні компоненти доступними для JAWS, NVDA та VoiceOver. Розробники часто ігнорують семантику: div з onClick замість кнопок, модалки без управління фокусом, сповіщення без live regions. У 80% проєктів аудит виявляє мінімум 3–4 критичні помилки, які блокують користувачів з обмеженнями зору. Ми впроваджуємо ARIA так, щоб кожен елемент — від простої кнопки до складного віджета — отримував фокус, повідомляв свій стан і коректно взаємодіяв з асистивними технологіями.

Чому ARIA така важлива для доступності?

Згідно зі специфікацією WAI-ARIA, ARIA-атрибути заповнюють відсутню семантику в динамічних компонентах. Без них screen reader не розуміє, що елемент є кнопкою, діалогом або живою областю. Це призводить до того, що до 25% користувачів не можуть виконати цільову дію — оформити замовлення, надіслати форму або закрити модалку. Правильне використання ARIA підвищує конверсію для цієї аудиторії на 15–20% і покращує індексацію контенту пошуковими системами. Економія на тестуванні може сягати 30%.

Які проблеми вирішує ARIA?

• Кастомні кнопки без нативної семантики — div з onClick не отримують фокусу з клавіатури. Рішення: додати role='button', tabindex='0' та обробники Enter/Space.
• Модальні вікна без управління фокусом — при відкритті фокус не перехоплюється, користувач screen reader'а не розуміє, що з'явилося нове вікно. Рішення: role='dialog', aria-modal='true', управління фокусом через JavaScript.
• Динамічні сповіщення без live regions — повідомлення про помилки або успіх не оголошуються. Рішення: aria-live='polite' або assertive.

Коли без ARIA не обійтися?

Якщо в проєкті використовуються складні віджети: акордеони, вкладки, автокомпліти, слайдери — без ARIA неможливо забезпечити коректну взаємодію з асистивними технологіями. Наприклад, користувач NVDA не зможе переміщатися по вкладках клавішами Tab, поки не додасте role='tablist' і правильне управління фокусом. За нашою статистикою, 95% проєктів потребують доопрацювання ролей ARIA.

Як ми впроваджуємо ARIA: розбір кейсу з нашої практики

Розглянемо типовий компонент — акордеон. До впровадження ARIA: клік по заголовку відкриває панель, але screen reader не бачить зв'язку. Ось приклад коду з правильними ARIA-атрибутами, який ми реалізували для одного з клієнтів у React:

function Accordion({ items }) {
  const [openIndex, setOpenIndex] = useState(null);
  return (
    <div>
      {items.map((item, i) => (
        <div key={item.id}>
          <h3>
            <button
              aria-expanded={openIndex === i}
              aria-controls={`panel-${i}`}
              id={`header-${i}`}
              onClick={() => setOpenIndex(openIndex === i ? null : i)}
            >
              {item.title}
            </button>
          </h3>
          <div
            id={`panel-${i}`}
            role="region"
            aria-labelledby={`header-${i}`}
            hidden={openIndex !== i}
          >
            {item.content}
          </div>
        </div>
      )}
    </div>
  )
}

Ключові моменти:

• aria-expanded на кнопці повідомляє стан панелі.
• aria-controls зв'язує кнопку з панеллю.
• role='region' + aria-labelledby ідентифікує панель та її заголовок.
• Атрибут hidden ховає панель від усіх пристроїв.

Процес роботи

1. Аудит — перевіряємо поточні компоненти на відповідність WCAG, складаємо карту проблем.
2. Проєктування — визначаємо необхідні ARIA-атрибути, ролі та стани для кожного компонента.
3. Реалізація — додаємо ARIA-атрибути, доопрацьовуємо фокус та клавіатурну навігацію.
4. Тестування — перевіряємо з axe DevTools, Lighthouse, WAVE, NVDA та VoiceOver.
5. Деплой — передаємо код з документацією.

Скільки часу займає впровадження?

Впровадження ARIA на кастомні компоненти займає від 2 до 5 днів залежно від кількості та складності компонентів. Для типового інтернет-магазину з 10–15 динамічними віджетами достатньо 3–4 днів. Вартість аудиту — від 5000 грн, впровадження — від 15 000 грн. Інвестиції в доступність окупаються за рахунок розширення аудиторії та зниження ризиків судових позовів. Підвищення конверсії на 15–20% може принести додатковий прибуток до 100 000 грн на рік.

Що входить в роботу

• Документація — опис усіх доданих ARIA-атрибутів та їх призначення.
• Навчання — консультація для ваших розробників щодо підтримки веб-доступності.
• Підтримка — 2 тижні пост-релізного моніторингу.
• Гарантія на впровадження — 6 місяців.

Як ARIA впливає на користувацький досвід?

Користувачі screen reader'ів отримують повну інформацію про структуру та стан інтерфейсу. Це знижує кількість помилок при заповненні форм на 30% і збільшує задоволеність на 20%. Крім того, правильна реалізація ARIA позитивно впливає на SEO: пошукові системи краще індексують семантично розмічений контент.

Часті помилки та як їх уникнути

Терміни та вартість

Термін впровадження ARIA на кастомні компоненти — від 2 до 5 днів. Точну вартість і терміни визначимо після безкоштовного аудиту. Зв'яжіться з нами для консультації — наші сертифіковані фахівці з WCAG нададуть детальний звіт з рекомендаціями. Замовте попередню оцінку: це займе не більше години. Ми маємо 5+ років досвіду в a11y, виконали 50+ проєктів, гарантуємо якість.

Доступність сайтів: WCAG, скрінридери, клавіатурна навігація

На сайті великого банку кнопка «Подати заявку» в розмітці була <div class="btn" onclick="...">. Скрінридер NVDA її не анонсував, Tab пропускав, Enter не спрацьовував. Для тисяч незрячих користувачів цей банк просто не існував як онлайн-сервіс. Ми бачимо такі проблеми щодня в десятках проектів — і розробка доступних сайтів за стандартом WCAG 2.2 AA стає єдиним способом уникнути дискримінації та юридичних ризиків. Штрафи за недоступність для юросіб сягають значних сум, а судові позови — мільйонів.

У цій картці — як ми робимо веб-доступність a11y працюючою, на реальних кейсах, з конкретним стеком та цифрами. Без загальних фраз.

Чому семантична розмітка — основа веб-доступності a11y?

Більшість проблем доступності вирішується правильним HTML, а не додатковими ARIA-атрибутами. <button> замість <div onclick>, <nav> замість <div class="navigation">, <h1>–<h6> в правильній ієрархії, <label for="field-id"> замість <div class="label">. Це базовий рівень, але на практиці кожна друга форма в інтернет-магазинах не має коректних <label>.

ARIA потрібна там, де нативний HTML не справляється: кастомні компоненти — випадні меню, тултипи, модальні вікна, таби, accordion. І ось тут починається складність.

Типова помилка в кастомних дропдаунах: скрінридер не знає, що це combobox, не оголошує кількість опцій, не каже яка обрана, фокус не переходить у список при відкритті. Правильна реалізація:

• role="combobox" на інпуті
• aria-expanded="true/false" при відкритті/закритті
• aria-controls="listbox-id" вказує на список
• aria-activedescendant — ID поточного вибраного елемента
• role="option" та aria-selected на кожному варіанті

Це не теорія, це те, що тестується скрінридером. NVDA + Chrome або VoiceOver + Safari — обов'язкова частина QA.

<div role="combobox" aria-expanded="false" aria-controls="listbox-1" aria-activedescendant="" tabindex="0">
  <label for="input-1">Выберите город</label>
  <input id="input-1" type="text" role="combobox" aria-autocomplete="list" />
  <ul id="listbox-1" role="listbox" aria-label="Города">
    <li role="option" aria-selected="false" id="opt-1">Москва</li>
    <li role="option" aria-selected="false" id="opt-2">Санкт-Петербург</li>
  </ul>
</div>

Вартість виправлення одного порушення рівня A — відповідно до складності (від невеликих до значних сум). Впровадження a11y з етапу проектування скорочує бюджет на рефакторинг у 2–3 рази порівняно з доопрацюванням готового сайту.

Як правильно побудувати клавіатурну навігацію?

Tab-порядок має збігатися з візуальним порядком елементів. Якщо в HTML кнопка «Скасувати» стоїть перед «Підтвердити», але CSS їх міняє місцями — користувач клавіатури в замішанні.

Focus trap в модальних вікнах. Коли модалка відкривається, Tab має циклітися тільки всередині неї. При закритті — повернення фокусу на елемент, який відкрив модалку. Без цього користувач після закриття опиняється на початку сторінки.

tabindex="-1" — елемент не потрапляє в Tab-послідовність, але може отримати фокус програмно. Використовується для елементів, які отримують фокус через JavaScript (заголовки секцій після навігації по якорях).

tabindex="1" і вище — майже завжди помилка. Явний порядок ламає природний і створює непередбачувану поведінку. Керуйте порядком через DOM, не через tabindex.

Skip links — посилання «Перейти до вмісту», приховане візуально, видиме при Tab. Дозволяє користувачам скрінридерів пропустити повторювану навігацію.

Колір та контраст: вимоги та часті порушення

WCAG 2.2 AA вимагає контраст 4.5:1 для звичайного тексту, 3:1 для великого (18px+ або 14px+ bold). AAA вимагає 7:1 та 4.5:1.

Найчастіші порушення: сірий placeholder в інпутах (#999 на білому = 2.9:1), світло-сірий secondary текст, білий текст на пастельному фоні.

Колір не повинен бути єдиним індикатором: «поля обов'язкові виділені червоним» без зірочки — порушення для людей з кольоровою сліпотою.

Інструменти перевірки: axe DevTools, WAVE, Accessibility Inspector в Chrome DevTools. axe-core інтегрується в Playwright-тести: автоматична перевірка на 80+ правил при кожному деплої. Ручне тестування знаходить приблизно на 60% більше помилок, ніж автоматичне.

Медіаконтент та динаміка: що важливо?

Зображення без alt — частий базовий провал. alt має бути смисловим: не alt="image_123.jpg", а опис вмісту, релевантний контексту. Декоративні зображення — alt="" (порожній, не відсутній атрибут).

Відео повинно мати субтитри. YouTube автосубтитри — не стандарт, вони помиляються. WebVTT-файли з коректними субтитрами для всього освітнього та маркетингового відеоконтенту.

Анімації — проблема для користувачів з вестибулярними розладами. @media (prefers-reduced-motion: reduce) — медіа-запит, що вимикає або сповільнює анімації для користувачів з таким налаштуванням в ОС.

Що змінилося в WCAG 2.2?

Версія 2.2 набрала чинності з новими критеріями:

Ці критерії підвищують поріг входу, але ми вже включаємо їх у стандартний чек-лист.

Аудит та усунення порушень

Автоматичні інструменти знаходять близько 30–40% порушень. Решта — тільки ручне тестування. Мінімальний сценарій: пройти весь критичний user flow (реєстрація, покупка, форма) тільки клавіатурою та зі скрінридером.

Процес роботи

1. Автоматичний аудит — axe-core, Lighthouse, WAVE — видача 80+ правил.
2. Ручне тестування — NVDA, VoiceOver, клавіатура — 2–3 дні на типовий сайт.
3. Пріоритизація порушень — P1 (блокує використання), P2 (створює складності), P3 (покращення).
4. Виправлення — ітераціями, вбудовуємо перевірки в CI через Playwright + axe.
5. Повторний аудит — закриття всіх P1/P2 перед релізом.
6. Документація та передача — звіт з результатами, рекомендації по підтримці, навчання команди.

Результати та обсяг робіт

• Повний звіт по аудиту з пріоритизацією порушень (PDF/HTML)
• Виправлений код: семантична розмітка, ARIA, клавіатурна навігація
• Інтеграція axe-core в CI/CD для регресійного контролю
• Навчання розробників замовника по роботі з a11y (2-годинна сесія)
• Доступ до репозиторію з прикладами коректних компонентів
• Гарантія відповідності WCAG 2.2 AA на момент здачі

Терміни

Бюджет розраховується індивідуально після аудиту. Зв'яжіться з нами — оцінимо ваш проект за 1 день. Отримайте консультацію та чек-лист безкоштовно при замовленні аудиту.

Досвід та гарантії

Ми займаємося веб-доступністю a11y понад 8 років. Реалізували понад 50 проектів для банків, рітейлу та держсектора. Сертифіковані спеціалісти (IAAP CPACC, WAS). Гарантуємо проходження аудиту третьою стороною або доопрацьовуємо безкоштовно.

Стандарт WCAG 2.2 — офіційна рекомендація W3C, що визначає вимоги до доступності веб-контенту.

Wikipedia: Web Content Accessibility Guidelines Wikipedia: ARIA

— рівні веб-доступності a11y за версією 2.2.

Замовте аудит зараз — отримайте чек-лист та попередню оцінку безкоштовно. Пишіть в Telegram або на пошту — відповімо протягом години.