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

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

Существует четыре компонента для экспертного тестирования:

· Инструментальная оценка: когда инструментальное средство ищет проблемы совместимости и предоставляет их оценщику (это включает средства проверки доступности и инструменты проверки кода).

· Скрининг: когда эксперт моделирует работу конечного пользователя с Web -сайтом. Часто не требуется слишком углубленного рассмотрения, чтобы обнаружить проблемы доступности. Вы можете только загрузить страницу в свой браузер и заметить, что текст очень трудно прочитать.

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

· Обзор кода: когда оценщик просматривает код и активы Web -сайта, чтобы исключить возможные проблемы.

В то время как начинающие оценщики могут быть особенно зависимыми от инструментальной оценки, оценщики любого уровня подготовки могут получить пользу от каждого компонента. Даже начинающие могут заметить элементы img без текстового эквивалента в разметкеHTML, а с получением дополнительного опыта вы станете быстрее выявлять проблемы, прежде чем переходить к более строгому тестированию. Для экспертов в больших проектах может быть невозможно вручную просмотреть весь клиентский код или проинспектировать все части Web -сайта, но инструментальная оценка может обнаружить области, вызывающие особую тревогу, которые заслуживают более тщательного рассмотрения. Оценщики люди могут также просмотреть вещи, которые заметит машинная оценка. К сожалению, хотя существует множество инструментов доступности, большинство из них являются неполноценными тем или иным образом. Например, один инструмент, который перечисляет заголовки в документах HTML, делает ошибку, не включая весь текст из элементов img. Также как вы должны помнить о смысле закона в отношении соответствия стандартам, вы должны помнить об этом при использовании инструментов. Прежде чем сообщать кому-то о проблеме доступности, проверьте, что это действительно проблема, а не ошибка инструмента.

Полуавтоматические средства контроля доступности

