Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 5
×

Проверка доступности сайта: обзор инструментов для accessibility testing

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!

В прошлом материале я делился деталями о том, что такое тестирования доступности, как с ним работать, а также — как использовать стандарт WCAG в работе. В данной статье я разберу разнообразные инструменты для тестирования доступности. Так, как сам список может показаться не достаточно интересным, я расскажу о том, что именно можно протестировать с помощью какого инструмента. В контексте данной статьи мы рассматриваем уровень доступности АА (по стандарту Web Content Accessibility Guidelines).

Инструменты тестирования можно поделить на несколько основных типов:

  1. Скринридеры (Screen Reader).
  2. Расширения для браузера.
  3. Букмарклеты (Bookmarklets) — скрипты которые определенным образом изменяют страницу. Эти скрипты обычно добавляются закладкой на панель закладок, поэтому их и называют букмарклеты. Для большей информации — Букмарклеты на Википедии.

Начнём более детальный обзор иструментов со Скринридеров.

Скринридеры (Screen Readers)

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

Большинство пунктов WCAG стандарта можно протестировать и без скринридеров. Но есть несколько пунктов для которых это критически необходимо. Почему? Без скринридеров достаточно тяжело понять будет ли функциональность действительно доступна для пользователей или нет. Так же часть пунктов прямо или косвенно подразумевают работу веб-приложения с вспомогающими устройствами (assistive technologies), такими как скринридеры.

Рекомендую максимально часто использовать скринридер при тестировании. Ниже привожу пример пунктов, где скринридер очень нужен (список не исчерпывающий):

  • 1.3.2 Meaningful Sequence — Level A
    Порядок чтения текста/объектов на странице. Без скринридера не всегда можно понять логична ли последовательность.
  • 2.1.1 Keyboard — Level A
    Работа веб-приложения с клавиатурой. Поскольку пользователи, которые используют скринридеры, чаще всего пользуются только клавиатурой, то данный пункт критически необходим.
  • 2.1.2 No Keyboard Trap — Level A
    Этот пункт связан с предыдущим. Если фокус пользователя попадёт в ловушку (невозможность двигаться ни вперед, ни назад), то дальнейшая работа будет затруднена.
  • 2.1.4 Character Key Shortcuts — Level A
    Если функциональность «шорткатов» была добавлена в веб-приложение, то нужно проверять, что это не мешает работе скринридеров, поскольку они используют определенные кнопки для навигации по странице.
  • 2.4.4 Link Purpose (In Context) — Level A
    Цель ссылки можно определить или по ее тексту, или по читаемому контексту. На данный момент уже есть инструменты, упрощающие поиск всех ссылок на странице. Но эти инструменты не могут со 100% точностью определить понятна ли будет цель ссылки пользователю или нет.
  • 2.5.3 Label in Name — Level A
    Доступное имя (Accessible name) должно или соответствовать видимому ярлыку или должно начинаться так же как и видимый текст.
  • 4.1.2 Name, Role, Value — Level A
    Если вы точно знаете какие веб элементы на странице были кастомизированные (не используют стандартные HTML теги), то возможно обойтись и без скринридера. Примером кастомизированного элемента может быть
    элемент, который содержит ссылку и внешне выглядит как кнопка.
  • 4.1.3 Status Messages — Level AA
    Статус сообщения должны произноситься скринридером. Как, например, озвучка текста «Форма успешно отправлена», который появился под формой. Или же озвучка обновленного текста «Три продукта в корзине» после нажатия на кнопку «добавить в корзину»

Сайт Webaim периодически предоставляет результаты опросов пользователей использующих скринридеры. С последним можно ознакомиться по ссылке — Screen Reader Survey 8.

Перечень основных вариантов скринридеров:

NVDA. Бесплатный. Скачать можно по ссылке. Является одним из самых популярных скринридеров. Поддерживается только на Windows. С годами становится все популярнее. Список команд можно найти здесь

JAWS. Платный. Есть варианты покупки годовой подписки или статус полноценного клиента. Также существует возможность использовать 40 минут бесплатно. После этого нужно будет перезагрузить компьютер, чтобы получить еще 40 минут. Скачать и посмотреть стоимость можно по ссылке. Список команд можно найти здесь

Microsoft Narrator. Бесплатный. По умолчанию добавлен в Windows. Список команд можно найти здесь

Voiceover. Бесплатный скринридер от компании Apple установленный на все устройства. Список команд можно найти здесь

Мобильные скринридеры. Для мобильных устройств чаще всего используются встроенные скринридеры. VoiceOver для iOS и TalkBack соответственно для Android. Список жестов для мобильных устройств можно найти по ссылкам:

Какой же скринридер выбрать для тестирования? Чаще всего скринридер будет зависеть от вашего основного браузера. Narrator лучше всего работает с Microsoft Edge, JAWS с Internet Explorer. Voiceover подойдет для Safari. NVDA/JAWS — для Firefox и Chrome. Для мобильных устройств выбор ограничен операционной системой.

В 90% случаев для тестирования я использую NVDA. С каждым годом он все популярнее, а также он полностью бесплатный. Насколько я знаю, большой разницы между JAWS и NVDA для тестирования нет. Если вы знаете случаи проблем воспроизводимые только в JAWS, оставьте, пожалуйста, комментарий. Это очень поможет и мне и другим тестировщикам.

Следующим среди инструментов тестирования доступности мы рассмотрим расширения.

Расширения для браузеров

Все расширения ниже приведены на примере использования в Google Chrome. Большой список для всевозможных браузеров вы можете найти в конце статьи.

WAVE

Ссылка в Chrome Web Store.

