От автора: в этой статье будет рассмотрена проверка доступности сайта, показано, как использовать автоматические и ручные средства для работы с настольными и мобильными версиями. Мы рассмотрим пять инструментов тестирования доступности, которые могут быть установлены либо как расширения браузера, либо букмарклеты JavaScript. Я укажу все плюсы и минусы каждого инструмента тестирования, опишу лучшие функции отдельного инструмента и покажу, какие проблемы доступности хорошо распознает каждый инструмент.
Важно помнить, что автоматические интсрументы тестирования доступности никогда не смогут заменить ручное считывание экрана и тестирование на клавиатуре. Мы обсудим, как автоматизированные инструменты для проверки доступности по страницам вписываются в процесс ручного тестирования и как использование автоматизированных инструментов на ранних этапах разработки может сэкономить время тестировщиков QA, чтобы избежать документирования очень простых проблем доступности.
Мы поговорим о том, какие инструменты тестирования работают на настольных веб-браузерах, а какие инструменты тестирования можно использовать непосредственно с мобильного устройства. Если вы тестируете настольные и мобильные представления с учетом настроенного дизайна, вы можете использовать те же инструменты для проверки доступности на рабочем столе, чтобы протестировать сайт RWD.
Изучение доступности через инструменты тестирования
Установка и использование инструментов автоматического и ручного тестирования доступности — отличный способ для разработчиков и тестировщиков QA изучить доступность, не вникая в сложность обучения ручному тестированию экранного ридера.
Инструменты тестирования специальных возможностей помогут изучить доступность веб-страниц, поскольку большинство из них содержат какую-либо справочную документацию ошибок или выполняют работу, указывая на ошибки, которые можно научиться избегать при кодировании.
Вместо того, чтобы сначала изучать WCAG, можно напрямую использовать инструменты тестирования доступности и знать, что если исправить все проблемы, о которых сообщают несколько инструментов, сайт, вероятно, будет достаточно доступен, даже не прочитав WCAG или не используя программу чтения с экрана.
Инструменты тестирования не могут найти все проблемы с доступностью, поэтому всегда требуется ручное тестирование с использованием клавиатуры и устройства чтения с экрана.
Изучение и использование инструментов тестирования vs. чтение экрана
Гораздо проще узнать, как использовать простой инструмент тестирования специальных возможностей, чем программное обеспечение вспомогательных технологий. Чтение экрана очень сложный процесс, и иногда тестеры могут сообщать ложноположительные ошибки доступности, основанные на недоразумениях относительно нормального поведения считывателя. Возможно, потребуется установить платное устройство чтения с экрана, или оно может замедлить работу системы. Могут быть другие причины, по которым не всегда есть возможность тестировать чтением экрана.
Тестирование только на клавиатуре
//pauljadam.com/demos/focusvisible.html
Тестирование на одной только клавиатуре — это простой и мощный метод тестирования доступности, который гарантированно найдет проблемы либо с отсутствующими индикаторами фокуса клавиатуры, либо просто без фокусировки и без клавиатуры. Современная сеть ужасна при проектировании и кодировании для работы с клавиатурой, поэтому, прежде чем тратить слишком много времени на изучение экранных программ, обязательно выполняйте базовую проверку на клавиатуре с помощью TAB, проводя навигацию по странице, и попробуйте другие ключи для сложных виджетов, например, Escape для меню и диалога, Up/ Down/ Right/ Left стрелки для других настраиваемых элементов управления.
ARIA Authoring Practices покажет вам, как пользовательские элементы управления и виджеты должны вести себя и как они должны быть закодированы для чтения экрана и клавиатуры пользователей.
Точное тестирование доступности для разработчиков и дизайнеров
//www.w3.org/TR/wai-aria-practices/examples/landmarks/main.html
Преимущество автоматических средств тестирования доступности — как можно раньше заставить разработчиков и дизайнеров использовать эти инструменты и решить свои проблемы доступности до того, как они перейдут на QA и тестеры доступности. Использование автоматизированных инструментов на ранних этапах разработки может сэкономить время тестировщикам QA, чтобы они не тратили его на документирование простейших проблем доступности, которые разработчики могли заметить с помощью одного из этих инструментов тестирования.
Если вы когда-либо писали отчет о доступности с сотней и более проблем, вам бы не хотелось тратить время на создание проблем и рекомендаций для простых сбоев, вроде отсутствующего текст, отсутствующих ярлыков или низкого цветового контраста, который легко может обнаружить автоматизированный инструмент.
Интеграция инструментов в процесс проверки доступности вручную
Во время ручного чтения экрана и тестирования доступности только на клавиатуре также можно запускать автоматические инструменты тестирования из расширений браузера и букмарклетов, чтобы найти больше проблем.
Использование этих инструментов в основном представляет собой комбинацию ручного процесса тестирования области проверки или пользовательских потоков, а для каждой посещаемой страницы, экрана или диалога нужно запускать все любимые инструменты тестирования доступности, документировать проблемы, а затем выполнять чтение и тестирование клавиатуры до или после использования автоматизированных инструментов.
У каждого есть другой процесс и поток для тестирования доступности, нет правильного или неправильного порядка, поэтому он помогает запускать несколько тестовых инструментов, тестировать только на клавиатуре, тестировать с помощью нескольких программ чтения экрана, а также тестировать на iPhone или iPad, чтобы найти еще больше проблем. Чем больше методов тестирования вы используете, тем больше проблем найдете, и в конечном итоге выберете некоторые из любимых инструментов и методов и повторите их для всех веб-сайтов, которые тестируете.
Пять инструментов проверки доступности для вашего инструментария
WAVE
aXe
a11yTools
tota11y
HTML_CodeSniffer
Это пять инструментов проверки доступности, которые я хотел бы использовать на регулярной основе для тестирования доступности и отчетности. У каждого инструмента есть свои плюсы и минусы, и у каждого есть определенные проблемы с доступностью, для идентификации которых они отлично подходят.
Тестеры доступности имеют разные настройки для инструментов, а также те браузеры и инструменты разработчика, которые они используют. Я пользователь MacOS и iOS, и Safari — мой любимый браузер для личного использования и для проверки кода и тестирования.
Safari и Chrome – два моих главных браузера, иногда я использую Firefox для тестирования инструментов и двойной проверки некоторых проблем, например, таких как видимость клавиатуры.
Хорошие / плохие возможности демонстрации и тестирования страницы
Чтобы узнать, как использовать инструменты тестирования доступности, запустите их на некоторых хороших и плохих страницах демонстрации доступности, прочитайте все ошибки, которые появляются на плохих страницах, затем запустите их на хороших страницах и посмотрите различия.
Я буду использовать эти три сайта в качестве примеров тестирования для инструментов.
WAVE
WAVE был одним из первых инструментов тестирования доступности, который я когда-либо использовал, и я все еще считаю его очень ценным, когда тестирую.
WAVE доступен для Firefox, Chrome в качестве расширений браузера, или вы можете использовать его с веб-сайта WAVE в качестве онлайн-инструмента тестирования. Расширения браузера WAVE намного мощнее, чем веб-сайт WAVE, потому что вы не сможете использовать онлайн-WAVE за защищенными паролем веб-сайтами, и иногда онлайн-версия не работает на очень сложных веб-сайтах. Расширения WAVE работают за брандмауэром, быстрее запускают тесты и обрабатывают сложные веб-сайты.
Основные шаги использования WAVE — посетить каждую страницу, которую вы хотите протестировать, и нажать кнопку значка WAVE в расширении браузера, чтобы увидеть нарушения доступности.
Нажимайте значки, которые появляются, и вы можете прочитать ошибки доступности или сообщения об успешности в подсказках значков.
Перейдите на вкладку Contrast, чтобы увидеть цветные контрастные ошибки в тексте. Автоматизированные инструменты обычно не обнаруживают ошибок контраста с помощью заполнителей или изображений текста, поэтому протестировать нужно вручную. Для ручной контрастной проверки того, что пропустит автоматический инструмент, я рекомендую Colour Contrast Analyser.
Вкладка No Styles покажет страницу без стилей CSS и упростит поиск значков ошибок WAVE, которые были визуально скрыты из-за макета страницы. Поэтому помните, когда вы не видите значки ошибок на странице, они могут быть визуально скрыты, и вам нужно проверить их на вкладке No Styles.
Ссылка для скачивания
Вы можете посетить WAVE Online Report наших страниц тестирования, даже если не можете установить расширения браузера. Помните, что расширения браузера будут работать за сайтами, защищенными паролем и паролем, тогда как онлайн-версия WAVE не будет тестировать сайты с поддержкой входа в систему.
Inaccessible University WAVE Report
Accessible University WAVE Report
«+»
Иконки с ошибками доступности и всплывающие подсказки в WAVE превосходны и понятны.
WAVE Online-сервис означает, что он может работать на любом веб-сайте, не имеющего логин.
Расширения для Chrome и Firefox.
Ни одна кнопка стилей не помогает найти проблемы со сложными веб-страницами, которые визуально скрыты, но все же ошибки.
WAVE Online позволяет вам следить за сайтом и тестировать новые страницы по мере их загрузки.
WAVE доступен только для чтения экрана и клавиатуры.
Я могу использовать WAVE Online в Safari, когда тестирую публичный сайт.
Тесты для возможных заголовков, в которых отсутствуют теги заголовков.
«-»
Иногда WAVE не может обрабатывать очень сложные веб-сайты.
Иногда ошибки трудно увидеть, если вы не нажмете кнопку No Styles.
WAVE Online работает медленнее, чем расширения Chrome и Firefox.
aXe
Это платформа тестирования доступности, основанная на JavaScript, которая может быть запущена множеством способов, например, при непрерывном тестировании сборки интеграции, запускаться из командной строки с консоли JavaScript или из расширений браузера с помощью пользовательского интерфейса. Самый популярный способ использования aXе, вероятно, через расширения Chrome и Firefox, которые предоставляют пользовательский интерфейс для вывода ошибок доступности.
aXe – расширение для браузера
Если вам нужен aXe в Safari, у меня есть в a11yTools и в ярлыке JavaScript, но у него нет пользовательского интерфейса, поэтому результаты нужно читать в консоли.
«+»
Философия «без ложных срабатываний» означает, что вы не будете перегружены множеством ошибок доступности.
Дополнительная справочная документация объясняет проблему и ее устранение.
Может запускаться из любого браузера в консоли JavaScript.
Непрерывная интеграция, тестирование командной строки, автоматическое тестирование сборки.
Точные тесты для повышения чувствительности при отключении в мета вьюпорте.
«-»
Никакие ложные срабатывания не могут означать, что при обнаружении других ошибок не могут возникнуть ошибки доступности.
Как и большинство инструментов, вы не найдете проблем с элементами, которые не работают на клавиатуре, например, div с событием JavaScript onclick.
aXe визуально не выделяет ошибки на странице, где они легко выделяются.
Проблемы в расширениях считываются по одной, приходится многократно нажимать Next.
Мне не нравится, что aXe говорит разработчикам, что можно исправить недостающее имя доступной формы, используя Aria-метку, потому что тогда метка не будет видна.
a11yTools
a11yTools — это расширение браузера Safari, которое я разработал как набор всех моих любимых инструментов тестирования доступности в одном месте в Safari, и которое является моим основным веб-браузером для личного использования и программой чтения экрана VoiceOver.
«+»
Работает на Safari!
Также большинство инструментов доступны в JavaScript Bookmarklet для любого браузера.
Объединяет все эти инструменты в одно расширение Safari с более полезными документами, такими как спецификация ARIA, практика ARIA, контрольный список WCAG и т. Д.
a11yTools — это инструмент тестирования по времени, в котором вы выбираете элемент или функцию HTML a11y, и вы тестируете по одному, а не сразу запускаете все тесты.
Расширение Safari будет работать на дополнительных защищенных веб-сайтах, которые блокируют букмарклеты JavaScript.
Имеет старую платформу инструментов разработчика Google Accessibility, в которой есть неплохие тесты.
Включен инструмент тестирования оттенков серого.
«-»
Нет расширения Chrome или Firefox.
Не запускает сразу все тесты, только по одному.
Не всегда имеет последнюю топовую версию, так как разработчик должен вручную обновлять ее при появлении новых выпусков.
tota11y
tota11y может иметь самое крутое имя из группы инструментов тестирования. tota11y — еще один букмарклет JavaScript, который будет работать в любом браузере. Закладки отлично подходят для тестирования цветового контраста, когда у вас нет инструмента ручного тестирования, доступного на устройстве, вроде iPhone.
«+»
tota11y классное имя
Инструмент тестирования заголовков отлично подходит для тестирования неправильных уровней заголовков и вложенности и не запускает страницу с элементом H1.
Отличается цвет от любого браузера, потому что это букмарклет.
Тесты на отсутствие меток.
«-»
Инструмент тестирования ориентиров ARIA кажется менее полезным, чем некоторые другие.
Иконки выглядят одинаково, поэтому они не выпрыгивают визуально так же быстро, как другие инструменты.
HTML_CodeSniffer
HTML_CodeSniffer это букмарклет JavaScript, который я использую уже очень давно. Мне нравится, что он работает в Safari, потому как есть возможность тестировать на iOS, используя VoiceOver. CodeSniffer может подавлять сложные веб-сайты, потому что генерирует большое количество ошибок, и могут возникнуть ложные срабатывания в зависимости от методов, выбранных разработчиками.
Нужно прощёлкать по всем проблемам, чтобы увидеть подробности для каждого типа интерфейса aXe.
«+»
Тестирование цветов и рекомендации по решению проблем.
vПоказывает HTML код ошибки, связанные с этим ошибки WCAG и методы решения.
Букмарклет, поэтому он работает во всех браузерах.
Тестирование iframe.
Тесты для значений атрибутов повторяющихся идентификаторов.
«-»
Проблема перегрузки! Сначала обязательно отключите предупреждения, чтобы уменьшить шум.
Ложные срабатывания.
Имейте в виду, как прочитать все результаты и узнать, что игнорировать, а что очень полезно.
Мне не нравится, что CodeSniffer говорит, что вы можете использовать атрибут title для исправления ввода формы без доступного имени, потому что тогда метка не будет видна.
Инструменты тестирования: настольная версия vs мобильная
Некоторые из инструментов в этом списке будут запускаться из мобильного браузера, такого как Mobile Safari в iOS или Chrome на Android. tota11y и HTML_CodeSniffer будут работать из любого веб-браузера, потому что это ярлыки JavaScript, которые не установлены как расширение.
Тестирование сайтов адаптивного дизайна
Вы можете использовать эти те же инструменты тестирования, чтобы протестировать отзывчивый веб-сайт, отрегулировав размер окна браузера, чтобы он был маленьким, как телефон или планшет, или увеличивая размер текста до самого большого, пока вы не активируете размеры вьюпорта мобильного устройства и, например, не отобразите гамбургер меню. После того, как вы запустите отзывчивые представления из своего веб-браузера, вы можете запустить все инструменты проверки доступности, которые мы рассмотрели.
Для мобильных сайтов, которые обслуживают разные HTML-представления на основе строки User Agent String, вы можете переключить пользовательский агент вашего браузера, например, iPhone или iPad на рабочем столе Safari в меню Develop. Переключите пользовательский агент на мобильную строку, и теперь браузер загрузит мобильный контент, и вы сможете запускать все эти автоматизированные средства тестирования и выполнять ручную проверку клавиатуры и проверку работоспособности.
Вывод
Инструменты проверки доступности — отличный способ изучить доступность и двойную или тройную проверку, если ваш сайт доступен. Существуют инструменты проверки доступности для вашего браузера по выбору или букмарклета JavaScript, которые будут запускаться в любом браузере. Не забудьте объединить инструменты тестирования доступности с помощью ручного считывателя экрана и тестирования работоспособности клавиатуры, и вы обнаружите больше проблем и создадите более удобный веб-сайт.
Поделитесь этими инструментами тестирования доступности с разработчиками и дизайнерами и попросите их протестировать их работу как можно раньше и чаще, поэтому большинство вопросов можно устранить, прежде чем они попадут к тестировщикам QA или другим экспертам.
Есть много доступных инструментов тестирования, но у меня не было времени, чтобы охватить их всех в одной статье. Я больше связан с моей страницей ресурсов, и, пожалуйста, поделитесь своими любимыми инструментами тестирования в комментариях ниже.
Есть ли определенная функция тестирования, которую вы хотите или нуждаетесь в инструменте тестирования? Дайте нам знать в комментариях, может быть, кто-то еще знает об инструменте, который может выполнить эту работу, или, может быть, вы будете мотивировать кого-то создавать их.
Автор: Paul J Adam
Источник: //www.24a11y.com/
Редакция: Команда webformyself.
