Home

Автор: Ян Бин (Iain Bean)
Оригинал статьи
Перевод: Ольга Алифанова

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

Начнем с начала: выберите сайт для тестирования. Если у вас есть свой сайт, или сайт вашей компании – можете использовать их, а если вы ищете что-то совсем ужасное – множество примеров можно найти на Awwwards и Product Hunt.

0. Первые впечатления

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

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

Вот на что я смотрю:

• Читабельность. Насколько читабелен текст? Можно ли прочитать весь текст на обычном расстоянии от экрана, или нужно напрягать глаза?
• Метки. Есть ли интерактивные элементы или ссылки, представленные только картинками?
• Видео: проигрывается ли оно автоматически? Можно ли его остановить? Есть ли субтитры у видео с речью?
• Анимация. Не слишком ли много на сайте анимированных элементов? Не вызывают ли они тошноту?

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

1. Клавиша TAB

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

Важно отметить, что не все браузеры ведут себя одинаково. В Google Chrome и Microsoft Edge на MacOs, и во всех самых распространенных браузерах Windows клавиша Tab курсирует через все интерактивные элементы – ссылки, кнопки, поля форм. На MacOS есть два исключения:

Firefox на MacOS

В Firefox фокус получают только поля ввода и кнопки, но не ссылки. Перейдите в System Preferences → Keyboard, кликните на панель Shortcuts, и внизу будет или радиопереключатель All controls, или чекбокс "Use keyboard navigation to move focus between controls", в зависимости от версии MacOS. Выберите эту опцию (возможно, понадобится перезапустить Firefox).

В более старых версиях MacOS у вас есть вариант выбора между "только текстовые поля и списки" и "всеми элементами". Выберите все элементы.

Safari на MacOS

В Safari все так же, как и в Firefox – ссылки автоматически не подсвечиваются. Вам нужно перейти в меню Safari в верхнем меню, выбрать Preferences, перейти на вкладку Advanced, и в разделе Accessibility выбрать чекбокс "Press Tab to highlight each item on a web page"

Вернемся к навигации.

Первый элемент в Tab на Gov.UK – это ссылка перехода к основному содержимому – обычно хороший индикатор того, что про доступность все же не совсем забыли.

Используя клавиатуру для навигации по сайту, вы не ограничены клавишей Tab. Можно также воспользоваться комбинацией Shift+Tab, чтобы вернуться к предыдущему элементу, Enter для открытия ссылок, Space для скролла экрана вниз (или взаимодействия с выбранной кнопкой), и клавишами курсора (↑ / ↓ / → / ←) для переключения между вариантами радиокнопок и чекбоксов.

Если вы тянетесь за мышью или трекпадом, перетащите эту закладку на панель закладок. Ее нажатие полностью скроет курсор.

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

1. Проходя при помощи Tab по странице, видите ли вы, какие элементы находятся в фокусе? Зачастую разработчики (на которых, возможно, давят дизайнеры или менеджеры) убирают стиль фокуса по умолчанию по "эстетическим причинам".
2. На все ли интерактивные элементы можно навести фокус? Разработчики часто используют неправильный элемент (например, <div> с атрибутом события по клику) вместо более подходящего доступного элемента (вроде <button>).
3. В случаях, когда для модификации DOM используется JavaScript (к примеру, сайт использует роутинг на стороне клиента, ленивую подгрузку списка по мере прокрутки, или модальные окна), правильно ли работает фокус?

Учитывая, что первые две проблемы легко решить, следуя двум простым правилам – а) не удаляйте стиль фокуса и б) используйте семантически верный HTML-элемент, прямо-таки поразительно, как часто эти проблемы возникают. В статье I Used The Web For A Day With Just A Keyboard Крис Эштон приводит такой пример span, который должен быть ссылкой.

<span onclick="window.location = 'https://google.com'">Click here</span>

Этот элемент может выглядеть в точности как ссылка, но пользователь клавиатуры не сможет его использовать – на span нельзя навести фокус.

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

2. Автоматизированные тест-инструменты

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

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

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

На этом моменте я обычно запускаю Lighthouse. Если вы пользуетесь Google Chrome, это можно найти в инструментах разработчика. Для других браузеров его можно запускать из закладки или использовать сервис вроде Lighthouse Metrics. Lighthouse замеряет не только доступность: у него есть разделы для производительности, лучших практик и SEO. Не игнорируйте эти метрики – плохая производительность тоже влияет на доступность, а медленный сайт выведет из себя кого угодно.

