Підтримка 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% за рахунок скорочення баг-репортів.

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