Игорь Колосов.ru Личная база знаний

Что такое a11y

Доступность интерфейса показывает, насколько удобно сайтом пользоваться людям с разными особенностями восприятия, моторики и взаимодействия с техникой. Веб-стандарты для этой области задаются WCAG. На март 2026 года W3C рекомендует ориентироваться на WCAG 2.2; эта версия включает предыдущие требования WCAG 2.1 и 2.0, а сами критерии организованы по четырем принципам: perceivable, operable, understandable, robust. Для оценки применяются уровни A, AA и AAA.

В практической работе тестировщика доступность помогает оценивать интерфейс шире, чем просто “кнопка нажимается” или “форма отправляется”. Проверка a11y показывает, может ли пользователь пройти сценарий с клавиатуры, понимает ли экранный диктор структуру страницы, читается ли текст, различимы ли состояния элементов и получает ли человек понятную обратную связь от системы.

Четыре принципа доступности

WCAG строится вокруг четырех опорных принципов. Контент должен восприниматься, элементы управления должны быть доступны для действий, логика интерфейса должна оставаться понятной, а разметка должна быть устойчивой для браузеров и вспомогательных технологий. Для тестировщика это удобно переводится в простой набор вопросов: видно ли контент, можно ли пройти сценарий, понятны ли подписи и ошибки, корректно ли интерфейс описан в HTML и accessibility tree.

Семантика HTML как основа

Самый сильный вклад в доступность дает правильная HTML-разметка. MDN прямо рекомендует брать нативные элементы и их встроенное поведение, когда они уже подходят под задачу. Для кнопки лучше использовать <button>, потому что этот элемент уже поддерживает взаимодействие мышью, клавиатурой, касанием и вспомогательными технологиями. Роль button на произвольном div сообщает смысл, но не добавляет автоматически нативную клавиатурную механику и прочее стандартное поведение.

Отсюда следует важный вывод для тестирования: если команда собирает ссылки, кнопки, вкладки или раскрывающиеся панели из случайных div и span, риск дефектов резко растет. Поэтому в a11y-проверке всегда стоит смотреть на теги элементов, роли и доступные им состояния.

Клавиатурная навигация и видимый фокус

Любой интерактивный элемент должен проходиться с клавиатуры в естественном порядке, а текущее место фокуса должно оставаться заметным. MDN отдельно подчеркивает, что элемент, получающий focus, должен иметь видимую фокусную индикацию; для этого обычно используют :focus и :focus-visible.

Для тестировщика это означает простую проверку: открыть страницу, убрать мышь и пройтись по интерфейсу клавишей Tab. Во время такого прохода сразу видны слабые места: “прыгающий” порядок обхода, пропущенные элементы, скрытый фокус, ловушка в модальном окне, недоступный бургер, вкладки без управления стрелками и диалог, из которого сложно вернуться назад.

Формы и подписи полей

Каждое поле формы должно иметь связанную подпись. Официальные рекомендации web.dev и правила axe указывают, что самый надежный путь — связать <label> и поле через for и id либо обернуть поле внутрь label. Такая подпись дает полю понятное имя для экранных читалок и делает область взаимодействия удобнее.

Для тестирования форм этого достаточно, чтобы собрать сильный чек-лист: есть ли у поля видимая подпись, понимает ли пользователь формат данных, получает ли он ясное сообщение об ошибке, переводится ли фокус в проблемное место после отправки, озвучивается ли ошибка для вспомогательных технологий. Поле с одним placeholder вместо настоящей подписи почти всегда создает лишний риск для восприятия.

Изображения и текстовые альтернативы

Осмысленные изображения должны иметь понятный alt, потому что именно он формирует текстовую альтернативу для экранных читалок и других технологий. Для декоративных изображений обычно применяют пустой alt, чтобы они не создавали шум в восприятии интерфейса.

На практике тестировщик проверяет три вещи: несет ли изображение смысл, есть ли у него alt, соответствует ли текст реальному содержанию. Если карточка товара, баннер, иконка действия или фото автора содержат информацию, эта информация должна доходить и до пользователя, который воспринимает страницу через голосовой интерфейс.

Контраст и читаемость

