Чому доступність і згода тепер перетинаються

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

З боку доступності Європейський закон про доступність (EAA), впроваджений у національне законодавство держав-членів ЄС, встановлює WCAG 2.1 AA як мінімум для веб-сайтів і додатків приватного сектору, що надають споживчі послуги. Режим санкцій варіюється залежно від країни, але зазвичай становить від €50 000 до €500 000 за порушення, плюс накази про виведення з ринку при стійкій невідповідності.

Основні вимоги WCAG для банерів файлів cookie

Керованість за допомогою клавіатури

Кожен елемент управління банером — Прийняти, Відхилити, Керувати налаштуваннями, закрити — має бути доступним і керованим лише за допомогою клавіатури. Користувачі мають змогу переміщатися між кнопками клавішею Tab у логічному порядку та активувати їх клавішею Enter або Space. Фокус має бути видимим із мінімальним коефіцієнтом контрасту 3:1 відносно фону.

Утримання фокусу в модальних банерах

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

Оголошення зчитувачів екрана

Банер має бути оголошений як діалог із доступною назвою і роллю. Використовуйте role="dialog" або role="alertdialog" з aria-labelledby, що вказує на заголовок банера, і aria-describedby, що вказує на пояснювальний текст.

Колірний контраст

Основний текст має забезпечувати контраст 4,5:1 відносно фону; великий текст (18pt+ або 14pt жирний) потребує 3:1. Текст кнопок, іконки та індикатори фокусу мають власні мінімальні значення контрасту. Світло-сіра кнопка «Відхилити» на білому фоні — поширена помилка WCAG, яку ми бачимо на аудитах.

Без підказок лише за кольором

Не покладайтеся виключно на колір для розрізнення «Прийняти» та «Відхилити». Використовуйте різні мітки, іконки або форми, щоб користувачі з порушенням кольорового зору могли розрізнити кнопки.

Темні патерни і доступність

WCAG 2.2 запроваджує нові критерії, що безпосередньо спрямовані проти темних патернів — особливо актуальних для згоди:

• 3.3.8 Доступна автентифікація — забороняє когнітивні головоломки як перешкоду для отримання згоди.
• 3.3.7 Надмірне введення — користувачі не мають повторно вводити інформацію лише для того, щоб відкликати згоду.
• 2.4.11 Фокус не перекрито — сам банер не повинен перекривати індикатор фокусу елементів за ним.
• 2.5.7 Жести перетягування — якщо ваш банер використовує взаємодію «перетягни, щоб прийняти», має існувати альтернатива з одним покажчиком.

RTL та інтернаціоналізація

Доступність поширюється на мови з написанням справа наліво (арабська, іврит, перська, урду) та на вимову зчитувача екрана:

• Встановіть dir="rtl" на банері, коли мова документа є RTL, щоб порядок кнопок і потік фокусу відповідали напрямку читання.
• Використовуйте правильні атрибути lang на перекладеному тексті банера, щоб зчитувачі екрана вимовляли слова з правильною фонетикою.
• Дзеркалюйте іконографію — кутові дужки, стрілки та індикатори прогресу мають дзеркально відображатися для RTL-локалей.

Тестування банера на відповідність WCAG

Не покладайтеся на єдиний інструмент. Поєднуйте автоматизоване сканування з реальним тестуванням допоміжних технологій:

• axe DevTools або Lighthouse — автоматично виявляє приблизно 30-40% порушень WCAG.
• NVDA або JAWS на Windows, VoiceOver на Mac/iOS, TalkBack на Android — тестуйте з реальними зчитувачами екрана. Чи можна оголосити банер, перейти по ньому та закрити лише за допомогою зчитувача екрана?
• Навігація лише за допомогою клавіатури — від'єднайте мишу. Якщо ви не можете Прийняти, Відхилити і керувати налаштуваннями, то й користувачі клавіатури не можуть.
• Симуляція кольорової сліпоти — Chrome DevTools має вбудовані симулятори порушень зору. Перевірте, чи «Прийняти» і «Відхилити» розрізняються при протанопії, дейтеранопії та тританопії.
• Масштабування до 400% — WCAG вимагає, щоб контент залишався придатним для використання при масштабуванні 400% без горизонтального прокручування. Банери з фіксованим позиціонуванням часто не проходять цей тест.

Поширені помилки доступності, які ми бачимо

• «Відхилити» приховано за іконкою шестерні — темний патерн плюс помилка доступності (відсутня доступна назва на кнопці-іконці).
• Фокус ніколи не досягає банера — банери, що привертають візуальну увагу, але пропускаються у порядку Tab.
• Модальний банер без утримання фокусу — користувачі можуть переходити Tab на фонову сторінку, поки банер стверджує, що блокує взаємодію.
• Відсутність aria-live при змінах налаштувань — користувачі зчитувача екрана не чують підтвердження того, що їхній вибір збережено.
• Перекладені банери без атрибута lang — зчитувачі екрана вимовляють іспанський текст з англійською фонетикою.

Як FlexyConsent забезпечує доступність