Что такое Web-доступность и как за нее бороться

Автор:© Никита Цейковец
Дата публикации:03.08.2010
Поделиться в Twitter Поделиться в F******k Поделиться в VKontakte Поделиться в Telegram Поделиться в Mastodon

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

Кроме людей, которым требуются вспомогательные технологии, существуют и другие люди, для которых это будет также справедливо. Например, технология Flash ещё недостаточно развита, чтобы она появилась на большенстве мобильных телефонах, даже такой мощный гаджет, как Apple iPhone не имеет и, скорей всего, никогда не будет её иметь. Всегда надо предусматривать альтернативные способы представления контента.

Свойство Интернет-ресурса, учитывающее все возможные проблемы, с которыми может столкнуться человек при его использовании, называется web-доступностью. В данной статье будут изложены основные доводы в пользу обязательного учёта web-доступности при создании сайтов, будет дан обзор основных стандартов и рекомендаций, следование которым поможет создать абсолютно доступный ресурс, а также будут приведены рекомендации по тестированию сайта на предмет его доступности. Материал носит обзорный характер, но включает ссылки на техническую документацию для профессиональных web-разработчиков.

Актуальность web-доступности

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

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

Кому это надо?

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

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

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

Таким образом, ответом на вопрос "кому это надо?" является - "это надо всем, и в первую очередь это надо самим web-разработчикам, хотя они сами это часто не осознают".

Потенциальные рынки

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

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

Можно привести реальный пример из жизни:

В 2000 году британская сеть супермаркетов "Tesco" запустила проект по созданию отдельной версии своего сетевого продуктового магазина специально для людей с нарушениями зрения. После этого, по заявлениям официальных представителей "Tesco", годовая прибыль их сети выросла на 13 миллионов фунтов стерлингов. Таким образом, если бы компания "Tesco" не рассматривала людей с недостатками зрения, как потенциальных потребителей своей продукции, они бы упустили рынок стоимостью, как минимум, 13 миллионов фунтов стерлингов. К тому же следует учитывать и повышение статуса их бренда, так как демонстрация того, что вы реально заботитесь о каждом члене общества, может только улучшить имидж компании.

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

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

Поисковые системы

Поисковые системы не являются людьми. Часто, когда люди создают web-сайты, они делают это, не рассматривая, как их можно будет найти в Google, Yahoo, Яндекс и других аналогичных сервисах. Поисковые системы являются просто компьютерными программами, и они могут использовать для индексации сайта только ту информацию, которую смогут понять. Это делает их похожими на программы чтения экрана (screen readers), которые может использовать человек с недостатками зрения.

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

Юридический аспект

В ряде стран стандарты доступности web-ресурсов оформлены в виде конкретных законодательных норм. Например, в Великобритании, США, странах Европейского союза и других. Таким образом, разработчик сайта может столкнуться с реальными проблемами, если не позаботится о данном аспекте своего сайта. К тому же если всё это будет происходить в стране с судебной системой, где сильно развит институт морального ущерба, то иск по дискриминации инвалидов может составить несколько миллионов долларов США, что в любом случае обойдётся намного дороже, чем изначальное создание сайта в соответствии со всеми стандартами доступности, не говоря уже о возможном ущербе репутации компании после проигранного судебного дела.

Обзор стандартов web-доступности

Если изложенные выше доводы убедили вас в необходимости соответствия вашего ресурса основным стандартам доступности, то, скорей всего, перед вами встал вопрос "Как это сделать?".

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

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

Рекомендации по доступности web-контента (WCAG), версия 1.0

Данный документ был разработан консорциумом "W3C" (http://w3.org), являющимся одним из основных органов стандартизации в Интернете. Его подразделение "Web Accessibility Initiative" (WAI) опубликовало первую версию своих рекомендаций по созданию доступных web-сайтов 5 мая 1999 года.

Рекомендации по доступности web-контента (англ. Web Content Accessibility Guidlines, сокращёно WCAG) являются наиболее широко используемым стандартом по обеспечению доступности в Интернете. Использование WCAG 1.0 было предложено рядом правительственных органов, включая Европейский союз и правительство Италии.

WCAG 1.0 является набором из четырнадцати рекомендаций, охватывающих цели, которые необходимо реализовать для получения максимально доступной страницы. В каждом пункте рекомендаций содержится ряд контрольных точек, которые составляют реальное содержание документа. В то время как рекомендации объясняют концепции, которые авторы имеют в виду, контрольные точки являются тем, что используется для проверки соответствия стандартам. Каждая из контрольных точек имеет приоритет от 1 до 3, чтобы указать на их важность. Чтобы соответствовать WCAG 1.0, необходимо удовлетворить всем контрольным точкам с приоритетом 1. Соблюдение всех контрольных точек с приоритетом 1 предоставляет рейтинг соответствия "A" (1A). Если вы удовлетворяете также контрольным точкам с приоритетом 2, то вы будете соответствовать рейтингу "AA" (2A). Если вы удовлетворяете всем контрольным точкам с приоритетами 1, 2 и 3, то вы будете соответствовать рейтингу "AAA" (3A), который является самым высоким.

Однако в современных условиях WCAG 1.0 несколько устарел, так как со времён 1999 года, стали активно применяться новые технологии, такие как JavaScript, ARIA Drag-and-Drop и другие. К тому же он изначально разрабатывался как часть пакета из трёх документов, где второй документ отводился для описания браузеров и вспомогательных программ доступности, например, screen reader-ов, а третий охватывал средства разработки, например, Dreamweaver, и CMS. Предполагалось, что большая часть работы по обеспечению доступности сайтов будет приходиться как раз на их долю. Однако общее признание из всех трёх получил лишь WCAG, описывающий только приёмы CSS. Таким образом, часто складывается ситуация, когда ожидания WCAG 1.0 в отношении агентов пользователей не удовлетворяются, поэтому даже полное соответствие WCAG 1.0 не гарантирует абсолютно доступности ресурса.

Рекомендации по доступности web-контента (WCAG) Samurai

26 февраля 2008 года группа разработчиков под руководством Джо Кларка (англ. Joe Clark), независимо от "W3C", опубликовала корректировки и расширения стандарта WCAG 1.0, получившие название WCAG Samurai. Данный документ предназначался для приведения WCAG 1.0 в соответствие современным реалиям web-технологий. Однако данный комплекс рекомендаций так и не получил широкого признания, так как не был поддержан консорциумом W3C, который в декабре того же года выпустил следующую версию WCAG.

Рекомендации по доступности web-контента (WCAG), версия 2.0

11 декабря 2008 года консорциум "W3C" опубликовал следующую версию рекомендаций - WCAG 2.0. Версия 2.0 отличается от 1.0 большей технологической независимостью, то есть данный комплекс рекомендаций в равной мере актуален для всех основных web-технологий: HTML, CSS, Flash и так далее.

В WCAG 2.0 используются те же три уровня соответствия, но общий подход к анализу ресурса несколько пересмотрен с целью получения большей универсальности стандарта. Он основывается на четырёх принципах доступности:

  1. Воспринимаемость:
    Люди должны получить доступ к контенту через ту среду, которая им доступна. Например, люди с нарушением зрения должны иметь возможность услышать контент.
  2. Взаимодействие:
    Люди должны иметь возможность взаимодействовать с приложением web или контентом в любых условиях.
  3. Понятность:
    Контент и интерфейс пользователя должны быть понятны всем людям, которые их используют.
  4. Надёжность:
    Любое предоставляемое решение должно быть широко доступно для использования на различных платформах или системах. Это должно остановить людей изобретать решения, которые большинство пользователей не смогут использовать, потому что оборудование/программное обеспечение ограничено или чрезмерно дорого.

Разумеется, не предполагается, что web-сайты будут удовлетворять абсолютно всем этим требованиям на 100%. Технология, которую имеет пользователь, также должна сделать часть работы. Например, ожидается, что screen reader будет читать страницы людям, которым это требуется, а не каждый web-сайт будет предоставлять аудио-версию своего контента. Однако в то же время ожидается, что web-сайт предоставит страницы, которые можно прочитать с помощью обычной программы чтения экрана.

WCAG 2.0 также отличается от WCAG 1.0 в техническом подходе. Так как стандарт более независим от технологии, и имеет дело с концепциями доступности, а не с конкретными техническими деталями, то важно уделить внимание сопровождающим стандарт документам.

Документ "стандарта" WCAG 2.0 (http://www.w3.org/TR/WCAG20/) даст понимание, а "технический" документ (http://www.w3.org/TR/WCAG20-TECHS/) предоставит разработчику надёжные реализуемые фрагменты информации. Всё это разбивается на "общие" методы (технологически неопределённые) и специфические для отдельных технологий "W3C".

Для перехода с WCAG 1.0 на 2.0 "Web Accessibility Initiative" разработало соответствующее руководство - "Comparison of WCAG 1.0 Checkpoints to WCAG 2.0, in Numerical Order" (http://www.w3.org/WAI/WCAG20/from10/comparison/).

Section 508

В 1998 году Конгресс США внёс поправки в закон "American Workforce Rehabilitation Act" от 1973 года. Данный нормативный акт обязывает все федеральные органы США обеспечивать доступность своих средств массовой информации. Раздел №508 был принят с целью устранения препятствий для людей с ограниченными физическими возможностями в области информационных технологий. Закон в обязательном порядке распространяется на все федеральные ведомства Соединённых Штатов и охватывает как доступность web, так и другие вопросы доступности, связанные с компьютерными системами и электронной коммуникацией.

Как уже было отмечено, закон распространяется только на правительственные агентства, но многие негосударственные учреждения также используют рекомендации Section 508 по собственной инициативе, в том числе и находящиеся за пределами Соединённых Штатов.

Частью Section 508, которая охватывает web-доступность, является "Subpart B §1194.22" (http://www.access-board.gov/sec508/standards.htm#Subpart_b). Статья 1194.22 состоит из шестнадцати требований, помеченных латинскими буквами от A до P.

Первые 11 требований (A-K) сформулированы как прямые эквиваленты частей WCAG 1.0. Эти требования и их эквиваленты в WCAG 1.0 перечислены в справочной таблице в документе Section 508. Все другие требования Section 508 должны удовлетворяться в WCAG 2.0 с одним исключением. Требование M относится к Section 508 Subpart B §1194.21. Это требование имеет частичный эквивалент в принципе "Надёжности" WCAG 2.0.

В настоящее время консультативный комитет телекоммуникаций и электронных и информационных технологий (англ. Telecommunications and Electronic and Information Technology Advisory Committee, сокращённо - TEITAC) продолжает работу над усовершенствованием Section 508. В частности в апреле 2008 года TEITAC представил свои предложения по модификации данного стандарта экспертному совету Section 508.

WAI-ARIA, версия 1.0

Ещё одним важным стандартом, разработанным консорциумом W3C, в 2008-2009 годах является стандарт WAI-ARIA 1.0, что расшифровывается как "Web Accessibility Initiative - Accessible Rich Internet Applications (Инициатива доступности web - доступность высокотехнологичных Интернет-приложений). Это пакет документов, который определяет, как сделать доступными сложные динамические web-приложения, которые используют такие технологии, как HTML, JavaScript и AJAX. Этот стандарт официально поддерживается ведущими Интернет-браузерами: Firefox 3.x и выше, Internet Explorer 8 и выше, Opera 9.5 и выше, а также некоторыми другими.

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

ГОСТ Р 52872-2007 Интернет-ресурсы. Требования доступности для инвалидов по зрению

1 января 2009 года в Российской Федерации вступил в действие национальный стандарт ГОСТ Р 52872-2007 "Интернет-ресурсы. Требования доступности для инвалидов по зрению" (англ. The Internet resources. Requirements of accessibility for invalids on sight). Данный документ был разработан ФГУП «СТАНДАРТИНФОРМ» и НУ ИПРПП ВОС «Реакомп» по заказу Федерального агентства по здравоохранению и социальному развитию в рамках федеральной целевой программы "Социальная поддержка инвалидов на 2006-2010 годы", утверждённой постановлением правительства Российской Федерации от 29 декабря 2005 года. Данный документ стандартизует русскоязычные Интернет-ресурсы и призван установить общие требования их доступности для людей с нарушениями зрения.

В ГОСТе Р 52872-2007 требования доступности ресурса выражаются в виде набора из нескольких десятков рекомендаций, касающихся общего дизайна сайта, обязательного использования некоторых HTML-конструкций, структуры и особенностей вёрстки Интернет-страниц.

Однако данный документ не лишён ряда ощутимых недостатков и вызывает немало вопросов. Например, сайт, созданный с безусловным соблюдением пункта 5.2 "Графические файлы":

Каждый графический файл должен быть снабжен поясняющим текстом. Для этого при включении в веб-страницу ссылки на графический файл (язык HTML) необходимо указать данный поясняющий текст в атрибуте ALT

может быть неудобным для посетителя ресурса, так как при этом на странице будет присутствовать информация не только о графических элементах, несущих конкретную смысловую нагрузку, например, "Картина К. Малевича - Чёрный квадрат" или "Логотип компании с изображением глобуса", но и простых элементов визуального дизайна, например, "Голубая волнистая линия" или "узор с цветочками", что будет только мешать работе незрячего пользователя.

Требование пункта 5.1 "Объем контента":

Частопосещаемые страницы по своему объему должны быть не более 2-3 экранов текста. Число ссылок на странице должно быть не более 15

также вызывает вопросы, например, "Что делать сайтам, у которых только меню уже насчитывает более 15 гиперссылок или сайтам типа wiki?", а главное не ясны мотивы ограничения числа ссылок с точки зрения доступности для инвалидов по зрению.

Однако имеет смысл отметить тот факт, что Федеральным законом "О техническом регулировании" №184-ФЗ от 27 декабря 2002 года разделены понятия "технический регламент" и "стандарт", в связи с чем все ГОСТы утрачивают обязательный характер и применяются добровольно, за исключением некоторых категорий, к которым ГОСТ Р 52872-2007 не относится. То есть данный документ носит лишь рекомендательный характер и несоблюдение его норм не влечёт никаких последствий для Интернет-ресурсов, в том числе и государственных, что делает его по сути бесполезным. К тому же раде справедливости стоит заметить, что не сайт института "Реакомп", как разработчика, не сайт Федерального агентства по техническому регулированию и метрологии, как учреждения отвечающего за распространение этого документа, не соответствуют данному ГОСТу. Причём на сайте Федерального агентства по техническому регулированию и метрологии сам данный документ выложен с нарушением себя самого, так как представлен в графическом формате с низким разрешением без текстовой альтернативы (несоответствие пункту 4.2.1 данного ГОСТа).

Таким образом, ГОСТ Р 52872-2007 не несёт никакой практической пользы по улучшению доступности Интернет-ресурсов для инвалидов по зрению и по сути является очередной "потёмкинской деревней". В данном же обзоре он рассматривается отдельно только потому, что имеет непосредственное отношение к русскоязычной части Интернета. Однако для web-разработчиков, озабоченных вопросом доступности их ресурсов, намного более полезно обратить внимание на стандарты Section 508 и, главным образом, на WCAG 2.0.

Прочие стандарты

Существует множество других стандартов web-доступности, принятых в различных странах мира, например, немецкий BITV 1.0 Level 2 или итальянский Stanca Act. Однако они носят локальный характер и актуальны только для сайтов, активно работающих в странах, в которых они приняты. Если же отбросить юридический аспект доступности, то есть руководствоваться в первую очередь созданием доступного сайта с функциональной, а не формальной точки зрения, то соблюдение директив "W3C" даёт всё необходимое, а именно стандарты WCAG и WAI-ARIA последних, на момент создания сайта, версий.

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

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

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

Однако с основными понятиями валидности сайта квалифицированный 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" встречает в коде страницы конструкцию типа <img alt=" ">, то она всегда выдаёт предупреждение, призывая проверить, что это изображение используется только для дизайнерских целей и не несёт конкретной смысловой нагрузки. Подробнее подобная ситуация уже рассматривалась в обзоре ГОСТа Р 52872-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-битным цветом, который создаёт палитру из 4294967296 различных цветов. Поэтому сейчас концепция безопасных цветов web не является особо актуальной, однако об этом не помешает знать любому web-разработчику.

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

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

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

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

[ Обсудить в форуме | Оглавление раздела ]
Распространение материалов сайта означает, что распространитель принял условия лицензионного соглашения.
Идея и реализация: © Владимир Довыденков и Анатолий Камынин,  2004-2024