Home

Автор: Артём Сапегин
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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

1. (для проектов на React) Установите плагин React ESLint, и исправьте все соответствующие проблемы.
2. Запустите FastPass в расширении браузера Accessibility Insights, чтобы найти две самые распространенные проблемы доступности, и исправьте их.
3. Пройдитесь по сайту или приложению при помощи Tab клавиатуры, чтобы проверить навигацию с клавиатуры и состояния фокуса.

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

Плагин React ESLint

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

eslint-plugin-jsx-a11y ищет множество проблем доступности в React-проектах – например, отсутствующий альтернативный текст у изображений или неверные атрибуты и роли ARIA.

К сожалению, он несколько ограничен в возможностях:

• Статический анализ кода находит лишь некоторые проблемы.
• Он работает только с элементами чистого HTML, и ничего не знает о кастомных компонентах.

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

Axe-core

Axe-core – это библиотека, проверяющая доступность HTML в браузере. Она более мощная по сравнению со статическим анализом кода вроде ESLint, так как находит больше проблем – например, убеждается, что у текста достаточный цветовой контраст.

На базе этой библиотеки основано множество инструментов.

Для Storybook есть аддон a11y:

Для React Styleguidist можно добавить react-axe вручную:

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

Cypress-axe

Если мы не тестируем доступность сайта или приложения после каждого изменения, то рано или поздно столкнемся с регрессом. Поэтому важно сделать тестирование доступности частью непрерывной интеграции (CI). Нельзя вливать код в базу, не проверив его на доступность.

Cypress-axe создан на основе axe-core. Он позволяет запускать тесты доступности внутри end-to-end тестов Cypress, и это хорошо – мы, скорее всего, уже прогоняем такие тесты в ходе непрерывной интеграции, где и отрисовываем все наши страницы. Проверки можно также прогнать несколько раз, тестируя страницы в разных состояниях – к примеру, с открытым модальным окном или раскрытой секцией контента.

Эти тесты могут быть неплохим смоук-тестом доступности, убеждающимся, что мы не сломали сайт или приложение. Однако cypress-axe неудобен для анализа страниц, уже имеющих проблемы доступности. Для этого лучше подходит браузерное расширение вроде Axe или Accessibility Insights.

Здесь можно узнать больше о настройке и использовании cypress-axe.

Совет: для автоматизированного тестирования доступности отдельных компонентов хорошим инструментом может быть jest-axe.

Расширение браузера Axe

Расширение Axe для Chrome и Firefox основано на axe-core. Однако это расширение запускается на реальном сайте или приложении, и находит проблемы, которые невозможно найти при работе с отдельным компонентом – например, проверяет корректность структуры заголовков или значимых областей.

Это расширение отлично подходит для аудита доступности, но надо не забывать запускать его каждый раз, когда в приложении что-то добавляется или меняется. Иногда оно выдает ложноотрицательные результаты – например, если не может определить цвет фона и сообщает, что у текста недостаточный цветовой контраст.

Расширение браузера Accessibility Insights

Расширение браузера Accessibility Insights от Microsoft тоже основано на axe-core, но у него есть ряд уникальных особенностей.

Accessibility Insights имеет автоматизированные проверки, похожие на расширение Axe, но также подсвечивает проблемы напрямую на странице:

Accessibility Insights также имеет инструкции для множества ручных проверок, которые нельзя автоматизировать.

Функция FastPass ищет две наиболее распространенных проблемы доступности, и это хороший шаг к улучшению доступности сайта или приложения.

И, наконец, расширение может подсвечивать заголовки, значимые области и tab-остановки (см. раздел "Клавиша Tab") на странице:

Приложение Contrast и проверка контраста в Chrome DevTools

Иногда нам нужно проверить цветовой контраст на макете или где-либо еще, где невозможно или неудобно запускать расширение браузера.

Для проверки цветового контраста в браузере хорошим вариантом будет проверка контраста Chrome DevTools (инспектируйте элемент и нажмите на иконку цвета вкладки Styles):

В прочих случаях используйте приложение Contrast, выбирая цветовую пару при помощи пипетки:

Бонус: Веб-приложение Contrast ratio от Леи Веру – еще один способ проверить контраст, если вы хотите поделиться ссылкой на результаты проверки.

Расширение для Chrome Spectrum

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

Бонус: Chrome DevTools умеют эмулировать некоторые из этих нарушений. Нажмите Escape, выберите вкладку "Отрисовка" из меню в правой части панели, и перейдите к секции "Эмулировать дефекты зрения".

Кнопка Tab

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

