Доступність wordpress: повний посібник з wcag 2.2 та eaa 2025

Коли користувач не може прочитати ваш текст, натиснути кнопку або просто зрозуміти, куди веде посилання, він іде. Не тому, що контент поганий. Тому, що сайт із ним не розмовляє.

З червня 2025 року Європейський акт про доступність (EAA) став обов’язковим до виконання. У Німеччині діє свій національний Barrierefreiheitsstärkungsgesetz (BFSG). Штрафи, приписи, втрата аудиторії. Але за юридичним тиском стоїть банальна правда: за даними ВООЗ, ~16% людей у світі, кожен шостий, живуть із тією чи іншою формою інвалідності. Ігнорувати їх, означає втрачати кожного шостого відвідувача.

WordPress тут не виняток і не вирок. CMS дає добру основу, але реальна доступність — це результат усвідомлених дій розробника або власника. У цьому посібнику, покроковий розбір: від структури заголовків до клавіатурної навігації, від вибору теми до автоматичних перевірок. Жодної води, лише те, що можна застосувати вже сьогодні. 💡 Швидкий огляд:

Перевірте сприйнятливість: осмислений alt у кожного зображення, aria-label у іконок, зрозумілий анкор у кожного посилання.
Досягніть контрасту 4.5 до 1 для звичайного тексту та 3 до 1 для великого через WebAIM Contrast Checker.
Вибудуйте ієрархію заголовків: один H1 на сторінці, потім H2 та H3 без пропусків рівнів.
Переконайтеся в доступності з клавіатури: усе, на що можна натиснути мишею, має працювати через Tab та Enter.
Перевірте форми: явна мітка label у кожного поля введення, плейсхолдер не замінює опис.
Запустіть WAVE або Lighthouse: автоматичний аудит знайде більшість проблем за пів хвилини.

Що таке вебдоступність і чому вона обов’язкова у 2026 році

Вебдоступність (web accessibility) — це практика проєктування та розробки сайтів, якими можуть користуватися люди з будь-якими фізичними та когнітивними можливостями. Скринридери для незрячих, навігація з клавіатури для людей із порушеннями моторики, достатній контраст для людей зі слабким зором, субтитри для глухих.

Стандартом де-факто є WCAG 2.2 (Web Content Accessibility Guidelines) від консорціуму W3C. Три рівні: A (мінімальний), AA (цільовий для більшості) та AAA (найвищий). Законодавство ЄС та США вимагає рівня AA.

З 28 червня 2025 року набув чинності European Accessibility Act (директива ЄС 2019/882), він охоплює електронну комерцію, банкінг, транспорт, медіа. У Німеччині паралельно діє BFSG. Штрафи варіюються: у Німеччині до €100 000, у Франції до €250 000. WordPress-сайти комерційних компаній підпадають під регулювання напряму.

Сприйнятливість: як зробити контент зрозумілим для скринридерів

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

Зображення та alt-текст. Кожен тег img зобов’язаний мати атрибут alt. Для змістовних картинок, опис того, що на них відбувається (5-8 слів, без «картинка» та «зображення»). Для декоративних, alt="" (порожній, але присутній). Скринридер пропускає порожній alt і не відволікає користувача.

1 /* functions.php — примусовий alt для мініатюр записів */
2 add_filter('wp_get_attachment_image_attributes', function($attr, $attachment) {
3     if (empty($attr['alt'])) {
4         $attr['alt'] = get_the_title($attachment->ID);
5     }
6     return $attr;
7 }, 10, 2);

Порожні посилання та кнопки. Іконка лупи без тексту, загадка для скринридера. Завжди додавайте aria-label до іконкових кнопок:

1 <button aria-label="Open search">
2     <span class="dashicons dashicons-search"></span>
3 </button>

Title-атрибути. Корисні для додаткового контексту, але не дублюйте в них текст посилання, скринридер озвучить одне й те саме двічі. WordPress за замовчуванням дублює текст посилання в title — це варто вимикати.

Колірний контраст: базові цифри та інструменти перевірки

Недостатній контраст тексту та фону, наймасовіша проблема. За даними WebAIM Million 2025, низький контраст виявлено на 81% просканованих сайтів.

Мінімальні вимоги WCAG 2.2 AA:

Звичайний текст (менше 18pt): контраст 4.5:1
Великий текст (18pt і більше або 14pt bold): контраст 3:1
Іконки та UI-елементи: контраст 3:1

