Глава 11.Доступность веб-контента, каскадные таблицы стилей и вы
Как раз в тот момент, когда вы думаете, что все плохо,мимо пролетает кошка, к спине которой привязанбутерброд с маслом
Меня иногда спрашивают: «А что вы скажете о доступности контента?Разве это не часть юзабилити?»
И они, конечно, правы. Нельзя сказать, что сайт пригоден к эксплуатации, еслион не общедоступен (если только пользователи с ограниченными возможностями не выводятся сознательно за рамки аудитории сайта).
В настоящее время каждый, кто занимается веб-дизайном, хоть чуть-чуть дазнает о доступности веб-контента, ну хотя бы слышал, что число 508 – это не совсем простое число. И все-таки почти каждый сайт, на который я захожу, непроходит моего экпресс-теста на доступность веб-контента (я просто увеличиваю размер шрифта).

Что слышат разработчики и дизайнеры
В большинстве фирм и учреждений доступность веб-контента обеспечивают те,кто реально создает продукт, а именно разработчики и дизайнеры.
Когда они интересуются, что же им следует делать, то какую бы книгу или статью они ни открыли, там приводится один и тот же набор причин, по которымсайт надо сделать доступным:

В этих правилах немало правды. К несчастью, есть и такие, которые вряд ли помогают убедить 26-летних разработчиков и дизайнеров, что они должны тратить время на доступность веб-контента. Вот, в частности, два аргумента, которые склоняют их к скептицизму:
- Их окружение в основном составляют здоровые, молодые люди, и им трудноповерить, что очень многим на самом деле нужна помощь в доступе к веб-контенту. Они стремятся проигнорировать этот факт, считая его преувеличением, как делают люди, когда ищут себе оправдание, но есть и естественныйсоблазн полагать, что «раз я смог опровергнуть один из аргументов, то имеюправо сомневаться и в остальных».
- Они также сомневаются, что улучшение доступности веб-контента выгодновсем. Некоторые выгодны – в качестве классического примера приведем субтитры, которые часто бывают удобны для тех, кто может слышать. Но поскольку никто, кажется, не приводит других примеров, то примерно с такимже успехом можно было бы доказывать, что космическая программа былаполезна, потому что благодаря ей у нас есть «Тенг». И разработчикам, и дизайнерам намного легче представить себе случаи, когда адаптация, призванная улучшить доступность веб-контента, скорее лишь затрудняет восприятие для «всех остальных».
Хуже всего в этом скепсисе то, что он заслоняет собою тот факт, что лишь однапричина имеет значение:
- Это правильно.
И это не просто правильно, это глубоко правильно, потому что единственный,редко принимаемый во внимание аргумент в пользу доступности веб-контентасостоит в том, что это поразительно улучшает жизнь некоторых людей. Лично ядумаю, что достаточно одного-единственного примера: незрячие люди, у которых есть компьютер, теперь могут читать ежедневную газету без постороннейпомощи. Представьте себе это.
Сколько возможностей у нас есть, чтобы коренным образом улучшить жизньдругих людей, лишь чуть лучше делая свою работу?
А тем, кто не считает этот аргумент убедительным, следует иметь в виду, чторано или поздно в качестве средства их убеждения выступит законодательныйкнут. Не сомневайтесь в этом.
Чего боятся разработчики и дизайнеры
По мере того как они больше узнают о доступности веб-контента, обычно вырисовываются два устрашающих фактора:
- Увеличение объема работ. Обеспечение доступности может показаться, особенно разработчикам, всего лишь еще одной сложной новой функцией, которую необходимо втиснуть в и без того невыполнимый график работ проекта.В худшем случае решение этой задачи приобретает вид «инициативы», спускаемой сверху и укомплектованной пожирающими время отчетами, проверками и заседаниями специальных комиссий.
- Скомпрометированный дизайн. Дизайнеры больше всего опасаются того,что я называю «кошкой с маслом», а именно ситуаций, когда дизайн, удобный для пользователей с ограниченными возможностями, грозит перейтив прямое противостояние дизайну, удовлетворяющему всех остальных. Онибеспокоятся, что их вынудят делать сайты, менее привлекательные (и менееполезные) для большей части аудитории.
В идеальном случае доступность веб-контента должна оказывать такое же действие, как табличка, увиденная мной на спинке переднего сиденья чикагского такси. На первый взгляд это была обыкновенная табличка, но она как-то по-особенному отражала свет. Присмотревшись, я понял, что она с фокусом.

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

