Підтримка VoiceOver/Screen Reader для сайту за WCAG

Уявіть: ваш сайт завантажується, але користувач із screen reader чує лише «div, div, div». Це не просто поганий UX — це порушення законодавства про доступність. За даними ВОЗ, понад 253 млн людей мають проблеми із зором, і багато з них покладаються на screen reader. Ігнорування доступності — це втрата клієнтів і репутаційні ризики. Згідно з WebAIM, 98% домашніх сторінок містять помилки доступності, а компанії, які впровадили WCAG, відзначають зростання конверсії на 15-20%. Ми допомагаємо виправити такі ситуації, роблячи сайт доступним для незрячих і слабозорих.

Чому підтримка screen reader критична для бізнесу

Screen reader — програма екранного доступу, яка озвучує вміст сторінки та дає можливість навігації з клавіатури. VoiceOver (macOS/iOS), NVDA та JAWS (Windows), TalkBack (Android) — основні інструменти. Стандарт WCAG 2.1 рівень AA зобов'язує забезпечити повну підтримку цих програм. Якщо ваш сайт ігнорує accessibility tree, ви втрачаєте аудиторію та ризикуєте судовими позовами. Понад 70% помилок доступності пов'язані з поганою семантикою. Використання правильних ARIA-атрибутів може скоротити час навігації на 30%.

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

Ми вирішуємо три ключові проблеми:

• Відсутність семантичної розмітки. DOM будується з div без орієнтирів, заголовків і ролей. Screen reader не може побудувати навігацію.
• Некоректні ARIA-атрибути. Часто зустрічаються зайві або неправильні атрибути, які ламають оголошення.
• Динамічний контент у SPA. Зміни DOM без aria-live не озвучуються, користувач залишається в невіданні.

Чому семантична розмітка критична для Screen Reader?

Screen reader використовує Accessibility Tree — представлення сторінки, побудоване з HTML і ARIA-атрибутів. Правильна розмітка — основа доступності.

<!-- Погано -->
<div class="header">
  <div class="nav">
    <div class="nav-item" onclick="go('/home')">Головна</div>
  </div>
</div>

<!-- Добре -->
<header>
  <nav aria-label="Основна навігація">
    <ul>
      <li><a href="/home">Головна</a></li>
    </ul>
  </nav>
</header>

Орієнтири (landmarks) полегшують навігацію: додайте header, nav, main, aside, footer з відповідними ролями. Це скорочує час пошуку інформації на 40%.

Як забезпечити підтримку динамічних оновлень у SPA?

У SPA контент оновлюється без перезавантаження сторінки. Screen reader не дізнається про зміни, якщо не використовувати aria-live. Приклад на React:

function DataSection({ isLoading, data }) {
    return (
        <section>
            <div aria-live="polite" aria-atomic="true" className="sr-only">
                {isLoading ? 'Завантаження даних...' : 'Дані завантажено'}
            </div>
            {isLoading ? (
                <div aria-busy="true">
                    <span className="sr-only">Завантаження...</span>
                    <Spinner aria-hidden="true" />
                </div>
            ) : (
                <ul>
                    {data.map(item => <li key={item.id}>{item.title}</li>)}
                </ul>
            )}
        </section>
    );
}

Також важливо керувати фокусом при навігації. На SPA-переходах переносьте фокус на заголовок сторінки, використовуючи tabIndex={-1} і ref.

Порівняння популярних screen reader

NVDA краще для початкового тестування через безкоштовність і часті оновлення. JAWS незамінний при корпоративних вимогах.

Порівняння критеріїв WCAG за важливістю

Аудит за рівнем AA покриває 90% потреб користувачів screen reader.

Як ми забезпечуємо підтримку screen reader?

Наш підхід включає кілька етапів:

Аудит

Перевіряємо семантику, ARIA, контрастність, навігацію. Використовуємо axe-core + ручне тестування з NVDA та VoiceOver. Також застосовуємо jest-axe для модульного тестування React-компонентів.

Проєктування

Складаємо карту accessibility tree, виправляємо помилки в розмітці.

Реалізація

Виправляємо шаблони, додаємо aria-live для динаміки, aria-describedby для підказок, групуємо поля через fieldset і legend. Використовуємо WAI-ARIA як керівництво.

На одному з проєктів інтернет-магазину ми замінили некоректні ARIA-атрибути на правильні, що скоротило час навігації на 30% за даними тестування з NVDA.

Тестування

Перевіряємо на реальних screen reader, виправляємо баги.

Деплой і документація

Фіксуємо рекомендації для майбутньої підтримки.

Приклад роботи з формами

<label for="email">Email</label>
<input type="email" id="email" name="email"
       aria-describedby="email-hint email-error"
       aria-required="true">
<span id="email-hint" class="hint">Ми не будемо відправляти спам</span>
<span id="email-error" role="alert" aria-live="polite"></span>

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

• Повний аудит доступності за WCAG 2.1 AA.
• Виправлення семантики, ARIA, керування фокусом.
• Налаштування aria-live для динамічного контенту.
• Тестування з NVDA та VoiceOver.
• Технічна документація та передача знань вашій команді.
• Підтримка після впровадження на 1 місяць.

Терміни орієнтовно

• Аудит: 1–2 дні.
• Виправлення на існуючому проєкті: 3–7 днів.
• Тестування та доопрацювання: 2–3 дні.

Терміни залежать від розміру проєкту та складності коду. Оцінюємо індивідуально. Вартість розраховується після аудиту. Наша команда має понад 50 успішних проєктів з доступності.

Типові помилки

• Використання aria-hidden="true" для всього підряд. Приховує елементи від screen reader без потреби.
• Порожні alt. Декоративні зображення повинні мати alt="", але інформативні — осмислений текст.
• Відсутність фокусу при AJAX-завантаженні. Після оновлення списку фокус залишається на старому елементі.

Уникайте цих помилок — і ваш сайт стане доступним для тисяч користувачів. Економія бюджету на підтримку може досягати 20% за рахунок скорочення баг-репортів.

Готові зробити ваш сайт доступним? Замовте аудит доступності — наші сертифіковані спеціалісти проведуть повну перевірку. Зв'яжіться з нами для консультації та отримайте детальну оцінку робіт.

Доступність сайтів: 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 або на пошту — відповімо протягом години.