Опубликован: 28.11.2008 | Доступ: свободный | Студентов: 7969 / 742 | Оценка: 4.49 / 4.28 | Длительность: 37:04:00
Лекция 26:

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

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

Рассмотрим особую важность создания доступного интерфейса пользователя 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 -сайтов.

Марина Медведева
Марина Медведева

Добрый день. Сегодня записалась на курс, хочу сразу оплатить, но не знаю, можно ли это сделать через сайт Интуит?

Кристина Семенова
Кристина Семенова

Здравствуйте,подскажите,можно ли оплатить курс частями?

Марина Дайнеко
Марина Дайнеко
Россия, Moscow, Nope, 2008
Анатолий Федоров
Анатолий Федоров
Россия, Москва, Московский государственный университет им. М. В. Ломоносова, 1989