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

Практические рассмотрения

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

Одним частным соображением, которое, вероятно, еще более важно для пользователей с физическими недостатками, чем для других пользователей, будет то, с какими технологиями они знакомы. Вспомогательная технология может добавить много слоев сложности для их опыта работы с компьютером, создавая большое разделение между пользователями компьютеров новичками и опытными, и разделяя пользователей на сообщества, которые могут быть очень искусны со своей собственной настройкой, но крайне дезориентированы незнакомой технологией. (Представьте, как трудно бывает пользователям без физических недостатков, которые влияют на их возможности использования компьютеров, переключиться с компьютеров Mac на PC!)

Если взять опытного пользователя считывателя экрана Window-Eyes, посадить его перед незнакомой машиной с установленным считывателем экрана JAWS, и попросить его протестировать Web -сайт, то будет очень трудно отличить его проблемы с JAWS от проблем, которые создает Web -сайт.

Учитывая значительные различия между версиями и учитывая, как часто пользователи модифицируют свою настройку, это может быть трудно, даже если предоставить пользователю Window-Eyes! В связи с этим, если только вы не специально тестируете, как хорошо будет сохраняться доступность Web -сайта с незнакомыми настройками (например, в библиотеке или на компьютере приятеля), то лучше позволить пользователям тестировать со своей собственной настройкой или чем-то насколько возможно близким к ней.

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

Выбор задач

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

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

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

Например, при тестировании сайта общего доступа к видео на доступность не начинайте с вопроса о том, могут ли они использовать определенные элементы управления ("Это регулятор громкости. Можете ли вы настроить громкость?"). Вместо этого дайте им сценарий и попросите выполнить ключевые задачи пользователей. Например:

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

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

Интерпретация результатов

В идеальном мире можно было бы протестировать все возможные комбинации и получить ответную реакцию от каждого. Но в реальности время и деньги ограничивают тестирование пользователей. Поэтому ответная реакция может быть обоюдоострым мечом. Хотя она может многому научить, существует реальная опасность придания слишком большого веса мнению одного человека, которое может не отражать мнение большей целевой аудитории. Например, некоторые пользователи считывателей экрана стремятся найти материалы, предназначенные для слепых пользователей; другие же хотят узнать все о сайте, что видят их зрячие друзья и коллеги. Именно здесь на помощь приходят такие стандарты как WCAG. Следуя таким рекомендациям можно увеличить свои шансы получить основы доступности даже для групп пользователей, для которых тестирование было невозможно выполнить.

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

• Проблему с кодом сайта. Например, возможно разработчики создали таблицу данных с помощью бессодержательных элементов div, а не с помощью подходящей разметки таблицы данных. В этом случае подходящим действием будет перепрограммирование таблицы.
• Неопытность со стороны пользователя. Например, пользователь JAWS может быть незнаком со свойствами JAWS для перемещения и чтения табличных данных. В этом случае подходящим действием может быть предоставление дополнительной документации или советов для менее опытных пользователей. Если опытные пользователи не будут идеально подходить для такого тестирования, то они будут отличными консультантами в таких ситуациях.
• Проблема с агентом пользователя. Например, Safari представляет таблицы данных в модели доступности Apple как последовательность полей компоновки, а не как множество отношений данных. Здесь подходящими действиями будет сообщение об ошибке в агенте пользователя поставщику или разработчикам, поиск методов, которые работают в агенте пользователя, или отметка об ограничении в документации и предложение альтернативных агентов пользователя, которые работают с вашим Web -сайтом.
• Проблема со считывателем экрана. Например, разработчики могли укоротить длинные заголовки таблицы с помощью атрибута abbr, но считыватель экрана может не предоставлять интерфейс пользователя для чтения сокращенной версии. Здесь подходящим действием будет сообщение об ошибке в считывателе экрана поставщику или разработчикам, и может быть поиск метода, который работает в считывателе экрана, или отметка об ограничении в документации и предложение альтернативного инструмента или навигационной стратегии, которые работают.

Сообщение о результатах тестирования доступности

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

Например, вы могли бы сообщить о проблеме с Web -сайтом общего доступа к видео следующим образом:

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

Как воспроизвести: Откройте страницу в браузере и попытайтесь добраться до подпунктов меню с помощью только клавиатуры.

Объяснение: Навигация Web должна быть независимой от устройства, чтобы пользователи, использующие устройства отличные от мыши — такие как слепые пользователи или пользователи с моторными недостатками — могли получить доступ к контенту и функциям. В настоящее время такие пользователи не могут получить доступ к позициям в подменю, а зрячие пользователи использующие клавиатуру могут быть поставлены в тупик, когда индикатор фокуса исчезает.

Последствия для соответствия: Взаимодействие с клавиатурой является требованием соответствия WCAG 1.0 и WCAG 2.0 Level "A" (см. WCAG 1.0 Guideline 9 и WCAG 2.0 Guideline 2.1).

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

Заключение

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

Контрольные вопросы

• Попробуйте поперемещаться по сложному сайту на свой выбор без использования мыши. С какими трудностями вы столкнулись? Как разработчики сайта могут вам помочь?
• Отключите CSS и пользуйтесь обычным образом Интернет в течение дня. С какими проблемами вы столкнулись?
• Отключите JavaScript и пользуйтесь обычным образом Интернет в течение дня. С какими проблемами вы столкнулись?
• Выберите любимый сайт, создайте для этого сайта несколько персон, затем оцените его соответствие WCAG 1.0 и общую доступность как тестировщик эксперт. Создайте план тестирования пользователя для сайта, и включите требования для найма и задания для теста. Напишите отчет о том, как можно было бы улучшить его доступность.

Об авторе

После изучения в университете набора средневековых королей, ученых восемнадцатого века и других исторических эксцентрических личностей, Бенджамин Хоукс-Левис как-то оказался работающим в качестве разработчика Web в Yahoo!, к своему большому удовольствию. Его любимые занятия включают хорошую еду в компании друзей, хороший фильм в кинотеатре, лежание на траве на солнышке и решение трудных проблем, ссылаясь на первичные источники, основные принципы и эмпирические доказательства.

Источник: Ben Ward http://www.flickr.com/ photos/benward/ 2404982169/

Материалы этого курса имеют лицензию Creative Commons Attribution, Non Commercial - Share Alike 2.5 license.