Тестирование доступности Web является подмножеством тестирования Web. Конечная цель как Web -сайт, и использовании этой информации для улучшения будущих конструктивных решений и реализаций.
Обычно оценка доступности более формализована, чем тестирование Web, таких как законодательство Section 508 федерального правительства США и Рекомендации по доступности контента Web ( WCAG ) консорциума W3C.
Однако важно различать подчинение стандарту и максимизацию доступности Web -сайта. В идеале они должны совпадать, но любой данный стандарт может не работать, потому что:
Такие слабости могут привести тех, кто имеет хорошие намерения, на неверный путь и могут недобросовестно использоваться теми, кто пытается протолкнуть неподходящие продукты.
Более того, доступность ).
Физические недостатки ставят специальные задачи при выяснении, насколько легко использовать продукт, так как они могут создавать дополнительный разрыв восприятия между пользователями и экспертами-оценщиками. Оценка доступности должна принимать во внимание, что значит воспринимать Web с помощью других чувств и познавательных возможностей, и различные необычные конфигурационные возможности и специальное программное обеспечение, которые обеспечивают доступ в Web для людей с конкретными недостатками.
Если вы попытаетесь оценить Web -сайта, с точки зрения киномана тинейджера или 50-летнего банковского менеджера, то сопоставить эти оценки будет трудно, даже еще до рассмотрения физических недостатков. Но что если киноман тинейджер будет глухим и нуждается в субтитрах для фильмов, которые он смотрит? Что если 50-летний банковский менеджер является слепым и использует специальную технологию (такую как считыватель экрана), которая незнакома оценщику, для взаимодействия со средой своего настольного компьютера и браузером Web?
Рекомендации по доступности и инструменты помогают ликвидировать этот разрыв в восприятии. Однако они являются дополнением, а не заменой, для чуткого воображения, технической изобретательности, и разговора с пользователями.
В этой статье рассматриваются подходы к оценке доступности Web, как с точки зрения создания формального соответствия, так и с точки зрения максимизации доступности. Статья имеет следующую структуру:
"Тестируйте рано, тестируйте часто" является старой поговоркой программирования.
Надежда на тестирование в конце процесса разработки содержит две опасности:
Поэтому для обеспечения качества и сохранения времени и денег оценка доступности должна начинаться с самого начала создания продукта и включаться в последующие итерации разработки до окончательной поставки.
Прежде чем начинать оценку проекта в отношении доступности, необходимо определить, какие ключевые требования существуют для этого проекта, с учетом его рабочей среды, предполагаемой аудитории, и ресурсов. Некоторые требования будут задаваться независимыми сторонами, такими как правительство и клиенты, некоторые вы сможете выбрать самостоятельно.
Часто требования приходят из внешних источников, таких как:
Shell в настоящее время пытается реализовать на своих Web -сайтах требования соответствия уровню "Double-A" рекомендаций WCAG 1.0, поэтому при разработке Web -сайта для Shell вы должны будете удовлетворить (по крайней мере) тому же стандарту.Section 508, может помочь продаже проекта озабоченным доступностью клиентам.Важно получить как можно более четкое представление о внешних требованиях. Некоторые стандарты доступности имеют более одного возможного уровня или типа соответствия, поэтому особенно важно определить, что требуется. Например, WCAG 1.0 имеет три уровня соответствия:
Черновой вариант WCAG 2.0 также имеет три уровня, но возможности соответствия более сложные. Когда ресурс является частью последовательности ресурсов, представляющих процесс (например, поиск продукта, выбор, подсчет стоимости, и подтверждение покупки для онлайнового магазина), то уровень соответствия для всех ресурсов в последовательности определяется ресурсом с самым слабым уровнем.
Требования соответствия должны основываться на технологии "поддерживающей доступность" контента. Такая технология должна:
Отметим, что в сети интернет можно гарантировать, что такие агенты пользователя будут доступны пользователям, в то же время это невозможно гарантировать в Web. Например, приложение может использоваться без какой-либо коммерческой технологии, но быть доступно для считывателей экрана с коммерческим подключаемым модулем, для которого организация имеет лицензию. Это приложение могло бы соответствовать WCAG 2.0 при развертывании в интранет организации, но не соответствовать при развертывании в публичной Web.
WCAG 2.0 допускает также более ограниченные заявления о соответствии. Недоступный ресурс может информировать, если предоставляется доступная альтернатива. Издатели могут делать заявление о частичном соответствии, когда контент формируется из других источников.
Определение внешних требований должно быть только началом процесса; они должны интерпретироваться как минимальный набор требований, к которым должны быть добавлены дополнительные характеристики, чтобы максимизировать доступность. Ваша роль, как человека оценивающего доступность, состоит в том, чтобы определить дополнительные средства доступности, так как вы являетесь экспертом в этой области.
Может понадобиться разграничить два набора требований при создании окончательного отчета. Например, техническое задание заказчика для онлайнового супермаркета может говорить, что они хотят сделать магазин доступным для слепых пользователей. С учетом предполагаемой аудитории необходимо также оценить, будет ли магазин доступен пользователям с другими физическими недостатками.
Отметим, что внешние требования соответствия определенному стандарту не обязательно препятствуют использованию лучших рекомендаций из других стандартов. Например, вы можете оценивать Web -сайт для федерального агентства, предназначенный для использования пожилыми гражданами, который должен соответствовать Section 508. Закон Section 508 обусловливает, что:
§ 1194.22 (c) Страницы Web должны создаваться таким образом, чтобы вся информация, передаваемая с помощью цвета, была доступна также без цвета, например, из контекста или разметки.
Это положение помогает пользователям, которые знают как изменить представление контента Web, но не максимизирует доступность используемого по умолчанию представления этого контента для целевой аудитории, обеспечивая достаточный контраст между предложенными цветами. К счастью, ничего не мешает Web -сайту выполнить это требование, но также удовлетворить следующим положениям чернового варианта Рекомендаций до доступности контента Web 2.0:
1.4.3 Контраст (Минимальный): Текст и изображения текста имеют относительный контраст не менее 5:1, за исключением следующего: (Уровень AA)
Примечание: Критерии успеха 1.4.3 и 1.4.6 могут удовлетворяться посредством управления контрастом, доступного на или со страницы.
1.4.6 Контраст (Улучшенный): Текст и изображения текста имеют относительный контраст не менее 7:1, за исключением следующего: (Уровень AAA)
Примечание: Критерии успеха 1.4.3 и 1.4.6 могут удовлетворяться посредством управления контрастом, доступного на или со страницы.
Под
WCAG 2.0 был создан с требованием высокой степени обратной совместимости с другими стандартами, особенно WCAG 1.0 и Section 508.
Рассмотрим особую важность создания доступного интерфейса пользователя ), для создания субтитров.
Идеальным подходом является встраивание ключевых функциональных ограничений для проекта в другие персоны пользователей (http://www.usability.gov/analyze/personas.html): т.е. фиктивных пользователей, которые действуют как архетипы для определения того, как некоторые типы пользователей будут использовать Web -сайт. Давайте предположим, что вы оцениваете прототипы для сайта общего доступа к видео и вашими персонами будут:
Вы можете взять эти персоны и добавить функциональные ограничения, включая (например):
Например, вы можете определить, что Джеймс является также глухим и хочет, чтобы комментарии к видео матчей были в виде субтитров, а
Публикации l) содержат еще несколько примеров персон с физическими недостатками, которые вы можете использовать.
Нет необходимости об этом и говорить, но не предполагайте, что люди с физическими недостатками будут взаимозаменяемыми. Физический недостаток является крайне изменчивым явлением, и кроме этого, люди с физическими недостатками варьируются в той же степени, что и люди без физических недостатков, различаясь (например) по полу, возрасту, интересам, ценностям, и навыкам (возможно, наиболее уместно, в своем опыте работы с компьютером).
Снова сравнение продуктов согласно рекомендациям по доступности может помочь заполнить пробелы, которые не покрывают ваши персоны. Например, возможно, что вы следуете WCAG 2.0 для сайта общего доступа к видео, но ваши персоны не включают пользователя с эпилепсией. Тем не менее вы прочли Рекомендацию 2.3 ("Припадки: Не создавайте контент таким образом, про который известно, что он вызывает припадки") и решили, что система должна иметь возможность скрывать загружаемое для вывода видео прежде чем его показывать.
Если требуется выбрать стандарт доступности, чтобы управлять проблемами доступности Web в команде или просто для некоторых ориентиров во время тестирования, я посоветовал бы использовать проект стандарта WCAG 2.0, так как он:
CSS (таким как Flash).Вы можете ссылаться на соответствие специфическому черновому варианту WCAG 2.0; однако для целей маркетинга лучше также найти кроме чернового варианта соответствие с готовым стандартом, таким как Section 508 и WCAG 1.0.
При тестировании согласно рекомендациям, важно помнить нижележащее обоснование любого конкретного технического требования: чтобы соответствовать смыслу, а не только букве закона.
Вот предостерегающая история. Section 508 (§ 1194.22) включает требование, которое говорит: "Для каждого нетекстового элемента должен быть предоставлен текстовый эквивалент (например, через alt, WCAG 1.0 включает контрольную точку, которая говорит:
Предоставляйте текстовый эквивалент для каждого нетекстового элемента (например, через alt, GIF ), апплеты и программные объекты, изображения ascii, фреймы, сценарии, изображения в качестве меток списка, разделитель,
К сожалению, многие люди при чтении такой рекомендации неправильно понимают, каким должен быть текстовый эквивалент для разделителя и декоративных элементов, и создают разметку следующего вида:
<img alt="fancy border" src="fancy-border.gif" border="0">
Фактически, так как эти изображения не несут никакой информации и не имеют никакой функции, правильным текстовым эквивалентом для этих изображений будет пустая строка ( alt =""), которая заставляет считыватель экрана просто пропустить атрибут alt и не читать его. Крайне неприятно для пользователя считывателя экрана слышать снова и снова повторяющийся текст "забавная граница", когда это не дает им никакой полезной информации.
) говорит: "Весь нетекстовый контент имеет текстовую альтернативу, которая предоставляет эквивалентную информацию, за исключением перечисленных ниже ситуаций". Одной из таких ситуаций является следующая: "Декорация, Форматирование, Невидимый: Если это чистая декорация, или используется только для визуального форматирования, или если не видно пользователям, то реализуется таким образом, что может быть проигнорировано вспомогательной технологией". В равной степени важно то, что ):
Назначение этой рекомендации состоит в том, чтобы гарантировать, что весь нетекстовый контент будет также доступен в виде текста. "Текст" относится к электронному тексту, а не к изображению текста. Электронный текст имеет уникальное преимущество, так как его представление нейтрально. То есть его можно представить визуально, с помощью звука, тактильным образом или любой комбинацией. В результате информация, представленная в электронном тексте, может быть представлена в той форме, которая в наилучшей степени удовлетворяет потребностям пользователя. Его можно также легко увеличить в размере, произнести голосом, который легко понять, или представить в той тактильной форме, которая лучше всего удовлетворяет потребностям пользователя.
Существует по сути две группы, которые выполняют тестирование: эксперты и пользователи.
Тестирование экспертов важно, так как эксперты понимают, как взаимодействуют нижележащие технологии Web, могут действовать в качестве центра обмена знаниями о различных группах пользователей, и имеют склонность к изучению специальных средств тестирования.
Тестирование пользователей критически важно, так как пользователи являются реальными экспертами своих возможностей и своей собственной вспомогательной технологии. Тестирование пользователей может также показать пробелы Web -сайтом (такими как сами тестировщики-эксперты) и людьми, которые такими не являются (новые пользователи).
Разработчик Web, который знает, как использовать считыватель экрана, скорее всего, будет исследовать Web -сайт несколько иначе, чем обычный пользователь считывателя экрана, а пользователи считывателя экрана, которые программировали свои собственные сценарии, скорее всего исследуют сайт с помощью других стратегий, чем пользователи считывателя экрана, которые выполняют обыкновенные вычислительные задачи, такие как создание сообщения e-mai l.
Знания, полученные при тестировании пользователей, передаются в процесс тестирования экспертов, когда тестирование выполняется в следующий раз (либо при другой итерации тестирования того же проекта, либо совершенно другого проекта). Тестирование пользователей имеет также более тонкое преимущество. Очеловечивая доступность и объединяя разработчиков с конечными пользователями можно усилить мотивацию создания доступных Web -сайтов.
Существует четыре компонента для экспертного тестирования:
Web -сайтом. Часто не требуется слишком углубленного рассмотрения, чтобы обнаружить проблемы доступности. Вы можете только загрузить страницу в свой браузер и заметить, что текст очень трудно прочитать.Web -сайта работают вместе.Web -сайта, чтобы исключить возможные проблемы.В то время как начинающие оценщики могут быть особенно зависимыми от инструментальной оценки, оценщики любого уровня подготовки могут получить пользу от каждого компонента. Даже начинающие могут заметить элементы img без текстового эквивалента в разметке HTML, а с получением дополнительного опыта вы станете быстрее выявлять проблемы, прежде чем переходить к более строгому тестированию. Для экспертов в больших проектах может быть невозможно вручную просмотреть весь клиентский код или проинспектировать все части Web -сайта, но инструментальная оценка может обнаружить области, вызывающие особую тревогу, которые заслуживают более тщательного рассмотрения. Оценщики люди могут также просмотреть вещи, которые заметит машинная оценка.
К сожалению, хотя существует множество инструментов доступности, большинство из них являются неполноценными тем или иным образом. Например, один инструмент, который перечисляет заголовки в документах HTML, делает ошибку, не включая весь текст из элементов img. Также как вы должны помнить о смысле закона в отношении соответствия стандартам, вы должны помнить об этом при использовании инструментов. Прежде чем сообщать кому-то о проблеме доступности, проверьте, что это действительно проблема, а не ошибка инструмента.
Когда очевидные проблемы будут исправлены, следующим шагом было бы неплохо подвергнуть страницу проверке с помощью полуавтоматического средства контроля доступности. При оценке соответствия определенному стандарту, вы, вероятно, захотите выбрать один из таких инструментов, созданный для использования с этим стандартом.
При оценке соответствия ) является разумным выбором. При тестировании согласно немецкому )
Такие инструменты имеют значительные ограничения. Не существует такой вещи, как полностью автоматизированное тестирование доступности. Например, учитывая примитивную природу современного искусственного интеллекта, компьютерная программа не может окончательно сказать, будет ли некоторый текст настоящим эквивалентом фотографии в контексте. Даже в областях, которые могут быть теоретически полностью автоматизированы, программисты средств проверки могут ошибаться в своей интерпретации рекомендаций по доступности и терять смысл закона среди его букв.
Хорошие инструменты проверяют страницу на наличие проблем доступности и создают список того, что они считают ошибками, и другой список того, что они считают заслуживающим проверки человеком. Например, если программа Cynthia Says находит элемент img с alt =" ", она создает предупреждение (не ошибку!), инструктируя пользователя "проверить, что это изображение используется только для интервала или дизайна, и не имеет никакого значения". Если правильным текстовым эквивалентом для этого изображения является пустая строка, нужно будет просто перейти к следующей ошибке или предупреждению.
Возможно самое большое преимущество средств проверки доступности состоит в том, что если выбрать одно из них, такое как ), которое может выполняться на нескольких URL, то можно найти страницы в больших совокупностях, которые требуют, видимо, более тщательной проверки.
Многие инструменты инспекции созданы для исследования структуры Web -контента.
Структура, говоря просто, определяет какие имеются компоненты Web -сайта, и как они связаны друг с другом. Например, в объектной модели документа (DOM) HTML текст может быть обозначен как метка поля формы с помощью элемента label. Браузеры преобразует код HTML в объектную модель документа. Браузер связывает различное поведение с определенными компонентами. Например, если щелкнуть на метке флажка, то он будет обычно инициирован.
Настольные рабочие среды и приложения поддерживают интерактивность со считывателями экрана, программным обеспечением распознавания речи, и другими вспомогательными технологиями, предоставляя аналогичную структуру, которая представляет контент и функции, доступные в визуальном представлении. В ). Например, диалоговое окно имеет ряд связанных потомков, таких как заголовок, поля, кнопки, и метки.
Типичная вспомогательная технология имеет дело в основном с представлением браузеров и подключаемых модулей Web -контента в терминах этих структурных систем, а не с обработкой объектных моделей Web -документов непосредственно.
Существуют средства инспекции, как для структур уровня настольного компьютера, так и для объектных моделей уровня ) и Accessibility Verifier (http://developer.apple.com/documentation/Accessibility/ Conceptual/AccessibilityMacOSX/OSXAXTesting/chapter_5_Section_3.html). Microsoft предоставляет инструменты инспекции для Microsoft Active Accessibility 2.0 и Microsoft Active Accessibility 1.3. Accerciser (http://live.gnome.org/Accerciser) доступен для вспомогательной технологии GNOME -- SPI API.
Инструментами для записи в объектную модель документа ) и
Инспекторы DOM показывают дерево элементов, атрибутов и текст, созданный из сериализации (X)HTML, в то время как инспекторы доступности Web абстрагируют отдельные компоненты или отношения и перечисляют их. Например, они могут перечислить все поля с их метками или все заголовки, или все ссылки.
Обычно для (X)HTML не требуется разбирать модель доступности, хотя вы можете захотеть исследовать этот слой, если считаете, что браузер представляет правильную структуру (X)HTML неправильно для вспомогательной технологии. Вместо этого вы будете обычно проверять структуры (X)HTML непосредственно.
Не весь контент может инспектироваться с помощью DOM или инспекторов доступности Web. Инспекция того, что доступно для структур доступности уровня настольного компьютера важна для проверки того, какой контент подключаемого модуля (медиа-плееров, контента Flash, и апплетов Java ) доступен вспомогательной технологии, которая использует эти модели доступности.
Обычно необходимо проверить, что все элементы управления доступны в модели с соответствующей ролью (например, текстовые поля являются текстовыми полями, кнопки - кнопками) и необходимыми свойствами.
Скрининг включает моделирование во время тестирования опыта работы людей с физическими недостатками. Это может принимать форму использования вспомогательной технологии для взаимодействия с сайтом или попытки ограничить чьи-то возможности некоторым образом. Например:
Скрининг может помочь разработчику создать приложение в соответствии с потребностями людей с физическими недостатками и может выявить фундаментальные недостатки дизайна. Использование вспомогательных технологий может снять определенные заблуждения в отношении того, насколько они соответствуют или не соответствуют стандартам Web. Например, популярные считыватели экрана не используют стили, предложенные для типов медиа CSS, соответствующих прослушиванию или азбуке Брайля, пытаясь вместо этого представить тип экрана, предоставленный визуальными браузерами, с которыми они взаимодействуют.
Использование вспомогательных технологий не является легкой задачей, так как хорошее понимание того, как использовать такие системы может требовать некоторой степени погружения и обучения. Существует серьезный риск создания новых заблуждений. Разработчики могут попытаться что-то сделать со считывателем экрана и предположить, что это отражает недостатки считывателя экрана, когда на самом деле это отражает их неопытность в обращении с инструментом. Они могут пытаться использовать инструмент неправильным образом, например, пытаться прочитать страницу последовательно, когда реальный пользователь считывателя экрана будет перемещаться по ней, используя заголовки и другие элементы, пытаясь найти интересующие его моменты. Или наоборот, они не смогут правильно прочитать экран. Чтение страницы, которую можно видеть или хорошо знать, с помощью считывателя экрана, очень отличается от исследования совершенно нового сайта, который вы не можете видеть.
Использование вспомогательной технологии должно сопровождаться опытом того, как повседневные пользователи используют технологию, и заключения, извлеченные из такого использования, должны в идеале подтверждаться пользователями экспертами. В целом, начинающим тестировщикам лучше передать использование вспомогательной технологии пользователям тестировщикам.
Когда все настоящие проблемы, идентифицированные выбранным инструментом проверки, были исправлены, можно перейти к тестированию вручную, испытаниям, и рецензированию проекта.
Проект WCAG 2.0 делит свои критерии лучших методов согласно четырем принципам. Контент и функции должны быть:
Web -сайтом без мыши и перемещение по нему с помощью считывателя экрана).Web -сайт должен действовать предсказуемым образом).Web -сайты должны взаимодействовать с различными агентами пользователей, а навигация должна быть согласованной).В этом разделе будет представлено несколько примеров того, как тестирующие эксперты могут оценить насколько контент соответствует этим принципам. Пожалуйста, помните, что этот раздел не предназначен в качестве замены рецензии WCAG и соответствующих методов.
Воспринимаемость
Одно из подмножеств проблем восприятия вращается вокруг предоставления альтернативной информационной среды различного типа. Можно проверить текстовые эквиваленты, отключая в браузере вывод изображений и мультимедиа и просматривая страницу. Но нужно уделить особое внимание элементам img и input. Обычно рекомендуется задавать для всех чисто декоративных изображений пустые значения атрибута alt ( alt =""), чтобы считыватель экрана просто пропускал их. Однако в следующих случаях:
когда этим элементам задаются атрибуты alt ="", считыватели экрана будут обычно интерпретировать изображение или кнопку, как если бы атрибут alt =" " отсутствовал, и попытаются предоставить его значение (например, читая URL изображения).
Поэтому в этих конкретных обстоятельствах необходимо гарантировать, что изображения в ссылках или кнопках имеют атрибут alt, который описывает место, назначение, ссылки или действие кнопки, даже если это и будет несколько избыточно.
Тестирование эквивалентных значений, синхронизированных с мультимедиа, таких как надписи и описание аудио, можно сделать, используя параметры медиа плеера, чтобы включить настройки доступности.
Другая группа проблем восприятия связана со стилевым оформлением страницы. Здесь имеется три области для исследования:
CSS издателя задает цвета, он должен явно задавать фон и передний план вместе, чтобы гарантировать, что комбинация необычных предпочтений и стилей издателя не приведут к нечитаемому или невидимому тексту. Популярные браузеры позволяют пользователям принудительно задавать свои собственные цветовые предпочтения и отключить фоновые изображения CSS. Когда вы попробуете сделать это самостоятельно, могут обнаружиться неправильно понятые методы замены изображений CSS, которые скрывают текст за пределами экрана, так как изображение не загружается, но текст тем не менее будет невидимым.Web для использования при стилевом оформлении по умолчанию агента пользователя или стилевого оформления пользователя?Попробуйте выключить CSS и проинспектировать объектную модель документа, чтобы проверить, что заголовки размечены как заголовки, и таблицы используются для табличных данных, а не для компоновки.
Взаимодействие
Здоровье и безопасность являются критически важной, хотя и редко рассматриваемой, частью создания взаимодействия Web -сайта. Но мигающий контент имеет риск вызвать приступ светочувствительной эпилепсии. Можно сделать снимок c экрана используемого Web -сайта и загрузить его в утилиту Trace Center (PEAT) для проверки, не может ли мигающий контента быть опасным для пользователей. Очевидно, что это особенно важная забота, если создается Web -сайт для общего доступа к видео. На этапе проектирования продукта, можно рассмотреть вопрос о включении автоматического процесса скрининга загружаемых видео-роликов. Кроме этого хорошим способом тестирования взаимодействия Web -сайтов будет просто попытка увидеть, можно ли получить доступ ко всему существенному контенту и функциям с помощью различных устройств:
Web -странице с помощью голосовых команд, используя браузер Opera для Windows и его дополнительный модуль Voice, или Windows Vista Считыватели экрана и другие вспомогательные технологии могут использовать семантическую структуру (X)HTML для правильной ассоциации контента и обеспечения навигации по контенту. Например, считыватели экрана могут разрешать пользователям перемещаться к следующему вхождению элементу заголовка или элементу другого типа, или могут перечислить все вхождения определенного типа. Правильное использование элементов label и legend позволяет вспомогательной технологии связать метки с правильными полями форм; правильное использование элементов th и атрибутов header, scope, и axis позволяет ей связать заголовки таблицы с ячейками данных таблицы. Семантическую структуру можно оценить с помощью инспектора объектной модели документа (DOM), такого как в Opera Dragonfly. Инструменты инспекции доступности, такие как Firefox Accessibility Extension могут сделать такие задачи легче, например, перечисляя заголовки на странице, или перечисляя атрибуты полей формы (быстро показывая, какие из них не и
меют связанных меток). Посмотрите на рис. 26.1 в качестве примера.
(рис 26.1) Снимок с экрана информационного окна форм Firefox Accessibility Extension для новой домашней страницы BBC
Понятность
Оценка понятности еще более субъективна чем тестирование удобочитаемости. Если только оценщик не является новым человеком в проекте или не является профессиональным редактором, то он, вероятно, является не лучшим человеком для оценки, будет ли основное содержимое понятно насколько возможно. Можно, однако, воспользоваться инструментом ) компании Juicy Studio для получения примерного представления о том, насколько простым является основное содержимое сайта.
Однако некоторые аспекты являются вполне объективно тестируемыми, такие как имеет ли контент метаданные языка, которые позволяют (например) считывателям экрана и голосовым браузерам читать контент с правильным произношением. В HTML можно использовать инспектор DOM для проверки присутствия для документа атрибута lang документа и каждого изменения языка.
Следите за несогласованностью на Web -сайтах, как в терминах внутренней согласованности, так и предсказуемости из общих соглашений Web. Пользователи экранных луп, которые видят только часть страницы, существенно опираются на такую согласованность, чтобы знать, где искать, чтобы найти данный контент и функции.
Надежность
Тестирование контента на надежность включает проверку правильности использования технологий. На самом базовом уровне можно прогнать разметку и код через программные анализаторы кода, такие как:
Затем можно исследовать код вглубь, чтобы проверить, что его средства используются правильно. Например, можно проверить, что используются собственные элементы управления ).
Затем можно протестировать в нескольких агентах пользователей и вспомогательных технологиях, проверяя, что сайт является воспринимаемым, взаимодействующим, и понятным, какая бы комбинация опубликованного CSS, JavaScript, и подключаемых модулей не была активирована, или деактивирована.
Наиболее распространенной проблемой является, вероятно, назойливый JavaScript, как в случае JavaScript, чтобы реально что-то сделать. Но существуют более тонкие проблемы, которые возникают из слишком тесной связи JavaScript с другими слоями в технологическом стеке. Например, JavaScript может применить CSS display: none ; чтобы скрыть контент, но что произойдет, когда CSS издателя неприменим?
Другим примером являются элементы управления мультимедиа, собственный интерфейс пользователя подключаемого модуля (плагина) деактивируется, а подключаемый модуль вместо этого управляется виджетами HTML со сценариями. Когда контент подключаемого модуля добавляется только через JavaScript после обнаружения подключаемого модуля на основе JavaScript, то все отлично. Но иногда контент подключаемого модуля включается в состояние страницы до сценария. В таких случаях стоит проверить не только, что имеется возврат в исходное состояние на случай, если подключаемый модуль обработки недоступен, но также, что собственный интерфейс пользователя подключаемого модуля не отключен, если JavaScript недоступен. Если отсутствует первое, то пользователи вообще не увидят резервного контента; если отсутствует второе, то пользователи увидят подключаемый модуль, но не смогут им управлять.
Никакой объем инспекции и скрининга разработчика не сможет заменить непосредственную встречу пользователя и Web -сайта. Учитывая трудности понимания всех тонких взаимодействий между контентом Web и вспомогательной технологией, и трудности аппроксимации опыта пользователей с физическими недостатками, это удваивается для пользователей с физическими недостатками. Если это вообще возможно, необходимо протестировать свой сайт с реальными пользователями с физическими недостатками. Это можно сделать широкомасштабно и дорого, но недооценивайте выгоды выполнения тестирования пользователей даже небольшого масштаба.
Тестировщиков можно найти таким же образом, как вы ищите обычно кандидатов для тестирования
Тестирование является реальной работой и должно в идеале компенсироваться соответствующим образом. Ставка в 70 USD за час тестирования является общепринятой для тестирования пользователей. Не говоря уже о том, что вы можете найти людей, которые будут тестировать меньшие проекты бесплатно. Можно найти людей с физическими недостатками среди друзей, родственников, и коллег. Кроме того, существуют онлайновые дискуссионные группы специально посвященные вопросам доступности программного обеспечения, такие как:
Web.JAWS.GW Micro Window-Eyes.Apple VoiceOver.Linux людьми с недостатками зрения.ZoomText.Такие группы обычно приветствуют вопросы от разработчиков Web о доступности их сайтов или определенных методов.
Помните, что сама рабочая среда тестирования должна быть доступна. Например, если вы готовите письменные тестовые материалы, нужно быть готовым предложить их в альтернативных формах. Повторение рабочей среды пользователя для просмотра Web в обычном месте тестирования может быть затруднительна, поэтому может быть более реалистично тестировать у пользователя дома. Если это невозможно, то даже полностью удаленное тестирование может быть ценно.
Одним частным соображением, которое, вероятно, еще более важно для пользователей с физическими недостатками, чем для других пользователей, будет то, с какими технологиями они знакомы. Вспомогательная технология может добавить много слоев сложности для их опыта работы с компьютером, создавая большое разделение между пользователями компьютеров новичками и опытными, и разделяя пользователей на сообщества, которые могут быть очень искусны со своей собственной настройкой, но крайне дезориентированы незнакомой технологией. (Представьте, как трудно бывает пользователям без физических недостатков, которые влияют на их возможности использования компьютеров, переключиться с компьютеров Mac на PC!)
Если взять опытного пользователя считывателя экрана Window-Eyes, посадить его перед незнакомой машиной с установленным считывателем экрана JAWS, и попросить его протестировать Web -сайт, то будет очень трудно отличить его проблемы с JAWS от проблем, которые создает Web -сайт.
Учитывая значительные различия между версиями и учитывая, как часто пользователи модифицируют свою настройку, это может быть трудно, даже если предоставить пользователю Window-Eyes! В связи с этим, если только вы не специально тестируете, как хорошо будет сохраняться доступность Web -сайта с незнакомыми настройками (например, в библиотеке или на компьютере приятеля), то лучше позволить пользователям тестировать со своей собственной настройкой или чем-то насколько возможно близким к ней.
Аналогично, если только вы не хотите специально протестировать пользователей новичков или пользователей экспертов, вы должны стараться выбрать пользователей, которые имеют около года опыта использования своей текущей настройки для доступа к Web. Как вспомогательную технологию, так и соглашения самой Web изучить не просто. С пользователями новичками вы не узнаете, возникли ли проблемы в связи с сайтом, или свойственны самому процессу обучения, а эксперты могут иметь свои собственные приемы, которых не имеют другие.
Крайне полезно даже наблюдать за пользователями, которые просто исследуют Web -сайт. Как и для любого другого тестирования пользователей:
При проектировании сайта необходимо сосредоточиться на транзакциях, которые хотят выполнить пользователи на сайте, а не на конкретных элементах управления, которые им нужно использовать. Аналогично при тестировании доступности поставленные задания должны (по крайней мере в начале) отражать реальные цели посетителя при использовании сайта, а не сосредотачиваться на их взаимодействии с определенными элементами управления. Эти транзакции будут обычно аналогичны для людей имеющих физические недостатки и не имеющих.
Например, при тестировании сайта общего доступа к видео на доступность не начинайте с вопроса о том, могут ли они использовать определенные элементы управления ("Это регулятор громкости. Можете ли вы настроить громкость?"). Вместо этого дайте им сценарий и попросите выполнить ключевые задачи пользователей. Например:
Таким образом вы, скорее всего, обнаружите множество проблем, которых не ожидали. Например, пользователи считывателя экрана не смогут найти поле поиска или элементы управления для видео. И наоборот, пользователи могут иметь навигационные стратегии для работы с Web, о которых вы даже можете не догадываться.
В идеальном мире можно было бы протестировать все возможные комбинации и получить ответную реакцию от каждого. Но в реальности время и деньги ограничивают тестирование пользователей. Поэтому ответная реакция может быть обоюдоострым мечом. Хотя она может многому научить, существует реальная опасность придания слишком большого веса мнению одного человека, которое может не отражать мнение большей целевой аудитории. Например, некоторые пользователи считывателей экрана стремятся найти материалы, предназначенные для слепых пользователей; другие же хотят узнать все о сайте, что видят их зрячие друзья и коллеги. Именно здесь на помощь приходят такие стандарты как WCAG. Следуя таким рекомендациям можно увеличить свои шансы получить основы доступности даже для групп пользователей, для которых тестирование было невозможно выполнить.
Когда вы видите проблему, проанализируйте ее причины. Например, ваш сайт общего доступа к видео включает страницу, показывающую популярные видео в виде таблицы данных, со столбцами содержащими рекламный кадр, заглавие, дату загрузки на сайт, дату последнего воспроизведения, и общую оценку, и организованные в группы строк по категории видео. При тестировании пользователь считывателя экрана имеет проблемы с использованием таблицы данных. Это может отражать:
div, а не с помощью подходящей разметки таблицы данных. В этом случае подходящим действием будет перепрограммирование таблицы.JAWS может быть незнаком со свойствами JAWS для перемещения и чтения табличных данных. В этом случае подходящим действием может быть предоставление дополнительной документации или советов для менее опытных пользователей. Если опытные пользователи не будут идеально подходить для такого тестирования, то они будут отличными консультантами в таких ситуациях.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 и пользуйтесь обычным образом Интернет в течение дня. С какими проблемами вы столкнулись?WCAG 1.0 и общую доступность как тестировщик эксперт. Создайте план тестирования пользователя для сайта, и включите требования для найма и задания для теста. Напишите отчет о том, как можно было бы улучшить его доступность.После изучения в университете набора средневековых королей, ученых восемнадцатого века и других исторических эксцентрических личностей, Бенджамин Хоукс-Левис как-то оказался работающим в качестве разработчика Web в Yahoo!, к своему большому удовольствию. Его любимые занятия включают хорошую еду в компании друзей, хороший фильм в кинотеатре, лежание на траве на солнышке и решение трудных проблем, ссылаясь на первичные источники, основные принципы и эмпирические доказательства.
Источник: Ben Ward http://www.flickr.com/ photos/benward/ 2404982169/
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.