Тестирование доступности: что это, зачем и как

Тестирование доступности — не самая частообсуждаемая тема на QA-конференциях и встречах. В сентябре Senior QA Engineer и руководитель QA-отдела Noveo Анастасия приняла участие в первом санкт-петербургском митапе по веб-доступности, где выступила с докладом о тестировании доступности. В связи с этим мы бы хотели обсудить, что вообще такое тестирование доступности (accessibility testing), почему веб нужно делать доступным, как можно тестировать доступность вручную и с использованием автоматических средств, а также развеять несколько связанных с темой мифов.

Noveo accessibility testing

Что такое тестирование доступности?

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

Как обеспечивается доступность цифровых технологий в мире, где почти все так или иначе ведет нас в веб? Как минимум, люди с особыми потребностями используют технологии, которые помогают им в обращении с ПО.

Вот примеры таких утилит:

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

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

Почему нужно тестировать доступность?

1. Учет людей с инвалидностью как части аудитории

Около 20% населения — люди с особыми потребностями. К особым потребностям относятся как постоянные нарушения здоровья (инвалидность, ухудшение здоровья с возрастом), так и временные потребности: травма, необходимость держать на руках ребенка, работа на улице в слишком ярком солнечном свете и даже похмелье.

2. Соблюдение законодательных норм

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

Таким образом, исходя из таких постановлений, как:

  • United States: Americans with Disabilities Act — 1990;
  • United Kingdom: Disability Discrimination Act — 1995;
  • Australia: Disability Discrimination Act — 1992;
  • Ireland : Disability Act of 2005;
  • Россия: Федеральный закон от 24.11.1995 N 181-ФЗ (ред. от 18.07.2019) «О социальной защите инвалидов в Российской Федерации», Статья 14. «Обеспечение беспрепятственного доступа инвалидов к информации»;

тестирование доступности обязательно для соблюдения законов.

Какие виды особых потребностей нужно учитывать?

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

 

Вид нарушений Примеры
Нарушения зрения
  • Полная слепота, слабое зрение или цветовая слепота;
  • необходимость пользоваться устройством в условиях яркой освещенности (например, на открытом воздухе в очень солнечный день);
  • человек со слабым зрением забыл очки.
Физические нарушения
  • Трудности с использованием мыши/клавиатуры одной рукой; нарушения моторики;
  • травма запястья;
  • невозможность пользоваться обеими руками одновременно, т.к. нужно держать на руках ребенка.
Когнитивные нарушения
  • Трудности с обучением или восприятием сложносоставных сценариев;
  • побочные действия от приема лекарственных препаратов;
  • усталость, стресс.
Нарушения слуха
  • Слабый слух;
  • глухота;
  • необходимость расслышать звук в очень шумной обстановке.
Нарушения чтения
  • Трудности при чтении: например, дислексия;
  • Необходимость читать на иностранном языке.

Как тестировать доступность?

1. Вручную

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

Если же у компании нет возможности привлечь к тестированию доступности людей с особыми потребностями, не все потеряно: существует довольно много гайдлайнов тестирования доступности для людей без инвалидности. Самый простой способ — по очереди «отключать» у себя органы чувств: попробовать взаимодействовать с приложением без звука, с разной степенью яркости, контраста и насыщенности экрана (или даже без возможности видеть экран совсем — для самых ответственных), использовать ТОЛЬКО мышку или ТОЛЬКО клавиатуру и так далее.

Другой вариант — воспользоваться готовыми чит-листами. Например, вот перевод чит-листа с сайта guru99, который мы предлагаем вам как один из вариантов:

  1. Есть ли у приложения клавиатурные эквиваленты для всех действий с мышкой, включая взаимодействие с окнами/вкладками?
  2. Есть ли инструкции по взаимодействию с приложением, включенные в пользовательскую документацию? Легко ли взаимодействовать с приложением, используя документацию?
  3. Логично ли расположены разделы приложения, чтобы навигация была понятной?
  4. Есть ли у приложения горячие клавиши для взаимодействия с разными меню?
  5. Все ли операционные системы поддерживает приложение?
  6. Ясно ли упомянуто нормальное время загрузки страниц/экранов, чтобы конечный пользователь знал, как долго ждать их?
  7. Все ли ярлыки/названия описаны корректно?
  8. Для всех ли доступна цветовая схема приложения?
  9. Корректно ли использованы изображения и логотипы, понятны ли их значения пользователям?
  10. Есть ли в приложении аудиосигналы?
  11. Может ли пользователь кастомизировать элементы управления аудио или видео?
  12. Может ли пользователь изменить шрифты по умолчанию для отображения и печати?
  13. Может ли пользователь включить/выключить мигания, вращение или перемещение контента на экране?
  14. Необходимо убедиться, что изменения цвета никогда не используются как единственное средство передачи информации или индикации действий пользователя.
  15. Видно ли подсвечивание текста с инвертированными цветами? Как меняется цвет приложения при изменении контрастности экрана?
  16. Доступен ли аудио- и видеоконтент для людей с нарушениями слуха? Как меняется взаимодействие пользователя с приложением, если колонки отключены?
  17. Существует ли обучающий тренинг, знакомящий с приложением людей с особыми потребностями и упрощающий их взаимодействие с ним?

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

2. Автоматически

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

  1. Wave
  2. TAW
  3. Accessibility Valet
  4. Accessibility Developer Tools
  5. Quick Accessibility Page Tester
  6. aDesigner
  7. WebAnywhere
  8. Web accessibility toolbar

Мифы о тестировании доступности

Если тестирование доступности так необходимо и, гипотетически, не слишком сложно, почему же это до сих пор не стало обязательной и повсеместной практикой?

К сожалению, тестирование доступности до сих пор окружено рядом мифов и предрассудков. Давайте рассмотрим некоторые из них.

Миф: создание доступного веб-сайта — это дорого

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

Миф: приведение недоступных сайтов к доступному виду дорого и требует много времени

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

Миф: доступность — это однообразно и скучно

Факт: доступность не значит одну лишь высококонтрастную текстовую страницу (наоборот, World wide web consortium не рекомендует использовать на страницах только текст). Обеспечение доступности — это ещё и дизайнерский челлендж: как сделать веб-сайт привлекательным и доступным? Как улучшить пользовательский опыт, не нарушая соответствия гайдлайнам доступности для всех пользователей (см. W3C стандарт: https://www.w3.org/WAI/)? Скучать с такими задачами точно не придется.

Миф: доступность — это только для людей с инвалидностью 

Факт: следование нормам доступности улучшает общее качество и удобство использования ПО, что помогает и пользователям без особых потребностей. Мы уже упоминали, что каждый из нас в результате травмы, стресса или определенных обстоятельств может оказаться человеком с особыми потребностями. Кроме того, все мы рано или поздно состаримся, и в наших силах обеспечить себе комфортное будущее, в котором нам не придется отказываться от новых технологий из-за их недоступности и неадаптированности к нашим потребностям.

Noveo accessibility testing

Дополнительные материалы

Почитать:

Посмотреть:

Ссылка на презентацию с митапа: https://docs.google.com/presentation/d/1zNZedNzhwkU6JdefjYek6zvgMyhli6p2VEVBS-H-w18