Доступний інтернет-магазин — це не головна сторінка з достатнім контрастом. Покупець має знайти товар, розібратися в характеристиках, вибрати варіант, виправити помилку, пройти автентифікацію, оплатити й отримати підтвердження без миші, ідеального зору та здогадок.
Коротка відповідь
Аудит вебдоступності інтернет-магазину починається не зі сканера. Спершу визначте ринки, юридичні особи, цифрові послуги та національні вимоги. Потім перевірте репрезентативні сценарії від пошуку до підтвердження замовлення: автоматично, лише з клавіатури, зі збільшенням і переформатуванням, за допомогою скринрідера та вручну. За можливості долучіть людей з інвалідністю. Першими усувайте бар’єри, що зупиняють покупку, а не ті, які найбільше псують умовний бал.
Директива (ЄС) 2019/882, або Європейський акт про доступність, застосовується через законодавство держав-членів із 28 червня 2025 року. Послуги електронної торгівлі прямо входять до її сфери. Для охоплених послуг інформація та функції мають бути придатними для сприйняття, керованими, зрозумілими й надійними, зокрема під час ідентифікації, перевірки безпеки та оплати.
З’ясуйте сферу EAA без небезпечних спрощень
Створіть реєстр застосовності: продавець, країни споживачів, сайт і застосунок, оформлення замовлення, платіжні сервіси та постачальники ідентифікації, підтримка, товари чи послуги, національний акт, відповідальна людина і дата наступного перегляду. Для транскордонного магазину базові вимоги гармонізовані, але нагляд, процедура і практичні деталі залежать від конкретної держави.
Директива звільняє від частини вимог мікропідприємства, які надають послуги. Проте фраза «ми малий бізнес» нічого не доводить: визначення враховує чисельність, фінансові показники та пов’язаність компаній, а остаточний висновок залежить від національної імплементації. «Фундаментальна зміна» та «непропорційний тягар» теж не є автоматичною відмовкою — вони передбачають обґрунтовану оцінку. Юридичну сферу має підтвердити профільний консультант.
Комерційний сенс ширший за юридичний обов’язок. Чіткі помилки, помітний фокус, керування клавіатурою, читабельний текст і передбачувана оплата допомагають не лише постійним користувачам допоміжних технологій. Вони потрібні людям після травми, старшим покупцям, користувачам на малому екрані та всім, хто оформлює замовлення поспіхом.
Не змішуйте правовий висновок із технічним орієнтиром
Директива формулює функціональні вимоги. Шлях підтвердження відповідності визначають національне право, застосовні гармонізовані стандарти чи технічні специфікації, договори й галузеві роз’яснення. WCAG 2.2 дає міжнародно визнані критерії та є сильним інженерним орієнтиром. Водночас вислів «ми перевірили WCAG 2.2 AA» не дорівнює автоматичній заяві «ми виконали всі обов’язки EAA».
Перед роботою зафіксуйте паспорт аудиту: межі, версію стандарту, цільовий рівень, браузери, пристрої, скринрідери, мови, тестові облікові записи, сторонні сервіси, метод вибірки, відомі винятки, формат доказів і дату повторної перевірки. Якщо без платіжного iframe або CAPTCHA неможливо завершити замовлення, напис «це сторонній сервіс» не прибирає бар’єр для покупця. Потрібні власник ескалації та доступний запасний шлях.
Перевіряйте сценарії та стани, а не зручні сторінки
Автоматичний тест головної сторінки майже нічого не каже про покупку. У вибірку варто включити пошук, категорію та фільтри, картку з варіантами, кошик, гостьове й авторизоване оформлення, промокод, доставку, платіжне підтвердження, сторінку успіху, скасування або повернення та звернення до підтримки. Відтворіть відсутній товар, помилку в полі, відхилену оплату, завершення сесії та завантаження.
Виберіть контент, де проявляються реальні відмінності: простий і конфігурований товар, відео або PDF-інструкція, довгий український текст, акційна ціна, сторонній продавець, сторінка, яку збирає редактор у CMS. Тестуйте принаймні мобільний і десктопний варіант. Мобільний застосунок потребує окремого аудиту — результат адаптивного сайту на нього не переноситься.
12 перевірок доступності інтернет-магазину
| Перевірка | Що зробити | Типовий бар’єр |
|---|---|---|
| 1. Клавіатура | Пройдіть сценарій Tab, Shift+Tab, Enter, Space, стрілками та Escape | Фільтр, варіант товару, модальне вікно або платіжне поле недоступні |
| 2. Фокус | Стежте за видимістю, порядком, входом у діалог і поверненням | Фокус ховається під липким блоком або губиться після оновлення кошика |
| 3. Семантика | Перевірте заголовки, області, підписи, назви, ролі, стани й значення | Візуально правильний нестандартний елемент нічого не повідомляє скринрідеру |
| 4. Контраст | Оцініть текст, фокус, іконки, помилки, поля й вибрані стани | Основний текст читабельний, а checkbox або повідомлення про помилку — ні |
| 5. Збільшення | Збільште текст і сторінку, звузьте область перегляду, змініть орієнтацію | Ціна, кнопка закриття або підсумок замовлення перекриваються |
| 6. Нетекстовий зміст | Перегляньте фото, схеми, іконки, відео, аудіо та PDF | Колір або зображення передає важливу характеристику без еквівалента |
| 7. Товарні дані | Перевірте характеристики доступності, сумісність, безпеку й сервіс | Магазин отримав важливі дані від виробника, але не показав їх |
| 8. Пошук і фільтри | Керуйте підказками, сортуванням, фільтрами й порожньою видачею без зору | Кількість результатів змінилася мовчки, активний фільтр не визначається |
| 9. Форми | Надішліть порожню, хибну та виправлену форму адреси й оплати | Є червона рамка, але немає тексту, зв’язку з полем або шляху виправлення |
| 10. Вхід і оплата | Протестуйте вхід, MFA, альтернативу CAPTCHA, цифровий гаманець, картку та 3-D Secure | Перевірка безпеки стає глухим кутом для клавіатури чи скринрідера |
| 11. Динамічні зміни | Викличте оновлення ціни, запасу, кошика, валідації та завантаження | Візуальне сповіщення є, а допоміжна технологія його не отримує |
| 12. Зміст і допомога | Перевірте простоту інструкцій, умови, чат, службу підтримки й альтернативні канали | Інтерфейс керований, але умови незрозумілі або допомога недоступна |
Автоматизуйте те, що справді можна перевірити правилами: відсутні назви, некоректні зв’язки, частину контрасту, мову документа, дублікати ID та вимоги до компонентів. Запускайте ці тести під час розробки й у CI. Але W3C прямо зазначає: жоден інструмент самостійно не визначає відповідність сайту стандартам доступності. Нуль автоматичних помилок — не сертифікат.
Здійсніть реальну покупку з допоміжною технологією
Спершу відкладіть мишу та пройдіть усе клавіатурою. Вголос фіксуйте, куди переміщується фокус і чи можна передбачити наступну дію. Потім використайте хоча б одну релевантну пару «скринрідер + браузер». Не дивіться на інтерфейс: слухайте, чи оголошуються назва й стан варіанта, зміна ціни, помилка, новий підсумок та успішне замовлення.
Тестової оплати успішною карткою недостатньо. Відтворіть відмову банку, додаткову автентифікацію, зміну доставки, прострочений промокод і зміну вартості кошика. Безпечно зберігайте введені дані, називайте помилку текстом, пов’язуйте її з полем, коректно спрямовуйте або повідомляйте фокус і пояснюйте шлях відновлення. Перед фінансовим зобов’язанням покупець повинен мати можливість переглянути й виправити замовлення.
Мова — частина доступності. Вкажіть коректну мову сторінки, позначайте справжні мовні перемикання, локалізуйте назви елементів і помилки, перевіряйте перенесення тексту після збільшення. Російський підпис усередині українського оформлення — не лише редакційний недолік: скринрідер може змінити вимову, а дія стане менш зрозумілою.
Ставте пріоритет за зірваним завданням і повторюваністю
Для кожної знахідки запишіть відтворюваний шлях, очікуваний і фактичний результат, компонент, конфігурацію, критерій, доказ, власника, виправлення та статус повторного тесту. Один загальний «рейтинг доступності» приховує головне: двадцять дрібних зауважень можуть бути менш небезпечними, ніж одна клавіатурна пастка, яка зупиняє всі оплати.
- P0 — покупку заблоковано: неможливо вибрати, увійти, заплатити або виправити помилку. Потрібні негайний безпечний обхідний шлях і ремонт.
- P1 — суттєва втрата інформації чи контролю: поширений сценарій стає надмірно складним або ненадійним.
- P2 — локальний бар’єр: завдання виконується, але потребує зайвих зусиль чи обхідного способу.
- P3 — покращення: корисна робота для зручності й підтримуваності з обмеженим негайним впливом.
Помножте серйозність на повторюваність. Дефект у спільному полі, модальному вікні, компоненті ціни або дизайн-токені поширюється на тисячі станів і кілька мов. Виправлення основи майже завжди ефективніше за латання окремих сторінок.
Зробіть доступність властивістю кожного релізу
Документуйте в дизайн-системі всі стани: звичайний, hover, focus, disabled, selected, error, loading, success та empty. Починайте із семантичного HTML; ARIA додавайте тоді, коли нативний елемент справді не виражає потрібної взаємодії. До критеріїв приймання компонента внесіть клавіатуру, оголошення змін, збільшення, touch target, reduced motion і вимоги до контенту.
Під час перевірки змін запускайте lint і браузерні тести для компонентів та критичних маршрутів. Для релізу тримайте короткий ручний набір із клавіатурою та збільшенням. За графіком і перед великою зміною оформлення повторюйте повні сценарії зі скринрідером та користувачами з інвалідністю. Вимірюйте частку бар’єрів, що потрапили у робочу версію, час виправлення, повторення за компонентом і виконання критичних завдань.
Не забудьте про постачальників. Запитуйте у провайдерів платежів, чату, відгуків, cookie consent та ідентифікації актуальну документацію, тестові конфігурації, відомі обмеження, контакт для ескалації та сповіщення про зміни. Для незамінної інтеграції потрібен план заміни або доступний канал допомоги.
План виправлень на 30 днів
Не витрачайте перший тиждень на віджет доступності з обіцянкою миттєво виправити сайт. Накладний інструмент у браузері не відновлює надійно семантику, клавіатурну логіку, сторонню оплату, якість змісту та відповідальність команди. Мета місяця — прибрати справжні бар’єри й створити відтворювані докази.
Чесно описуйте межі й оновлюйте докази
Аудит — це датований результат для визначеної вибірки та конфігурації, а не довічний сертифікат. Новий товар, банер, контент із CMS, реліз платіжного сервісу або A/B-тест завтра може створити новий бар’єр. Зберігайте версію, дату, тестові матеріали, відповідальних і графік повторних перевірок; публікуйте лише ті твердження, які підтверджені.
Для охоплених послуг директива передбачає доступну інформацію про те, як послуга виконує вимоги. Формат і деталі залежать від національної імплементації. Аудит має дати фактичну основу: опис послуги, застосовні вимоги, спосіб їх виконання, відомі обмеження, канал звернення й процес оновлення. Публічну заяву перевіряє юридично відповідальна сторона.
У дослідженні WebAIM Million 2026 автоматичний аналіз виявив у середньому 56,1 помилки на головній сторінці мільйона популярних сайтів. Автори водночас наголошують: відсутність виявлених помилок не доводить доступність. Це сигнал про поширені регресії, а не планка для вашого магазину. Корисна мета інша: люди виконують важливі завдання, а команда вміє довести, підтримувати й покращувати результат.
Поширені запитання
Чи стосується Європейський акт про доступність українського інтернет-магазину?
Може стосуватися, якщо магазин пропонує послугу споживачам у ЄС. Важливі продавець, ринок, характер послуги, можливі винятки та право конкретної держави. Сферу підтверджує юрист.
Чи достатньо WCAG 2.2 AA для відповідності EAA?
Це сильний технічний орієнтир, але не автоматичний правовий висновок. Потрібно врахувати національні норми, стандарти, сторонні сервіси, інформаційні обов’язки та процес підтримки.
Чи може сканер сертифікувати доступність магазину?
Ні. Автоматизація бачить лише частину проблем. Клавіатуру, скринрідер, збільшення, зрозумілість, виправлення помилок і повні сценарії оцінює людина.
З чого почати аудит доступності сайту?
Із найціннішого повного маршруту: знайти товар, оформити успішну покупку та відновитися після невдалої оплати. Спершу виправляйте блокери у спільних компонентах.
Як часто повторювати перевірку?
Автотести — постійно, короткий ручний набір — для релізів, повний аудит сценаріїв — за графіком і після суттєвої зміни теми, CMS, оформлення чи провайдера.
Rendframe може описати критичні маршрути магазину, провести технічний аудит, виправити спільні компоненти й оформлення, додати регресійні тести та передати доказовий перелік робіт. Юридичний висновок залишається за вашим консультантом. Дізнайтеся, як ми створюємо надійні ecommerce-системи, або надішліть адресу магазину, ринки й платіжних провайдерів для першого огляду доступності.
Читайте далі: зіставте бар’єри доступності з повним аудитом причин покинутого оформлення, підготуйте запитання до агенції розробки або вбудуйте доступність у продуктову розробку.