• Все интерактивные элементы имеют фокус и видимое состояние фокуса.
• Порядок Tab имеет смысл; как правило, он соответствует визуальному порядку следования элементов на странице.
• Фокус пойман в модальные окна – переход по tab назад на страницу за спиной модального окна невозможен, пока оно не закрыто, и как только оно закрыто, фокус возвращается в элемент, вызвавший модальное окно.

• Ссылка пропуска навигации должна появляться, если Tab нажата впервые:

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

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

Совет: я часто использую меняющееся выражение в document.activeElement Chrome DevTools, чтобы видеть, какой элемент в фокусе ("Создать меняющееся выражение" в панели инструментов консоли). Это помогает найти элементы без видимого состояния фокуса, а также невидимые элементы, фокус на которых возможен.

Бонус: No Mouse Days пакет npm, созданный Марси Саттон, отключает курсор мыши, чтобы повысить клавиатурную поддержку сайта или приложения.

Зум

Увеличивая сайт или приложение, можно проверить, как оно реагирует на зум. Попробуйте увеличить его на 200% в браузере и посмотреть, что отвалится. Многие (в том числе я) увеличивают экран, когда текст чересчур мелок, и поэтому надо убедиться, что верстка не съезжает, текст не обрезается, и элементы не наезжают друг на друга.

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

Экранный чтец

Используя сайт или приложение с экранным чтецом, можно проверить, что:

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

Тестирование с экранным чтецом очень похоже на тестирование с клавиатуры. Так как мы не можем видеть экран (и я рекомендую выключить его или закрыть глаза в ходе тестирования), мы не можем пользоваться мышью или трекпадом для выбора элементов страницы – к ним можно только перейти по Tab с клавиатуры. Главное отличие тут в том, что мы не можем опознать такие элементы, как кнопка, зрительно, или связать поля ввода с их метками по их местоположению. Мы должны выявить эти взаимоотношения, используя семантическую разметку или атрибуты ARIA.

В macOS уже есть VoiceOver. В Windows есть встроенный Narrator, бесплатный NVDA, и платный JAWS. Существует также ChromeVox, который можно установить как расширение Chrome.

Совет: для начала работы с VoiceOver прочитайте эту статью и сохраните этот чит-лист.

Бонус: воспользуйтесь вкладкой "Специальные возможности" в Chrome DevTools, чтобы проверить, как вспомогательные технологии видят отдельные элементы:

И многое другое

Вот что еще стоит протестировать:

• Режим чтения в браузере – это инструмент доступности: он помогает читателям сконцентрироваться на основном содержании или сделать цвета читабельными. Его также можно использовать как быстрый способ тестирования семантической разметки страниц: мы должны видеть заголовок основной страницы, полное основное содержание, все изображения, и не видеть ничего лишнего вроде декоративных изображений или баннеров.

• Снижение движения – это опция операционной системы, сообщающая сайтам и приложениям (при помощи запроса prefers-reduced-motion), что пользователь предпочитает минимизировать излишнее шевеление на экране. Это можно использовать для отключения анимации на вещах, открывающихся по скроллу или в карусели.
• Темный режим может быть опцией сайта, приложения или операционной системы, считываемой через запрос prefers-color-scheme. Нужно убедиться, что наш сайт или приложение, особенно его цветовая схема, доступны в темном режиме.
• Альтернативы при наведении курсора для клавиатур и тачскринов: наведение курсора не должно быть единственным способом получения контента или интерактивного элемента. Частый пример – это меню, появляющееся при наведении курсора на элемент длинного списка. Другой пример – подсказка. Эти элементы можно показывать пользователям клавиатуры, когда их контейнер в фокусе, и всегда показывать на тачскринах.

Совет: Используйте запрос взаимодействия CSS any-hover для тестирования поддержки наведения курсора на устройстве – однако опасайтесь неверных допущений.

Совет: Можно использовать Cypress и cypress-axe для тестирования доступности сайта или приложения в темном режиме.

Дополнительная информация:

• Accessible to all
• Color contrast guide
• Accessibility for teams
• Web accessibility course от Google
• The a11y project accessibility checklist
• Writing HTML with accessibility in mind от Мануэля Матузовича
• Writing JavaScript with accessibility in mind от Мануэля Матузовича
• Writing CSS with accessibility in mind от Мануэля Матузовича
• Beyond automatic accessibility testing: 6 things I check on every website I build от Мануэля Матузовича
• Assistive technologies I test with от Дейва Руперта
• Testing web accessibility от Адриана Болонио
• 16 things to improve your website accessibility (checklist) от Брюса Лоусона
• The business case for digital accessibility
• Getting Started with VoiceOver & Accessibility от Сью Локвуд

Заключение

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

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

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

Автоматизированное тестирование доступности дешево в запуске и бережет нас от регресса. Однако оно позволяет найти лишь некоторые проблемы.

Обсудить в форуме