GH GambleHub

Тестування доступності інтерфейсів

1) Навіщо і що вважаємо «готово»

Доступність (A11y) - це вимірний набір умов, при якому продукт однаково зрозумілий і керований для людей з різними особливостями сприйняття і моторики, пристроїв і контекстів. Готово значить:
  • виконані критерії WCAG 2. 1/2. 2 рівня AA для цільових платформ;
  • інтерфейс повністю проходимо з клавіатури;
  • коректна робота зі скрінрідерами;
  • контрасти відповідають нормам;
  • всі стани/помилки/статуси доступні поза зору і без миші;
  • враховані локалізація, RTL, reduce motion і мобільні особливості.

2) Стратегія тестування (пірамідка A11y)

1. Автотести/лінтери (швидке покриття до 40-60% класів проблем).
2. Ручна перевірка патернів (клавіатура, фокус, контент, логіка).
3. Assistive Tech (AT) сесії: скрінрідери, масштабування, колірні фільтри.
4. Польові випробування з користувачами (по можливості).

Мета: зловити системні дефекти на рівні компонентів/патернів, щоб не розмножувалися у фічах.

3) Чек-лист базових перевірок (швидкий прогін)

  • Клавіатура: все досяжно табом/стрілками; порядок фокусу логічний; пастка фокусу в модалках є; ESC/Enter/Space працюють.
  • Фокус-індикатор бачимо в будь-якій темі/на будь-якому тлі.
  • Контраст: текст ≥ 4. 5:1 (звичайний), ≥ 3:1 (великий), іконки/контролі читаються.
  • Семантика: коректні теги ('button','a','label','ul/li','th/td'), ролі і'aria-'тільки при необхідності.
  • Скрінрідер: заголовки за ієрархією, смислові назви кнопок/посилань, альтернативи для іконок/зображень.
  • Форми: явні'label', підказки/помилки пов'язані ('aria-describedby'), тексти помилок конкретні.
  • Динаміка: тости/банери/помилки оголошуються через'aria-live'('polite '/' assertive').
  • Анімації поважають'prefers-reduced-motion'; без «тряски» інтерфейсу.
  • Локалізація/RTL: ключові екрани вирівняні, числа/дати/валюти форматуються утилітами.
  • Мобільність: цілі торкання ≥ 44 × 44 px, зум не заборонений, поворот екрану не ламає контент.

4) Ролі, відповідальності та артефакти

Дизайн-система: A11y-вимоги в описі кожного компонента.
Розробники: автоперевірки, unit/interaction-тести з A11y-асертами.
QA: ручні сценарії + AT-сесії; звіт з серйозністю/частотою.
UX/Content: microcopy помилок/статусів, читабельність вголос.
Артефакти: чек-листи, сценарії, скрінкасти AT, список дефектів з WCAG-референсами, рекомендації.

5) Автоматизовані перевірки

Лінтери/аналізатори: axe, eslint-plugin-jsx-a11y, pa11y, Lighthouse.
У пайплайні: блокуємо PR при критичних порушеннях (role/label/контраст/таб-пастки).
Снапшоти контрасту: візуальні тести тем/станів.

💡 Пам'ятаємо: автоінструменти не перевіряють сенс і не бачать фокус очима - ручні тести обов'язкові.

6) Ручне тестування: сценарії

6. 1 Клавіатура

Пройдіть сторінку тільки клавіатурою (Tab/Shift + Tab/Enter/Space/стрілки).
Перевірте: видимість фокусу, черговість, доступність всіх дій, відсутність «пасток» і «мертвих» елементів.
У модалці: фокус всередині, при закритті повертається до ініціатора.

6. 2 Скрінрідери (мінімальний набір)

Desktop: NVDA/JAWS (Windows), VoiceOver (macOS).
Mobile: VoiceOver (iOS), TalkBack (Android).
Перевіряємо: коректні заголовки (H-ієрархія), назви кнопок/посилань, читання таблиць ('th '/' scope'), оголошення статусів, зрозумілі помилки форм.

6. 3 Контент і microcopy

Читаємо критичні тексти вголос - без двозначностей, без «помилка 400».
Помилка = «що не так + як виправити + обмеження/формат».

6. 4 Динаміка і живі регіони

Тост успіху -'aria-live = «polite»', помилка -'assertive'.
Прогрес/завантаження пояснені текстом; skeleton краще спінера.

7) Форми і помилки (поглиблено)

Кожне поле має зв'язаний label (не placeholder).
Помилки пов'язані з полем: `aria-invalid="true"`, `aria-describedby="[id ошибки]"`.
Формули форматів (дата, телефон) зазначаються заздалегідь; маски не ламають введення/вставку.
Сумарний банер помилок при submit + авто-скролл і фокус на першу помилку.
Тексти помилок: конкретні, без технічного жаргону.

8) Таблиці, списки, графіки

Таблиці: заголовки'th'со'scope = «col/row»', підписи, резюме.
Списки - реальними'ul/ol/li', не дівами.
Графіки - альтернативні таблиці/описи; легенди доступні; кольори ≠ єдиний сигнал.

9) Мультимедіа та анімації

Відео: субтитри/розшифровка; управління з клавіатури; без автоплея (або з тихим).
GIF/мікроанімації: вимикаємо при'prefers-reduced-motion'; уникаємо спалахів.
Вібрації/звуки - необов'язкові і дублюються візуально/текстом.

10) Мобільна доступність

Інтерактиви ≥ 44 × 44 px, достатні інтервали.
Масштабування не забороняти (meta viewport без'user-scalable = no').
Форма/клавіатура: правильні типи («tel», «email», «number»), не ховаємо системні можливості.
Перевірка в темній темі і з системними шрифтами «більше».

