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

Важность интерфейса пользователя

Рассмотрим особую важность создания доступного интерфейса пользователя Web -сайта. Даже если контент недоступен в подходящей форме, доступный интерфейс пользователя может помочь пользователям идентифицировать интересующий контент и найти внешнюю помощь для преобразования его в ту форму, которую они могут использовать. Например, плохо слышащий человек может быть направлен на видеозапись разговора на сайте видео без субтитров. Так как URL уникальным образом определяет это видео, и так как он может, тем не менее, использовать плеер для просмотра видео, то он может отправить ее третьей стороне, такой как бесплатная служба Project readOn (http://www.projectreadon.com/), для создания субтитров.

Персона с функциональными ограничениями

Идеальным подходом является встраивание ключевых функциональных ограничений для проекта в другие персоны пользователей (http://www.usability.gov/analyze/personas.html): т.е. фиктивных пользователей, которые действуют как архетипы для определения того, как некоторые типы пользователей будут использовать Web -сайт. Давайте предположим, что вы оцениваете прототипы для сайта общего доступа к видео и вашими персонами будут:

• 23-летний Джеймс Смит, который является фанатом футбола и особенно заинтересован в обмене фрагментами спортивных матчей с друзьями.
• 34-летняя Сара Мэдисон, которая является работающей матерью, которая может обычно не иметь времени для сайта общего доступа к видео. Но ее трехлетняя дочь, на самом деле, обожает смотреть видео, и Сара хочет сесть и помочь ей найти подходящие видео, которые она хочет посмотреть.

Вы можете взять эти персоны и добавить функциональные ограничения, включая (например):

• Нарушение зрения.
• Дальтонизм.
• Слепота.
• Глухота.
• Тугоухость.
• Слепоглухота.
• Эпилепсия.
• Дислексия.

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

Публикации WAI "Как люди с физическими недостатками используют Web " (http://www.w3.org/WAI/EO/Drafts/PWD-Use-Web) и Шауна Лоутона Генри "Просто спросите: Реализация доступности в ходе всего проекта" (http://www.uiaccess.com/accessucd/personas.html) содержат еще несколько примеров персон с физическими недостатками, которые вы можете использовать.

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

Снова сравнение продуктов согласно рекомендациям по доступности может помочь заполнить пробелы, которые не покрывают ваши персоны. Например, возможно, что вы следуете WCAG 2.0 для сайта общего доступа к видео, но ваши персоны не включают пользователя с эпилепсией. Тем не менее вы прочли Рекомендацию 2.3 ("Припадки: Не создавайте контент таким образом, про который известно, что он вызывает припадки") и решили, что система должна иметь возможность скрывать загружаемое для вывода видео прежде чем его показывать.

Выбор стандарта доступности

Если требуется выбрать стандарт доступности, чтобы управлять проблемами доступности Web в команде или просто для некоторых ориентиров во время тестирования, я посоветовал бы использовать проект стандарта WCAG 2.0, так как он:

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

Вы можете ссылаться на соответствие специфическому черновому варианту WCAG 2.0; однако для целей маркетинга лучше также найти кроме чернового варианта соответствие с готовым стандартом, таким как Section 508 и WCAG 1.0.

Смысл закона

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

Вот предостерегающая история. Section 508 (§ 1194.22) включает требование, которое говорит: "Для каждого нетекстового элемента должен быть предоставлен текстовый эквивалент (например, через alt, longdesc или в контенте элемента)." Аналогично, WCAG 1.0 включает контрольную точку, которая говорит:

Предоставляйте текстовый эквивалент для каждого нетекстового элемента (например, через alt, longdesc или в контенте элемента). Это включает: изображения, графические представления текста (включая символы), области карт ссылок, анимации (например, анимированные изображения GIF ), апплеты и программные объекты, изображения ascii, фреймы, сценарии, изображения в качестве меток списка, разделитель, графические кнопки, звуки (воспроизводимые с помощью или без помощи взаимодействия пользователя), автономные аудио-файлы, аудио треки для видео, и видео/

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

<img alt="fancy border" src="fancy-border.gif" border="0">

Фактически, так как эти изображения не несут никакой информации и не имеют никакой функции, правильным текстовым эквивалентом для этих изображений будет пустая строка ( alt =""), которая заставляет считыватель экрана просто пропустить атрибут alt и не читать его. Крайне неприятно для пользователя считывателя экрана слышать снова и снова повторяющийся текст "забавная граница", когда это не дает им никакой полезной информации.

WCAG 2.0 пытается быть понятнее. Эквивалентная рекомендация (http://www.w3.org/TR/WCAG20/#text-equiv) говорит: "Весь нетекстовый контент имеет текстовую альтернативу, которая предоставляет эквивалентную информацию, за исключением перечисленных ниже ситуаций". Одной из таких ситуаций является следующая: "Декорация, Форматирование, Невидимый: Если это чистая декорация, или используется только для визуального форматирования, или если не видно пользователям, то реализуется таким образом, что может быть проигнорировано вспомогательной технологией". В равной степени важно то, что WCAG 2.0 пытается уточнить обоснование в основе рекомендации: (http://www.w3.org/TR/2007/WD-UNDERSTANDING-WCAG20-20071211/text-equiv.html#text-equiv):

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

Кто должен тестировать?

Существует по сути две группы, которые выполняют тестирование: эксперты и пользователи.

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

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

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

Знания, полученные при тестировании пользователей, передаются в процесс тестирования экспертов, когда тестирование выполняется в следующий раз (либо при другой итерации тестирования того же проекта, либо совершенно другого проекта). Тестирование пользователей имеет также более тонкое преимущество. Очеловечивая доступность и объединяя разработчиков с конечными пользователями можно усилить мотивацию создания доступных Web -сайтов.