Чекліст доступності сайту для малого бізнесу та магазинів

Уявіть покупчиню, яка користується скринрідером. Вона знаходить потрібні кросівки, обирає розмір і натискає те, що вважає кнопкою кошика. Скринрідер каже: «кнопка». І все. На сторінці три такі кнопки, і жодна не має назви, тож вона йде, а ви так і не дізнаєтеся чому.

Більшість проблем доступності на сайтах малого бізнесу виглядають саме так: власник їх не бачить, а для покупця це глухий кут. Цей чекліст — для тих, хто має сайт на Shopify, WooCommerce, Wix чи Squarespace, а розробника в штаті не має.

Чи має сайт малого бізнесу бути доступним?

Якщо ви продаєте споживачам у ЄС, найімовірніше, так. Європейський акт про доступність (відкриється в новій вкладці) поширюється на послуги електронної комерції з 28 червня 2025 року. Головний виняток — для мікропідприємств, що надають послуги: компаній, у яких працює менше ніж 10 осіб і річний оборот або підсумок балансу не перевищує 2 млн євро.

Електронна комерція тут означає продаж на відстані, через сайт чи застосунок, «на індивідуальний запит споживача з метою укладення споживчого договору» (стаття 3(30)). Інтернет-магазин чи система бронювання під це визначення підходять. Виняток стосується лише послуг: якщо ви продаєте охоплені товари, наприклад електронні рідери, вимоги до товарів однаково діють (стаття 4(5)). Не рятує й те, що компанія перебуває за межами ЄС: британський магазин, що продає покупцям у Франції, підпадає під дію акта щодо них (стаття 3(4)). Про національні закони й штрафи розповідає наш посібник із Європейського акта про доступність.

Британський Закон про рівність 2010 року (відкриється в новій вкладці) (Equality Act 2010) вимагає розумного пристосування для людей з інвалідністю, але не встановлює технічного стандарту для сайтів. У США роз’яснення Міністерства юстиції від березня 2022 року (відкриється в новій вкладці) кажуть, що компанії, відкриті для публіки, мають робити доступним те, що вони пропонують онлайн, і що такі стандарти, як WCAG, «дають корисні орієнтири». Хоч би що казав закон, покупець, який не може завершити оформлення замовлення, нічого не купить.

Які проблеми доступності трапляються на сайтах найчастіше?

Шість помилок трапляються частіше за всі інші. У WebAIM Million 2026 (відкриється в новій вкладці) — автоматичному скануванні мільйона найпопулярніших головних сторінок у лютому 2026 року — на 95,9% сторінок виявлено порушення WCAG, у середньому 56,1 помилки на сторінку. Найпоширенішою проблемою виявився текст із низьким контрастом: його знайшли на 83,9% головних сторінок.

Ці перевірки ґрунтуються на WCAG, Настановах з доступності вебконтенту; більшість законів посилаються на їхній рівень AA, а про останню версію розповідає наш посібник із WCAG 2.2. Деякі перевірки нижче не може оцінити жоден сканер.

Чи всі можуть прочитати ваш текст і зрозуміти ваші зображення?

Почніть звідси: ці виправлення дешеві, і здебільшого ви можете зробити їх самі в редакторі сайту. Текст має бути достатньо контрастним, зображення, які несуть інформацію, мають мати альтернативний текст, і ніщо не повинно передаватися лише кольором. За даними Colour Blind Awareness (відкриється в новій вкладці), порушення колірного зору має приблизно кожен 12-й чоловік і кожна 200-та жінка.

• Контраст. Звичайному тексту потрібен коефіцієнт контрасту щонайменше 4,5:1 (відкриється в новій вкладці) відносно тла, великому — щонайменше 3:1. Перевірте свої кольори, зокрема текст поверх фото на банерах, у безкоштовному інструменті. Наш посібник із колірного контрасту показує виправлення, які зберігають фірмовий стиль.
• Альтернативний текст для товарів. Опишіть те, що потрібно знати покупцеві: «Темно-синій вовняний светр із високим коміром у рубчик, вигляд спереду» краще, ніж «зображення товару 1». Почніть із десяти найпродаваніших товарів.
• Декоративні зображення. Фоновий завиток має мати порожній альтернативний текст, щоб скринрідери його пропускали. Деякі платформи підставляють у порожнє поле alt назву файлу, тож перевірте свою.
• Лише колір. «Немає в наявності», показане лише сірим зразком кольору, чи обов’язкове поле, позначене лише червоним, дійдуть не до всіх. Подивіться на сторінку крізь фільтр відтінків сірого в телефоні й додайте слово чи значок усюди, де зникає сенс.
• Масштаб. За масштабу браузера 200% текст має збільшуватися, не накладаючись і не обрізаючись, а меню — і далі працювати.
• Мова сторінки. Будь-який безкоштовний інструмент перевірки покаже, що мову сторінки не вказано. Це налаштування теми або зміна одного рядка в шаблоні.

Чи можна користуватися вашим сайтом із клавіатури?

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

• Видимий фокус. Контур має показувати, який елемент активний, і його не повинні закривати закріплена шапка чи значок чату (критерій WCAG 2.2 2.4.11 «Фокус не приховано»). Багато тем прибирають контур заради вигляду; розробник може його повернути.
• Жодних пасток. Відкрийте з клавіатури меню, вибір розміру, спливні вікна й галерею зображень, оберіть щось і спробуйте вийти. Escape має закривати спливні вікна.
• Назви для значків. Кожне посилання-значок і кожна кнопка потребують назви, яку може озвучити скринрідер, наприклад «Кошик, 2 товари». Замініть «Натисніть тут» словами, які кажуть, куди веде посилання.
• Посилання для пропуску й заголовки. В ідеалі перше натискання Tab показує посилання «Перейти до вмісту». В опитуванні користувачів скринрідерів WebAIM 2024 року (відкриється в новій вкладці) 71,6% респондентів сказали, що на довгій сторінці спершу орієнтуються за заголовками, тож використовуйте справжні рівні заголовків, а не жирний текст.
• Області натискання. WCAG 2.2 вимагає областей натискання щонайменше 24 на 24 CSS-пікселі або достатнього вільного місця навколо них (критерій успішності 2.5.8 (відкриється в новій вкладці)).