11) Локалізація, числа і RTL

Рядки через i18n-ключі з контекстом; довгі язики (DE/TR) не ламають макет.
Формати дат/валют - утилітами, не рядками.
Режим RTL: дзеркалимо іконки навігації, перевіряємо порядок фокусу і каретки, двонаправлене введення.

12) Специфіка критичних флоу (iGaming)

Платежі/висновки

Чіткі інструкції, ліміти/терміни/комісії - текстом.
Помилки провайдера оголошуються явно, без кодів; є альтернатива дії.
Підтвердження операції: фокус на логічному CTA, можливість скасування.

КУС/верифікація

Покрокові підказки до фото/документів; прогрес і ETA.
Помилки «розмито/відблиск/обрізано» - з прикладами виправлення.
Нейтральний тон, ніякого гумору.

13) Оцінка серйозності дефектів

Blocker: неможливо завершити ключове завдання (клавіатурою/скрінрідером).
Critical: критичний функціонал працює, але з серйозними бар'єрами.
Major: заважає, є обхідний шлях.
Minor: косметика/невідповідність гайдам без впливу на задачу.

Кожному дефекту - посилання на критерій WCAG і відтворюваний сценарій.

14) Критерії приймання (Definition of Done, A11y)

Проходження клавіатурного сценарію без миші на 100%.
axe/Lighthouse: немає критичних/високих порушень.
Контраст AA у всіх темах/станах.
Скрінрідер-прогін ключових шляхів (навбар, форми, модалки, тости).
Документація A11y для нових компонентів/фіч (рольова модель, aria, фокус, приклади).
Регресія A11y-тестів зелена в CI.

15) Процеси та автоматизація

До розробки: A11y-критерії в задачах, макети зі станами фокусу/помилок.
У розробці: лінтери/ахе при локальній збірці; візуальні снапшоти контрастів/фокусу.
В CI: pa11y/axe-скан по критичних сторінках; падіння білда при Blocker/Critical.
Після релізу: квартальні аудити, моніторинг призначених для користувача скарг по A11y-тегу.

16) Анти-патерни

Плейсхолдер замість label.
'div'замість'button '/' a'.
Відключені фокус-кільця «заради краси».
Колір як єдиний носій статусу.
Модалки без фокус-трепу/ESC.
Заборона масштабування на mobile.
«Помилка 400/500» без людського пояснення.

17) Шаблони сценаріїв тестування

Сценарій 1 - Клавіатурна навігація (сторінка з формою)

1. Tab до першого поля, введіть дані.
2. Shift + Tab назад - переконайтеся в коректному порядку.
3. Викличте валідацію (submit) - фокус переноситься до першої помилки.
4. Закрийте модалку клавішею ESC, фокус повернувся до ініціатора.

Сценарій 2 - Скрінрідер (сторінка платежу)

1. Перейдіть до заголовка сторінки (h1), прослухайте розділи.
2. Відкрийте вибір методу - оголошення ролей/станів чутно.
3. Свідомо припустіться помилки суми - повідомлення прочитане і пов'язане з полем.
4. Успішний тост про платіж оголошено «polite».

Сценарій 3 - Динаміка

1. Запустіть операцію з очікуванням> 3 с - є текст про процес/ЕТА.
2. При помилці мережі - банер'assertive', доступний з клавіатури, є шлях «повторити/допомогу».

18) Корисні мікро-шаблони

Ролі/aria для тостів

html
<div role = "status" aria-live = "polite"> Payment accepted. Balance updated. </div>
<div role = "alert" aria-live = "assertive"> The payment was denied. Try another method. </div>

Зв'язок помилки з полем

html
<label for = "amount "> Amount </label>
<input id="amount" aria-invalid="true" aria-describedby="amount-error">
<div id = "amount-error "> Minimum 100 UAH. Please enter a larger amount. </div>

Модалка (смислові атрибути)

html
<div role="dialog" aria-modal="true" aria-labelledby="m-title">
<h2 id =" m-title "> Confirm Payment </h2>
<! -- content -->
<button> Confirm </button>
<button> Cancel </button>
</div>

19) Швидкий план впровадження A11y-практик

1. Аудит поточних компонентів/патернів (контраст/фокус/рольова семантика).
2. Правки дизайн-системи: додати A11y-розділ до кожного компонента.
3. Інструменти: налаштувати лінтери/axe/pa11y/Lighthouse локально і в CI.
4. Навчання: короткі гайди для дизайнерів/розробників/копірайтерів.
5. Пілот: полагодити 3-5 найчастіших дефектів (модалки, форми, тости).
6. Регламент: DoD з A11y-критеріями; Квартальний аудит.

Підсумкова шпаргалка

Перевіряй клавіатуру, фокус, контрасти, скрінрідер, динаміку.
Оголошуй статуси через aria-live; помилки - пов'язані з полями.
Поважай reduce motion, не забороняй масштабування.
Думай семантикою (теги/ролі), а не «як виглядає».
Автоматизуй перевірки, але завжди доповнюй ручними.
Фіксуй дефекти з посиланням на WCAG, серйозність і сценарій відтворення.

Contact

Зв’яжіться з нами

Звертайтеся з будь-яких питань або за підтримкою.Ми завжди готові допомогти!

Розпочати інтеграцію

Email — обов’язковий. Telegram або WhatsApp — за бажанням.

Ваше ім’я необов’язково
Email необов’язково
Тема необов’язково
Повідомлення необов’язково
Telegram необов’язково
@
Якщо ви вкажете Telegram — ми відповімо й там, додатково до Email.
WhatsApp необов’язково
Формат: +код країни та номер (наприклад, +380XXXXXXXXX).

Натискаючи кнопку, ви погоджуєтесь на обробку даних.