Веб-доступность

Страницей пользуются люди, которые не видят её такой, какой её нарисовали: незрячий слушает её через скринридер, слабовидящий увеличивает масштаб или включает высокий контраст, кто-то работает без мыши — после травмы или потому, что при треморе мышь бесполезна.
Скринридер не смотрит на страницу как на картинку. Браузер создаёт специальное представление страницы — accessibility tree, дерево доступности, — где указано, что является заголовком, кнопкой, ссылкой или полем ввода. Если нужной информации нет в этом дереве, скринридер не сможет сообщить её пользователю.
Дефекты веб-доступности — обычные дефекты: они воспроизводимы, и за ними стоит документированный источник требований. С 28 июня 2025 года требования European Accessibility Act применяются в ЕС к ряду цифровых продуктов и услуг.
Всё, что описано ниже, проверяется руками: понадобятся вкладка Elements — разметка и панель Styles рядом с ней, — вкладка Lighthouse и клавиатура вместо мыши.

Что произносит скринридер

Он читает страницу в том порядке, в каком элементы идут в разметке, а не в том, как они расставлены на экране. Для каждого элемента скринридер может произнести его название и роль: например, «Купить, кнопка» или «Email, поле ввода».
Если элемент только выглядит как кнопка, но сделан обычным <div> или <span> без правильной семантики, скринридер может воспринять его как обычный текст. Иногда разработчики используют ARIA — набор специальных ролей и атрибутов, которые помогают сообщить скринридеру роль, название или состояние элемента: например, role="button" говорит, что элемент нужно воспринимать как кнопку. Но role="button" сам по себе не делает <div> настоящей кнопкой — работу с клавиатурой разработчику нужно реализовать отдельно. Поэтому многие дефекты веб-доступности не видны на скриншоте и хорошо видны во вкладке Elements.
Как проверитьВыбери элемент во вкладке Elements и открой панель Accessibility рядом со Styles: там видно название и роль, которые элемент получает в дереве доступности, — именно эту информацию браузер передаёт скринридеру.

Какие требования разберём

Критериев в WCAG десятки, и одной страницей их не охватить. Ниже — три требования, которые нарушают чаще всего и которые тестировщик может проверить руками, без специальных инструментов: контраст текста, работа с клавиатуры и альтернативный текст изображений. Остальные критерии с примерами собраны в кратком справочнике WCAG 2.2.

Контраст

Слишком бледный текст перестаёт читаться при слабом зрении, на тусклом экране ноутбука и на солнце. 1.4.3 Contrast (Minimum), уровень AA, требует не меньше 4.5:1 для обычного текста и 3:1 для крупного.
Как проверитьПравый клик по тексту → Inspect, затем клик по квадратику перед значением color в панели Styles: в палитре написан Contrast ratio и отмечено, проходит ли он AA. Тот же дефект Lighthouse показывает как «Background and foreground colors do not have a sufficient contrast ratio».

Фокус и клавиатура

Всё, что делается мышью, должно быть доступно с клавиатуры — 2.1.1 Keyboard, уровень A, — и должно быть видно, на каком элементе сейчас клавиатура, — 2.4.7 Focus Visible, уровень AA. Порядок перехода между элементами должен оставаться логичным — 2.4.3 Focus Order, уровень A. Обычно при нажатии Tab фокус получают интерактивные элементы: ссылки, кнопки и поля. Разработчик может сделать фокусируемыми и другие элементы, например с помощью tabindex. Lighthouse эту проверку не делает, её выполняют руками.
Как проверитьОтложи мышь и нажимай Tab, чтобы двигаться вперёд, и Shift + Tab — назад. До каждого элемента управления должно быть возможно добраться, порядок фокуса должен быть логичным, а текущий элемент — заметным. Кнопки, ссылки и другие элементы попробуй также использовать с клавиатуры — например, с помощью Enter или Space.

Атрибут alt

У каждого тега в разметке могут быть атрибуты — пары имя="значение" внутри самого тега, которые о нём что-то сообщают. У картинки в src лежит путь к файлу, а в alt — альтернативный текст, то есть картинка, пересказанная словами:
<img src="logo.png" alt="Логотип Tallinn Learning"> — атрибут есть: скринридер прочитает «Логотип Tallinn Learning».
<img src="logo.png">alt нет: скринридер может прочитать имя файла или другую бесполезную информацию, а может и не передать смысл картинки вообще.
Ещё браузер может показать alt, если изображение не загрузилось. А без него то, что несла картинка, до пользователя не дойдёт: подпись к схеме, отметка «нет в наличии», кнопка-иконка так и останутся непонятными. Ради этого и существует критерий 1.1.1 Non-text Content, уровень A.
Три исхода означают разное: alt с текстом описывает то, что передаёт картинка; пустой alt="" намеренно скрывает декоративное изображение от скринридера; отсутствие alt — это дефект, описанный выше. Оценить сам текст может только человек: alt="изображение" проходит автоматическую проверку и не сообщает пользователю ничего.
Как проверитьПравый клик по картинке → Inspect и посмотри атрибуты тега <img> во вкладке Elements.

На собеседовании

На собеседовании на junior QA обычно спрашивают не детали стандарта, а понимаете ли вы базовые принципы и умеете ли проверить их руками. Попробуйте ответить сами, прежде чем открыть ответ.
juniorначальный уровень знаний
1. Что такое веб-доступность?
2. Что такое WCAG?
3. Как проверить веб-доступность сайта с клавиатуры?
4. Для чего нужен alt у изображения?
middleболее продвинутый уровень
5. Что такое ARIA и зачем она нужна?
6. Текст на странице светло-серый на белом фоне. Это дефект?
Вопросы по остальным темам собраны на странице Вопросы на собеседовании QA по DevTools.
НазадДалее