Доступность сайта: формы, навигация и WCAG без лишней сложности

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

Доступность, или accessibility, — это свойство сайта и интерфейса, которое позволяет людям с разными возможностями, устройствами и способами взаимодействия получить информацию и выполнить задачу. Она важна для пользователей скринридеров, людей с нарушениями зрения, моторики, слуха или когнитивными особенностями. Но многие решения одновременно помогают и более широкой аудитории: понятные подписи полей — тем, кто спешит; заметный фокус — тем, кто временно работает без мыши; ясный текст ошибки — всем, кто вводит номер или адрес с телефона.

На 17 августа 2026 года практичным техническим ориентиром остаётся WCAG 2.2 — рекомендации W3C по доступности веб-контента. Это не «чекбокс для дизайнера» и не автоматическая юридическая оценка сайта. WCAG задаёт проверяемые критерии, а требования закона зависят от страны, сферы и конкретной ситуации. Поэтому здесь мы не делаем правовых выводов. Вместо этого разберём, как владельцу сайта или продукта снизить трение в формах, навигации и чтении контента, выстроить проверку и превратить замечания в понятный план работ.

Что доступность даёт продукту и почему начинать стоит с пути к форме

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

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

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

WCAG 2.2 группирует 13 рекомендаций по четырём принципам — воспринимаемость, управляемость, понятность и надёжность. Соответствие определяют критерии успеха уровней A, AA и AAA. Для первого плана работ обычно полезно ориентироваться на применимые критерии A и AA, но не объявлять страницу «полностью соответствующей» только потому, что пройдены несколько ручных проверок или автоматический сканер показал ноль ошибок.

Доступность форм: где возникают самые дорогие потери

У каждого поля должна быть понятная, постоянная подпись

Плейсхолдер вида «Введите телефон» не заменяет . Он исчезает при вводе, часто имеет слабый контраст и не всегда даёт корректное имя элементу для вспомогательных технологий. Видимая подпись над или рядом с полем помогает человеку быстро проверить контекст, а связанный с элементом label сообщает назначение поля скринридеру.

Пишите «Телефон», «Рабочий e-mail», «Комментарий к задаче», а не только «Данные» или «Контакт». Если формат важен, сообщите его до ввода: «Телефон в формате +7 999 123-45-67». Не полагайтесь на цвет, иконку или звёздочку без текстового объяснения. Укажите, какие поля обязательны, единым понятным способом и сделайте это доступным программно.

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

Ошибка должна быть найдена, названа и объяснена

После отправки формы недостаточно обвести поле красной рамкой или вывести сверху «Проверьте данные». Пользователь должен понять три вещи: что именно не так, где ошибка и что сделать дальше. Например: «Поле „Рабочий e-mail“: укажите адрес в формате name@company.ru». Такая формулировка конкретнее, чем «Некорректные данные».

Свяжите сообщение с полем так, чтобы его мог прочитать скринридер; при необходимости используйте доступное объявление статуса. После неуспешной отправки переведите фокус к сводке ошибок или к первому проблемному полю — в зависимости от сценария — и не стирайте уже введённые корректные данные. Если ошибка появляется во время ввода, не ругайте человека за каждый незавершённый символ: предупреждение должно быть своевременным и не мешать продолжить действие.

На форме заявки полезен минимум из трёх проверок:

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

Не требуйте от человека догадаться, почему форма «молчит». И не превращайте anti-spam-механику в блокер: CAPTCHA и похожие проверки должны объяснять назначение и иметь доступные альтернативы для разных способов восприятия, как отмечает WCAG в критерии о нетекстовом контенте.

Подтверждение отправки — часть формы, а не конец разработки

Когда форма ушла, пользователь должен получить недвусмысленный результат: «Заявка отправлена. Мы ответим по указанному каналу связи» или сообщение об ошибке отправки с безопасным следующим шагом. Если интерфейс обновляет блок без перезагрузки, статус нужно сделать доступным для вспомогательных технологий. Если кнопка временно блокируется, объясните состояние визуально и текстом; не оставляйте человека перед серой кнопкой без ответа.

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

Навигация и клавиатура: проверить сайт без мыши

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

Начните с ручной прогулки по ключевым страницам. Откройте сайт в чистом профиле браузера и используйте Tab, Shift + Tab, Enter, Space и Esc. Не нажимайте мышью, чтобы «помочь» сценарию. Запишите результат:

Не удаляйте outline ради «чистого дизайна». Если стандартный контур не вписывается в визуальную систему, замените его собственным, но заметным и контрастным. В WCAG 2.2 появились уточнения о том, что фокус не должен быть перекрыт и как должно выглядеть его состояние. Это особенно важно для фиксированной шапки, cookie-баннера, плавающего чата и липкой кнопки: они могут физически закрыть активный элемент.

Уберите ловушки. Если пользователь может войти с Tab в сложный виджет, он должен тем же стандартным способом выйти из него. Слайдер, редактор, карта или iframe нередко ломают этот сценарий. Не подменяйте нативные элементы самодельными без необходимости. Обычная кнопка, ссылка, поле ввода и select уже несут ожидаемые роли и поведение; кастомный компонент требует воспроизвести это поведение полностью, включая клавиатуру, имя, роль, состояние и сообщение об изменениях.

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

Текст, структура и контраст: сделать содержание различимым и понятным

Заголовки задают карту страницы

Заголовок — не способ сделать текст крупнее. Семантические h1–h6 создают структуру, по которой многие пользователи скринридеров переходят между разделами. На странице обычно нужен один содержательный H1, далее H2 для крупных смысловых блоков и H3 для вложенных. Не выбирайте уровень только ради размера: оформление решается CSS.

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