Беда в том, что когда сайт пропускают через валидатор, то оказывается, что онпроверяет скорее грамматику, чем орфографию. Да, он действительно находитнекоторые очевидные ошибки и недосмотры, которые нетрудно устранить (например, пропущенный альтернативный текст). Но он, кроме того, обязательновыдает массу невнятных предупреждений о том, что вы, может быть, что-то делаете не так, и длинный список рекомендаций проверить что-то, что, как он самдопускает, может вовсе не быть ошибкой.
Это может сильно обескуражить тех, кто только начинает знакомство с вопросами доступности веб-контента, потому что длинные перечни и двусмысленные советы заставляют предположить, что еще очень многому предстоит научиться.
И правда в том, что сделать сайт доступным намного труднее, чем это должнобыть.
В конце концов, большинство дизайнеров и разработчиков не собираются становиться экспертами по доступности веб-контента. Если доступность веб-контентапретендует на вездесущность, то ее реализация должна стать проще. Экранныедикторы и другие адаптационные технологии должны стать изощреннее, инструментальные средства построения сайтов (такие как Macromedia Dreamweaver)должны упростить написание кода, обеспечивающего доступность веб-контента; не обойтись и без усовершенствования принципов доступности сетевых документов (WCAG).
Для настоящего прогресса в этой области потребуется добиться успехов на четырех фронтах, оперируя при этом соображениями выгоды, законами и угрозамисудебных процессов, а также желанием производителей пробиться на рынок мобильных устройств, которым свойственны те же проблемы доступности контента.

