Доступность сайта: как сделать так, чтобы им мог пользоваться каждый

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

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

Кому на самом деле нужна доступность

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

• Слабовидящие. Люди, которые не используют скринридер, но увеличивают масштаб страницы до 150–200% или выкручивают системный шрифт. Если вёрстка жёстко завязана на пиксели, такой сайт разваливается: текст уезжает за блок, кнопки накладываются друг на друга.
• Люди с нарушениями цветовосприятия. Для них «красное поле — ошибка, зелёное — всё хорошо» не несёт никакой информации, если рядом нет текста или иконки.
• Пользователи, которые не работают мышью. Кто-то из-за моторных нарушений, кто-то из-за травмы, кто-то просто привык управлять клавиатурой. Им нужно, чтобы по сайту можно было пройти табуляцией и всё время понимать, где ты находишься.
• Люди с когнитивными особенностями и те, кому трудно читать длинные тексты. Им помогают простые формулировки, короткие абзацы, предсказуемая навигация и отсутствие внезапных анимаций.
• Пользователи с временными ограничениями. Сломанная рука, яркое солнце на экране телефона, шумное место, где нельзя включить звук видео. Это бывает с каждым.

И есть ещё одна категория, о которой чаще всего думают в последнюю очередь: поисковые роботы. Они тоже «смотрят» на сайт без глаз — через код, заголовки, подписи к изображениям и текстовое содержание. Поэтому доступный сайт почти всегда оказывается технически более здоровым и лучше индексируется.

Что делает сайт недоступным: типичные ошибки

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

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

Текст, вшитый в картинку. Баннер, где всё предложение — одно изображение. Его нельзя увеличить без потери качества, нельзя выделить, нельзя прочитать скринридеру, нельзя перевести автоматическим переводчиком.

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

Ссылки без смысла. Десять ссылок «Подробнее» подряд. Пользователь скринридера часто просматривает список ссылок отдельно от текста, и этот список превращается в бессмыслицу.

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

Невидимый фокус. Разработчик убрал «некрасивую рамку» вокруг активного элемента и ничем её не заменил. Человек, идущий по странице клавишей Tab, теряет курсор и перестаёт понимать, куда он попадёт, нажав Enter.

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

Базовый набор: что заложить в проект

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

Структура и семантика

• Один заголовок первого уровня на странице, дальше — последовательная иерархия без пропусков. Заголовки нужны не для размера шрифта, а для навигации: по ним ориентируются и люди, и роботы.
• Осмысленные области страницы: шапка, основная часть, навигация, подвал. Это позволяет перескакивать между блоками одной командой, а не прослушивать меню на каждой странице заново.
• Ссылка «перейти к основному содержанию» в самом начале — простое решение, которое экономит пользователю клавиатуры десятки нажатий.
• Списки оформлены списками, таблицы — таблицами, а не набором блоков, имитирующих их внешний вид.

Текст и изображения

• Альтернативное описание у содержательных картинок — коротко и по делу, без «картинка», «фото» и перечисления ключевых слов. У декоративных изображений описание должно быть пустым, чтобы они не засоряли чтение.
• Подписи к схемам и инфографике дублируются текстом рядом или под ними: иначе вся информация оказывается заперта внутри изображения.
• Язык страницы указан в коде — от этого зависит, с каким произношением синтезатор речи прочитает текст.
• Видео сопровождается субтитрами, а подкаст или аудио — текстовой расшифровкой. Это нужно не только людям с нарушением слуха, но и всем, кто смотрит без звука.

Цвет, размеры, движение

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

Интерактив

• Всё, что делается мышью, делается и с клавиатуры: открыть меню, закрыть модальное окно, пролистать галерею, отправить форму.
• Фокус виден всегда и логично перемещается: открылось модальное окно — фокус внутри него и не убегает на фон; окно закрылось — фокус вернулся туда, откуда его вызвали.
• У полей формы есть связанные подписи, у ошибок — текстовое объяснение рядом с проблемным полем, а не только общее «проверьте данные».
• Таймеры и автозакрытие уведомлений либо отключаются, либо дают достаточно времени прочитать.

Как проверять, а не верить на слово

Доступность легко заявить и трудно подтвердить, поэтому её стоит проверять так же, как вёрстку или скорость.

1. Пройдите сайт клавиатурой. Уберите руку с мыши и попробуйте сделать всё: открыть меню, выбрать товар, заполнить форму, закрыть всплывающее окно. Если где-то застряли или потеряли фокус — это баг, а не особенность.
2. Увеличьте масштаб страницы. Посмотрите, что происходит при 200%: не исчезла ли часть интерфейса, не появился ли горизонтальный скролл, читаются ли кнопки.
3. Проверьте контраст. Для этого есть бесплатные инструменты и расширения; достаточно прогнать основные пары «текст — фон».
4. Отключите изображения. Если после этого страница перестала быть понятной, значит, слишком много информации живёт только в картинках.
5. Прогоните автоматический аудит. Автотесты ловят часть проблем: отсутствие альтернативных описаний, подписей у полей, нарушения иерархии заголовков. Но они не умеют оценивать смысл — «альт» вида «image_0012.jpg» формально есть, а пользы от него нет.
6. Попробуйте скринридер. Даже получасовой опыт работы с программой экранного доступа меняет отношение к вёрстке сильнее, чем любая теория.

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

Почему это выгодно, а не благотворительность

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

Это расширение аудитории. Люди с ограничениями — реальные клиенты с реальными деньгами. Если конкурент сделал сайт, на котором невозможно оформить заказ без мыши, а у вас — можно, выбор очевиден.

Это дешевле на старте. Переделывать доступность в готовом проекте дорого: приходится трогать и макеты, и вёрстку, и контент. Заложенная в начале, она почти не влияет на бюджет — это просто дисциплина работы, а не отдельный этап.

Это качество кода. Семантическая разметка, предсказуемая структура, подписанные элементы — то же самое, что требуется для нормальной поддержки, тестирования и индексации. Доступный сайт обычно оказывается аккуратнее написанным.

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

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