Соответствие уровня AA, требуемое EAA и большинством юридических норм, означает что выполнены все критерии успеха уровней A и AA. Вместе они охватывают: у изображений есть alt-текст (A), цвет не единственный визуальный индикатор (A), контрастность обычного текста не менее 4.5:1 (AA), вся функциональность доступна с клавиатуры (A), индикаторы фокуса видны (AA), поля форм имеют программно привязанные метки (A).

Как тестировщику не нужно запоминать всю спецификацию. Нужно знать какие критерии нарушаются чаще всего и как их тестировать.

Ручное тестирование доступности: клавиатура и скринридеры

Ни один автоматический инструмент не найдёт все ошибки доступности. Ручное тестирование с клавиатурой и скринридером незаменимо.

Самый распространённый сбой клавиатурной навигации: разработчик строит модальный диалог, но Tab изнутри него уходит на фоновую страницу. Модальное окно визуально присутствует, но пользователь клавиатуры теперь взаимодействует с контентом позади него, не зная об этом.

Индикаторы фокуса: тоже часть этого теста. У каждого сфокусированного элемента должен быть видимый индикатор: стандартный браузерный контур, кастомный стиль, что угодно. Дизайны полностью убирающие :focus-стили через outline: none в CSS создают невидимый фокус, что делает клавиатурную навигацию полностью неработоспособной. Ищи это в каждом review спринта.

Установи NVDA и открой приложение. Отключи монитор если хочешь полного погружения. Перемещайся по Tab к интерактивным элементам, используй режим просмотра NVDA (стрелки) для чтения статичного контента. Слушай что объявляет скринридер. Кнопка «Click here» ничего не говорит пользователю. Кнопка «Submit payment» говорит точно что произойдёт. Кнопка с иконкой без aria-label объявляет свою роль как «button» но ничего о своей функции. Непомеченное поле формы объявляется как «edit» без контекста о том что вводить.

Комбинация клавиатурного тестирования и базового использования скринридера найдёт большинство серьёзных ошибок доступности в типичном веб-приложении.

Автоматизированное тестирование доступности с axe-core и Playwright

Автоматические инструменты не заменят ручное тестирование, но они надёжно находят определённый набор проблем (отсутствие alt-текста, недостаточный цветовой контраст, отсутствие меток форм, некорректное использование ARIA) постоянно и в масштабе. Запуск в CI означает что регрессии находятся до того как они доходят до тестировщиков.

Наиболее широко используемый движок: axe-core от Deque Systems. Он лежит в основе браузерных расширений (axe DevTools), Lighthouse и ряда интеграций с фреймворками. Для команд уже использующих Playwright, пакет @axe-core/playwright добавляет сканирование доступности с минимальной настройкой.

Базовый Playwright-тест сканирующий страницу на нарушения доступности:

import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('homepage should have no automatically detectable accessibility violations', async ({ page }) => {
  await page.goto('/');

  const accessibilityScanResults = await new AxeBuilder({ page }).analyze();

  expect(accessibilityScanResults.violations).toEqual([]);
});