Аудит доступності сайту за WCAG 2.1 AAA — максимальний рівень

Аудит доступності сайту за стандартом WCAG 2.1 (рівень AAA)

Ви помічали, що користувачі зі скринрідерами не можуть заповнити форму на вашому сайті? Або літні клієнти скаржаться на дрібний текст із низьким контрастом? Це типові проблеми, які вирішує аудит доступності за рівнем AAA. Ми знаємо, як виявити такі точки відмови та надати конкретні виправлення.

Ми провели аудит доступності для 50+ сайтів — від державних порталів до банківських додатків. Наш досвід показує: навіть не критичні на перший погляд порушення призводять до втрати до 30% аудиторії з обмеженими можливостями.

WCAG 2.1 AAA — найвищий рівень відповідності стандарту веб-доступності. Він включає 28 додаткових критеріїв поверх AA. Повна відповідність AAA на всьому сайті практично недосяжна і не є метою — W3C прямо вказує це в документі. Використовують AAA для критично важливих розділів: державних послуг, медичних платформ, освітніх сервісів.

Які додаткові вимоги з'являються на рівні AAA?

Сприйняття:

1.2.6 Sign Language (AAA) — синхронний переклад відео жестовою мовою. 1.2.7 Extended Audio Description (AAA) — розширений аудіоопис для відео, де пауз недостатньо для опису дії. 1.4.6 Contrast Enhanced (AAA) — мінімальний контраст 7:1 для звичайного тексту, 4.5:1 для великого:

/* AAA: 7:1 для основного тексту */
body {
    color: #1a1a1a;       /* 17.1:1 на білому ✓ */
    background: #ffffff;
}
.text-secondary {
    color: #595959;       /* 7.0:1 на білому — рівно AAA */
}
/* Visual Presentation (1.4.8) — налаштування блоків тексту */
article {
    max-width: 80ch;
    line-height: 1.5;
}
p + p { margin-top: 1.5em; }
article { text-align: left; }

1.4.9 Images of Text (AAA) — текст не повинен відображатися як зображення (крім логотипів).

Керованість:

2.1.3 Keyboard (No Exception) (AAA) — абсолютно всі функції з клавіатури, без винятків. AA допускає винятки для малювання та подібного — AAA не допускає нічого. 2.2.3 No Timing (AAA) — жодних часових обмежень взагалі. 2.2.6 Timeouts (AAA) — попереджати користувача про тайм-аут за 20+ секунд. 2.3.2 Three Flashes (AAA) — нічого, що блимає частіше 3 разів на секунду. 2.4.8 Location (AAA) — користувач розуміє, де знаходиться в структурі сайту:

<nav aria-label="Breadcrumb">
    <ol>
        <li><a href="/">Головна</a></li>
        <li><a href="/products">Продукти</a></li>
        <li aria-current="page">Смартфони</li>
    </ol>
</nav>

2.4.9 Link Purpose — Link Only (AAA) — призначення кожного посилання зрозуміле з його тексту без контексту:

<!-- Порушує AAA -->
<a href="/read-more">Детальніше</a>

<!-- Відповідає AAA -->
<a href="/products/iphone-15">Смартфон iPhone 15 Pro — детальніше</a>

Зрозумілість:

3.1.3 Unusual Words (AAA) — механізм пояснення незвичайних слів та жаргону:

<abbr title="Єдиний податок на поставлений дохід">ЕНВД</abbr>
<p>Використано метод KPI оцінки.</p>

3.1.4 Abbreviations (AAA) — розшифровка абревіатур через <abbr>. 3.1.5 Reading Level (AAA) — спрощена версія контенту, якщо рівень вище 9-го класу:

<details>
    <summary>Спрощене пояснення</summary>
    <p>Говорячи простими словами: ...</p>
</details>

3.2.5 Change on Request (AAA) — нічого не змінюється без явної дії користувача. Жодних автоматичних редиректів, автоматичних оновлень контенту без запиту. 3.3.4 Error Prevention (All) (AAA) — для будь-яких відправок форм: можливість перевірити, виправити або скасувати.

Коли дійсно потрібен рівень AAA?

• Державні портали та e-government сервіси
• Медичні інформаційні системи
• Освітні платформи (СДПО, дистанційне навчання)
• Фінансові сервіси з літньою аудиторією
• Будь-який сервіс, де виключення частини користувачів неприпустиме за законом

Методологія AAA-аудиту

AAA-аудит включає все з AA плюс:

1. Відеоконтент — субтитри, аудіодескрипція, жестова мова (за наявності)
2. Ручне тестування з користувачами — залучення людей із різними порушеннями
3. Когнітивна доступність — перевірка читабельності тексту (Flesch-Kincaid, Fog Index)
4. Тест у режимі монохромного відображення — Windows High Contrast Mode

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

• Детальний звіт із зазначенням кожного порушення WCAG 2.1 AAA та його пріоритету
• Дорожня карта виправлень з оцінкою трудозатрат по кожному пункту
• Рекомендації щодо виправлення з готовими прикладами коду (HTML/CSS/JS)
• Повторна перевірка (регрес) після внесення змін
• Консультація з вашими розробниками щодо складних сценаріїв
• Доступ до нашої бази знань з веб-доступності

Строк проведення аудиту

Наші спеціалісти сертифіковані та мають понад 7 років досвіду в галузі веб-доступності. Ми гарантуємо якість аудиту та надаємо підтримку на всіх етапах виправлення. Зв'яжіться з нами, щоб обговорити ваш проєкт і отримати консультацію щодо обсягу робіт.

W3C Web Content Accessibility Guidelines 2.1 — https://www.w3.org/TR/WCAG21/

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