Когда очевидные проблемы будут исправлены, следующим шагом было бы неплохо подвергнуть страницу проверке с помощью полуавтоматического средства контроля доступности. При оценке соответствия определенному стандарту, вы, вероятно, захотите выбрать один из таких инструментов, созданный для использования с этим стандартом. При оценке соответствия Section 508 или WCAG 1.0, инструмент Cynthia Says (http://www.cynthiasays.com/) является разумным выбором. При тестировании согласно немецкому BITV 1.0 Level 2, итальянскому Stanca Act, или черновому варианту WCAG 2.0 единственный имеющимся вариантом является экспериментальное средство ATRC Web Accessibility Checker (http://checker.atrc.utoronto.ca/index.html) Такие инструменты имеют значительные ограничения. Не существует такой вещи, как полностью автоматизированное тестирование доступности. Например, учитывая примитивную природу современного искусственного интеллекта, компьютерная программа не может окончательно сказать, будет ли некоторый текст настоящим эквивалентом фотографии в контексте. Даже в областях, которые могут быть теоретически полностью автоматизированы, программисты средств проверки могут ошибаться в своей интерпретации рекомендаций по доступности и терять смысл закона среди его букв. Хорошие инструменты проверяют страницу на наличие проблем доступности и создают список того, что они считают ошибками, и другой список того, что они считают заслуживающим проверки человеком. Например, если программа Cynthia Says находит элемент img сalt =" ", она создает предупреждение (не ошибку!), инструктируя пользователя "проверить, что это изображение используется только для интервала или дизайна, и не имеет никакого значения". Если правильным текстовым эквивалентом для этого изображения является пустая строка, нужно будет просто перейти к следующей ошибке или предупреждению. Возможно самое большое преимущество средств проверки доступности состоит в том, что если выбрать одно из них, такое как TAW 3 (http://www.tawdis.net/), которое может выполняться на нескольких URL, то можно найти страницы в больших совокупностях, которые требуют, видимо, более тщательной проверки.

Многие инструменты инспекции созданы для исследования структуры Web -контента.

Структура, говоря просто, определяет какие имеются компоненты Web -сайта, и как они связаны друг с другом. Например, в объектной модели документа (DOM) HTML текст может быть обозначен как метка поля формы с помощью элемента label. Браузеры преобразует кодHTML в объектную модель документа. Браузер связывает различное поведение с определенными компонентами. Например, если щелкнуть на метке флажка, то он будет обычно инициирован. Настольные рабочие среды и приложения поддерживают интерактивность со считывателями экрана, программным обеспечением распознавания речи, и другими вспомогательными технологиями, предоставляя аналогичную структуру, которая представляет контент и функции, доступные в визуальном представлении. В Windows основная структурная система называется Microsoft Active Accessibility (MSAA), или UI Automation в Vista (http://msdn.microsoft.com/en-us/library/ms788733.aspx). Например, диалоговое окно имеет ряд связанных потомков, таких как заголовок, поля, кнопки, и метки. Типичная вспомогательная технология имеет дело в основном с представлением браузеров и подключаемых модулей Web -контента в терминах этих структурных систем, а не с обработкой объектных моделей Web -документов непосредственно. Существуют средства инспекции, как для структур уровня настольного компьютера, так и для объектных моделей уровня Web. Для настольного компьютера OS X поставляется с Accessibility Inspector (http://developer.apple.com/documentation/ Accessibility/Conceptual/AccessibilityMacOSX/OSXAXTesting/chapter_5_Section_2.html) и 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. Инструментами для записи в объектную модель документа (X)HTML являются DOM Inspectors, как видно в Opera Dragonfly (http://www.opera.com/products/dragonfly/) и Firebug (http://www.getfirebug.com) и пакеты инструментов доступности, такие как Web Accessibility Toolbar для Internet Explorer и Opera (http://www.wat-c.org/tools/index.html) и ICITA Firefox Accessibility Toolbar (http://firefox.cita.uiuc.edu). Инспекторы DOM показывают дерево элементов, атрибутов и текст, созданный из сериализации (X)HTML, в то время как инспекторы доступности Web абстрагируют отдельные компоненты или отношения и перечисляют их. Например, они могут перечислить все поля с их метками или все заголовки, или все ссылки. Обычно для (X)HTML не требуется разбирать модель доступности, хотя вы можете захотеть исследовать этот слой, если считаете, что браузер представляет правильную структуру (X)HTML неправильно для вспомогательной технологии. Вместо этого вы будете обычно проверять структуры (X)HTML непосредственно. Не весь контент может инспектироваться с помощью DOM или инспекторов доступности Web. Инспекция того, что доступно для структур доступности уровня настольного компьютера важна для проверки того, какой контент подключаемого модуля (медиа-плееров, контентаFlash, и апплетов Java) доступен вспомогательной технологии, которая использует эти модели доступности Обычно необходимо проверить, что все элементы управления доступны в модели с соответствующей ролью (например, текстовые поля являются текстовыми полями, кнопки - кнопками) и необходимыми свойствами.

Скрининг и использование вспомогательной технологии конечного пользователя

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

· Использование удерживаемой ртом указки для нажатия клавиш во время тестирования доступности клавиатуры.

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

· Отключение монитора при использовании считывателя экрана вместе с браузером.

Скрининг может помочь разработчику создать приложение в соответствии с потребностями людей с физическими недостатками и может выявить фундаментальные недостатки дизайна. Использование вспомогательных технологий может снять определенные заблуждения в отношении того, насколько они соответствуют или не соответствуют стандартам Web. Например, популярные считыватели экрана не используют стили, предложенные для типов медиа CSS, соответствующих прослушиванию или азбуке Брайля, пытаясь вместо этого представить тип экрана, предоставленный визуальными браузерами, с которыми они взаимодействуют. Использование вспомогательных технологий не является легкой задачей, так как хорошее понимание того, как использовать такие системы может требовать некоторой степени погружения и обучения. Существует серьезный риск создания новых заблуждений. Разработчики могут попытаться что-то сделать со считывателем экрана и предположить, что это отражает недостатки считывателя экрана, когда на самом деле это отражает их неопытность в обращении с инструментом. Они могут пытаться использовать инструмент неправильным образом, например, пытаться прочитать страницу последовательно, когда реальный пользователь считывателя экрана будет перемещаться по ней, используя заголовки и другие элементы, пытаясь найти интересующие его моменты. Или наоборот, они не смогут правильно прочитать экран. Чтение страницы, которую можно видеть или хорошо знать, с помощью считывателя экрана, очень отличается от исследования совершенно нового сайта, который вы не можете видеть. Использование вспомогательной технологии должно сопровождаться опытом того, как повседневные пользователи используют технологию, и заключения, извлеченные из такого использования, должны в идеале подтверждаться пользователями экспертами. В целом, начинающим тестировщикам лучше передать использование вспомогательной технологии пользователям тестировщикам.

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

Проект WCAG 2.0 делит свои критерии лучших методов согласно четырем принципам. Контент и функции должны быть:

· Воспринимаемыми (например, изображения должны иметь текстовые эквиваленты).

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

· Понятными (основной материал должен быть не более сложным, чем требуется, а Web -сайт должен действовать предсказуемым образом).

· Надежными (например, Web -сайты должны взаимодействовать с различными агентами пользователей, а навигация должна быть согласованной).

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

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

· изображения, которые являются единственным контентом ссылок

когда этим элементам задаются атрибуты alt ="", считыватели экрана будут обычно интерпретировать изображение или кнопку, как если бы атрибут alt =" " отсутствовал, и попытаются предоставить его значение (например, читая URL изображения).

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

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

Другая группа проблем восприятия связана со стилевым оформлением страницы. Здесь имеется три области для исследования:

· Является ли предложенное представление страницы разумно доступным? Например, является ли достаточным контраст цветов? Является ли текст достаточно большим? Кроме рассмотрения самой страницы, можно использовать такие инструменты как Juicy StudioCSS Analyser (http://juicystudio.com/services/csstest.php) для проверки комбинаций цветов фона и переднего плана согласно формулам, которые предназначены для измерения удобочитаемости.

· Можно ли предложения издателя для представления безопасно смешивать с обычными предпочтениями пользователей, нацеленными на улучшение удобочитаемости, такими как увеличение размера шрифта, масштабирование, и другие цвета по умолчанию? Попробуйте увеличить размер текста примерно на 2 - 5 шагов; не беспокойтесь, если результаты не будут совершенны с точки зрения пикселей, но беспокойтесь о том, что не будет ли компоновка разрушена так, что представление контента будет трудно прочитать. Попробуйте изменить цветовые предпочтения и посмотреть, что произойдет. Если CSS издателя задает цвета, он должен явно задавать фон и передний план вместе, чтобы гарантировать, что комбинация необычных предпочтений и стилей издателя не приведут к нечитаемому или невидимому тексту. Популярные браузеры позволяют пользователям принудительно задавать свои собственные цветовые предпочтения и отключить фоновые изображения CSS. Когда вы попробуете сделать это самостоятельно, могут обнаружиться неправильно понятые методы замены изображений CSS, которые скрывают текст за пределами экрана, так как изображение не загружается, но текст тем не менее будет невидимым.

· Если предложения издателя по представлению отвергаются, будет ли вся информация, передаваемая такими предположениями, сохраняться в контенте Web для использования при стилевом оформлении по умолчанию агента пользователя или стилевого оформления пользователя?

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

Здоровье и безопасность являются критически важной, хотя и редко рассматриваемой, частью создания взаимодействия Web -сайта. Но мигающий контент имеет риск вызвать приступ светочувствительной эпилепсии. Можно сделать снимок c экрана используемого Web -сайта и загрузить его в утилиту Trace Center Photosensitive Epilepsy Analysis Tool (PEAT) для проверки, не может ли мигающий контента быть опасным для пользователей. Очевидно, что это особенно важная забота, если создается Web - сайт для общего доступа к видео. На этапе проектирования продукта, можно рассмотреть вопрос о включении автоматического процесса скрининга загружаемых видео-роликов. Кроме этого хорошим способом тестирования взаимодействия Web -сайтов будет просто попытка увидеть, можно ли получить доступ ко всему существенному контенту и функциям с помощью различных устройств:

· Попробуйте использовать свой сайт только с помощью клавиатуры. Всегда ли четко указан текущий фокус? Все ли функции будут доступны с клавиатуры?

· Попробуйте использовать свой сайт с помощью сенсорного экрана.

· Попробуйте поперемещаться по своей Web -странице с помощью голосовых команд, используя браузер Opera для Windows и его дополнительный модуль Voice, или Windows Vista Speech Recognition и браузер Internet Explorer. (Примечание: коммерческая система распознавания речи качества диктовки была недавно представлена в Mac OS X в форме MacSpeech Dictate, но в данное время не существует эквивалентной разработки на бесплатных платформах *nix.)

Считыватели экрана и другие вспомогательные технологии могут использовать семантическую структуру (X) HTML для правильной ассоциации контента и обеспечения навигации по контенту. Например, считыватели экрана могут разрешать пользователям перемещаться к следующему вхождению элементу заголовка или элементу другого типа, или могут перечислить все вхождения определенного типа. Правильное использование элементов label и legend позволяет вспомогательной технологии связать метки с правильными полями форм; правильное использование элементов th и атрибутов header, scope, и axis позволяет ей связать заголовки таблицы с ячейками данных таблицы. Семантическую структуру можно оценить с помощью инспектора объектной модели документа (DOM), такого как в Opera Dragonfly. Инструменты инспекции доступности, такие как Firefox Accessibility Extension могут сделать такие задачи легче, например, перечисляя заголовки на странице, или перечисляя атрибуты полей формы (быстро показывая, какие из них не и меют связанных меток). Посмотрите на рис. 26.1 в качестве примера.

Рис. 26.1. Снимок с экрана информационного окна форм Firefox Accessibility Extension для новой домашней страницы BBC

Оценка понятности еще более субъективна чем тестирование удобочитаемости. Если только оценщик не является новым человеком в проекте или не является профессиональным редактором, то он, вероятно, является не лучшим человеком для оценки, будет ли основное содержимое понятно насколько возможно. Можно, однако, воспользоваться инструментом Readability Test(http://juicystudio.com/services/readability.php) компании Juicy Studio для получения примерного представления о том, насколько простым является основное содержимое сайта. Однако некоторые аспекты являются вполне объективно тестируемыми, такие как имеет ли контент метаданные языка, которые позволяют (например) считывателям экрана и голосовым браузерам читать контент с правильным произношением. В HTML можно использовать инспектор DOM для проверки присутствия для документа атрибута lang документа и каждого изменения языка. Следите за несогласованностью на Web -сайтах, как в терминах внутренней согласованности, так и предсказуемости из общих соглашенийWeb. Пользователи экранных луп, которые видят только часть страницы, существенно опираются на такую согласованность, чтобы знать, где искать, чтобы найти данный контент и функции.

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

· Валидатор WDG HTML с активированными предупреждениями (http://htmlhelp.com/tools/validator/)

Затем можно исследовать код вглубь, чтобы проверить, что его средства используются правильно. Например, можно проверить, что используются собственные элементы управления HTML, а не сомнительные элементы управления с бессмысленными элементами и JavaScript, и что JavaScript использует обнаружение свойств, а не использует, где возможно, браузер (http://www.jibbering.com/faq/faq_notes/not_browser_detect.html).

Затем можно протестировать в нескольких агентах пользователей и вспомогательных технологиях, проверяя, что сайт является воспринимаемым, взаимодействующим, и понятным, какая бы комбинация опубликованного CSS, JavaScript, и подключаемых модулей не была активирована, или деактивирована. Наиболее распространенной проблемой является, вероятно, назойливый JavaScript, как в случае анкеров и кнопок, которые находятся в разметке страницы без сценария, но зависят от JavaScript, чтобы реально что-то сделать. Но существуют более тонкие проблемы, которые возникают из слишком тесной связи JavaScript с другими слоями в технологическом стеке. Например, JavaScript может применить CSS display: none; чтобы скрыть контент, но что произойдет, когда CSS издателя неприменим? Другим примером являются элементы управления мультимедиа, собственный интерфейс пользователя подключаемого модуля (плагина) деактивируется, а подключаемый модуль вместо этого управляется виджетами HTML со сценариями. Когда контент подключаемого модуля добавляется только через JavaScript после обнаружения подключаемого модуля на основе JavaScript, то все отлично. Но иногда контент подключаемого модуля включается в состояние страницы до сценария. В таких случаях стоит проверить не только, что имеется возврат в исходное состояние на случай, если подключаемый модуль обработки недоступен, но также, что собственный интерфейс пользователя подключаемого модуля не отключен, если JavaScript недоступен. Если отсутствует первое, то пользователи вообще не увидят резервного контента; если отсутствует второе, то пользователи увидят подключаемый модуль, но не смогут им управлять.

Что делает отдел по эксплуатации и сопровождению ИС? Отвечает за сохранность данных (расписания копирования, копирование и пр.)...

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

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

ЧТО И КАК ПИСАЛИ О МОДЕ В ЖУРНАЛАХ НАЧАЛА XX ВЕКА Первый номер журнала «Аполлон» за 1909 г. начинался, по сути, с программного заявления редакции журнала...

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