Перевіряється за хвилину через WebAIM Contrast Checker, вводите колір тексту та фону в HEX, отримуєте вердикт: Pass / Fail для кожного рівня.

Типові проблемні зони у WordPress: сірий текст на білому фоні в підвалі, світлі кнопки з білим написом, текст поверх фотографій без затемнювальної підкладки. Вирішується правкою CSS, найчастіше затемненням тексту на пару тонів.

Структура заголовків: ієрархія, яку розуміють усі

Скринридери будують «зміст» сторінки із заголовків, користувач стрибає по H2 та H3, минаючи навігацію. Якщо ієрархію порушено, навігація ламається.

Правила:

Один H1 на сторінку, як правило, заголовок запису
H2 для основних розділів, H3 для підрозділів усередині H2
Заголовки не перескакують: H2 → H4 (минаючи H3), помилка
Не використовуйте h*-теги заради розміру шрифту, для цього є CSS

У WordPress типова проблема, плагіни та теми, що вставляють H2/H3 для своїх блоків (слайдери із заголовком, форма підписки, віджети сайдбару). Рішень три: знайти налаштування тега в плагіні, кастомізувати виведення через фільтр або змінити плагін на акуратніший. Терпіти розбиту ієрархію «бо гарно», не варіант.

Навігація та landmarks: орієнтири для скринридера

HTML5-ландмарки дають скринридеру мапу сторінки. Чотири ключові теги: header для шапки, nav для навігації, main для основного контенту та footer для підвалу. Користувач натискає гарячу клавішу й перестрибує одразу до основного контенту.

1 <header role="banner">
2 <nav role="navigation">
3 <main role="main">
4 <footer role="contentinfo">

Роль role="main" має бути рівно одна на сторінку. Більшість сучасних WordPress-тем використовують ці теги з коробки, перевірте через WAVE: розділ «Structure» покаже всі landmarks.

Ще один обов’язковий елемент, «Skip to Content», невидиме посилання першим елементом сторінки, що дає змогу перестрибнути меню й одразу потрапити до тексту. У WordPress додається фільтром або через плагін доступності.

Форми без бар’єрів

Контактна форма, підписка, оформлення замовлення, кожне поле має бути підписане й досяжне з клавіатури.

*Кожному input, свій label (явний або через aria-label):*

1 <label for="user-email">Email</label>
2 <input id="user-email" name="email" type="email">

Плейсхолдер (placeholder) не замінює мітку, він зникає під час введення й погано зчитується скринрідерами. Використовуйте placeholder лише як підказку формату, а не як назву поля.

Групування: радіокнопки та чекбокси обгортайте в <fieldset> із <legend>. Обов’язкові поля: позначайте текстом «(обов’язково)», а не лише зірочкою чи кольором.

Клавіатурна навігація: ваша сторінка без миші

Деякі користувачі взагалі не використовують мишу, тремор, спастика, параліч. Усе має працювати через Tab, Shift+Tab, Enter, Escape та стрілки.

Швидкий тест: відкрийте сторінку й пройдіть її лише клавішею Tab. Кожен інтерактивний елемент повинен отримувати видимий фокус. Модальне вікно, закриватися по Escape. Випадне меню, розкриватися по Enter.

Типові провали WordPress-сайтів:

Кастомні дропдауни без tabindex та aria-expanded
outline: none у CSS (прибирає індикатор фокусу, не робіть так)
Нескінченна пастка фокусу в попапах
Слайдери, не керовані з клавіатури

Ніколи не вимикайте стандартний :focus-стиль повністю. Якщо не подобається браузерна рамка, замініть на кастомний :focus-visible із контрастним кільцем.

Масштабування: не забороняйте користувачеві збільшувати текст

Чимало мобільних версій WordPress-сайтів блокують pinch-zoom через мета-тег:

1 <!-- НЕПРАВИЛЬНО — так робити не можна -->
2 <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no">
3  
4 <!-- ПРАВИЛЬНО -->
5 <meta name="viewport" content="width=device-width, initial-scale=1">

WCAG 2.2 вимагає можливості збільшення до 200% без втрати контенту та функціональності — це Success Criterion 1.4.4. Перевірте, що під час зуму текст не обрізається й не наїжджає на інші блоки.

Теми WordPress і доступність: на що звертати увагу при виборі

