Доступність вебу означає створення веб-сайтів, які люди з інвалідністю можуть використовувати ефективно. Це включає людей, які використовують програми для читання з екрану, навігацію лише за допомогою клавіатури, голосове управління, збільшувачі екрану або тих, хто має обмеження зору кольору. У екосистемі WordPress доступність є як юридичною вимогою в багатьох юрисдикціях, так і практичним способом досягти ширшої аудиторії — понад 1 мільярд людей у всьому світі мають якусь форму інвалідності.
У цьому посібнику ми розглядаємо практичні кроки для забезпечення доступності вашого сайту на WordPress, дотримуючись Рекомендацій щодо доступності веб-контенту (WCAG) 2.2 на рівні AA — стандарту, який найчастіше вимагається законами про доступність, включаючи ADA (США), EAA (ЄС) та AODA (Канада).
Розуміння принципів WCAG 2.2
WCAG організовано навколо чотирьох принципів, відомих як POUR:
| Принцип | Що це означає | Приклади WordPress |
|---|---|---|
| Відчутний | Користувачі можуть сприймати контент через зір, слух або дотик | Альтернативний текст для зображень, підписи для відео, достатній контраст кольорів |
| Операбельний | Користувачі можуть навігувати та взаємодіяти з інтерфейсом | Навігація за допомогою клавіатури, пропускні посилання, відсутність пасток для клавіатури |
| Зрозумілий | Користувачі можуть зрозуміти контент і як користуватися інтерфейсом | Чітка мова, послідовна навігація, повідомлення про помилки |
| Стійкий | Контент працює на різних браузерах, пристроях та допоміжних технологіях | Дійсний HTML, правильні ролі ARIA, семантична розмітка |
Вибір доступної теми
HTML-структура та CSS вашої теми WordPress становлять основу доступності вашого сайту. Коли вибираєте тему WordPress, оцініть ці фактори доступності:
- Семантичний HTML: Тема використовує правильні елементи HTML5 (header, nav, main, article, aside, footer) замість загальних div для всього
- Ієрархія заголовків: H1 → H2 → H3 слідує логічному порядку без пропуску рівнів
- Пропускні посилання: Посилання "Пропустити до контенту" присутнє як перший елемент, на який можна зосередитися, що дозволяє користувачам клавіатури обійти навігацію
- Навігація за допомогою клавіатури: Всі інтерактивні елементи (посилання, кнопки, форми) доступні та зручні для використання за допомогою клавіші Tab
- Індикатори фокусу: Зосереджені елементи мають видимий контур або підсвічування (не видалено з outline: none)
- Контраст кольорів: Текст відповідає співвідношенням контрасту WCAG AA (4.5:1 для звичайного тексту, 3:1 для великого тексту)
Теми, позначені "доступними" на WordPress.org, пройшли базову перевірку доступності. Однак ця позначка вказує на початкову точку, а не на повну відповідність WCAG. Серед популярних тем GeneratePress особливо добре закодована з чистим семантичним HTML та правильними ARIA маркерами.
Доступність зображень
Альтернативний текст
Кожне значуще зображення потребує описового альтернативного тексту. WordPress робить це простим — поле альтернативного тексту доступне в Медіа-бібліотеці та при вставці зображень у контент.
| Тип зображення | Підхід до альтернативного тексту | Приклад |
|---|---|---|
| Фото продукту | Описати продукт | "Червона шкіряна сумка через плече з золотою пряжкою, вид спереду" |
| Скріншот | Описати, що показує скріншот | "Панель управління WordPress, що показує сторінку плагінів з 12 активними плагінами" |
| Інфографіка | Підсумувати ключову інформацію | "Діаграма порівняння: функції Elementor та Gutenberg. Elementor має понад 100 віджетів, Gutenberg має понад 90 блоків" |
| Декоративне зображення | Порожній альтернативний текст (alt="") | Фонові візерунки, роздільники, чисто декоративні іконки |
| Графік/діаграма | Описати тенденцію або ключову точку даних | "Лінійний графік, що показує збільшення трафіку веб-сайту на 45% з січня по грудень 2025 року" |
Оптимізація зображень для доступності
- Не використовуйте зображення тексту — використовуйте справжній текст, стилізований за допомогою CSS
- Переконайтеся, що текст, вбудований у зображення, відповідає вимогам до контрасту
- Надайте довгі описи для складних зображень (графіків, діаграм) за допомогою сусіднього абзацу або атрибута longdesc
- Переконайтеся, що зображення мають відповідні розміри, щоб не викликати зміщення макета (CLS)
Навігація за допомогою клавіатури
Багато користувачів навігують веб-сайтами повністю за допомогою
клавіатура—Tab для переходу вперед, Shift+Tab для переходу назад, Enter для активації посилань/кнопок, Space для перемикання чекбоксів і натискання кнопок, а Escape для закриття модальних вікон.
Поширені проблеми доступності клавіатури
- Пастки фокусу: Модальні діалоги, які не дозволяють повертатися до основного контенту (модали повинні утримувати фокус всередині модального вікна, а Escape має їх закривати)
- Відсутні індикатори фокусу: CSS, який видаляє стандартний контур на елементах з фокусом (ніколи не використовуйте *:focus { outline: none } глобально)
- Неінтерактивні елементи з обробниками кліків: Div або span з подіями onClick, які не доступні з клавіатури (використовуйте кнопки або посилання замість цього)
- Випадкові меню, які відкриваються лише при наведенні: Користувачі клавіатури не можуть активувати стани наведення. Меню також повинні відкриватися при фокусі/Enter
- Користувацькі компоненти без ARIA: Вкладки, акордеони та каруселі, створені без належних ролей ARIA та обробників клавіатури
Колір і контраст
WCAG AA вимагає ці мінімальні співвідношення контрасту:
| Елемент | Мінімальне співвідношення | Приклад (Проходить) | Приклад (Не проходить) |
|---|---|---|---|
| Звичайний текст (<18px) | 4.5:1 | #333 на #fff (12.6:1) | #999 на #fff (2.8:1) |
| Великий текст (≥18px або ≥14px жирний) | 3:1 | #555 на #fff (7.4:1) | #aaa на #fff (2.3:1) |
| UI компоненти (кнопки, поля вводу) | 3:1 | Синя кнопка #2563eb (4.6:1) | Світло-синя #93c5fd (1.8:1) |
| Не текстовий контент (іконки, рамки) | 3:1 | Темна іконка на світлому фоні | Світло-сіра іконка на білому |
Використовуйте інструменти, такі як Contrast Checker від WebAIM або розширення браузера axe, щоб перевірити співвідношення контрасту. Не покладайтеся лише на колір для передачі інформації—використовуйте текстові мітки, візерунки або іконки на додаток до кольорового кодування.
Доступність форм
Форми є однією з найважливіших областей для доступності. Використовуючи Gutenberg blocks, Gravity Forms або WPForms:
- Позначте кожне поле: Використовуйте елемент <label>, пов'язаний з кожним полем через атрибут for/id. Текст підказки не є заміною для міток
- Групуйте пов'язані поля: Використовуйте <fieldset> та <legend> для груп пов'язаних полів вводу (наприклад, поля адреси доставки)
- Надавайте повідомлення про помилки: Коли валідація не проходить, вкажіть, яке поле має помилку, і опишіть, як її виправити. Використовуйте aria-describedby, щоб пов'язати повідомлення про помилки з їхніми полями
- Позначте обов'язкові поля: Використовуйте атрибут required і візуально позначайте обов'язкові поля текстом (не лише зірочкою)
- Підтримуйте автозаповнення: Додайте відповідні атрибути автозаповнення (name, email, tel, address-line1), щоб браузери могли автоматично заповнювати дані форми
Доступність контенту
Структура заголовків
Правильна ієрархія заголовків допомагає користувачам з екранними читалками зрозуміти структуру сторінки та навігувати між розділами. Правила:
- Один H1 на сторінку (назва сторінки/посту)
- H2 для основних розділів
- H3 для підрозділів в межах H2
- Ніколи не пропускайте рівні (H2 → H4 без H3 є неправильним)
- Не використовуйте заголовки для візуального стилю—використовуйте CSS класи замість цього
Текст посилань
Уникайте загального тексту посилань, який не має сенсу без контексту:
| Поганий текст посилання | Доступний текст посилання |
|---|---|
| "Натисніть тут" | "Прочитайте посібник з безпеки WordPress" |
| "Читати далі" | "Прочитайте повний огляд Elementor Pro" |
| "Дізнатися більше" | "Дізнайтеся, як оптимізувати оформлення замовлення WooCommerce" |
| "Тут" | "Завантажте звіт про продуктивність" |
Таблиці
Таблиці даних повинні включати:
- <thead> з <th> елементами для заголовків стовпців (з scope="col")
- <th scope="row"> для заголовків рядків
- Елемент <caption>, що описує мету таблиці
- Проста структура—уникайте об'єднаних клітин, коли це можливо, оскільки їх важко інтерпретувати екранним читалкам
Тестування доступності вашого сайту
| Інструмент | Тип | Що він тестує |
|---|---|---|
| axe DevTools | Розширення браузера | Автоматизований WCA |
| Виявлення порушень G | ||
| WAVE | Розширення для браузера / веб | Візуальна оцінка доступності з вбудованими анотаціями |
| Lighthouse | Chrome DevTools | Аудит доступності з оцінками та рекомендаціями |
| Тестування клавіатури | Ручне | Навігація по всьому сайту, використовуючи лише Tab, Enter та Escape |
| Читач екрану | Ручне | Тестування з VoiceOver (Mac), NVDA (Windows) або TalkBack (Android) |
Автоматизовані інструменти виявляють приблизно 30-50% проблем з доступністю. Ручне тестування за допомогою клавіатури та читача екрану є необхідним для виявлення проблем, пов'язаних з взаємодією, які автоматизовані інструменти не можуть виявити.
Плагіни WordPress для доступності
- WP Accessibility: Додає пропускні посилання, виправляє поширені проблеми з доступністю, додає панель інструментів для налаштувань користувача
- One Click Accessibility: Додає панель інструментів доступності на фронтенді (розмір шрифту, контраст, підсвічування посилань)
- Шаблони для початківців з доступністю: Astra та GeneratePress обидва мають сильні основи доступності у своїх базових темах
Примітка: Плагіни накладення доступності (які додають плаваючий віджет з кнопками "виправити") широко критикуються спільнотою доступності. Вони не роблять сайт доступним — вони додають поверхневий шар, який насправді може заважати допоміжним технологіям. Сфокусуйтеся на інтеграції доступності у вашу тему та контент, а не на покладенні на накладення.
Для отримання додаткової інформації зверніться до офіційної документації: Рекомендації WCAG, Команда доступності WordPress.
Поширені запитання
Чи є WordPress доступним "з коробки"?
Ядро WordPress значно покращилося в плані доступності. Адмін-панель в основному навігабельна за допомогою клавіатури, а редактор блоків включає ARIA мітки. Однак доступність вашого сайту сильно залежить від теми та плагінів, які ви використовуєте. Тема з поганою структурою HTML підриває вбудовані функції доступності WordPress.
Чи потрібен мені юридично доступний вебсайт?
У багатьох юрисдикціях — так. ADA (США), Європейський закон про доступність (ЄС, набирає чинності в червні 2025 року), AODA (Канада) та подібні закони вимагають, щоб вебсайти були доступними. Конкретні вимоги залежать від вашого місцезнаходження, типу бізнесу та аудиторії. Консультуйтеся з юридичним фахівцем щодо вимог, специфічних для вашої ситуації.
Чи впливає доступність на SEO?
Так, існує значна перекриття. Правильна структура заголовків, описовий alt текст, семантичний HTML, швидке завантаження сторінок та мобільна дружність приносять користь як доступності, так і SEO. Сайти, які дотримуються рекомендацій WCAG, зазвичай займають кращі позиції, оскільки вони забезпечують фундаментально кращий користувацький досвід. Для найкращих практик SEO дивіться наш контрольний список.
Чи можуть конструктори сторінок створювати доступні вебсайти?
Elementor та інші конструктори сторінок можуть створювати доступний контент, якщо їх правильно використовувати. Ключовим є забезпечення правильної ієрархії заголовків, додавання alt тексту до зображень, використання семантичних віджетів (кнопки замість стилізованих div) та тестування навігації клавіатурою. Сам конструктор не визначає доступність — важливо, як ви його використовуєте.
Яка найпоширеніша помилка доступності на сайтах WordPress?
Відсутність або недостатній alt текст на зображеннях є найчастіше повідомленим порушенням WCAG. Другою найпоширенішою є недостатній колірний контраст. Обидві проблеми легко виправити — вони вимагають уваги та постійної практики, а не технічної експертизи.
Як зробити WooCommerce доступним?
За замовчуванням шаблони WooCommerce мають розумну доступність. Ключові області для перевірки: alt текст зображень продуктів, мітки форм на полях оформлення замовлення, навігабельність кошика та процесу оформлення замовлення за допомогою клавіатури, а також доступні повідомлення про помилки для невдач валідації форм. Використання доступної теми як основи значно зменшує обсяг роботи, специфічної для WooCommerce.
Створюйте доступні сайти WordPress
Почніть з доступної теми. Перегляньте легкі, добре закодовані теми, які пріоритизують семантичний HTML та відповідність WCAG.
Переглянути доступні теми →
