10 найпоширеніших помилок доступності (і як їх виправити)
96.3% сайтів мають помилки WCAG. Розбираємо 10 найчастіших: відсутній alt-text, низький контраст, форми без label та ін. Код і виправлення для кожної.
Андрій Вдовин
Доступність вебсайту — це не лише юридична вимога, а й базова повага до людей з інвалідністю. За даними WHO, понад 1,3 мільярда людей у світі мають певну форму інвалідності. Проте більшість сайтів досі містять одні й ті ж критичні помилки, які унеможливлюють їх використання. Нижче — 10 найпоширеніших порушень, які виявляє автоматичний аудит InclusiveWeb, та як їх виправити.
1. Відсутній alt-текст на зображеннях
Зображення без атрибута alt або з незмістовним значенням на кшталт alt="image123.jpg" не передають жодної інформації незрячим користувачам. Це одне з найпоширеніших порушень у вебі.
Чому це проблема: Screen reader VoiceOver або NVDA прочитає назву файлу замість опису зображення: «image123.jpg, зображення». Користувач не зрозуміє, що зображено. Якщо зображення є кнопкою або посиланням — дія стає повністю незрозумілою.
Неправильно
<img src="/hero.jpg">
<img src="/logo.png" alt="image123.jpg">
<img src="/banner.webp" alt=""/>Правильно
{/* Інформаційне зображення — описовий alt */}
<img src="/hero.jpg" alt="Команда InclusiveWeb проводить аудит сайту" />
{/* Декоративне зображення — порожній alt */}
<img src="/decorative-wave.svg" alt="" role="presentation" />Як виправити: Для кожного смислового зображення напишіть короткий опис того, що зображено та навіщо воно тут. Для декоративних зображень використовуйте alt="" — це сигналізує screen reader пропустити елемент.
2. Низький контраст тексту
Текст із співвідношенням контрасту менше 4.5:1 для звичайного або 3:1 для великого тексту (18px+ або 14px+ жирний) важко читати людям з порушеннями зору, катарактою або дальтонізмом. Популярна помилка — сірий текст на білому фоні або світло-блакитний на синьому.
Чому це проблема: До 8% чоловіків і 0.5% жінок мають дальтонізм. Люди похилого віку часто мають знижену чутливість до контрасту. Низький контраст унеможливлює читання навіть при збільшенні шрифту.
Неправильно
/* Контраст ~2.3:1 — не відповідає WCAG AA */
.subtitle {
color: #9CA3AF; /* сірий */
background: #FFFFFF; /* білий */
}
/* Контраст ~2.1:1 — не відповідає WCAG AA */
.badge {
color: #60A5FA; /* світло-блакитний */
background: #EFF6FF; /* майже білий */
}Правильно
/* Контраст 7:1 — відповідає WCAG AAA */
.subtitle {
color: #374151; /* темно-сірий */
background: #FFFFFF;
}
/* Контраст 4.6:1 — відповідає WCAG AA */
.badge {
color: #1D4ED8; /* темно-синій */
background: #EFF6FF;
}Як виправити: Перевіряйте контраст у WebAIM Contrast Checker або за допомогою DevTools браузера. InclusiveWeb Audit автоматично виявляє всі елементи з недостатнім контрастом та пропонує конкретні значення кольорів для виправлення.
3. Форми без підписів (label)
Поля форм без явного елемента <label> залишають незрячих та людей із когнітивними порушеннями без розуміння того, що потрібно ввести. Placeholder-текст — не замінник label: він зникає при введенні і не зчитується як підпис.
Чому це проблема: Screen reader оголосить лише «редагувати текст» без жодного контексту. Користувач з NVDA чи VoiceOver не зможе зрозуміти, ім'я це поле, email чи щось інше.
Неправильно
<input type="email" placeholder="Введіть ваш email" />
{/* aria-label є, але не пов'язаний через for/id */}
<p>Email</p>
<input type="email" />Правильно
{/* Явний label через for/htmlFor */}
<label htmlFor="email">Email-адреса</label>
<input type="email" id="email" placeholder="[email protected]" />
{/* Або aria-label для прихованого label */}
<input type="search" aria-label="Пошук по сайту" placeholder="Пошук..." />Як виправити: Завжди пов'язуйте <label for="..."> із відповідним id поля. Якщо дизайн не передбачає видимого підпису, використовуйте aria-label або aria-labelledby.
4. Відсутній атрибут lang на тегу html
Без атрибута lang на тегу <html> браузер та допоміжні технології не знають, якою мовою написаний контент сторінки. Це критично для синтезаторів мовлення.
Чому це проблема: Screen reader використовуватиме правила вимови мови за замовчуванням (найчастіше англійської) для читання українського тексту. Результат — повністю незрозуміла вимова, яка унеможливлює сприйняття контенту на слух.
Неправильно
<html>
<head><title>Мій сайт</title></head>
<body>...</body>
</html>Правильно
<html lang="uk">
<head><title>Мій сайт</title></head>
<body>
{/* Якщо є вставка іншою мовою — вкажіть lang на елементі */}
<p lang="en">This section is in English.</p>
</body>
</html>Як виправити: Додайте lang="uk" для українських сайтів (або відповідний BCP 47 код для вашої мови). Для мультимовних ділянок додайте lang безпосередньо на відповідний елемент.
5. Порушена ієрархія заголовків
Пропускання рівнів заголовків (наприклад, H1 → H3 без H2) або використання заголовків виключно для стилізації (замість семантичного значення) руйнує структуру документа та навігацію для незрячих користувачів.
Чому це проблема: Незрячі користувачі навігують сторінкою через список заголовків (клавіша H у NVDA/JAWS). Якщо структура порушена, вони не можуть зрозуміти логіку документа та знайти потрібну секцію.
Неправильно
<h1>Наші послуги</h1>
{/* H2 пропущено! */}
<h3>Аудит доступності</h3>
<h4>Що включено</h4>
{/* H2 використано лише для великого шрифту */}
<h2>Детальніше</h2>Правильно
<h1>Наші послуги</h1>
<h2>Аудит доступності</h2>
<h3>Що включено</h3>
<h3>Вартість</h3>
<h2>Технічна підтримка</h2>
<h3>SLA та умови</h3>Як виправити: Перегляньте структуру сторінки у вигляді outline. Не пропускайте рівні. Якщо вам потрібен великий текст без семантичного значення — використовуйте CSS-класи, а не теги заголовків.
6. Кнопки без доступного імені
Кнопки, які містять лише іконку або SVG без текстового альтернативу, не мають доступного імені. Screen reader не може повідомити користувачу, що робить ця кнопка.
Чому це проблема: VoiceOver оголосить таку кнопку просто як «кнопка» без будь-якої додаткової інформації. Якщо на сторінці є три такі кнопки поспіль, користувач не зможе розрізнити їх призначення.
Неправильно
<button>
<img src="/icons/search.svg" />
</button>
<button>
<svg>...</svg>
</button>Правильно
{/* Варіант 1: aria-label */}
<button aria-label="Пошук по сайту">
<img src="/icons/search.svg" alt="" />
</button>
{/* Варіант 2: Прихований текст */}
<button>
<svg aria-hidden="true">...</svg>
<span className="sr-only">Відкрити меню</span>
</button>Як виправити: Додайте aria-label з описом дії кнопки, або приховайте іконку від screen reader (aria-hidden="true") і додайте текст із класом sr-only (видимий лише для screen reader).
7. Недоступна клавіатурна навігація
Використання <div> або <span> з обробником onClick замість семантичних елементів <button> або <a> унеможливлює навігацію клавіатурою. Такі елементи не отримують фокус через Tab і не активуються через Enter/Space.
Чому це проблема: Люди з моторними порушеннями, що не використовують мишу, не зможуть взаємодіяти з інтерактивними елементами. Screen reader не ідентифікує <div> як кнопку і не повідомить про можливість взаємодії.
Неправильно
<div onClick={handleSubmit} className="btn">
Надіслати
</div>
<span onClick={openDropdown}>
Вибрати категорію ▼
</span>Правильно
<button onClick={handleSubmit} className="btn">
Надіслати
</button>
{/* Або з повним ARIA для кастомного dropdown */}
<button
aria-haspopup="listbox"
aria-expanded={isOpen}
onClick={openDropdown}
>
Вибрати категорію
</button>Як виправити: Замінюйте <div onClick> на семантичні <button> та <a>. Для складних UI-компонентів (dropdown, modal, tabs) дотримуйтесь ARIA Authoring Practices Guide від W3C.
8. Відсутній видимий індикатор фокусу
Прибирання стандартного outline браузера через CSS без надання альтернативного стилю фокусу — дуже поширена помилка дизайнерів, які вважають обведення «некрасивим». Але без нього клавіатурні користувачі не бачать, де знаходиться фокус.
Чому це проблема: Користувачі, що навігують клавіатурою (люди з моторними порушеннями, літні люди, користувачі без мишки), не знають, який елемент активний. Це еквівалентно роботі з мишею, коли курсор невидимий.
Неправильно
/* Глобальне прибирання outline — критична помилка */
* {
outline: none;
}
button:focus {
outline: 0; /* Фокус невидимий */
}Правильно
/* Приховуємо лише для мишки, залишаємо для клавіатури */
button:focus:not(:focus-visible) {
outline: none;
}
button:focus-visible {
outline: 3px solid #2563EB;
outline-offset: 2px;
border-radius: 4px;
}Як виправити: Ніколи не прибирайте outline глобально. Використовуйте :focus-visible для показу стилізованого фокусу лише при клавіатурній навігації, що задовольняє і дизайнерів, і вимоги доступності.
9. Автозапуск відео та аудіо
Медіа-контент (відео або аудіо), що запускається автоматично при завантаженні сторінки та триває більше 3 секунд, є порушенням WCAG. Особливо критично, якщо немає легкодоступного механізму зупинки.
Чому це проблема: Автозапуск аудіо заглушає голос screen reader. Незрячі користувачі не можуть почути, що читає програма, і не завжди можуть швидко знайти кнопку зупинки. Для людей з когнітивними порушеннями або ПТСР несподіваний звук може бути дезорієнтуючим.
Неправильно
<video autoPlay src="/promo.mp4">
Ваш браузер не підтримує відео.
</video>
<audio autoPlay src="/background-music.mp3" />Правильно
{/* autoPlay лише з muted і без звуку — допустимо для фонових відео */}
<video autoPlay muted loop playsInline aria-hidden="true">
<source src="/promo.mp4" type="video/mp4" />
</video>
{/* Відео зі звуком — лише за взаємодією користувача */}
<video controls src="/presentation.mp4">
<track kind="captions" src="/captions.vtt" srclang="uk" label="Українська" />
</video>Як виправити: Не використовуйте autoPlay для медіа зі звуком. Якщо автозапуск необхідний для фонового відео — глушіть звук (muted). Завжди надавайте субтитри та доступні елементи керування.
10. Порожні або неінформативні посилання
Посилання з текстом «Читати далі», «Тут», «Клікнути» або порожнім текстом не мають сенсу поза контекстом. Для незрячих користувачів, які переглядають список посилань, це набір ідентичних елементів без будь-якої корисної інформації.
Чому це проблема: NVDA та JAWS дозволяють навігувати між усіма посиланнями на сторінці клавішею Tab або переглядати їх у списку. Якщо всі посилання звучать однаково («читати далі, читати далі, читати далі»), навігація стає неможливою.
Неправильно
<a href="/blog/post-1">Читати далі</a>
<a href="/blog/post-2">Читати далі</a>
<a href="/blog/post-3">Читати далі</a>
{/* Порожнє посилання — повністю недоступне */}
<a href="/home"></a>Правильно
{/* Варіант 1: Описовий текст */}
<a href="/blog/post-1">
Читати далі про 10 помилок доступності
</a>
{/* Варіант 2: Видимий текст + прихований уточнюючий */}
<a href="/blog/post-1">
Читати далі
<span className="sr-only"> про 10 помилок доступності</span>
</a>
{/* Варіант 3: aria-label */}
<a href="/blog/post-1" aria-label="Читати статтю: 10 помилок доступності">
Читати далі
</a>Як виправити: Текст посилання повинен чітко описувати призначення — або самостійно, або разом із найближчим контекстом (aria-labelledby). Уникайте шаблонних фраз «тут», «клік», «детальніше» без уточнення.
Як знайти ці помилки автоматично
Ручна перевірка кожної сторінки — тривалий і затратний процес. InclusiveWeb Audit автоматично сканує ваш сайт та виявляє всі 10 перерахованих типів помилок (і ще десятки інших), формуючи детальний звіт із пріоритетами та конкретними рекомендаціями щодо виправлення.
Порада
Автоматичні інструменти виявляють приблизно 30-40% проблем доступності. Для повного аудиту рекомендується поєднувати автоматичне сканування з ручною перевіркою та тестуванням зі screen reader.
Запустіть безкоштовний аудит вашого сайту вже зараз і отримайте детальний звіт із усіма порушеннями WCAG:
Запустити безкоштовний аудитЧасті питання
Скільки часу потрібно, щоб виправити всі 10 помилок?
Залежить від розміру та технічного стану сайту. Прості виправлення (додати alt-текст, lang, label) займають 1-2 дні роботи розробника. Системні проблеми (клавіатурна навігація, ARIA для складних компонентів) можуть потребувати кількох тижнів. InclusiveWeb надає пріоритизований план дій, щоб ви спочатку виправили найкритичніше.
Чи достатньо виправити лише ці 10 помилок для відповідності WCAG?
Ці 10 помилок є найпоширенішими, але WCAG 2.1 Level AA містить 50+ критеріїв успіху. Виправлення лише цих помилок значно покращить доступність, але не гарантує повну відповідність стандарту. Рекомендується провести повний аудит для комплексної оцінки.
Які інструменти можна використати для перевірки доступності безкоштовно?
Безкоштовні інструменти: axe DevTools (розширення для Chrome/Firefox), WAVE (WebAIM), Lighthouse в Chrome DevTools, NVDA (безкоштовний screen reader для Windows). Однак вони виявляють лише частину проблем. InclusiveWeb Audit поєднує автоматичне сканування з ширшим охопленням правил та пропонує конкретні рекомендації.
Чи обов'язкові ці виправлення для українських сайтів?
Україна імплементує Директиву ЄС 2016/2102 про доступність вебсайтів та мобільних додатків для державного сектору. Крім юридичних вимог, доступність покращує SEO, збільшує аудиторію та знижує ризик судових позовів від міжнародних клієнтів, особливо з США (ADA) та ЄС (EAA).