Жодна тема не буває «повністю доступною з коробки», надто багато залежить від контенту та налаштувань. Але стартова база важлива.

При виборі теми звертайте увагу:

В описі зазначено «accessibility ready» — це тег на WordPress.org, означає базову відповідність вимогам
Коректна HTML5-структура з landmarks
Меню навігації, нативний <nav> з <ul>, а не div-конструкція з JS
Наявність :focus-стилів для посилань і кнопок
Відсутність maximum-scale=1.0 у viewport

Стандартні теми WordPress (Twenty Twenty-Four, Twenty Twenty-Five), непогана відправна точка. Комерційні теми з візуальними конструкторами, зона ризику: що більше візуальної «магії», то вищий шанс зламаної доступності.

Інструменти для аудиту: від швидкої перевірки до професійного тестування

WAVE Evaluation Tool. Браузерне розширення WAVE від WebAIM, накладає іконки прямо на сторінку: червоні, помилки, жовті, попередження, зелені, добре. Ідеально для першого аудиту. Показує контраст, alt-тексти, структуру заголовків, ARIA-атрибути.

Google Lighthouse. Вбудований у Chrome DevTools (F12 → Lighthouse → Accessibility). Дає числову оцінку 0-100 і список конкретних елементів для виправлення. Зручний для регулярного моніторингу.

Accessibility Checker (Equalize Digital). Плагін для WordPress, Accessibility Checker перевіряє контент прямо в редакторі (Gutenberg і Classic). Безкоштовна версія сканує запис перед публікацією, Pro додає повний аудит сайту.

WP Accessibility. Ветеран серед плагінів доступності, WP Accessibility від Joe Dolson. Додає skip links, ARIA-landmarks, прибирає дубльовані title-атрибути посилань, лагодить :focus-стилі, прибирає tabindex з форм і target з посилань. Не панацея, але закриває десяток типових проблем одним махом.

One Click Accessibility. Плагін з тулбаром, One Click Accessibility дозволяє користувачеві самому перемкнути контраст, збільшити шрифт, підкреслити посилання. Це не заміна нативної доступності, а додатковий шар для тих, кому потрібні специфічні налаштування.

NVDA. Безкоштовний скринрідер для Windows, NVDA. Пройдіть свій сайт із вимкненим монітором. Почуєте те, що чує незрячий користувач. VoiceOver (вбудований у macOS/iOS), аналог для екосистеми Apple.

Десять кроків до доступного WordPress-сайту

Ось вичавка з усього посібника, контрольний список. Пройдіть його після будь-якого редизайну або запуску нового проєкту.

Пропишіть alt для кожного зображення. У медіатеці WordPress заповнюйте поле «Альтернативний текст». Декоративним картинкам ставте alt="".
Опишіть посилання. Текст посилання має повідомляти, куди воно веде. «Натисніть тут» і «Докладніше», погані анкори. «Завантажити плагін Accessibility Checker», хороший.
Вибудовуйте заголовки за порядком. Один H1, потім H2, всередині H2, H3. Перевірте в WAVE: Structure → Heading Outline.
Доведіть контраст до 4.5:1. Пройдіться WebAIM Contrast Checker за основними кольорами теми: текст, заголовки, кнопки, посилання, підвал.
Увімкніть видимий фокус. Переконайтеся, що :focus не задано як outline: none без заміни. Кастомний фокус робиться через :focus-visible.
Перевірте клавіатурну навігацію. Tab, по всіх посиланнях і кнопках, Enter, активація, Escape, закриття модалок. Застрягли, помилка.
Підпишіть форми. У кожного поля, свій <label>. Обов’язкові поля, з текстовою позначкою. Групи, у <fieldset>.
Не блокуйте zoom. Viewport без maximum-scale і user-scalable=no. Перевірте при двократному збільшенні: контент не має обрізатися.
Додайте skip link. Посилання «Перейти до вмісту» першим елементом <body>. WP Accessibility робить це автоматично.
Запустіть WAVE або Lighthouse. Автоматичний аудит не замінить ручного тестування, але знайде переважну більшість проблем за хвилину.

⁉️🤔 Часті запитання

Чи зобов’язана моя WordPress-сторінка відповідати WCAG?

Якщо ваш сайт представляє бізнес у ЄС, так, із червня 2025 року. Європейський акт про доступність охоплює електронну комерцію, фінанси, транспорт і медіа. У США схожі вимоги: ADA + Section 508 для державних установ та їхніх підрядників. Особистий блог формально не зобов’язаний, але значна частка користувачів з інвалідністю — це сильний комерційний аргумент.