Одно из самых популярных расширений, создано и поддерживается компанией WebAim. Анализирует страницу в поисках достаточно большого количества ошибок, связанных с контрастом, заголовками, ярлыками, ссылками и т.д. Ради примера давайте проанализируем сайт компании Apple с помощью данного расширения.

Расширение WAVE в действии (сайт компании Apple)

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

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

Ниже пример работы расширения.

Пример работы расширения WAVE

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

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

Сообщение в WAVE о том, что контраст с картинками заднего плана не тестируется

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

Как вы видите на картинке выше есть ошибка с контрастом для ссылки «Watch the trailer». Если мы откроем сайт и сравним цвет текста к цвету картинки — проблемы не будет.

Проверка котраста элементов с помощью сайта webaim.org

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

Lighthouse

Ссылка в Chrome Web Store.

Еще одно популярное расширение. Создано компанией Google. Автоматически проводит аудит производительности, доступности, SEO, использовании лучших практик и предоставляет отчёт. Альтернативно можно использовать сайт Web.dev-Measure. Та же функциональность, но без использования расширения.

Частые ошибки которые показывает аудит: дубликаты айди объектов, некорректные значения для [aria-*] атрибутов, проблемы с контрастом, ошибки в порядке заголовков и т.д. Если проводить аудит на том же сайте Apple, можно увидеть примеры того, в каком формате подается аудит.

Пример аудита Lighthouse на сайте Apple

Например мы видим, что два элемента на главной странице содержат «role=text», что не является правильным значением для такого элемента.

Список существующих ролей можно посмотреть здесь — Ссылка

Также не стоит забывать о том, что Score, который показывает Lighthouse — это еще не все. Рекомендую обратить внимание на ссылку, которой коллега любезно поделилась в комментариях к предыдущей статье — Ссылка, комментарий

Axe

Ссылка в Chrome Web Store.

Еще один инструмент для аудита страницы. Использует axe-core, созданный как опенсорс и поддерживаемый той же компанией, которая создала это расширение. Сам axe-core также часто используют для создания автотестов. Само расширение доступно через Dev Tools. По традиции запустим его на сайте Apple.

Работа расширения Axe на сайте компании Apple

Если сравнивать с аудитом проведенным Lighthouse, то к тому же списку добавилось несколько пунктов, которые относятся к разделу о Landmark-ах. Примеры ошибок с данной страницы:

  • Landmark роль присвоена для элемента;
  • Две одинаковых Landmark роли на странице;
  • Не весь контент на странице находится в Landmark контейнерах.

Также для некоторых проблем Axe просит проверить вручную действительно ли это баг или нет.

Пример сообщения о необходимости проверки вручную

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

NoCoffee и ChromeLens

Ссылка на Chrome Web Store — NoCoffee, ChromeLens.

Два расширения, которые позволяют имитировать разные проблемы со зрением на странице.

Пример работы расширения NoCoffee

Пример работы расширения ChromeLens

Это основная идея этих двух расширений. Дополнительный плюс ChromeLens в том, что он позволяет показать путь табуляции сквозь контент. Может быть полезно для визуализации проблем.

Пример пути табуляции в расширении ChromeLens

Букмарклеты

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

Spacing Validator

Ссылка на букмарклет.

Этот инструмент нужен для тестирования одного единственного пункта стандарта — 1.4.12 Text Spacing (Level AA). Данный скрипт меняет расстояния между буквами и словами, а также — высоту строки для проверки того, что контент все так же доступен. Иногда пользователи используют сторонние инструменты для того, чтобы улучшить читаемость текста. Вот как раз в таких случаях не должна существовать потеря доступа к контенту.

Пример работы букмарклета Spacing Validator.

Autocomplete validator

Ссылка на букмарклет.

Поскольку на данный момент autocomplete является единственным атрибутом, который позволяет полностью соответствовать пункту стандарта 1.3.5 Identify Input Purpose (Level AA), который появился в версии 2.1, то данный скрипт позволяет отобразить значение атрибута «autocomplete» над полем.

Пример работы букмарклета Autocomplete validator

WCAG parsing validator

Ссылка на букмарклет.

Данный букмарклет предназначен для фильтрации ошибок парсинга W3C валидатора. Скрипт оставляет только те ошибки, которые имеют отношение к доступности.

Для того, чтобы использовать данный инструмент, сначала нужно провалидировать исходный код страницы validator.w3.org/nu/#textarea, затем использовать букмарклет.

Пример работы букмарклета WCAG parsing validator

Tota11y

Ссылка на букмарклет.

Достаточно удобный и многофункциональный букмарклет. Добавляет кнопку в левый нижний угол страницы. Позволяет тестировать заголовки, контраст, «alt» текст, ярлыки.

Пример работы букмарклета Tota11y на сайте компании Apple

WAI-ARIA usage

Ссылка на букмарклет.

Данный инструмент создает отдельную страницу со статистикой использования WAI-ARIA атрибутов на сайте в очень удобном и читаемом формате.

Пример результатов аудита букмарклета WAI-ARIA

Заключение и ссылки

На данный момент существует множество разнообразных инструментов для тестирования доступности. Стоит использовать те инструменты, которые вам удобны. В данной статье я привел лишь то небольшое количество, которые мне понравились. Если вы пользуетесь другим набором инструментов для тестирования доступности, пожалуйста, поделитесь в комментариях ниже.

И, как и обещал, ссылки на сборники инструментов:

👍ПодобаєтьсяСподобалось13
До обраногоВ обраному7
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Чудові інструменти! WAVE прямо на цій сторінці 55 помилок знайшов :-D

Женя, дуже корисна збірка по тулзам 👍
Я про більшість навіть не чула

Отличный обзор

Класна стаття, спасибі за огляд та рекомендацію хороших інструментів для перевірки accessibility! NVDA супер)

Підписатись на коментарі