Пять шагов, которые можно сделать уже сейчас
Наш мир пока несовершенен, но это обстоятельство, однако, ни от чего нас не избавляет.
Даже те технологии и стандарты, которыми мы располагаем, позволяют сделатьлюбой сайт очень даже доступным, избегая при этом чрезмерного напряжения.Достаточно сосредоточиться на нескольких факторах, оказывающих наибольшее влияние на доступность. И никому при этом и близко не придется иметь дело с намазанными маслом кошками.
Шаг#1. Устраните те проблемы с юзабилити,которые мешают всем
Аргумент, апеллирующий к напитку «Тэнг» («если сделать веб-контент сайтадоступным, то он будет удобен всем»), раздражает меня тем, что он скрывает тообстоятельство, что на самом деле верно обратное. Один из самых эффективных способов сделать сайт более удобным для людей с ограниченными возможностями состоит в том, чтобы сделать его более удобным «для остальных».
Если что-то смущает большинство посетителей вашего сайта, то почти наверняка это что-то станет причиной неприятностей для тех, чей доступ затруднен.(Они не станут внезапно намного сообразительнее только от того, что их возможности ограничены.) И весьма вероятно, что им будет труднее оправиться от своего замешательства.
Вспомните, например, какими были ваши затруднения, когда вы последний раззаходили на чей-то сайт (допустим, вы отправили веб-форму и получили невнятное сообщение об ошибке). А теперь представьте себе, что вы не видите эту страницу и должны выпутаться из создавшейся ситуации.
Тестируйте свою веб-страницу почаще и все время исправляйте упущения, доставляющие неудобства всем – это лучшее и единственное, что вы можете сделать. Если не сделать этого с самого начала, то уже неважно, насколько неукоснительно вы будете придерживаться принципов доступности, – пользователис ограниченными возможностями все равно не смогут взаимодействовать с вашей страницей. Если работа с вашим сайтом непрозрачна, то стараться подогнать его под требования валидатора Bobby – это все равно что мазать свиньюпомадой (по-нашему, мартышкин труд).
Шаг#2. Прочитайте статью
Надеюсь, вы уже поняли, что лучший способ научиться делать сайт более удобным – это посмотреть, как люди пытаются работать с этим сайтом. Но большинство из нас не имеет опыта применения адаптивных методик, если не считатьопыта наблюдения за работой других людей.
Тем, кому это интересно и у кого есть время, я бы очень советовал найти одногодвух незрячих пользователей и потратить несколько часов, наблюдая, как они насамом деле работают со своими экранными дикторами в походах по Интернету.
К счастью, черную работу за вас уже сделали. Мэри Теофанос (Mary Theofanos)и Джэнис (Джинни) Редиш (Janice Redish) наблюдали, как 16 незрячих пользователей работали с экранными дикторами, выполняя ряд заданий на нескольких сайтах. Результаты обобщены в статье «Guidelines for Accessible and UsableWeb Sites: Observing Users Who Work with Screen Readers» (Принципы создания доступных и удобных веб-сайтов: наблюдение за пользователями, работающими с экранными дикторами).
Как юзер-тестинг любого рода, это исследование дало неоценимые результаты.Вот, в частности, что они узнали:
- Пользователи, прибегающие к помощи экранных дикторов, «смотрят» ушами.Большинство незрячих пользователей так же нетерпеливы, как и те, кто обладает даром зрения. Нужную им информацию они хотят получать как можно быстрее. Они непытаются услышать каждое слово на странице, как зрячие не читают все подряд. Онистараются услышать ровно столько, сколько им необходимо, чтобы решить, имеет лисмысл слушать дальше. Многие из них устанавливают поразительно высокую скоростьвоспроизведения.
Они слушают первые несколько слов в ссылке или в строке текста. Если услышанное некажется им подходящим, они быстро переходят к следующей ссылке (строке, заголовку, абзацу). Там, где зрячий пользователь может найти ключевое слово, глядя на всюстраницу сразу, незрячий это ключевое слово не услышит, если оно не расположенов начале ссылки или строки.
Очень советую прочитать эту статью, прежде чем вы возьметесь как-то улучшатьдоступность веб-контента. Потратив минут 20, вы начнете понимать проблемы,которые взялись решать, и этого вам не дадут никакие другие книги или статьи.
Шаг#3. Прочитайте книгу
Прочитав статью Джинни и Мэри, вы будете готовы потратить день (или неделю) на книгу о доступности веб-контента. Я бы рекомендовал следующие:
-«Building Accessible Websites» (Построение доступных веб-сайтов) Джо Кларка (Joe Clark).
-«Constructing Accessible Websites» (Создание доступных веб-сайтов) ДжимаТэчера и др. (Jim Thatcher et al).
-«Maximum Accessibility: Making Your Web Site More Usable for Everyone»(Максимальная доступность: как сделать веб-сайт более удобным для всех)Джона Слатина и Шэрон Раш (John Slatin and Sharron Rush).
-CD-ROM под названием «The WebAIM Guide to Web Accessibility Techniquesand Concepts» (Руководство WebAIM по методам и принципам обеспечениядоступности веб-контента).
...и я уверен, что в недалеком будущем появятся новые
Эти книги охватывают широкий спектр тем, поэтому не надо стремиться усвоить все, что там написано, – важно увидеть картину в целом.
Шаг#4. Начните применять каскадные таблицы стиле
Для начала небольшая веб-история.
Сначала все представлялось в виде текста. С появлением броузеров, поддерживающих графику, дизайнеры обнаружили, что HTML, в отличие от средств, предоставляемых настольными издательскими системами, которые позволялиуправлять абсолютно всем, не обеспечивает практически никакого контроляни над чем. Команды, управляющие оформлением текста, были грубыми, и точное размещение объектов на странице стоило больших трудов. И даже если удавалось их разместить, в разных броузерах страницы частенько выглядели совершенно по-разному.

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

