Тестирование доступности

Пошаговое руководство для тестировщиков по проверке доступности сайта

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

В статье изложены основные проверки веб приложения на доступность, если этим придется заниматься функциональному тестировщику.

Тестовая страница

Предварительные условия:

  • Предполагается, что читатель знаком с понятием цифровой доступности (Accessibility или A11y) и технологиями обеспечения доступности интерфейсов (см. список литературы);
  • Не затрагиваются инструменты автотестирования;
  • Перечисленные ниже проверки — базовые, они проводятся без использования скринридера;
  • В качестве примера выбрана страница популярного подкаста на Яндекс.Музыке.

Клавиатурная навигация

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

1. Фокус интерактивных элементов

Пробуем пройтись по странице по нажатию TAB, обращаем внимание на выделение активных элементов при навигации — они должны быть заметны, чтобы было понятно в где мы оказались.

Фактический результат:

  • У большинства ссылок и кнопок отсутствует фокус;
1.1. Фокус интерактивных элементов — на выделенных элементах нет фокуса, пользователю непонятно на каком элементе он находится

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

1.2. Фокус интерактивных элементов — ссылка [технологии] имеет дефолтный стиль фокуса

Зачем? Подсвеченный фокус — визуальная обратная связь для того, чтобы пользователь понимал где он находится.

Это пункт 2.4.7 «Видимый фокус» требований WCAG (подробнее).

Рекомендуется обеспечивать очевидный стиль фокуса (особенно, если стиль по умолчанию оказывается удален):

2. Последовательность элементов при клавиатурной навигации

Навигируемся по странице нажатием TAB, элементы последовательно выделяются слева направо и сверху вниз.

Фактический результат совпадает с ожиданием: навигация происходит в логической последовательности. Визуальный порядок элементов соответствует реальному порядку в DOM-дереве, т.е. CSS свойства не меняют порядок элементов.

Это пункты 1.3.2 «Значимая последовательность чтения» и 2.4.3 «Порядок перемещения фокуса» требований WCAG (подробнее).

3. Расстановка tabindex

Навигируемся по странице нажатием TAB, со всеми интерактивными элементами можно взаимодействовать.

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

3. Расстановка tabindex — запустить трек с клавиатуры не получится, т.к. кнопка ► появляется только при наведении

Ожидалось: на интерактивные элементы можно попасть с клавиатуры.

Зачем? Чтобы пользоваться всеми функциями сайта.

Это пункт 2.1.1 «Клавиатура» требований WCAG (подробнее).

Элементы включаются или исключаются из порядка табуляции при правильном использование tabindex.

4. Значение tabindex

Проверяем значения атрибутов в коде страницы.

Фактический результат: есть множество элементов с одинаковым > 0.

Ожидалось: единственный элемент с > 0.

Зачем? Чтобы не сбивать браузер с толку или специально указать на первый фокусный элемент (при использовании единственного ).

Не смотря на то, что может быть больше 0 (но не превышать 32767), желательно иметь единственный элемент с > 0, т.к. на него первым придет фокус с клавиатуры по TAB.

Семантика

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

5. Язык документа

У Яндекс.Музыки есть локализация — язык страницы можно поменять на английский, армянский, узбекский, кириллический казахский, украинский или азербайджанский. Поэтому проверяем объявление языка страницы.

Фактический результат: в теге не указан язык документа.

Ожидалось: .

Зачем? Чтобы синтезатор речи точно определил язык страницы. Иначе русские слова он может читать как «Cyrillic letter A, Cyrillic letter Б, Cyrillic letter В», а при смене локали нужно менять lang на соответствующее значение из реестра IANA: en, hy, uz, kk, uk или azb.

6. Структура документа

Проверяем наличие тегов заголовков в коде страницы.

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

6. Структура документа — <h1>Слушай, Алиса!</h1>

Зачем? Продуманная структура документа (наличие заголовков в иерархическом порядке) поможет быстрее перемещаться по сайту — скринридеры позволяют «прыгать» между заголовками.

Это пункт 1.3.1 «Информация и взаимосвязи» требований WCAG (подробнее).

В случае наличия одних ов и невозможности их замены на семантически верные заголовки, нужные блоки можно включить в A11y-дерево через добавление соответствующих ARIA ролей: .

7. Ориентиры документа

Проверяем наличие атрибутов ARIA Landmark Roles в коде страницы.

Фактический результат: ничего.

