Веб-разработчики к адаптации сайтов для слабовидящих (и других категорий людей с ограниченными возможностями здоровья) относятся двойственно. С одной стороны, я еще не встречал человека, который бы сказал «их слишком мало, чтобы тратить на них время»; с другой — в условиях фиксированных бюджетов и сжатых сроков именно так и случается. К тому же, тот факт, что для этого надо изучать какие-то правила, рекомендации, часто просто пугает. А между тем, большинство рекомендаций WCAG 2.0 от консорциума W3C (Web Content Accessibility Guidelines, Руководство по обеспечению доступности веб-контента) при ближайшем рассмотрении банально совпадают с правилами хорошего тона, рекомендациями для адаптации сайтов под мобильные устройства, да и просто не так уж и сложны в реализации. При этом следование этим рекомендациям упростит работу с сайтом не только не только пользователям с ограниченными возможностями здоровья, но и пользователям с ограниченными техническими возможностями (низкоскоростной Интернет; отсутствие мыши, как на смартфонах; маленький экран), а также пожилым людям. Поэтому я решил написать вольное изложение всех двенадцати положений WCAG 2.0, которое и предлагаю вашему вниманию.
Предоставьте текстовую версию любого нетекстового контента для его возможного преобразования в альтернативные формы, удобные для различных пользователей
Самый простой и универсальный способ восприятия информации для любого человека — печатный текст. Он не всегда оптимален для условно-здоровых людей (совсем здоровых, как мы знаем, не бывает): песни лучше слушать, видео — смотреть. Но текстовый формат хорош тем, что его воспринимаемость легко можно улучшить: слабовидящим при помощи экранной лупы или увеличения шрифта средствами операционной системы, слепым — при помощи программ компьютерного озвучивания текста или вывода его на Брайлевский дисплей. Поэтому весь контент, который поддается представлению в текстовом виде, нужно так и представлять (или предлагать текстовое представление как альтернативный способ донесения информации). Исключения из этого правила — специальные формы контента:
- Элементы управления и ввода информации (поля ввода, выпадающие списки, переключатели). Такие элементы невозможно представить в виде текста, для них необходимо использовать тег label и атрибуты alt, title. Это поможет программно ассоциировать поле ввода с поясняющей надписью и, как следствие, донести до пользователя смысл элемента.
- Тесты или упражнения, которые невозможно представить в виде текста. В этом случае необходим хотя бы краткий текст-пояснение этого упражнения. То же относится к контенту, создающему специфическое сенсорное восприятие (картины, музыка без слов).
- Капча. Во-первых, необходимо чёткое пояснение, зачем нужно это поле ввода и как что туда вводить (наверняка вы встречали «аскетичную» капчу, состоящую только из картинки и поля ввода, без текстовых пояснений?). Во-вторых, капча должна иметь альтернативный вывод информации (аудиокапча).
- Нетекстовые элементы, предназначенные для украшения, форматирования или вообще не видные. Такие элементы необходимо описывать так, чтобы вспомогательные (ассистивные) технологии (например, озвучивание текста) их игнорировали. То есть, к примеру, выносить оформление в CSS или не прописывать атрибуты alt и title.
Предоставьте альтернативную версию медиа-контента, ограниченного по времени
Случались ли у вас ситуации, когда вам нужно быстро понять, что именно содержит длинный видеоролик, чтобы решить, стоит его смотреть? Или найти нужный вам фрагмент, который «где-то посередине»? Или человек, говорящий на аудиозаписи, делает это слишком быстро или неразборчиво? Согласитесь, всегда полезно иметь текстовой аналог содержимого аудио- или видеоклипа. Или как минимум описание того, что там записано.
При этом надо понимать, что расшифровка аудиоряда не в полной мере описывает содержимое видеоролика. Текстовой аналог должен включать еще и описание того, что важного изображено на экране, чтобы донести до читателя полный смысл видео. Помимо текстовой версии видео-роликов создают еще и аудио-версии, по тем же самым принципам.
И полезность субтитров в видеоролике никто не отменял.
Создавайте контент, который можно представить в различных видах без потери данных или структуры (например, с более простым макетом страницы)
Ассистивные технологии, предназначенные для компьютерного озвучивания текста, воспринимают HTML-страницу как последовательность текста, а не как совокупность блоков, геометрически расставленных на странице. Поэтому очень важно в исходном коде страницы соблюдать ту же последовательность блоков, что подразумевается при отображении. Например, при абсолютном позиционировании div-ов они должны приведены в той же последовательности, что и показаны на странице. Также это накладывает ограничения на сенсорные характеристики контента (цвет, местоположение и пр.). Пример инструкций, которые могут создать проблемы пользователям с ограниченными возможностями: «если вы физическое лицо, заполните форму во второй колонке таблицы» или «нажмите зеленую кнопку, если вы согласны с условиями оферты».
Также полезно предоставить пользователю страницу с облегченным дизайном (например, версия для печати).
И, само собой, важно использовать семантически правильную верстку. Не только для ассистивных технологий, но и для других случаев автоматического извлечения контента, например, поисковых машин.
Упростите просмотр и прослушивание контента, отделив важные части от второстепенных
Начнем с цвета. Цветовое кодирование — вещь полезная. Например, кнопка/иконка сохранения может быть зеленой, а кнопка удаления — красной. Или пользователю предлагается для какой-то задачи выбрать цвет: гораздо нагляднее вывести цветные квадратики и предложить нажать на понравившийся цвет, чем выбрать из выпадающего списка значения «зеленый», «красный» и пр.
Но нельзя использовать цвет как единственный способ передачи информации или обозначения действия. На красной кнопке должно быть четко написано «удалить» (или она должна иметь соответствующий атрибут title), то же относится к цветным квадратам. Еще один пример, который, к сожалению, встречается очень часто: выделение красным бордюром неправильно заполненных полей формы. Цветового кодирования здесь недостаточно: нужно как минимум перечислить все неправильные поля и указать, в чем именно ошибка (в телефонном номере мало цифр, email не соответствует формату).
Это положение касается также аудиоконтента, проигрываемого автоматически. Наверняка вы, как и я, встречали навязчивые баннеры или другие элементы страниц, которые не только показывают, но и рассказывают вслух свое послание. И наверняка вас, как и меня, в большинстве случаев это раздражает. Лично я считаю, что такие элементы на страницах использовать нельзя (за исключением редких случаев типа браузерных игр или онлайн-трансляций), но если они все же есть, необходимо предоставить средство выключения звука или уменьшения его громкости непосредственно на странице, а не средствами операционной системы или кнопки выключения колонок.
Также желательно отказаться от фонового звука или, если уж очень хочется, сделать его тихим и отключаемым.
Также к этому положению относятся следующие несложные правила:
- текст должен быть достаточно контрастным по отношению к фону, за исключением второстепенного текста и элементов типа логотипов
- пользователь должен иметь возможность увеличить текст как минимум до 200%, и при этом страница не должна разъехаться
- не нужно выводить текст в виде картинки (если это не имеет четкого оправдания)
- при верстке текста желательно соблюдать общие правила типографики для веба: ширина строки не больше 80 символов, текст не выравнивается по обоим краям, межстрочный интервал должен быть небольшим и ощутимо меньше интервала между абзацами и т. д.
Предоставьте возможность управления всей функциональностью с клавиатуры
Когда я впервые сел за компьютер, самой популярной средой работы был текстовый Norton Commander. Все без исключения операции в нем было удобно делать на клавиатуре, а мышь мы использовали гораздо реже, чем сейчас, в графических операционных системах. Оно и понятно: попробуйте без мыши, одним Tab-ом добраться до восемьдесят третьей иконки на рабочем столе или до ссылки в футере вашего сайта.
Тем не менее, по старой памяти я часто использую клавиатуру не только для ввода текста: клавиша «вниз» в полях ввода или выпадающих списках, ctrl-c/ctrl-v, Tab, Enter и т.д. И я испытываю хотя и легкое, но недовольство, если по нажатии Enter не происходит отправка формы, а после ввода логина клавиша Tab не переводит курсор на поле ввода пароля.
Вот и в положении WCAG также говорится об обеспечении управления функциональностью контента при помощи клавиатуры. В первую очередь это относится к формам. Отдельная проблема — модные сегодня одностраничные сайты (когда переход к подразделам сайта происходит без перезагрузки страницы: новая страница либо выползает справа или снизу, либо всплывает поверх старой), parallax-эффекты, выпадение меню при наведении мыши и пр.
Проверить соответствие вашей страницы этому положению очень просто: отодвиньте мышку и попробуйте все значимые действия со страницей произвести только при помощи клавиатуры.
Предоставьте пользователям достаточно времени для ознакомления и работы с контентом
В этом положении идет речь о контенте, ограниченном во времени. Например, это могут быть сменяющиеся кадры спецпредложений или новинок, онлайн-тесты, настольные онлайн-игры с ограничением на время хода или партии, автоматические листалки слайдов презентаций и пр. Такие ограничения могут создать проблему не только слабовидящим, но и пожилым, а также людям, для которых язык контента не является родным. По возможности временных ограничений лучше избегать, а если совсем не получается — давать пользователю вручную возможность поставить на паузу или продлить срок действия контента, заранее предупредив его об истечении времени.
Конечно, бывают случаи, когда продлить срок действия невозможно, например, онлайн-аукционы, выбор места в самолете в реальном времени. Для таких случаев тоже есть приемы: давать больше времени на шаг аукциона, блокировать выбранное пользователем место, чтобы дать ему избыточное время для подтверждения выбора и т. д.
Если же ограничение времени связано с вопросами безопасности (например, клиент-банк прерывает сессию, если пользователь долго бездействует), то помимо предупреждения о скором разрыве сессии, если такой разрыв все же произошел, нужно после повторной авторизации вернуть пользователя на то место, где он был до этого, не заставляя заново проходить весь путь с начала.
Не используйте заведомо опасные для здоровья элементы дизайна
Здесь речь идет о вспышках или слишком частых миганиях страницы или ее элеметов. (Сюда же я бы добавил резкие неожиданные звуки.) Думаю, нежелательность таких приемов и для условно-здоровых людей вполне очевидна. Если же по какой-то причине без таких вспышек не обойтись, нужно по крайней мере делать их не очень частыми.
Предоставьте пользователям помощь и поддержку в навигации, поиске контента и в определении их текущего положения на сайте
И снова опытный веб-разработчик не найдет в этом положении ничего такого, что бы противоречило логике при проектировании сайта без учета аудитории людей с ограниченными возможностями здоровья:
- каждая страница должна иметь заголовок, описывающий контент
- текст ссылки должен достаточно явно описывать страницу, на которую попадет посетитель при нажатии («подробная информация о продукте находится здесь» — плохой пример; «см. также подробную информацию о продукте» — хороший)
- посетитель должен иметь несколько способов поиска нужной ему страницы (стандартная навигация, карта сайта, строка поиска)
- при перемещении по форме при помощи клавиатуры (клавишей Tab) активное поле формы должно быть очевидно выделено
- на любой странице посетителю должно быть понятно, что это за страница и сайт
Также при верстке надо учитывать, что при перемещении по странице при помощи клавиатуры последовательность перемещения должна быть такая же, как и при использовании мыши; смысл страницы при этом не должен нарушаться.
Если основному контенту страницы предшествует большое количество второстепенной информации (шапка, реклама, элементы навигации, второстепенные элементы), то как можно выше на странице должен быть элемент, при нажатии на который посетитель увидит основное содержимое. Впрочем, использовать массивные шапки и прятать контент на вторую прокрутку экрана — и так дурной тон.
Сделайте весь текстовый контент удобочитаемым и понятным
Во-первых, язык (или основной язык) страницы должен быть определен в HTML-коде страницы. Если на странице присутствуют блоки текста на другом языке (например, цитаты), их контейнер должен иметь атрибут xml:lang, определяющий язык. Во-вторых, если в тексте присутствуют редкие слова, аббревиатуры или специфические значения слов, имеет смысл их пояснить сразу же.
Если же контент слишком специализирован (например, в нем использованы формулы, научный, медицинский или финансовый лексикон), но ориентирован не только на профессиональную аудиторию, было бы неплохо предоставить альтернативное содержание контента, более простое и по смыслу, и по возможностям прочтения.
Веб-страницы должны отображаться и функционировать предсказуемым образом
При разработке следует избегать нестандартного поведения страницы или ее элементов, которое может запутать пользователя. Примеры ошибочного поведения страницы:
- при перемещении фокуса с неправильно заполненного поля на другое поле фокус без спроса пользователя перемещается обратно
- при фокусе на поле, требующее пояснения, окно подсказки всплывает автоматически
- пояснение к полю ввода отображается не рядом с ним, а внутри него, и пропадает при получении фокуса
- стандартная навигация по сайту на разных страницах располагается или ведет себя по-разному
- если роль списка (тег select) в том, чтобы пользователь выбрал, на какую страницу перейти, переход должен осуществляться после выбора пункта и нажатия пробела или Enter, а не Esc или Tab
Иными словами, изменение контекста страницы (открытие нового окна, переход на другую страницу, динамическая замена ощутимого количества контента) должно быть предсказуемым для пользователя; его действие, которое вызвало это изменение (отправка формы, перевод фокуса, наведение мышки на элемент, прокрутка), должно в понимании пользователя явно ассоциироваться с последствиями.
Помогайте пользователям избегать ошибок при вводе информации и исправлять их
Наверняка вы не раз видели сообщения об ошибках в духе «Ошибка №355» или «Переполнение стека» или «Форма некорректно заполнена». Увидишь окошко с такой надписью и смотришь на нее, как на новые ворота, каждый раз думая: ну неужели сложно было написать так, чтобы было понятно, что мне с этим делать?! Но ведь эти надписи писали не секретари, а программисты, причем, хорошие программисты. Замечали ли вы, что с ростом профессионального уровня разработчики отдаляются от «простого народа»? Мы знаем, что поле со звездочкой — обязательное, что дата в России заполняется в формате «дд.мм.гггг», что если после поля «пароль» идет такое же поле без подписи, то это повтор пароля, а поле рядом с цифорками — капча.
Если же мы встанем на место человека, восприятие которым нашей формы затруднено по той или иной причине (неродной язык, слабое зрение, возраст, отсутствие опыта в Интернете), нам будет гораздо проще составить формы так, чтобы они были понятны для любой категории пользователей. Под составлением формы я подразумеваю не только саму ее верстку, но и реакцию на некорректное заполнение: место вывода и содержимое сообщений об ошибках, подсказки и шаблоны.
Также очень важны принципы подтверждения и обратимости, особенно в случаях когда речь идет о юридических или финансовых операциях (согласие с офертой, отправка платежа и пр.): пользователю нужно, во-первых, предоставить возможность проверки введенных данных и исправления ошибок до отправки, а во-вторых, если это возможно, возможность отзыва отправленной информации (отмены действия).
Обеспечьте максимальную совместимость контента с существующими и разрабатываемыми пользовательскими приложениями, включая ассистивные технологии
Иногда с целью украшательства разработчики заменяют стандартные элементы HTML альтернативными средствами. Например, вместо выпадающего списка — невидимый слой, появляющийся при нажатии на элемент; вместо радиобатонов — картинки с изображением включенных/выключенных кружков, вместо кнопки сабмита — картинка с onclick-ом. Таких приемов лучше избегать, благо, возможности HTML/CSS достаточно мощные для подобных визуальных эффектов, а если совсем не получается — проверять на совместимость с ассистивными технологиями.
И сюда же еще раз: семантически правильная верстка очень важна!
Заключение
Как видите, ничего экзотического Руководство по обеспечению доступности веб-контента от разработчика не требует. Конечно, сам документ более сложный и подробный, с уровнями соответствия, глоссарием и пр. К сожалению, основная часть сопроводительного контента (объяснения, примеры) еще не переведена на русский, но в избытке есть в оригинале.
В России зарегистрировано больше 13 миллионов лиц с ограниченными возможностями, то есть 10% от населения страны. То есть с определенными допущениями можно считать, что каждый десятый посетитель ваших сайтов имеет какие-либо ограничения по здоровью. А если учесть пользователей различных гаджетов, для которых описанные принципы также применимы, а также пожилых людей, их доля в аудитории сайта может вырасти до 30-40%. Согласитесь, даже десять (не говоря уже о сорока) процентов посетителей — более чем ощутимая цифра для того, чтобы позаботиться о том, чтобы им было удобно читать ваш сайт, писать, делать на нем покупки.
Лично я считаю, что в точности следовать букве Руководства в каждом проекте не обязательно: в некоторых случаях это может оказаться слишком трудоемким. Но если вы будете держать в голове основные принципы и учитывать их в работе, ваши проекты будут гораздо более дружелюбны к самым разным пользователям.
P.S. Благодарю за помощь в подготовке статьи экспертов российского офиса W3C Алексея Любимова и Даниэля Новичкова.
Автор: dimatwork