Кроме того, появилась мода разнообразного применения команд HTML способами, для них не предусмотренными и призванными обеспечить дополнительныесредства управления форматированием текста. Все это напоминало свалку «самобытных конструкций», которые держались на жевательной резинке.
К счастью, в 1998 г. нашлись целеустремленные люди, уставшие от такого положения дел и решившие убедить производителей броузеров поддерживать веб-стандарты, которые дали бы дизайнерам надежную опору. Образовалась группа дизайнеров, которые сами назвали себя «The Web Standards Project» (Проект веб-стандартов) и прибегли к гениальной форме ненасильственного сопротивления. Онипопросту перестали делать свои сайты совместимыми с броузерами, не поддерживавшими стандарты, аналогичные CSS, и призвали остальных к тому же самому.
Несколько лет спустя на примере CSS Zen Garden (одной-единственной веб-страницы, которая преображалась до неузнаваемости в зависимости от того, какаяиз таблиц стилей, созданных дизайнерами, к ней применялась) было показано,что CSS позволяют создавать великолепные, изощренные макеты веб-страниц.
Сейчас CSS настолько хорошо поддерживаются большинством броузеров, чтонет никакого смысла создавать сайт, не прибегая к ним, потому что они дают огромные преимущества:
-Неизмеримо более мощные возможности форматирования.
-Гибкость. Всего одно изменение в таблице стилей способно преобразить целый сайт или автоматически сгенерировать его различные версии (например, страницы для печати).
-Единообразная интерпретация различными броузерами. До сих пор для того чтобы обеспечить функционирование CSS во всех броузерах, требуютсяобходные маневры и хаки, но эта необходимость исчезнет по мере того, какпроизводители броузеров будут улучшать поддержку CSS.
Применение CSS даст вам две возможности, которые помогут существенно улучшить доступность веб-контента:
-Сериализации контента. В отличие от табличного дизайна, CSS позволяетразмещать контент в исходном файле последовательно (т. е. так, как его услышит пользователь, работающий с экранным диктором), но тем не менеерасполагать его на странице по своему желанию.
-Изменения размера шрифта. CSS позволяет без труда менять размер шрифта, что чрезвычайно удобно для пользователей со слабым зрением (и пожилым людям, вынужденным носить бифокальные очки).
Возможно, самый быстрый способ изучения CSS – попросить кого-то, кто хорошо знаком с этим предметом, сделать для вас что-то вроде путеводителя, т. е.приспособить код нескольких шаблонов ваших страниц для применения CSS, а пока он будет это делать, понаблюдать за ним и поучиться. Получив некоторую подготовку, можно прочитать несколько хороших книг, особенно написанных Эриком Мейером («CSS – каскадные таблицы стилей», 3-е издание. – Пер.с англ. – СПб: Символ-Плюс, 2008).
Шаг#5. Начните с того, что лежит ближе
Итак, вы готовы заняться тем, что большинство людей называют обеспечениемдоступности веб-контента, а именно особым образом изменить код HTML.
Сейчас считается, что важнее всего, вероятно, сделать следующее:
-Снабдить каждое изображение подходящим текстом. Надо добавить атрибутalt к изображениям, которые будут игнорироваться экранными дикторами,а ко всему остальному – описательный текст. Во всех книгах по доступностивеб-контента очень хорошо рассказывается, как это сделать.
-Научите ваши формы взаимодействовать с экранными дикторами. Эта задача в значительной степени сводится к тому, чтобы посредством HTML-элемента label связать поля формы с текстом соответствующих подсказок, помогая тем самым пользователям понять, что именно они должны вводить.
-Создайте в начале каждой страницы ссылку «Skip to Main Content» (Перейти на главную страницу). Представьте, что вы должны по 20 секунд (или 1–2 минуты) прослушивать меню навигации в начале каждой страницы, и вы поймете, почему это важно.
-Сделайте так, чтобы доступ ко всему контенту можно было получить при помощи клавиатуры. Помните, что не все могут работать с мышью.
-Постарайтесь обойтись без JavaScript, если только у вас нет уважительнойпричины. Некоторые адаптационные технологии пока еще не слишком хорошо его поддерживают.
-Карты-изображения надо реализовывать на стороне клиента (не на стороне сервера). Теги alt не поддерживаются в картах-изображениях на стороне сервера.
Так что вот. Наверное, по ходу дела вы узнаете намного больше, но даже ограничившись только тем, что я сказал здесь, вы отлично справитесь с задачей.
Надеюсь, что лет через пять я смогу просто убрать эту главу из книги, и на освободившемся месте будет что-то другое, потому что и инструменты разработки,и броузеры, и экранные дикторы, и принципы доступности веб-контента достигнут такой степени зрелости, что образуют сплав, из которого можно будет делать доступные веб-сайты, не слишком задумываясь об этом.
