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, возможность отмены.

KYC/верификация

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

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

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

Каждому дефекту — ссылка на критерий WCAG и воспроизводимый сценарий.

14) Критерии приемки (Definition of Done, A11y)

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

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

До разработки: A11y-критерии в задачах, макеты со состояниями фокуса/ошибок.
В разработке: линтеры/axe при локальной сборке; визуальные снапшоты контрастов/фокуса.
В 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 с — есть текст о процессе/ETA.
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).

Нажимая кнопку, вы соглашаетесь на обработку данных.