Язык страницы нужно обозначать в HTML (lang="ru" для русской страницы), а фрагменты на другом языке — когда это действительно нужно — размечать соответствующим языком. Так синтезатор речи сможет выбрать подходящее произношение. Расшифровывайте редкие сокращения при первом упоминании: «Web Content Accessibility Guidelines (WCAG)».

Контраст — это не только текст

Для обычного текста критерий WCAG 2.2 1.4.3 уровня AA устанавливает минимальную контрастность 4,5:1; для крупного текста — 3:1. «Крупный» в самом критерии определяется размером и начертанием, а не субъективным ощущением макета. Это минимальный ориентир, а не дизайнерская цель: тонкий светло-серый текст на белом фоне способен пройти на грани, но всё ещё плохо читаться в ярком свете или при усталости.

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

Проверяйте контраст в реальном состоянии: hover, focus, disabled, ошибка, выбранный пункт, текст поверх изображения, тёмная и светлая тема. Компоновка может быть доступна в Figma и перестать быть такой в браузере из-за прозрачности, градиента, фонового изображения или наложения баннера.

Простой язык снижает нагрузку

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

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

Как выстроить проверку по WCAG без иллюзии «одной кнопки»

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

Рабочий процесс можно собрать в пять шагов.

1. Определите объём и риск

Соберите не все URL подряд, а шаблоны и сценарии с ценой ошибки: главная и страницы услуг, рекламные посадочные, каталог и карточка, личный кабинет, поиск, корзина, оплата, лид-форма. За каждым сценарием закрепите владельца: продукт отвечает за путь, дизайн — за состояния, разработка — за семантику и поведение, контент — за понятность текста, аналитика — за наблюдение результата.

2. Проведите быструю ручную проверку

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

3. Добавьте технические проверки

Запустите автоматический сканер в CI или перед релизом, но настройте исключения прозрачно и не «глушите» предупреждения пачкой. Сверьте разметку: нативные контролы, label, заголовки, язык страницы, корректные имена ссылок и кнопок. Для динамических компонентов ориентируйтесь на паттерны WAI-ARIA Authoring Practices, а не на случайные фрагменты кода из чужих проектов.

4. Приоритизируйте не по количеству замечаний

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

5. Подтвердите исправление повторным сценарием

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

Практический чек-лист для владельца сайта

• У каждой критичной формы есть видимые подписи полей, понятные обязательные поля и инструкции формата.
• Ошибка содержит текст: что не так и как исправить; она не передаётся только цветом.
• При неуспешной отправке фокус приводит пользователя к ошибке, а корректно введённые данные сохраняются.
• Успешная отправка и техническая ошибка сообщаются понятным, доступным статусом.
• Все CTA, меню, поля, чекбоксы, селекты, модальные окна и закрытие доступны с клавиатуры.
• Фокус всегда заметен, не скрыт плавающими элементами и перемещается логично.
• На странице есть один H1 и последовательная иерархия H2–H3; ссылки ясны вне контекста.
• Основной текст и его состояния имеют достаточный контраст; важные элементы не различаются одним цветом.
• У изображений, иконок-кнопок и нетекстовых контролов есть корректные текстовые альтернативы или доступное имя.
• У страницы задан язык, а сложные и редкие термины пояснены.
• В команде есть тест ключевых сценариев перед релизом и владелец устранения замечаний.

Частые ошибки, которые выглядят как «современный UI»

Поле без label, потому что «плейсхолдер и так всё объясняет»

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

Убрали outline, чтобы не портить макет

Это лишает клавиатурного пользователя координат. Проектируйте состояние фокуса в дизайн-системе так же внимательно, как hover и active. Контур может быть фирменным, но обязан быть различимым.

Кликабельный блок сделан из `div`

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

Аудит ограничили автоматическим сервисом

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

ARIA добавляют «для доступности» без модели поведения

ARIA не лечит неверную разметку сама по себе. Неподходящая роль или несинхронное состояние могут сообщить скринридеру ложную информацию. Сначала выбирайте нативный HTML; ARIA применяйте, когда компонент действительно требует дополнительной семантики, и тестируйте результат.

FAQ

Достаточно ли пройти автоматический тест, чтобы сайт стал доступным?

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

Какой уровень WCAG выбрать для коммерческого сайта?

WCAG задаёт критерии A, AA и AAA, а не один универсальный «уровень сайта». Для практической разработки часто рассматривают применимые критерии A и AA, но целевой объём следует определить с учётом продукта, аудитории и применимых требований. Это не юридическая консультация.

Улучшит ли доступность конверсию формы?

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

Нужно ли переписывать весь сайт, если проверка нашла много проблем?

Не обязательно. Начните с шаблонов и сценариев с максимальным риском: основные формы, меню, авторизация, корзина, страницы услуг. Многие базовые исправления — label, фокус, семантическая кнопка, резервирование состояния ошибки — точечны. Сложные компоненты и устаревшую архитектуру планируйте отдельными этапами.

Можно ли использовать цвет для статуса ошибки или успеха?

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

Зачем проверять доступность с клавиатуры, если большинство посетителей на смартфоне?

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

Доступность — это качество пути, а не отдельная галочка

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

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

Источники

Проверены 17 августа 2026 года.

1. W3C WAI — WCAG 2 Overview
2. W3C WAI — How to Meet WCAG 2.2 (Quick Reference)
3. W3C WAI — Forms Tutorial
4. W3C WAI — Menus Tutorial
5. W3C WAI — Headings
6. W3C WAI — Writing for Web Accessibility
7. W3C WAI — Understanding Success Criterion 1.4.3: Contrast (Minimum)
8. W3C WAI — Understanding Success Criterion 2.1.1: Keyboard
9. W3C WAI-ARIA Authoring Practices Guide