Lighthouse ловит множество распространенных нарушений доступности, но вы обнаружите, что разные инструменты находят разные проблемы. Инициатива веб-доступности (WAI) перечисляет 155 различных инструментов оценки веб-доступности. Вот что стоит попробовать:

• axe – проверка доступности с расширениями для Chrome и Firefox. Основана на библиотеке JavaScript axe-core с открытым исходным кодом и нацелена на нулевое количество ложноположительных результатов.
• WAVE Web Accessibility Evaluation Tool – еще один автоматизированный инструмент проверки доступности, тоже имеет расширения для Chrome и Firefox.
• W3C Validator не предназначен для доступности как таковой, но как мы выяснили на шаге 1, хорошо написанный семантический HTML может помочь повысить искомую доступность.

Автоматизированные инструменты не могут найти все проблемы – их количество варьирует от 25-35 до 71%, если сравнивать результаты работы разных инструментов. Для поиска оставшихся проблем нужно задуматься о том, как люди с ограниченными возможностями пользуются сетью. В следующем шаге мы разберемся со вспомогательными технологиями и начнем пользоваться одной из них.

3. Тестирование экранного диктора

Вспомогательная технология – это устройство или система, поддерживающая и помогающая людям с ограниченными возможностями выполнять задачи, которые невозможно или сложно выполнить другим образом. Сегодня мы сконцентрируемся на экранном дикторе – программах, которые вслух читают содержимое экрана. Среди примеров – VoiceOver для Mac и iOS, JAWS и NVDA для Windows, и TalkBack для Android. Не все пользователи с ограниченным зрением используют экранные дикторы – некоторые пользуются экранной лупой вроде 'Zoom' для MacOS или Magnifier для Windows. Существуют также Обновляемые дисплеи Брайля, которые автоматически поднимают и опускают различные комбинации шпилек для динамического создания символов Брайля (так как они стоят от $3,500 to $15,000, я не буду сердиться, если вы еще не побежали в магазин).

Все экранные дикторы работают немного по-разному, поэтому имеет смысл проверить максимум возможных программ как на десктопе, так и на мобильных устройствах. Для удобства ознакомьтесь с экранным диктором на вашей машине. Я добавил несколько кратких руководств для старта – одно для Windows, второе для Mac.

NVDA для Windows

В Windows есть встроенный диктор экрана – Narrator, но большая часть пользователей экранных дикторов для Windows устанавливает другие приложения – наиболее популярны NVDA и JAWS. JAWS стоит $90 в год, а NVDA бесплатна и с открытым исходным кодом – начните с нее.

Скачав и установив NVDA, вы сможете открыть ее в любой момент, нажав Ctrl + Alt + N.

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

Теперь, если вы вернетесь в браузер (рекомендую использовать Firefox или Chrome), вы сможете путешествовать по странице при помощи клавиш из шага 1, но теперь NVDA будет озвучивать содержимое каждого элемента в фокусе (это называется "режим фокуса"). Если вы хотите услышать озвучку нефокусируемых элементов, воспользуйтесь кнопками курсора "вверх" и "вниз" (это называется "режим браузинга"). NVDA также озвучивает содержимое элементов, если вы навели на них курсор.

Большинство специфичных для NVDA команд клавиатуры используют клавишу-модификатор, которая нажимается вместе с другими клавишами. По умолчанию это Insert, но программу можно настроить и для использования Caps Lock (что делает ряд комбинаций выполнимыми одной рукой – гораздо проще). Я буду далее называть клавишу-модификатор просто NVDA.

У NVDA множество команд, расскажу о самых полезных:

• Ctrl останавливает речь.
• Shift ставит речь на паузу. Снова нажмите Shift, чтобы продолжить.
• H переходит к следующему заголовку. Используйте Shift и H для перехода к предыдущему заголовку.
• NVDA + Q выключает NVDA.
• NVDA + N выводит меню NVDA. Для зрячих изучающих  NVDA тут есть ряд полезных инструментов:
  • В Preferences → Settings… → Vision, включите 'Enable Highlight' для отображения рамки вокруг элемента в фокусе.
  • Tools → Speech viewer выводит окно, отображающее весь проговариваемый NVDA текст.

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

