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

Рассмотрим особую важность создания доступного интерфейса пользователя 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, фреймы, сценарии, изображения в качестве меток списка, разделитель, графические кнопки, звуки (воспроизводимые с помощью или без помощи взаимодействия пользователя), автономные аудио-файлы, аудио треки для видео, и видео/ К сожалению, многие люди при чтении такой рекомендации неправильно понимают, каким должен быть текстовый эквивалент для разделителя и декоративных элементов, и создают разметку следующего вида:

Фактически, так как эти изображения не несут никакой информации и не имеют никакой функции, правильным текстовым эквивалентом для этих изображений будет пустая строка (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): Назначение этой рекомендации состоит в том, чтобы гарантировать, что весь нетекстовый контент будет также доступен в виде текста. "Текст" относится к электронному тексту, а не к изображению текста. Электронный текст имеет уникальное преимущество, так как его представление нейтрально. То есть его можно представить визуально, с помощью звука, тактильным образом или любой комбинацией. В результате информация, представленная в электронном тексте, может быть представлена в той форме, которая в наилучшей степени удовлетворяет потребностям пользователя. Его можно также легко увеличить в размере, произнести голосом, который легко понять, или представить в той тактильной форме, которая лучше всего удовлетворяет потребностям пользователя.

Что вызывает тренды на фондовых и товарных рынках Объяснение теории грузового поезда Первые 17 лет моих рыночных исследований сводились к попыткам вычислить, когда этот...

Что способствует осуществлению желаний? Стопроцентная, непоколебимая уверенность в своем...

Система охраняемых территорий в США Изучение особо охраняемых природных территорий(ООПТ) США представляет особый интерес по многим причинам...

Что делать, если нет взаимности? А теперь спустимся с небес на землю. Приземлились? Продолжаем разговор...

Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте: