Тестирование web-доступности. 
Гипертекстовая справочная система "Я инвалид-26", реализованная в виде Web–сайта

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

Сразу следует отметить тот факт, что начать тестирование вашего ресурса желательно с проверки его ключевых страниц общими валидаторами HTML и CSS. Так как даже если ваш сайт был создан с учётом основных стандартов доступности, вряд ли он может считаться качественным продуктом, если, при всём этом, не соответствует базовым спецификациям. К тому же валидный HTMLи CSS-код — это уже половина успеха на пути создания доступного ресурса. Для осуществления подобной проверки существуют инструменты, предоставляемые консорциумом «W3C»:

HTML-валидатор W3C: http://validator.w3.org.

CSS-валидатор W3C: http://jigsaw.w3.org/css-validator/.

Однако с основными понятиями валидности сайта квалифицированный web-разработчик должен быть уже знаком, поэтому здесь мы остановимся более подробно лишь на тестировании сайта конкретно на предмет его доступности.

Автоматизированное тестирование.

Как уже было отмечено выше, существует достаточно много стандартов доступности сайтов. Разумеется, автоматизированные системы проверки созданы далеко не для всех. Однако с проверкой самых основных проблем не возникнет.

Если разработчик при создании своего сайта придерживался стандарта WCAG 1.0 или Section 508, то ему следует воспользоваться сервисом «Cynthia Says», доступным по адресу: http://www.cynthiasays.com. Здесь следует указать URL-адрес проверяемой страницы и задать стандарт, в соответствии с которым следует выполнять проверку. Причём для WCAG 1.0 можно выбрать один из трёх возможных уровней: 1A, 2A или 3A. При необходимости, можно задать дополнительные настройки. Например, для проверки доступности динамического контента имеет смысл провести тестирование несколько раз в режимах совместимости с разными браузерами, так как на разных Интернет-обозревателях он может выглядеть по-разному.

Если же разработчиком был использован стандарт WCAG 2.0, то «Cynthia Says» в данном случае будет бессилен. Для проверки соответствия стандарту WCAG версии 2.0 следует воспользоваться сервисом «ATRC Web Accessibility Checker», доступным по адресу: http://checker.atrc.utoronto.ca. Здесь также следует указать URL-адрес страницы и нажать на кнопку «Check It», но помимо проверки по URL сервис также предоставляет возможность загрузить файл напрямую. Это может быть полезно в том случае, если ваш сайт ещё не размещён в Интернете. «ATRC Web Accessibility Checker» также пригоден для проверки соответствия не только международному стандарту WCAG 2.0, но и некоторым региональным, например, уже упоминавшимся BITV 1.0 Level 2 или Stanca Act.

Однако всегда следует помнить, что современные системы искусственного интеллекта далеки от совершенства. Поэтому подобные методы тестирования доступности не являются абсолютно автоматизированными. Программист ресурса всё равно должен вручную просмотреть результат проверки и самостоятельно решить, является ли помеченное место проблемным в отношении доступности. Например, если система «Cynthia Says» встречает в коде страницы конструкцию типа , то она всегда выдаёт предупреждение, призывая проверить, что это изображение используется только для дизайнерских целей и не несёт конкретной смысловой нагрузки. Подробнее подобная ситуация уже рассматривалась в обзоре ГОСТа Р 52 872−2007, разработчики которого не учли всех её нюансов.

Однако проблема доступности может заключаться не только в отдельных HTML-конструкциях или несовершенных полностью автоматизированных публичных тестах Тьюринга для различия компьютеров и людей (CAPTCHA), но и в не оптимальной цветовой схеме сайта. Например, его цветовая палитра может быть недостаточно контрастной. Помочь подобрать оптимальное сочетание цветов может сервис «Color Scheme Designer», доступный по адресу: http://colorschemedesigner.com. Если же требуется проверить уровень контрастности уже существующей страницы, то выполнить это можно при помощи сервиса «Contrast Analyser», доступного по адресу: http://www.paciellogroup.com/resources/contrast-analyser.html. Он определяет контраст между цветами фона и переднего плана.

Также в аспекте цветовой web-доступности имеет смысл затронуть такое понятие, как «безопасные цвета web», хотя данная тема и не имеет прямого отношения к автоматизированному тестированию доступности. Это наследие тех времён, когда компьютерные мониторы могли гарантировано выводить только 216 цветов (так называемая палитра 6Ч6Ч6). Эти 216 цветов должны были выглядеть одинаково на всех компьютерных платформах и браузерах, которые содержала 256-цветная (8-битная) компьютерная система, поэтому они были названы безопасными для использования на различных платформах, так как их применение при любых условиях не влекло никаких проблем совместимости. В системе RGB они кодируются в каждом из трёх потоков как 00, 33, 66, 99, CC и FF. Однако современные браузеры способны работать с 32-битным цветом, который создаёт палитру из 4 294 967 296 различных цветов. Поэтому сейчас концепция безопасных цветов web не является особо актуальной, однако об этом не помешает знать любому web-разработчику.

Пользовательское тестирование.

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

Тестеров можно найти среди своих знакомых или в соответствующих Интернет-сообществах, которые есть на всех языках, в том числе и на русском. Также можно обратиться в рекрутинговые агентства, но на постсоветском пространстве это вряд ли даст ощутимые результаты, так как на таком уровне данная сфера развита только в Западной Европе и отдельных странах Северной и Южной Америки. Для русскоязычного проекта оптимальным вариантом будет являться связь с представителями соответствующего сетевого сообщества.

Доступность является важным понятием, как по экономическим, так и по социальным причинам. Это не только функциональное свойство web-сайта, а ещё и показатель качества, с которым он был создан. Если учитывать аудиторию сайта со всеми её особенностями во время его создания, то вы создадите более доступные страницы со всеми преимуществами, которые это приносит.