Содержание
Сайт может выглядеть спокойно: ровная сетка, правильные цвета, форма в конце страницы. Потом человек не пользуется мышью, нажимает Tab и обнаруживает, что фокус исчез, меню перескочило через кнопку, а ошибка в форме сообщает только красным оттенком. Компания при этом обычно уверена, что всё отправляется. Человек – уже не очень.
Не начинайте с обещания «проверить доступность сайта целиком». Выберите одно главное действие – отправить форму, записаться, заказать, открыть контакты – и пройдите его клавиатурой, при увеличении текста и после безопасной ошибки. Если в каждом состоянии понятно, где вы находитесь, что нужно ввести и что получилось, у маршрута есть хорошая базовая устойчивость. Если нет, красивый экран пока не выполняет свою работу.
Это не заменяет полноценный аудит, тестирование со вспомогательными технологиями или юридическую оценку. Но короткий проход находит неприятные дефекты раньше, чем человек решит, что проще написать конкуренту. Для владельца сайта это уже достаточно серьёзная причина не оставлять проверку только в чек-листе разработчика.
Главное действие должно проходиться без мыши
Клавиатура не экзотический режим для узкого круга людей. Ею пользуются люди без зрения, люди с ограниченной моторикой, пользователи экранной клавиатуры, голосового ввода и переключателей. Иногда ею пользуется и человек с обычным ноутбуком, когда мышь внезапно решила отдохнуть. Базовое правило простое: всё, что можно сделать на сайте, должно работать с клавиатуры, кроме действий, которым по природе нужен свободный путь указателя.
Для сайта услуг полезно не проверять все ссылки подряд ради спортивного интереса. Начните с одного маршрута: открыть страницу, понять предложение, перейти к форме или контакту, заполнить нужные поля, отправить. Нажимайте Tab и Shift+Tab, затем Enter или Space там, где это ожидаемо. Меню открывается? Выпадающий список можно выбрать? Кнопка нажимается? Не застревает ли фокус в чате, cookie-баннере или декоративной карусели?
Отдельный вопрос – видно ли текущее положение. Если после Tab вокруг ссылки или кнопки ничего не меняется, зрячему человеку с клавиатурой остаётся угадывать, какое действие произойдёт следующим нажатием. Текущий элемент должен быть заметен и не прятаться целиком под содержимым страницы. Липкая панель, виджет и модальное окно иногда умудряются спрятать именно то, к чему человек только что пришёл.
Практический вывод: не нужно запоминать все критерии. Достаточно спросить: «Могу ли я без мыши увидеть следующий шаг и завершить главное действие?» Если ответ нет, маршрут уже блокирует часть клиентов.
Увеличение текста не должно убирать содержание и действие
Частая ошибка выглядит невинно: дизайнер точно рассчитал высоту карточки, а в ней чуть позже стало больше текста, крупнее шрифт или длиннее подпись. На привычном разрешении всё аккуратно. При увеличении обрезается условие, наезжает кнопка или исчезает сообщение об ошибке. Человек видит не «сложный интерфейс», а половину фразы и решение, до которого нельзя добраться.
При увеличении текста вдвое содержание и действия не должны пропадать. Это не просьба нарисовать на сайте собственную кнопку «А+». Браузер уже умеет увеличивать страницу или текст; задача страницы – не мешать ему. На узком экране обычный вертикальный текст не должен заставлять человека постоянно прокручивать и по вертикали, и по горизонтали, чтобы прочитать одну строку.
Для первого прохода увеличьте страницу в браузере до 200% и снова проверьте только важные места: заголовок действия, подписи полей, текст ошибки, кнопку и подтверждение. Смотрите не на то, насколько красиво сохранилась сетка, а на то, можно ли прочесть и выполнить сценарий. Горизонтальная прокрутка в большой таблице или рабочем чертеже может быть оправдана. В короткой форме записи она обычно означает, что кто-то выбрал фиксированную ширину вместо человека.
Что здесь важно: 200% – полезная граница первого теста, а не сертификат. Если в этом масштабе главное действие осталось понятным и доступным, вы проверили реальное свойство маршрута, а не только десктопный макет.
Подпись объясняет ввод, а ошибка – что исправить
Поле без ясной подписи заставляет человека угадывать, что от него хотят. Placeholder внутри поля выглядит как подсказка, пока пользователь не начал печатать; потом он исчезает ровно в тот момент, когда может понадобиться. У поля должен быть понятный вопрос или инструкция: что вводить, обязательно ли это, в каком формате и зачем данные нужны, если это не очевидно из действия.
Когда сайт сам нашёл ошибку, он должен обозначить проблемное поле и описать ошибку текстом. Одна красная рамка, иконка или встревоженное покачивание поля недостаточны: их может не увидеть человек с нарушением зрения, не понять человек с особенностями восприятия или просто пропустить тот, кто смотрит на увеличенную страницу. Хорошее сообщение называет поле и говорит простыми словами, что не так. Если безопасный способ исправления известен, его тоже стоит подсказать.
Проверьте это на намеренно безопасной ошибке: оставьте обязательное поле пустым или введите явно неверный формат в тестовом контуре. После отправки должны сохраниться уже введённые данные, появиться текстовое объяснение, а фокус или ссылка помочь вернуться к нужному месту. Необязательно строить огромный диалог ошибок. Иногда достаточно сообщения рядом с полем и краткой сводки сверху. Важно, чтобы человек не искал одну неверную букву как потерянный ключ от машины.
Практический вывод: цвет может помогать, но не несёт объяснение один. Человек должен прочесть, какое поле требует внимания и какое действие вернёт его в маршрут.
После нажатия человек должен понять, что получилось
Доступность не заканчивается в момент, когда кнопка получила нажатие. После отправки формы человек должен получить понятный результат: заявка принята, в данных есть ошибка, запрос не удалось завершить или нужен ещё один шаг. Важно сообщать и об ошибках, и об успешном завершении задачи. Успешное сообщение особенно важно, когда форма остаётся на той же странице и визуально почти ничего не меняется.
Для клиента подтверждение отвечает хотя бы на три вопроса: что именно принято, что произойдёт дальше и когда или каким способом ждать продолжение. Не обязательно обещать ответ через десять минут, если бизнес так не работает. Достаточно не оставлять человека с зелёной галочкой, которая ничего не говорит о реальном результате. Для заказа это может быть номер и состав следующего шага; для записи – время и способ связи; для заявки – честный срок или канал ответа.
Здесь есть важная граница. Видимое подтверждение доказывает, что интерфейс показал человеку состояние. Оно не доказывает, что сервер сохранил данные, письмо дошло, а менеджер уже взял обращение в работу. Эту вторую половину маршрута я разбирал отдельно: после формы у компании появляются доставка, точка учёта и ответственный. Не стоит смешивать два теста и объявлять победу после первого.
Что проверить: главный путь закончен только тогда, когда посетитель получил понятный результат, а не когда разработчик увидел обработчик события в консоли.
Пройдите один маршрут и запишите место разрыва
Выберите одно действие, которое действительно важно бизнесу сейчас: отправить форму расчёта, записаться на услугу, оформить заказ или открыть способ связи. Запишите начало и ожидаемый результат до теста. Затем уберите мышь и пройдите путь с клавиатурой. Повторите его при увеличении до 200%. После этого сделайте безопасную ошибку, исправьте её и завершите действие на тестовом контуре или с данными, которые не создадут ложную заявку.
На каждом шаге фиксируйте не оценку «удобно» или «неудобно», а наблюдение: фокус пропал после меню; подпись исчезла в поле; кнопка ушла за край; ошибка не назвала формат; подтверждение не объяснило продолжение. Рядом запишите владельца участка: дизайн, верстка, форма, интеграция, редактура. Это не поиск виноватого. Это способ не передавать один дефект по кругу между «кажется, всё работает» и «у нас не получается повторить».
Короткий проход не проверит экранный диктор, контраст всех состояний, сложные жесты, документы, сторонние виджеты и весь сайт на всех устройствах. Если на маршруте есть оплата, государственная услуга, медицинские данные, большой личный кабинет или критичная для людей функция, нужен более глубокий тест и участие тех, кто реально пользуется вспомогательными технологиями. Но даже тогда один пройденный путь остаётся хорошим началом: он даёт команде общий предмет разговора вместо абстрактного слова «доступность».
Результат проверки: не ставьте сайту оценку «доступен». Назовите конкретный разрыв, его владельца, безопасный обход и следующий тест после исправления.
Доступный маршрут – это возможность довести своё действие до понятного результата
Хороший сайт не заставляет человека выбирать между мышью, зрением, привычным масштабом и попыткой угадать смысл ошибки. Он даёт несколько способов сделать одно важное действие и не теряет смысл по дороге. Клавиатура показывает порядок, увеличение – устойчивость текста и элементов управления, подписи – ожидание от ввода, ошибка – путь обратно, подтверждение – конец текущей задачи.
Начните с малого: с одного маршрута и одного безопасного прохода. Не нужно ждать редизайна, покупки специальной платформы или идеального списка критериев. Если на пути нашёлся разрыв, исправьте его и пройдите тот же сценарий снова. Если разрывов нет, не объявляйте сайт полностью соответствующим стандарту – просто сохраните результат и выберите следующий важный путь.
Небольшой вывод: доступность помогает клиенту завершить собственное действие. Красивый статус здесь вторичен. Для бизнеса это довольно практичная роскошь.
Главный вывод: сначала проверьте, может ли человек пройти главный маршрут без мыши и догадок. Только потом спорьте о том, как назвать весь сайт.
Пять вопросов после первого прохода
Нужно ли убрать мышь с сайта ради клавиатуры?
Нет. Речь не о замене одного способа другим, а о том, чтобы главное действие было выполнимо с клавиатурой. Мышь, касание и обычный интерфейс остаются на месте.
Достаточно ли проверить страницу при 200%?
Нет. Это полезный первый тест текста, полей и кнопок. Он не заменяет проверку reflow, экранных дикторов, контраста, сторонних компонентов и других пользовательских сценариев.
Можно ли оставить только placeholder внутри поля?
Лучше нет. Текст внутри поля исчезает при вводе и плохо заменяет понятную подпись. У человека должна оставаться видимая или программно доступная информация о том, что и в каком формате нужно указать.
Достаточно ли красной рамки для ошибки?
Нет. Рамка может быть дополнительным сигналом, но ошибка должна быть названа текстом: какое поле требует внимания и что с ним не так. Если известно безопасное исправление, его стоит подсказать.
Такой проход докажет полную доступность сайта?
Нет. Он покажет состояние одного важного маршрута. Полная оценка зависит от объёма сайта, технологий, критериев, устройств и, при необходимости, тестирования с пользователями вспомогательных технологий.
Официальные ориентиры для следующей проверки
Эти документы задают критерии и примеры проверки. Они не заменяют изучение конкретного сайта, договорённость об объёме работ или юридическую консультацию.
- Как проверить работу сайта с клавиатуры Что означает доступность функциональности с клавиатурного интерфейса и где остаётся узкое исключение для действий со свободным движением указателя. Открыть источник ↗
- Как сделать текущий элемент заметным Почему человек должен видеть, какой элемент сейчас получит следующее клавиатурное действие. Открыть источник ↗
- Как проверить увеличение текста Критерий увеличения текста до 200% без потери содержания или функции. Открыть источник ↗
- Как проверить страницу на узком экране Как оценить перестройку обычного вертикального контента при узком представлении. Открыть источник ↗
- Как сообщать результат после отправки формы Практика текстовых ошибок, подсказок и подтверждения успешного завершения действия. Открыть источник ↗
- Росстандарт: ГОСТ Р 52872-2019 Действующий российский стандарт о доступности цифрового контента и интерфейсов; его наличие не превращает этот короткий проход в юридическое заключение. Открыть источник ↗
