От автора: в рамках подготовки к Всемирному дню осведомленности о доступности, команда Pulsar недавно получила доступ к своим функциям, занимаясь различными делами, чтобы улучшить доступность системы проектирования Pulsar и программного обеспечения, которое она обслуживает. Я потратил время на эксперимент с несколькими популярными расширениями и инструментами для проверки доступности, которые мы используем для проверки доступности наших пользовательских интерфейсов.
Эти инструменты дадут вам хорошую основу для доступности, прежде чем вы перейдете к пользовательскому тестированию с реальными людьми и / или полномасштабными аудитами доступности. Вы должны использовать эти инструменты для того, чтобы произвести тестирование доступности, так же, как вы проверяете свою разметку, используя валидаторы W3C, которые всегда были одним из самых основных тестов, которые мы все выполняем перед тем, как начать жить.
Расширения браузера (я использую Chrome для целей этого сообщения)
Другие инструменты
Tenon.io (бесплатные и платные тарифы)
Запуск теста
Мне нужен был реальный пользовательский интерфейс для тестирования, что-то довольно маленькое с несколькими элементами формы и взаимодействиями, поэтому я начал с того, где все наши пользователи Continuum запустили наш экран входа. Здесь немного дизайна взаимодействия, пользователи будут перемещаться между несколькими различными формами на месте, но не слишком много разметки, поэтому для целей этой публикации это хороший пример того, как мы можем работать с различными проблемами помечены инструментами.
Во-первых, давайте посмотрим, что каждый инструмент говорит нам, прежде чем мы вносим какие-либо изменения. Если инструмент дает мне возможность фильтровать результаты, я установлю его, чтобы показать мне что-либо, связанное с Руководством по доступности веб-контента 2.0 на уровне соответствия АА, хотя в нашем реальном тестировании мы также заинтересованы в рассмотрении соответствия раздела 508 для американского рынка.
Инструмент оценки веб-доступности WAVE
Как правило, первые разработчики расширений браузера думают о том, когда появляется тестирование доступности, но, как я покажу в сообщении, это, вероятно, не первый, к которому вы должны обратиться.
Нажатие кнопки WAVE на панели расширений Chrome отображает панель инструментов WAVE в виде столбца внутри вашего окна, здесь он показывает мне 1 ошибку и 9 предупреждений. Раньше мы уделяли основное внимание устранению «ошибок» в нашем внутреннем тестировании, но теперь мы увеличиваем сферу своей деятельности и в «предупреждениях».
WAVE накладывает значок для каждой проблемы в пользовательском интерфейсе, но смущает абсолютное позиционирование и не показывает никакой другой информации о связанном элементе, например, атрибутах разметки или идентификатора / класса. Это несколько проблематично, если у вас есть проблемы с частичными элементами пользовательского интерфейса, которые еще не видны, например, скрытые формы. Для того, чтобы определить элемент, вызывающий ошибку, требуется некоторая охота. Альтернативно, как было предложено Чарльзом Холом в комментариях ниже (ведущий разработчик WAVE), вы можете переключать режим «без стилей», который даст вам простой старый вид HTML вашего пользовательского интерфейса, но все же покажет значки WAVE рядом со связанными элементами. Это также имеет удобный эффект отображения любых частичных элементов пользовательского интерфейса, которые визуально скрыты с помощью CSS.
Проверка красного значка в пользовательском интерфейсе приводит меня к связанному элементу (изображение .signin-brand ', без атрибута
alt`
Lighthouse
Если вы используете последнюю версию Chrome, у вас, вероятно, уже есть Lighthouse, потому что он встроен! Откройте devtools и перейдите на вкладку «Аудит», нажмите кнопку «Выполнить аудит», и вам будет предоставлен список проверок, которые Lighthouse сможет выполнить, мы только проверим аудит доступности, чтобы сэкономить время.
Lighthouse немного мягче, чем WAVE для этого образца пользовательского интерфейса, только жалуясь на проблемы с alt и tabindex . Он показывает поврежденную разметку, но не выделяет или не перескакивает на затронутые элементы devtools. Это также самый медленный тест, рассмотренный здесь.
Интересно, что Lighthouse использует ax-core (о котором мы говорим далее) для его аудита доступности, но я подозреваю, что не запускает полный набор из ~ 70 тестов, которые делают расширение топора, мне нужно посмотреть на это немного больше …
Расширение браузера aXe
Я большой поклонник aXe, расширение добавляет новую вкладку в Dev Tools от Chrome с синей кнопкой «анализ», как только вы нажмете на нее, вам показывают очень хороший список проблем (я отфильтрован до просто покажите нарушения здесь, но есть также список других вещей для обзора) с действительно полезной связанной информацией.
Каждая проблема четко показывает соответствующую разметку, ударяя «inspect node», перепрыгивая обратно на вкладку элементов DevTools, выделяя элемент.
aXe оценивает влияние a11y-проблем по-разному на WAVE, в этом примере проблема с альтернативным текстом имеет решающее значение, проблема tabindex серьезна, а другие умеренные. Стоит отметить, что эта презентация заставляет меня разрешать все нарушения, потому что она говорит мне, что их девять, а не WAVE, сообщивших мне, что есть одна ошибка и девять предупреждений.
aXe также перечисляет вещи для обзора, которые конкретно не вызывают нарушения руководящих принципов доступности, но, возможно, их необходимо учитывать на основе фактического контекста элемента в пользовательском интерфейсе. Изображение галактики, лежащее за нашим пользовательским интерфейсом входа, на самом деле является видео, которое особо не нуждается в подписях или дорожке аудио-описания, но, возможно, ему нужно только обозначать только презентацию. Я пока не могу этого сделать, потому что мы используем стороннюю библиотеку для вставки элемента video, но это то, что я должен рассмотреть в будущем.
Интересно, что aXe достаточно умен, чтобы знать, что синяя коробка, содержащая нашу форму, имеет непрозрачность (0,9) с изображением за ней. Проблемы с цветовым контрастом отмечены, поскольку инструмент не может гарантировать, что цвет фона позволит обеспечить требуемый уровень контрастности переднего текста (это действительно так, но полезно напомнить, чтобы проверить).
WCAG Accessibility Audit Developer UI
Он проверил только четыре вещи и передал их все. В корзине с тобой.
Я удалил его.
SiteImprove Accessibility Checker
SiteImprove очень популярен в водах, в которых мы плаваем (местное и центральное правительство, высшее образование, некоммерческое и т. д.). Поэтому очень полезно иметь инструмент SiteImprove для проверки доступности наших пользовательских интерфейсов.
Этот инструмент дает много актуальной информации о проблемах, хотя я нахожу, что он указан в списке, который будет более сложным для сканирования, и вам нужно щелкнуть по проблеме, чтобы получить подробную информацию об этой проблеме, а затем вернуться в основной список, чтобы увидеть ваши проблемы. Я предпочитаю точный мастер / подробный вид, но SiteImprove делает все возможное с единственным ограничением столбца.
Tenon.io
Tenon отличается, поскольку это веб-сервис, который вы можете использовать так же, как W3C HTML Validator, которого мы все знаем и любим, но для доступности. Просто дайте ссылку или вставьте разметку вашего пользовательского интерфейса, и она создаст отчет для вас. Есть несколько (платных) способов интеграции Tenon с инструментами сборки или CI-серверами, но это мясо для другого сообщения в блоге.
Это медленнее, чем тесты в браузере, но главное предостережение при передаче URL-адреса в версию браузера состоит в том, что для вашего сайта / интерфейса пользователь должен публично получить доступ к Tenon. Пока я просто собираюсь использовать ngrok для создания временного общедоступного URL-адреса для моего локального хоста и предоставить эту ссылку для Tenon.
Оценки доступных дверей?
За исключением одного шамболического усилия, все инструменты дали довольно последовательные результаты для этого, по общему признанию, ограниченного теста UI. Для меня, чтобы дать им какую-то форму ранжирования, это сводилось к тому, как представлена информация и какие инструменты она дает мне для решения проблем, которые она поднимает. Реалистично нет серебряной пули, и мы, скорее всего, будем использовать большинство, если не все эти инструменты, чтобы проверить работоспособность каждого пользовательского интерфейса, но первым инструментом, который я использую почти во всех случаях, является расширение браузера тонов в Chrome. Информация ясна, хорошо организована, а интеграция с подсветкой и инструментальными инструментами — это лучший инструмент из тех, которые я тестировал до сих пор. Я также очень заинтересован в интеграции ядра ax или tenon.io в наш процесс CI в ближайшем будущем для более автоматизированного тестирования.
Итак, с точки зрения результатов, мой личный порядок полезности:
aXe
SiteImprove
Tenon
WAVE
Lighthouse*
* Я бы не списал Lighthouse как несущественный, пока Google продолжает обновлять количество проверок, которые он будет продолжать улучшать.
Исправления
Поэтому я знаю, что у меня есть все, чтобы исправить, и, честно говоря, я не собираюсь вас утомлять, я буду использовать aXe во время моего первоначального прохода, а затем посмотрю, что мне говорят другие инструменты.
Исправления, вкратце, включали:
Добавление alt-текста в изображение бренда Continental
Добавьте main оболочку вокруг содержимого, чтобы действовать как aria-ориентированный регион
Измените текст «Pulsar» на заголовок h1 (с исправлениями CSS для поддержания размера)
Удаление кода javascript, который добавляет добавочные значения tabindex (1, 2, 3 и т. д.) в пользу просто 0 или -1
Добавлены атрибуты id в формы «забытый пароль» и «авторизация», чтобы действовать как цель для связанных пропусков
После этих исправлений давайте возьмем их за другое вращение в инструментах тестирования.
ax = Нарушений нет
WAVE = нет ошибок, нет предупреждений
Lighthouse = нет ошибок
SiteImprove
OK, поэтому SiteImprove все еще не доволен …
Во-первых, давайте разберемся в этом вопросе с контрастом, ранее используя aXe, мы увидели, как он не мог понять цвет нашего фона из-за непрозрачности контейнера, но это не то, что SiteImprove жалуется на …
SiteImprove считает, что фон всех этих элементов белый, честно говоря, я не уверен, почему, но я подумал, что, возможно, он игнорирует видео, а резервное изображение не загружается, а цвет фона в базовом элементе body конечно, белый. Таким образом, установка явного цвета для контейнера под видео держит SiteImprove счастливым в этом случае и улавливает любые ситуации, когда изображение и резервное изображение не загружаются при сохранении белого текста. Стоит исправить.
Далее — обходные блоки.
SiteImprove хочет, чтобы я разместил ссылку на верхний уровень для контента, в которой мы могли бы работать со всем нашим пользовательским интерфейсом, так что это легко проверить.
Предупреждение «Введите свое имя пользователя и пароль» — это элемент с ролью = «alert»
Наконец, это aria-atomic вещь, мы используем aria-live область, используя role=»alert» (текст «Pulsar»), чтобы изменить отображение предупреждений или ошибок, когда пользователь пытается войти в систему, любое изменение содержания здесь объявляется приложением для чтения с экрана.
Добавление aria-atomic=»true» гарантирует, что скрин ридер объявит весь регион, если его часть изменится, в этом случае он действительно не нужен, но SiteImprove не знает, что мы всегда будем обновлять весь регион, так что это хорошо, чтобы убедить инструмент в том, что это произойдет, и гарантировать поведение на экране.
Итак, еще несколько быстрых настроек, и все готово! SiteImprove счастлив!
Tenon.io
Наконец, еще немного от Tenon…
Первые два связаны с тем, что метки полей не являются уникальными. Как наши формы входа, так и забытые пароли запрашивают имя пользователя, а Tenon дает нам правильные рекомендации об их обертке в fieldset, однако после этого он по-прежнему обозначает это как ошибку на момент написания. Я считаю, что это ошибка, и я вернул ее в поддержку Tenon.
* Обновление * Начиная с публикации, Tenon подтвердил, что это ошибка, и исправит ее в предстоящем выпуске.
Другой последний жалуется на href=»#» в некотором примерном коде для этого пользовательского интерфейса, Tenon громко жалуется на абсолютно каждый экземпляр использования символа хэша в качестве href поэтому, если вы хотите протестировать прототип, образец или демонстрационный код вы обнаружите, что вы вытираете их по всему месту. Если вы используете <a href=»#»>something like this</a> в качестве триггера для поведения javascript, вы должны использовать вместо него button или если он абсолютно должен быть ссылкой, то, возможно, вам нужна фактическая ссылка в качестве резервной копии, когда js не загружается, а не пустой хеш. Обычно у вас нет реального времени для использования href=»#» в производственном коде, поэтому хорошо, что Tenon ловит это.
Заключение
После экспериментов с этим набором инструментов для проверки доступности на основе браузера, самое главное, что нужно убрать, это то, что ни один инструмент не дал мне полный список проблем, обнаруженных другими, вам действительно нужно протестировать несколько инструментов.
Я в значительной степени принял расширение браузера aXe в качестве своего основного инструмента тестирования, как только я разрешил любые проблемы там, я перехожу на SiteImprove, Tenon.io, а затем WAVE. Это позволяет мне устранить множество проблем с доступом в наших пользовательских интерфейсах и очистить колоды от нас, чтобы провести тестирование устройств с помощью вспомогательных технологий, таких как устройства чтения с экрана. Подробнее об этом скоро.
И еще раз, для тех, кто доходит до конца статьи, чтобы найти лист ответов, мой личный порядок полезности:
aXe
SiteImprove
Tenon
WAVE
Lighthouse
Если есть какие-либо другие инструменты или методы, которые вы используете для хорошего эффекта, пожалуйста, дайте мне знать!
Автор: Paul Stanton
Источник: //medium.com/
Редакция: Команда webformyself.