Цветовой контраст относится к самым частым проблемам интерфейса. Для обычного текста WCAG AA задает минимальный контраст 4.5:1, для крупного текста и существенных иконок действует порог 3:1. web.dev приводит те же значения и уточняет критерии крупного текста.

Для тестировщика отсюда следует прямое правило: проверять формы, подсказки, ошибки, ссылки, вторичные кнопки, серые тексты в карточках, плейсхолдеры и статусы. Самые частые потери читаемости происходят именно в “спокойных” серых палитрах, где дизайнеру кажется, что интерфейс выглядит аккуратно, а пользователь получает слабую различимость текста и состояний.

ARIA и динамические интерфейсы

ARIA помогает описывать роли, состояния и свойства интерфейса для вспомогательных технологий, особенно в сложных JavaScript-компонентах. При этом MDN формулирует важное правило: сначала стоит использовать нативный HTML, а затем уже добавлять ARIA там, где это действительно усиливает интерфейс.

Тестировщик чаще всего сталкивается с ARIA в модальных окнах, выпадающих списках, переключателях, вкладках, аккордеонах и кастомных кнопках. Здесь полезно смотреть на aria-label, aria-expanded, aria-hidden, связи aria-labelledby и доступные им состояния при клике или навигации с клавиатуры. Самый частый учебный вывод звучит просто: хорошая семантика делает интерфейс доступнее быстрее, чем сложный набор ролей на случайных контейнерах.

Инструменты тестировщика

Для первичной проверки удобно использовать Chrome DevTools и панель Lighthouse. Chrome Developer Documentation описывает Lighthouse как автоматизированный инструмент аудита, который умеет проверять accessibility и запускается прямо в Chrome DevTools, в том числе на страницах с авторизацией. В Chrome DevTools также есть встроенные accessibility-возможности для анализа структуры и контраста.

Для более точной локальной проверки удобно подключать axe DevTools. По официальной документации Deque, расширение доступно в Chrome и Edge, а в Firefox действует ограниченная версия. Документация Chrome также указывает, что Lighthouse и axe дают близкий класс автоматических проверок и полезны как стартовый слой диагностики.

Итог

Доступность в тестировании — это проверка интерфейса глазами более широкой аудитории и через разные способы взаимодействия. Базовый набор студента состоит из семантики, клавиатуры, фокуса, подписей полей, alt-текстов, контраста, ролей и автоматического аудита. Если эти проверки входят в регулярную работу команды, качество интерфейса растет сразу в нескольких направлениях: удобство, предсказуемость, стабильность и зрелость продукта.

Практическая работа

Тема: Базовое тестирование доступности сайта

Цель работы

Проверить доступность выбранного сайта по базовому чек-листу a11y и оформить короткий отчет с найденными проблемами и техническими наблюдениями.

Ожидаемый результат

К концу занятия студент:

  1. Проверяет страницу с клавиатуры.
  2. Находит проблемы с семантикой, формами, фокусом и контрастом.
  3. Запускает Lighthouse и axe DevTools.
  4. Оформляет отчет по найденным дефектам.

Оснащение

  • компьютер с доступом в интернет
  • Google Chrome или Microsoft Edge
  • DevTools браузера
  • расширение axe DevTools
  • любой учебный или публичный сайт по согласованию с преподавателем

Объект исследования

Для практики лучше брать страницу, где есть:

  • меню или навигация
  • хотя бы одна форма
  • карточки или список контента
  • кнопки, ссылки, иконки
  • всплывающее окно или раскрывающийся блок

Ход работы

Этап 1. Первичное знакомство со страницей

  1. Откройте страницу.
  2. Определите ее основной сценарий: каталог, форма обратной связи, вход в личный кабинет, новостная страница, карточка товара.
  3. Кратко запишите, какие интерактивные элементы присутствуют на странице.

Что зафиксировать:
адрес страницы, тип страницы, основной пользовательский сценарий.

Этап 2. Проверка структуры заголовков и семантики

  1. Откройте DevTools.
  2. Найдите главный заголовок страницы.
  3. Проверьте, есть ли на странице логичная иерархия заголовков.
  4. Посмотрите, какими тегами оформлены кнопки и ссылки.
  5. Отметьте случаи, где роль и поведение элемента расходятся.

