Доступність сайту на WordPress Привести до WCAG — без заміни теми й переписування сайту
WordPress — найпоширеніший рушій серед сайтів, які ми перевіряємо. Картина зазвичай однакова: тему купили давно, сторінки зібрані в Elementor, зверху стоїть плагін доступності — і сайт усе одно не проходить перевірку. Добра новина в тому, що переробляти все майже ніколи не потрібно: більшість порушень лікується правками в дочірній темі й налаштуваннями вже встановлених плагінів.
Що в WordPress найчастіше ламає доступність
- 01
Тема
Куплені теми малюють кнопки значками без підпису: екранний диктор читає «посилання» і замовкає. Там само зазвичай лежить заборона масштабування в метатезі viewport — сторінку не можна збільшити на телефоні, а це одне з найважчих порушень.
- 02
Конструктори сторінок
Elementor, WPBakery і Divi збирають розмітку з однакових блоків: заголовки виходять не за порядком, а за розміром шрифту. Для екранного диктора структура сторінки при цьому зникає — він не може перейти «до наступного розділу».
- 03
Плагін доступності
Кнопка-чоловічок у кутку змінює розмір тексту й кольори поверх сайту. Сам сайт вона не лагодить, але власнику здається, що питання закрите. Перевіряючий дивиться на код сторінки, а не на віджет.
- 04
Форми
Contact Form 7, WPForms і форми Elementor за замовчуванням ставлять підказку всередину поля замість підпису. Підказка зникає під час введення, і людина з екранним диктором не знає, що саме заповнює.
- 05
Слайдери та спливні вікна
Revolution Slider і попапи забирають фокус клавіатури й не віддають: з клавіатури зі сторінки не вийти. Автопрокрутка без кнопки «стоп» — окреме порушення.
- 06
Медіатека
Зображення завантажують пачками, і поле alt лишається порожнім одразу в сотень файлів. Декоративним воно й не потрібне, а змістовним — обов’язкове, і відрізнити одне від одного може лише людина.
Як ми це виправляємо
- 01
Перевіряємо
Автоматична перевірка плюс руки: прохід сторінкою лише з клавіатури, екранний диктор, збільшення до 200 %. Звіт — списком за важливістю, із зазначенням, де саме в темі чи плагіні лежить причина.
- 02
Правимо в дочірній темі
Зміни йдуть у дочірню тему й окремий файл стилів, а не у файли купленої теми. Тоді оновлення теми не стирає роботу — це головна причина, через яку «полагоджені» сайти за півроку знову не проходять перевірку.
- 03
Налаштовуємо те, що налаштовується
Підписи полів у формах, імена кнопок, порядок заголовків, кнопка «стоп» у слайдера, видимий фокус. Багато що в плагінах вмикається галочкою — просто про неї ніхто не знає.
- 04
Пишемо заяву
Готуємо текст заяви про доступність і ставимо її окремою сторінкою з посиланням у підвалі. Публікує організація від свого імені; те, що лишилося невиправленим, у заяві теж перелічується.
Чого ми не робимо
- Не ставимо плагін доступності замість роботи й не видаємо його за відповідність
- Не обіцяємо «повної відповідності»: частина вимог перевіряється лише людиною й залежить від вашого вмісту
- Не правимо файли купленої теми напряму — перше ж оновлення зітре правки
- Не чіпаємо зміст сторінок без вашої згоди: тексти й зображення ваші
Що залишиться на вашому боці
Доступність — це не разова робота, а звичка. Після наших правок сайт проходить перевірку, але кожна нова сторінка знову залежить від того, як її зібрали. Ми показуємо редактору три речі, яких вистачає у дев’яти випадках із десяти.
- Заповнювати alt у змістовних зображень одразу під час завантаження: потім їх сотні й уже не розібрати
- Ставити заголовки за порядком — H2, під ним H3, а не «той, що більший»
- Називати посилання за змістом: «умови роботи», а не «докладніше» й «читати далі»
- Не публікувати PDF без текстового шару — скан документа недоступний у принципі
Перевірте свій сайт просто зараз
Безкоштовна перевірка читає ту саму розмітку, що й перевіряючий: збільшення сторінки, імена кнопок, підписи полів, порядок заголовків, заява. Вона не замінює ручний аудит, але за десять секунд показує, з чого починати.
Перевірити доступність сайтуЧасті запитання
Чи потрібно міняти тему або робити сайт заново?
Майже ніколи. Траплялися теми, де розмітка настільки своя, що простіше переїхати, але це рідкість. Зазвичай вистачає дочірньої теми, власного файлу стилів і налаштувань плагінів. Якщо виявиться, що переробка дешевша за правки, скажемо про це у звіті, а не після оплати.
У мене Elementor. З ним можна привести сайт до стандарту?
Так. Elementor уміє задавати рівень заголовка, підписи для полів форми й імена для кнопок — просто за замовчуванням цього не робить. Частина правок — у налаштуваннях віджетів, частина — у коді. Найскладніше з готовими шаблонами: у них заголовки розставлені за розміром шрифту, і порядок доводиться збирати заново.
У мене стоїть плагін доступності. Цього достатньо?
Ні. Плагін змінює розмір тексту й кольори поверх сторінки, але не дає імена кнопкам, не лагодить навігацію з клавіатури й не робить форми зрозумілими для екранного диктора. Перевіряючий дивиться на сам сайт. Віджет можна лишити, але вважати його рішенням не можна.
Правки не злетять під час оновлення WordPress або теми?
Саме тому ми й працюємо в дочірній темі: оновлення основної теми її не чіпає. Налаштування плагінів лишаються в базі. Злетіти може тільки те, що зроблено правкою файлів теми напряму — так ми не робимо. Після великих оновлень сайт варто перевірити, це чверть години.
А якщо це магазин на WooCommerce?
Працюємо і з ним, тільки обсяг більший: картка товару, кошик і оформлення замовлення — це окремі шаблони зі своїми формами й кнопками. Найчастіше в магазинах ламаються вибір варіанта товару, фільтри й кроки оформлення. Це видно у звіті, і строки ми називаємо після нього.
Скільки часу займає робота?
Перевірка зі звітом — три-п’ять днів. Виправлення залежать від знахідок: звичайний корпоративний сайт на WordPress укладається в кілька днів, магазин з особистим кабінетом — довше. Точні строки називаємо разом зі звітом, коли видно обсяг.
Скільки це коштує?
Перевірка зі звітом — фіксована сума, вона вказана на сторінці напряму. Виправлення рахуються за годинами після звіту: поки не видно, скільки порушень і наскільки глибоко вони сидять у темі, називати цифру нечесно. Заява про доступність входить у роботу.
Хто публікує заяву про доступність?
Організація від свого імені — ми готуємо текст і сторінку, перелічуємо зроблене й залишені обмеження. Заява потрібна не для галочки: саме з неї користувач дізнається, куди писати, якщо щось не працює, і хто за це відповідає.
Поширені випадки
- Доступність сайту на WixWix закриває частину вимог сам — решту однаково роблять руками
- Доступність сайту на TildaСтандартні блоки вже майже готові — ламається зазвичай Zero Block
- Доступність магазину на WooCommerceЯдро підтягнули — ламаються тема, розширення і шлях до оплати
- Доступність сайту клінікиЗапис на прийом має працювати з клавіатури й екранного диктора
- Доступність сайту закладу освітиСайт, на якому батьки знаходять потрібне без сторонньої допомоги
- Доступність сайту громади та ГОРішення, послуги й звернення — доступні без сторонньої допомоги
- Доступність сайту юриста та бухгалтераКлієнт сам знаходить відповідь і сам подає заявку
- Доступність сайту ресторануМеню, яке можна прочитати, і замовлення, яке можна оформити
- Доступність сайту автосервісуЗапис на ремонт працює з клавіатури й екранного диктора
- Доступність сайту нерухомостіОб’єкт можна знайти й подивитися без сторонньої допомоги
- Доступність туристичного сайтуЗабронювати можна з клавіатури, а не лише мишею
- Заява про доступністьЗаява про доступність: готовий шаблон