Ожидалось: разметка областей страницы основными ролями в соответствии с их содержимым: banner, complementary, contentinfo, main, navigation, search.

7. Ориентиры документа — пример расстановки ARIA Landmarks

Зачем? Ориентиры, как и заголовки, помогают быстрее перемещаться по сайту — скринридеры позволяют «прыгать» между размеченными блоками.

Это пункт 1.3.6 «Определение назначений» требований WCAG (подробнее).

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

8. Описание интерактивных элементов

Проверяем наличие и понятность описания интерактивных элементов (кнопок и ссылок). Здесь пригодится включение скринридера, чтобы понимать, как эти элементы прочитываются.

Фактический результат: описаний нет или они непонятны.

Ожидалось: описания отражают логический смысл интерактивных элементов. Например:

  • Вместо стандартного наименования ссылки [технологии] можно ;
  • Вместо стандартного наименования кнопки [Слушать] можно;
  • Вместо отсутствия описания кнопки […] нужно .

Зачем?

Это пункт 2.4.4 «Цель ссылки (в контексте)» требований WCAG (подробнее).

9. Описание изображений

Проверяем наличие атрибута у изображений.

Фактический результат: отсутствуют описания изображений.

9. Описание изображений — у тега <img> отсутствует alt

Ожидалось:

  • У обложи подкаста будет атрибут с описанием ;
  • У логотипа сайта будет описание. Не смотря на то, что логотип размещен на сайте не через , а через свойство , у ссылки логотипа должно быть описание: .

Зачем? Для контекстных картинок (которые несут какой-то смысл) необходимо предусматривать альтернативный текст, чтобы пользователь со скринридером получил представление об изображении.

Это пункт 1.1.1 «Нетекстовый контент» требований WCAG (подробнее).

10. Цветоощущение

Проверяем:

  • Отображение сайта в монохромном режиме и режимах имитации дальтонизма и дальнозоркости (размытие картинки) с помощью встроенного в Firefox симулятора или стороннего расширения для браузера (см. список литературы);
  • Отображение ссылок в каждом из режимов;
  • Контрастность текста с помощью Accessibility Inspector в Firefox.

Фактический результат:

  • Неконтрастный текст: «ПОДКАСТ», «Популярно у слушателей», «2019» и «технологии» слишком светлые — коэффициент контрастности должен составлять не менее 4,5:1 для текста стандартного размера (подробнее);
10.1. Цветоощущение — коэффициент контрастности ≠ 4,5:1
10.2. Цветоощущение — контрастность в Firefox Developer Tools
  • Не видно состояния ссылки [технологии] при наведении в монохромном режиме.
10.3. Монохромазия (отсутствие цветовосприятия), 10.4 Дальнозоркость или затуманенное зрение
10.5. Протанопия (нарушение цветовых ощущений в красной части спектра), 10.6 Тританопия (нарушение цветовых ощущений в сине-фиолетовой области спектра)

Ожидалось:

Зачем?

Это пункты 1.4.1 «Использование цвета» и 1.4.3 «Контраст (минимальные требования)» требований WCAG (подробнее).

11. Увеличение шрифта

Увеличиваем размеры текста на странице до 200 %.

11. Увеличение шрифта до 200 %

Фактический результат совпадает с ожиданием: верстка адаптировалась под изменившиеся пропорции текста.

Это пункт 1.4.4 «Изменение размеров текста» требований WCAG (подробнее).

12. Самопроверка в Lighthouse

Запускаем Accessibility Audit в Chrome Dev Tools.

Смотрим, что было упущено при ручных проверках.

12. Самопроверка в Lighthouse
  • Остались некоторые кнопки без описаний;
  • Фреймы остались без описаний (вне текущей области тестирования);
  • Подписи к картинкам покрыты в п. 9;
  • Элементы форм остались без описаний (строка поиска вне текущей области тестирования);
  • Подписи к интерактивным элементам покрыты в п. 8.

Если не знать что искать, то автоматический аудит можно было бы запустить в начале тестирования или использовать Accessibility Inspector в Firefox для выявления проблем в конкретных элементах.

Перечисленных проверок достаточно для проведения первичного тестирования и/или аудита.

Список литературы

Похожие статьи про тестирование доступности

Ресурсы

Официальная документация

ARIA

MDN

Google

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

Скринридеры

Браузерные расширения

Статьи

На русском (свежие сверху):

На английском (свежие сверху):

Статьи про ARIA

Курсы

Quality assurance engineer