Чи всі можуть пройти ваші форми, кошик і оформлення замовлення?

На етапі оформлення замовлення проблеми доступності прямо коштують вам грошей, тож перевірте його від початку до кінця, зокрема те, що відбувається в разі помилки. Кожне поле має мати видимий підпис, помилки мають пояснювати проблему словами, а вхід в акаунт не повинен залежати від перевірки пам’яті чи головоломок. Сторінки вашого платіжного провайдера теж враховуються.

• Підписи, а не підказки. Текст-підказка всередині поля зникає, щойно людина починає друкувати, і часто надто блідий, щоб його прочитати. Кожному полю потрібен підпис, який залишається на видноті.
• Повідомлення про помилки. Надішліть форму порожньою. Кожну помилку має бути описано словами («Введіть поштовий індекс, наприклад 01001»), вона має стояти поруч зі своїм полем і озвучуватися скринрідером, а не зводитися до червоної рамки.
• Не питайте двічі. Запропонуйте варіант «Адреса для рахунку збігається з адресою доставки», а не змушуйте знову вводити адресу. У WCAG 2.2 це стало вимогою рівня A — 3.3.7 «Повторне введення».
• Вхід в акаунт. Дозвольте вставляти паролі й одноразові коди та користуватися менеджерами паролів. Заборона вставлення порушує критерій «Доступна автентифікація» (відкриється в новій вкладці) WCAG 2.2, якщо ви не пропонуєте іншого способу увійти.
• CAPTCHA. В опитуванні WebAIM 2024 року користувачі скринрідерів назвали CAPTCHA найпроблемнішим елементом в інтернеті. Якщо потрібен захист від ботів, уникайте візуальних головоломок і завжди пропонуйте невізуальну альтернативу.
• Обмеження в часі. Якщо резерв кошика чи бронювання спливає, попередьте про це й дайте змогу продовжити строк.

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

А банери про cookie, спливні вікна й віджети чату?

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

• Банер про cookie. Чи можна дістатися клавішею Tab до кнопок «прийняти» й «відхилити», прочитати їх за масштабу 200% і потім продовжити з того самого місця?
• Спливні вікна. Фокус має переходити у спливне вікно, залишатися в ньому до закриття, а потім повертатися. Escape має його закривати.
• Віджети чату. Кнопка має мати назву, вікно має відкриватися й закриватися з клавіатури, а на телефоні не повинно перекривати кнопку «Оплатити».
• Каруселі. Для всього, що рухається автоматично довше ніж п’ять секунд, потрібен спосіб це призупинити, зупинити чи приховати (WCAG 2.2 (відкриється в новій вкладці), критерій успішності 2.2.2).
• Вбудовані елементи. Віджети відгуків, карти й інструменти бронювання теж розміщені на вашій сторінці. Про порушення повідомляйте постачальникові.

Чи працюють ваші відео, PDF і меню для всіх?

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

• Субтитри й розшифровки. Виправляйте автоматичні субтитри перед публікацією. Подкастам потрібна текстова версія.
• Текст на картинках. Розміщуйте меню, прайс-листи, таблиці розмірів і години роботи на звичайній вебсторінці. Якщо без PDF не обійтися, експортуйте його з текстового редактора із заголовками й тегами, а не скануйте роздруківку.
• Старі файли. EAA не вимагає виправляти офісні файли й попередньо записані аудіо та відео, опубліковані до 28 червня 2025 року, чи архіви, які ви більше не оновлюєте (стаття 2(4)). Нові файли під дію акта підпадають.

Що можна виправити самому, а коли потрібен розробник чи аудит?

Більшість проблем із контентом ви можете виправити самі в CMS: альтернативний текст, заголовки, текст посилань, кольори, субтитри й чимало підписів полів форм. Проблеми на рівні теми — відсутні стилі фокуса, клавіатурні пастки й нестандартні випадні списки — потребують розробника. Аудит найдоцільніше проводити, коли основне вже виправлено, або перед запуском редизайну.

Яке місце тут має віджет на кшталт нашого? Панель на боці відвідувача, як-от SiteAccessible, дає змогу підвищити контраст, збільшити текст чи ввімкнути лінійку для читання. Це допомагає частині відвідувачів, але не закриває жодного пункту цього чекліста: кнопка без назви так і лишається без назви, а клавіатурна пастка — пасткою. Спершу виправте сайт, а віджет вважайте доповненням.

Як зафіксувати зроблене?

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

Цей другий обов’язок випливає з додатка V до директиви, а формат визначає національний закон. У нашому посібнику зі складання заяви про доступність є шаблон, який можна адаптувати. Далі головне — не кидати:

1. Пройдіть чекліст на трьох ключових сторінках і зробіть скриншот кожної помилки.
2. Цього тижня самі виправте пункти, що стосуються контенту.
3. Поставте розробникові завдання щодо теми й оформлення замовлення, починаючи з найсерйозніших.
4. Перевіряйте кожне виправлення не лише інструментом, а й клавіатурою.
5. Опублікуйте чи оновіть заяву, зазначивши дату.
6. Повторюйте все це щоразу, коли додаєте застосунок, змінюєте тему чи запускаєте новий лендинг.