• Using NVDA to Evaluate Web Accessibility
• NVDA User Guide
• NVDA command key quick reference

VoiceOver для MacOS

Если вы пользуетесь Mac, то VoiceOver уже установлен. Для старта (или остановки) VoiceOver нажмите Cmd + F5, а если у вас Mac с Touch Bar, зажмите Cmd + тапните Touch ID / кнопку включения трижды.

При использовании VoiceOver лучший браузер – это Safari.

Для навигации при помощи VoiceOver используются клавиши-модификаторы (в дальнейшем помечены как VO) в комбинации с другими клавишами. Клавиши VO по умолчанию – это или Ctrl + Option (alt), или ⇪ Caps Lock.

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

Вы можете нажать Ctrl в любое время, чтобы поставить VoiceOver на паузу. Для возобновления снова нажмите эту клавишу.

VoiceOver рисует темную рамку вокруг области фокуса. Эта рамка называется "курсор VoiceOver". Для навигации можно пользоваться клавишами из шага 1, переходя между фокусируемыми элементами (ссылками, кнопками, полями), и курсор VoiceOver будет следовать за вами. Для передвижения курсора через все элементы, а не только фокусируемые, используйте VO + → / ←. VoiceOver озвучит текст каждого элемента, а если элемент интерактивен, сообщит, как с ним взаимодействовать.

Иногда, путешествуя по странице, вы наткнетесь на интерактивный элемент, содержащий другие элементы – например, панель инструментов, список, таблицу. Нажмите VO + Shift + ↓, чтобы начать взаимодействовать с элементом – думайте об этом как о перемещении курсора внутрь элемента. Затем можно взаимодействовать с его дочерними элементами, используя VO + → / ←; курсор VoiceOver останется на родительском элементе. Нажмите VO + Shift + ↑, чтобы выйти из элемента.

В любой момент можно вывести меню помощи VoiceOver при помощи сочетания VO + H.

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

• Using VoiceOver to Evaluate Web Accessibility
• VoiceOver User Guide

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

• Все ли изображения имеют значимый альтернативный текст?
• Имеют ли ссылки смысл вне окружающего их контента? Текст вроде "узнать больше" или "нажать здесь" ничего не говорит вам о том, на что вы нажимаете.
• Соответствует ли видимый контент тому, что вы слышите? Разработчики, которые хотят, как лучше, могут добавлять слишком длинные метки к элементу, или прятать видимые элементы от экранных дикторов, используя aria-hidden. Не все пользователи экранных дикторов слепы, и любое несоответствие между видимым и слышимым вызовет непонимание.

Если вы хотите разобраться, как пользователи экранных дикторов пользуются Интернетом, то рекомендую посмотреть видео How A Screen Reader User Surfs The Web с Леони Уотсон.

4. Дальнейшие шаги

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

• Прочитайте гайдлайны доступносит веб-содержимого (WCAG) – это набор рекомендаций для более доступных веб-страниц, который широко используется как основа для законов и политик доступности.
• Заплатите профессионалу доступности за тестирование сайта.
• Воспользуйтесь инструментами вроде Speedlify для периодического тестирования сайта, чтобы вовремя отловить регресс. Speedlify запускает как Lighthouse, так и ace, и его можно интегрировать в CI.

Заключение

Как все прошло? Если вы не нашли никаких проблем, мои поздравления! Сайты без проблем доступности – большая редкость: при опросе миллиона сайтов WebAIM выявил, что проблемы есть у 98,1% из них (исследование использовало автоматизированный инструмент – упомянутый выше WAVE). Думаю, что реальный шанс найти сайт без проблем доступности близок к нулю.

Если вы нашли крупные проблемы доступности, то они обычно вызваны или недостатком знаний, или победой эстетики над доступностью, или тем, что на разработчиков надавил другой отдел (к примеру, маркетинг). Если вы еще нуждаетесь в убеждении, или вам надо убедить кого-то еще в важности доступности, то рекомендую a11y.coffee в качестве введения. Если это не ваш сайт, обратитесь к ним публично – игнорирование доступности противоречит закону, и в 2019 году в США было подано 2256 исков о доступности.

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

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