Так, комерційні сайти в ЄС зобов’язані відповідати WCAG 2.2 AA з 28 червня 2025 року згідно з European Accessibility Act. Штрафи встановлюють країни-члени: суми сягають сотень тисяч євро залежно від юрисдикції. У США аналогічні вимоги через ADA та Section 508. Для особистих некомерційних блогів юридичного обов’язку немає, але доступність розширює аудиторію.

Чи достатньо встановити плагін на кшталт One Click Accessibility?

Плагін-тулбар — це допоміжний шар, а не рішення. Він дає змогу користувачеві змінити контраст або розмір шрифту, але не виправить відсутність alt-текстів, порушену ієрархію заголовків чи недоступні з клавіатури попапи. Починайте з нативної доступності в коді та контенті, а тулбар додавайте як фінальний штрих.

Ні. Тулбар (One Click Accessibility, UserWay) — це лише додаткова «надбудова». Він не замінює нативну доступність: не виправляє alt-тексти, ієрархію заголовків, клавіатурні пастки та непідписані поля форм. Починайте з виправлення коду й контенту, тулбар, останній штрих.

Як протестувати сайт без придбання дорогих інструментів?

Повноцінний цикл із безплатних засобів: WAVE Extension (перше швидке сканування) → Google Lighthouse (числова оцінка + список проблем) → ручний прохід із клавіатури (Tab/Enter/Escape) → NVDA на Windows або VoiceOver на Mac (пройти сайт із вимкненим монітором). Цього достатньо для закриття переважної більшості проблем.

Безплатний цикл: WAVE Extension для браузера → Google Lighthouse у Chrome DevTools → ручний прохід із клавіатури → NVDA (Windows) або VoiceOver (macOS/iOS) для тестування скринридером. Ці чотири інструменти закривають 90% задач. Платні сервіси потрібні лише для регулярного аудиту великих проєктів.

Чи можна зробити доступним сайт на візуальному конструкторі (Elementor, WPBakery)?

Можна, але складніше. Конструктори генерують HTML динамічно, і деякі віджети порушують ієрархію заголовків або вставляють div-обгортки без семантики. Перевіряйте кожен блок окремо через WAVE. Elementor Pro з версії 3.15+ додав налаштування aria-атрибутів для віджетів, використовуйте їх.

Можна, але знадобиться більше ручної роботи. Візуальні конструктори схильні до порушення ієрархії заголовків і генерування надлишкових div-обгорток. Перевіряйте результат WAVE після кожної зміни. Elementor Pro (3.15+) дає змогу задавати ARIA-атрибути для віджетів — це частково вирішує проблему.

Як часто потрібно перевіряти доступність сайту?

Після кожного значного оновлення: нова тема, новий плагін, редизайн, велика публікація контенту. Мінімальний цикл, раз на квартал запускати Lighthouse і проходити ключові сторінки з клавіатури. Автоматичний моніторинг через Accessibility Checker Pro виправданий для сайтів із регулярним контентом.

Щонайменше після кожної великої зміни (зміна теми, новий плагін, редизайн) і раз на квартал профілактично. Для сайтів із регулярними публікаціями виправданий автоматичний моніторинг через Accessibility Checker Pro. Скринридерний тест достатньо проводити раз на пів року, якщо кодова база не змінювалася.

Що робити з доступністю WordPress-сайту просто зараз

Не чекайте ідеального моменту. WCAG 2.2 AAA — це мета, а не старт. Почніть із трьох дій сьогодні:

Запустіть WAVE на головній сторінці. Виправте червоні помилки (зазвичай 5-10 штук), вони усувають найгрубіші бар'єри.
Пройдіть сайт із клавіатури. Tab, Tab, Tab. Застрягли, лагодьте. Не видно фокус, додавайте :focus-visible.
Перевірте контраст трьох кольорів: колір тексту, колір кнопок, колір посилань. Доведіть до 4.5:1.

Ці три кроки, пів години роботи, і левова частка результату. Решту, плагіни, скринрідери, ARIA, додавайте поступово.

Якщо сайт комерційний і працює в ЄС, не відкладайте. EAA з 2025 року дає наглядовим органам реальні важелі. Краще зустріти перевірку із зеленим Lighthouse, ніж із листом від регулятора.