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

Экспертное тестирование

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

• Инструментальная оценка: когда инструментальное средство ищет проблемы совместимости и предоставляет их оценщику (это включает средства проверки доступности и инструменты проверки кода).
• Скрининг: когда эксперт моделирует работу конечного пользователя с 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, соответствующих прослушиванию или азбуке Брайля, пытаясь вместо этого представить тип экрана, предоставленный визуальными браузерами, с которыми они взаимодействуют.

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

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