Что означает доступность сайта
Доступность сайта означает, что люди могут пользоваться им без лишних трудностей. Пользователь с экранным диктором, человек, который работает только с клавиатурой, тот, кто открыл сайт на телефоне под ярким солнцем, и человек со слабым зрением — все они сталкиваются с одной и той же страницей, но с разными потребностями, и страница должна работать для каждого из них; именно поэтому доступность сайта WCAG так часто рассматривают вместе с практическими сценариями использования.
Звучит просто. На практике — редко.
Хороший подход к доступности начинается не только с технологий. Он начинается с одного вопроса: может ли человек выполнить задачу за 3 клика, с мышью, только с клавиатурой или с помощью вспомогательного ПО? Если хотя бы для одного сценария ответ «нет», сайт сложнее, чем должен быть.
Доступность полезна и обычным пользователям в обычных ситуациях. Субтитры помогают человеку в шумном вокзале. Понятные состояния фокуса помогают тому, кто потерял курсор. Хорошо выстроенные заголовки позволяют быстро просмотреть длинную страницу за 20 секунд вместо 2 минут.
Команды часто воспринимают доступность как отдельную функцию. Это неверный подход. Она относится к структуре, тексту, формам, мультимедиа и навигации. Если вы уже работали над корпоративным сайтом, вы и так знаете, что структура влияет на каждую страницу; доступность просто делает эту структуру удобной для большего числа людей.
Что означает соответствие WCAG
WCAG расшифровывается как Web Content Accessibility Guidelines — рекомендации по доступности веб-контента. Это опубликованный стандарт, который помогает сделать веб-контент более доступным, и о соответствии WCAG часто говорят так, будто это один переключатель. Это не так.
Соответствие WCAG означает, что сайт отвечает релевантным критериям успеха на определённом уровне. Большинство команд ориентируются на AA, потому что этот уровень даёт баланс между объёмом работы и реальным эффектом. Сайт может быть частично, почти полностью или полностью соответствующим стандарту — в зависимости от того, что уже проверено и что ещё не работает.
Есть разница между соблюдением отдельных рекомендаций и соблюдением стандарта в целом. Страница с alt-текстом у изображений, но сломанным управлением с клавиатуры, не становится «достаточно доступной» только потому, что один пункт отмечен. Сайт с отличной контрастностью, но без подписей у полей формы, всё равно оставляет людей без возможности завершить действие.
Думайте о соответствии WCAG как о дисциплине, а не о значке. Стандарт даёт проверяемые критерии, а эти критерии помогают командам избегать расплывчатых обещаний. Если в обзоре упоминается «как сделать сайт доступным и что означает соответствие WCAG», нужно связать эти две вещи: одно — практическая работа, другое — стандарт, который её измеряет.
Начните с аудита доступности
Аудит доступности даёт первый список проблем; по сути, это аудит доступности сайта, который помогает понять, с чего начать. Начните с выборки из 10–20 важных страниц, а не со всего сайта сразу: обычно одни и те же барьеры повторяются снова и снова — отсутствующий alt-текст, низкий контраст, ловушки для клавиатуры, неподписанные формы и заголовки, которые без причины прыгают с H2 на H4.
Используйте и автоматические проверки, и ручной просмотр. Автоматизация быстро находит шаблоны, но не скажет, понятна ли кнопка в контексте и закрывается ли модальное окно корректно. Один быстрый ручной тест с клавиатурой может выявить больше, чем 50 автоматических предупреждений.
Проверяйте изображения по одному. Декоративные изображения обычно стоит скрывать от вспомогательных технологий, а смысловые — описывать через alt-текст, который передаёт главное. «График роста продаж в 2024 году» лучше, чем просто «график», а «Фото команды» лучше, чем «image123».
Формы требуют особого внимания. У каждого поля должна быть понятная подпись, а не только placeholder, потому что подсказка исчезает, когда человек начинает вводить текст. Поле входа без подписи превращается в игру в угадайку. На первом же шаге это уже сбой.
Проверяйте заголовки с помощью простой схемы. Заголовки не должны использоваться только ради оформления, а пользователь должен иметь возможность просмотреть структуру по порядку. Если структура запутана, страница сложнее и для пользователей экранных дикторов, и для всех, кто хочет быстро прочитать текст.
Постройте доступную структуру контента
Доступная структура контента начинается с семантических заголовков. Используйте H2 для основных разделов и H3 для подтем. Смысл здесь не в оформлении, а в навигации. Пользователи экранных дикторов переходят по заголовкам, и понятная структура позволяет им перемещаться по странице за секунды, а не читать каждую строку.
Организация страницы не менее важна. Размещайте основную задачу ближе к началу, держите связанный контент рядом и не разбрасывайте ключевые действия по пяти несвязанным блокам. Один понятный путь лучше трёх конкурирующих. Хаотичная компоновка может сделать простое действие похожим на головоломку.
Ссылки должны говорить, куда они ведут. «Подробнее» само по себе — слабый вариант. «Подробнее о поддержке сайта после запуска» уже объясняет, что получит пользователь, а это особенно важно, когда на странице 12 ссылок. Используйте описательный текст каждый раз, когда назначение не очевидно из соседнего предложения.
Для практического примера сравните «скачать» и «скачать PDF-чек-лист по доступности». Второй вариант длиннее, но он удобен. В списке ссылок для экранного диктора лишние слова — это не вода, а карта.
Alt-текст должен быть содержательным, а не театральным. На фото продукта может понадобиться название продукта и одна отличительная деталь. На скриншоте может потребоваться короткое объяснение состояния интерфейса. Декоративный элемент может остаться без описания. Такое различие экономит время пользователей, которые слышат подряд каждое описание изображения.
Хорошо читаемый текст тоже важен. Короткие абзацы помогают. Простые формулировки помогают ещё больше. Если одно предложение выполняет работу целого абзаца, разделите его. Если в предложении три мысли, сделайте из него 2 предложения. Экранные дикторы справляются с длинными текстами, но внимание человека всё равно не бесконечно.
Такой подход к странице также поддерживает контентные проекты, включая контентный портал об инвестициях, где пользователям нужны быстрое сканирование, чёткое деление на разделы и единая терминология от страницы к странице.
Сделайте навигацию и элементы управления удобными для клавиатуры
Доступ с клавиатуры не является опцией по желанию. Меню, кнопки, диалоги и формы должны работать без мыши. Если человек может дойти до элемента с помощью Tab, но не может его активировать, значит элемент сломан.
Сначала проверьте порядок перехода по Tab. Нажимайте Tab по странице и смотрите, идёт ли фокус в логичной последовательности сверху вниз, слева направо. Если фокус прыгает на скрытый элемент или пропускает важную кнопку, страницу нужно доработать. Видимость фокуса не менее важна: если не видно, где находится клавиатура, приходится гадать.
Диалоговые окна должны закрываться клавишей Escape или другим понятным действием. Когда диалог открывается, фокус должен переходить внутрь него, а при закрытии — возвращаться к элементу, который его вызвал. Без этого пользователи клавиатуры могут оказаться в ловушке или потеряться. Никто не хочет нажимать Tab 18 раз, чтобы найти выход.
Меню должны открываться и закрываться предсказуемо. Меню, которое работает только при наведении, недостаточно. Выпадающий список, зависящий от курсора мыши, может одновременно закрыть доступ и для пользователей клавиатуры, и для пользователей сенсорных экранов. Правило простое: если элемент существует, им должно быть можно управлять больше чем одним способом.
Формы заслуживают ещё одной проверки. Сообщения об ошибках должны показываться рядом с полем, быть написаны понятным языком и быть связаны именно с этим полем. Сообщение вроде «некорректный ввод» никому не помогает. Скажите, что пошло не так. Скажите, как это исправить. Два предложения могут сэкономить обращение в поддержку.
В крупных проектах полезно совмещать работу над доступностью с сайтом, который уже обрабатывает сложные сценарии, например инфраструктуру частной сети, потому что та же дисциплина, которая делает внутренние системы предсказуемыми, делает и публичные интерфейсы удобными.
Улучшите доступность цвета, контраста и мультимедиа
Контрастность цвета напрямую влияет на читаемость. Текст, который сливается с фоном, может выглядеть стильно в макете, но провалиться в повседневном использовании. Проверьте контрастность инструментом, а затем посмотрите на реальных экранах.
Не полагайтесь только на цвет, если нужно передать смысл. Если обязательные поля выделены красным, дополните это текстом или иконкой с текстом. Если в диаграмме используются красный и зелёный, добавьте подписи или узоры. Один цветовой сигнал может исчезнуть для людей с нарушением цветоразличения, но задача всё равно должна оставаться понятной.
Субтитры — первый шаг для видео. Они помогают людям, которые не слышат звук, и тем, кто держит звук выключенным в общественных местах. Расшифровка ещё полезнее, если пользователь хочет искать по тексту, цитировать или позже сверять детали. Аудиоописание важно для видео, где визуальная информация не произносится вслух.
Изображения с текстом внутри требуют особого внимания. Если этот текст важен, продублируйте его и в тексте страницы. Баннер с надписью «Регистрация до пятницы» не должен заставлять человека разбирать скриншот, чтобы найти дедлайн. Небольшое решение, большая разница.
Проверки цвета и мультимедиа должны быть частью и ревизии безопасности сайта, потому что сайт, который выглядит безопасным, но скрывает важный текст или содержит сломанные медиафайлы, часто вызывает то же недоверие, что и техническая ошибка. Если вы уже отслеживаете безопасность сайта, добавьте проверки доступности в тот же цикл ревизии.
Тестируйте, исправляйте и поддерживайте доступность со временем
Доступность — это не разовая уборка. Сайты меняются каждую неделю, а иногда и каждый день. Новый баннер, обновление формы или переработанное меню могут за 30 минут вернуть старые проблемы.
Постройте простой процесс. Сначала запускайте автоматические проверки на изменённых страницах. Затем вручную проверяйте ключевые пользовательские сценарии с клавиатурой и экранным диктором. Потом собирайте отзывы пользователей и фиксируйте проблему с URL страницы, браузером и точным шагом, на котором она возникает. Четыре поля в тикете лучше, чем одна расплывчатая жалоба.
Поддерживать сайт проще, когда доступность входит в обычную релизную работу. Если разработчики добавляют компоненты, у них должны быть подписи, состояния фокуса и поддержка клавиатуры ещё до выкладки. Если редакторы загружают изображения, у них должна быть привычка добавлять alt-текст. Если маркетологи добавляют промо-блоки, им нужно проверять контраст и текст ссылок.
Используйте шаблоны с версионированием, где это возможно. Закреплённый хедер, стандартный блок формы и проверенный паттерн модального окна уменьшают число повторяющихся ошибок. Именно поэтому команды, которым важна поддержка сайта после запуска, часто лучше справляются с доступностью: работа встроена в поддержку, а не добавляется потом заплатками после жалоб.
Обратная связь от реальных пользователей — самый точный тест. Пользователь с клавиатурой найдёт ловушку в меню из трёх пунктов быстрее любого инструмента аудита. Пользователь экранного диктора сразу услышит, понятна ли кнопка при первом использовании. Если 2 человека сообщают об одной и той же блокировке, считайте это закономерностью, а не совпадением.
И ещё одна полезная привычка: связывайте проверки доступности с каждым обновлением контента. Если команда публикует новую страницу, не проверяя заголовки, подписи и медиа, сайт постепенно откатывается назад. Список из 5 пунктов по поддержке может остановить этот откат до того, как он распространится на все страницы.