Ориентир для вывода:
кнопка должна быть кнопкой, ссылка должна быть ссылкой, главный контент должен иметь понятную структуру, а нативные HTML-элементы обычно дают лучший результат для доступности, чем случайные контейнеры с ролями.

Что зафиксировать:
минимум 3 элемента с указанием тега и назначения.

Этап 3. Проверка клавиатурной навигации

  1. Уберите мышь.
  2. Пройдитесь по странице клавишей Tab.
  3. Посмотрите, виден ли фокус на каждом шаге.
  4. Проверьте, можно ли дойти до меню, ссылок, кнопок и полей формы.
  5. Если есть диалог или меню, откройте его с клавиатуры и пройдите элементы внутри.

Ориентир для вывода:
фокус должен быть заметным, а порядок обхода должен совпадать с логикой страницы.

Что зафиксировать:

  • есть ли видимый фокус
  • где порядок обхода удобный
  • где порядок обхода сбивается
  • удалось ли пройти основной сценарий только с клавиатуры

Этап 4. Проверка изображений и иконок

  1. Найдите на странице 3 изображения.
  2. Посмотрите, есть ли у них alt.
  3. Оцените, передает ли alt смысл изображения.
  4. Отдельно проверьте иконки действий: корзина, поиск, закрытие окна, профиль, меню.

Ориентир для вывода:
осмысленные изображения должны иметь текстовую альтернативу, а значимые элементы управления должны иметь доступное имя.

Что зафиксировать:
таблица из трех строк: элемент, наличие alt или доступного имени, краткая оценка качества.

Этап 5. Проверка формы

  1. Найдите форму на странице.
  2. Для каждого поля проверьте наличие подписи.
  3. Посмотрите, связано ли поле с label.
  4. Попробуйте отправить форму с пустыми или некорректными значениями.
  5. Посмотрите, как отображаются ошибки и куда переводится фокус.

Ориентир для вывода:
поле формы должно иметь связанную подпись, а пользователь должен получать ясное сообщение о формате и ошибках.

Что зафиксировать:

  • список полей
  • наличие подписи
  • поведение при ошибке
  • понятность сообщения

Этап 6. Проверка контраста и читаемости

  1. Выберите 5 текстовых элементов на странице: заголовок, обычный текст, ссылка, ошибка формы, вторичный текст.
  2. Откройте DevTools и посмотрите цвета текста и фона.
  3. Проверьте контраст через встроенные средства браузера или Lighthouse.
  4. Оцените заметность состояний ссылок и кнопок.

Ориентир для вывода:
для обычного текста минимальный ориентир составляет 4.5:1, для крупного текста и важных иконок — 3:1.

Что зафиксировать:
минимум 2 удачных примера и 2 спорных или слабых примера.

Этап 7. Проверка через Lighthouse

  1. Откройте DevTools.
  2. Перейдите в панель Lighthouse.
  3. Оставьте категорию Accessibility.
  4. Запустите отчет.
  5. Изучите найденные замечания.

Ориентир для вывода:
Lighthouse выполняет автоматические accessibility-аудиты прямо в Chrome DevTools и помогает быстро найти проблемные места.

Что зафиксировать:

  • итоговый балл
  • 3 самых важных замечания
  • 1 сильная сторона страницы по мнению инструмента

Этап 8. Проверка через axe DevTools

  1. Запустите axe DevTools.
  2. Выполните анализ страницы.
  3. Изучите список нарушений.
  4. Сравните результаты axe и Lighthouse.

Ориентир для вывода:
axe DevTools доступен как расширение браузера и подходит для локального a11y-анализа страницы.

Что зафиксировать:

  • сколько замечаний найдено
  • какие типы проблем встречаются чаще
  • совпадают ли основные проблемы с Lighthouse

Этап 9. Итоговый вывод

Сформулируйте короткий вывод по странице:

  1. Насколько удобно пройти основной сценарий.
  2. Какие 3 проблемы сильнее всего влияют на доступность.
  3. Какие 2 улучшения дали бы самый быстрый эффект.

[task_id id=»21476″]