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

Когда должно выполняться тестирование?

"Тестируйте рано, тестируйте часто" является старой поговоркой программирования.

Надежда на тестирование в конце процесса разработки содержит две опасности:

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

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

Понимание требований

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

Внешние требования

Часто требования приходят из внешних источников, таких как:

• Правительство. Оно имеет обычно форму общего законодательства против дискриминации людей с функциональными ограничениями, а не требования определенного стандарта или перечисления точных требований соответствия. Важным исключением является случай, когда законодательство требует использовать определенный стандарт для публичного сектора. Например, Section 508 (http://www.Section508.gov/) является частью федерального законодательства США, которое требует, чтобы Web -сайты, создаваемые для федеральных агентств соответствовали как минимум специальному множеству определенных требований. Страница WAI о политиках, относящихся к доступности Web (http://www.w3.org/WAI/Policy/) содержит частичный список аналогичного законодательства. Но чтобы получить авторитетное мнение об обязательствах в ваших условиях, посоветуйтесь с юристом.
• Политика заказчиков. Например, компания Shell в настоящее время пытается реализовать на своих Web -сайтах требования соответствия уровню "Double-A" рекомендаций WCAG 1.0, поэтому при разработке Web -сайта для Shell вы должны будете удовлетворить (по крайней мере) тому же стандарту.
• Маркетинговая полезность. Соответствие определенному стандарту, такому как Section 508, может помочь продаже проекта озабоченным доступностью клиентам.
• Внутренняя политика доступности в организации. Например, проекты, создаваемые в BBC, должны соответствовать Рекомендациям по доступности v1.3 компании BBC.

Детали соответствия

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

1. Люди с некоторыми физическими недостатками "не смогут получить доступ к информации" в документе, который не прошел уровень "A".
2. Люди с некоторыми физическими недостатками "будут испытывать трудности при доступе к информации" в документе, который не прошел уровень "Double-A".
3. Люди с некоторыми физическими недостатками "будут испытывать иногда затруднения при доступе к информации" в документе, который не прошел уровень "Triple-A".

Черновой вариант 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)

• Большая печать: Текст большого масштаба и изображения текста большого масштаба имеют относительный контраст не менее 3:1;
• Второстепенное: Текст или изображения текста, которые являются частью неактивного компонента интерфейса пользователя, который является чистой декорацией, который является случайным текстом в изображении, или который никому не виден, не имеет минимальных требований контрастности.

Примечание: Критерии успеха 1.4.3 и 1.4.6 могут удовлетворяться посредством управления контрастом, доступного на или со страницы.

1.4.6 Контраст (Улучшенный): Текст и изображения текста имеют относительный контраст не менее 7:1, за исключением следующего: (Уровень AAA)

• Большая печать: Текст большого масштаба и изображения текста большого масштаба имеют относительный контраст не менее 5:1;
• Второстепенное: Текст или изображения текста, которые являются частью неактивного компонента интерфейса пользователя, который является чистой декорацией, который является случайным текстом в изображении, или который никому не виден, не имеет минимальных требований контрастности.

Примечание: Критерии успеха 1.4.3 и 1.4.6 могут удовлетворяться посредством управления контрастом, доступного на или со страницы.

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

WCAG 2.0 был создан с требованием высокой степени обратной совместимости с другими стандартами, особенно WCAG 1.0 и Section 508.