Доступный веб-дизайн — это не пункт проверки после публикации, а включение навигации с клавиатуры, рамки фокуса, подписей и текстовых альтернатив в проектные решения. Это руководство поможет Вам встроить эти четыре аспекта в структуру страницы на конкретных примерах. Цель — дать посетителю, который не пользуется мышью, возможность выполнить ту же задачу.
Доступный веб-дизайн — не контрольный список, который открывают после выбора цветовой палитры. Навигация с клавиатуры, сохранение видимой рамки фокуса, подписи полей формы и текстовые альтернативы — проектные решения, которые принимают так же рано, как решения о сетке, отступах и типографике.
Это руководство рассматривает доступность не как последующую доработку, а как работу с фокусом, подписями, альтернативами и порядком навигации. Сценарий, понятный при использовании мыши, должен позволять выполнить ту же задачу человеку, который перемещается только клавишей Tab.
Почему доступный веб-дизайн — задача проектирования
Если в отчёте аудита накапливаются пункты «фокус не виден», «меню не открывается с клавиатуры», «у иконки нет имени», проблема не в технике, а в недостаточно проработанном дизайне. Эти вопросы связаны с компоновкой интерфейса, поведением компонентов и написанием контента.
На этапе проектирования согласуйте четыре аспекта вместе:
- Порядок навигации: Совпадает ли путь перемещения клавишей Tab с визуальной иерархией?
- Фокус: Видно ли активный элемент везде и не скрывается ли он под закреплёнными сверху панелями?
- Подпись: Согласуется ли видимое название кнопки, ссылки или поля с именем, которое озвучивает вспомогательная технология?
- Альтернатива: Можно ли передать текстом информацию, которую несут изображение, иконка или диаграмма?
Эти четыре аспекта позволяют выполнить одну и ту же задачу при временной травме, двигательных ограничениях, предпочтении клавиатуры или использовании программы чтения с экрана. В новом проекте по направлению веб-дизайн откладывать их на «проверку качества в последнем спринте» — значит впоследствии получить множество проблем с фокусом и пустыми альтернативами.
Согласуйте навигацию с клавиатуры с визуальным порядком
Пользователь клавиатуры ориентируется на положение фокуса, а не просто просматривает страницу глазами. Фокус должен перемещаться слева направо, сверху вниз и в первую очередь вести к основной задаче. Если поле поиска визуально находится слева, но при нажатии Tab оказывается последним, дизайн и поведение не согласованы.
При проектировании порядка навигации рассматривайте следующие правила как часть дизайна:
- В последовательность Tab входят только интерактивные элементы: ссылки, кнопки, поля форм, раскрывающиеся меню и вкладки.
- Обычный текст, вся поверхность карточки или декоративный блок не получают фокус.
- Визуальный порядок совпадает с порядком DOM. «Исправление» порядка положительным tabindex — временная заплатка.
- Ссылка для пропуска повторяющегося верхнего меню и перехода к основному содержимому — один из первых полезных шагов при объёмной шапке страницы.
Делать всю карточку кликабельной — распространённая ловушка. Если карточка целиком становится огромной ссылкой, Tab останавливается на каждой карточке, а расположенные внутри «Подробнее» и «Сравнить» не озвучиваются отдельно. Более простое решение: карточка служит визуальным контейнером, а фокус получает одна понятная ссылка или кнопка. Так последовательность остаётся короткой, а имя — ясным.
Нестандартный компонент, меню и удержание фокуса
Готовое раскрывающееся меню, календарь выбора даты или нестандартный select могут хорошо работать с мышью. Для клавиатуры требуется отдельная модель состояний: Enter или Space открывает компонент, клавиши со стрелками переключают варианты, Escape закрывает его, а фокус возвращается к элементу, который его открыл. Это не «микроанимация», а правила взаимодействия.
Фокус не следует удерживать внутри компонента, за исключением модальных окон и выдвижных панелей. При открытии диалога фокус переносится внутрь, Tab перемещает его в пределах диалога, а после закрытия фокус возвращается к открывшему его элементу управления. Если фоновая страница по-прежнему доступна через Tab, пользователь теряет ориентир. Это поведение применимо и к направлению корпоративный веб-дизайн : к формам запроса предложения, панелям настройки cookies и переключателям языка.
Закреплённая верхняя панель может закрывать ссылку, получившую фокус. Предусмотрите в дизайне внутренний отступ или отступ при прокрутке, равный высоте панели. Если фокус «есть», но его не видно, для пользователя клавиатуры такого элемента управления не существует.
Сделайте рамку фокуса заметной и единообразной
Удаление стандартной рамки фокуса обещает «более чистый» вид при работе мышью, но при использовании клавиатуры скрывает активный элемент. Если Вы убираете рамку, замените её не менее заметным индикатором фокуса, соответствующим стилю бренда. Цвет при наведении не заменяет фокус: наведение связано с мышью, фокус — с клавиатурой.
Требования к рамке фокуса можно сформулировать кратко:
- Рамка заметна и на светлом, и на тёмном фоне.
- Толщина и отступ не позволяют тонкой линии потеряться.
- На всём сайте используется единый визуальный подход: рамка на одной странице и полное отсутствие индикации на другой подрывают доверие.
- Рамка фокуса не обрезается из-за скруглённых углов или тени.
В проектах KepezWeb рамку фокуса не следует оставлять как «деталь для разработчика». Кнопки, ссылки, вкладки, элементы управления внутри карточек и поля форм относятся к одной системе. В библиотеке компонентов состояния hover, active и focus оформляются отдельно; focus — не «бледная версия active».
Тёмные секции, текст поверх изображения и полупрозрачные слои создают дополнительные риски для фокуса. Светлая кнопка в первом экране может хорошо читаться на тёмной фотографии при работе мышью, но если рамка фокуса сливается с фото, пользователь клавиатуры теряет ориентир. Цвет фокуса выбирают отдельно с учётом фона этого блока.
Текстовая альтернатива: когда писать, а когда оставлять пустой
Текстовая альтернатива передаёт текстом назначение изображения. Это не требование писать длинное предложение для каждой картинки. Вопрос в другом: сообщит ли страница ту же информацию без этого изображения?
- Информативное изображение: Товар, команда, офис, инфографика, диаграмма. Альтернатива кратко передаёт информацию изображения. «Изображение1.jpg» или «фотография товара» — не информация.
- Декоративное изображение: Атмосферная иллюстрация, текстура, узор для заполнения пространства. Альтернативу оставляют пустой, чтобы программа чтения с экрана пропустила изображение.
- Изображение, повторяющее текст: Если рядом уже написан тот же заголовок, повторное озвучивание изображения создаёт лишний шум.
- Функциональная иконка: Лупа, корзина, закрытие, отправка. Указывают не описание картинки, а название элемента управления: «Поиск», «Корзина», «Закрыть».
Сложную диаграмму не описать одним предложением. Краткая альтернатива обозначает тему, а сами данные приводятся в таблице или в пояснении сразу под диаграммой. «Диаграмма, показывающая рост продаж» — недостаточно: нужно передать текстом период и сравнение, которые на ней представлены.
Изображение внутри ссылки создаёт ещё одну ловушку. Если логотип ведёт на главную страницу, альтернативой служит название бренда, а не слово «логотип». Если изображение товара является ссылкой, альтернатива не должна дублировать название товара; когда цель ссылки — «перейти к подробностям товара», её передают видимым текстом или доступным именем. Тот же подход полезен и для направления технический SEO-аудит : пустая или повторяющаяся альтернатива ухудшает восприятие вспомогательными технологиями и делает контекст изображения менее ясным.
Кнопка-иконка и призыв к действию только в виде изображения
Иконка без текста может казаться «понятной» при работе мышью. Но если у элемента управления нет видимого названия, для клавиатуры и программы чтения с экрана он остаётся безымянным. Иконки сердца, трёх точек, стрелки и закрытия должны сопровождаться либо коротким текстом, либо согласованным доступным именем. Имя не должно противоречить видимой подписи: кнопка с текстом «Отправить» на экране не должна озвучиваться как «Передать форму».
Если фоновое изображение задано через CSS, у него нет атрибута alt. Если информация встроена в это изображение, перенесите её в HTML-текст. Дата акции, цена или предупреждение, присутствующие только на картинке, недоступны тому, кто не может её увидеть. Не встраивайте изменяющиеся условия, например цену или срок, в изображение; сохраняйте их в текстовом слое.
Подпись, доступное имя и ссылка для перехода к содержимому
Видимая подпись — источник доступного имени. Текст-подсказка внутри поля не заменяет подпись. Подсказка «Ваше имя» исчезает при заполнении поля; при ошибке пользователь уже не видит, что у него спрашивали. Подпись размещается снаружи, программно связывается с полем, а сообщение об ошибке поясняет проблему этого поля.
Атрибуты Aria не заменяют семантический HTML. Кнопка должна быть кнопкой, ссылка — ссылкой. Добавлять поддержку клавиатуры и имя к кликабельному элементу div впоследствии дороже, чем сразу выбрать правильный элемент. Используйте Aria, чтобы восполнить недостающую семантику в действительно нестандартном компоненте.
Ссылка для перехода к содержимому («Перейти к содержимому») — первый элемент, способный получить фокус; при фокусе она становится видимой. Если такая ссылка скрыта и не появляется даже при получении фокуса, считайте, что её нет. На длинных корпоративных страницах этот небольшой элемент избавляет от необходимости каждый раз проходить всё меню.
Язык страницы, иерархия заголовков и ориентиры landmark тоже помогают навигации. Набор заголовков только уровня h2 или три области «основного содержимого» нарушают не только навигацию с клавиатуры, но и работу со списком заголовков в программе чтения с экрана. Заголовок — структурный ориентир, а не размер текста: крупный текст может не быть элементом заголовка, а небольшая подпись может быть настоящим заголовком.
Что проверить на этапе проектирования
Сравнение ниже показывает, какие решения и на каком этапе нужно принимать, чтобы не исправлять всё заплатками впоследствии.
| Решение | Предусмотреть в дизайне | Исправлять впоследствии |
|---|---|---|
| Порядок навигации | Визуальная иерархия и порядок DOM проектируются согласованно | Порядок принудительно меняют через tabindex и скрытый фокус |
| Рамка фокуса | Отличается от hover и видна у всех компонентов | Рамку удаляют, а затем возвращают на одной странице |
| Текстовая альтернатива | Указывается роль изображения: информация, декор или элемент управления | Подставляют имя файла или бессодержательный текст «изображение» |
| Подпись и имя | Видимый текст совпадает с доступным именем | Оставляют только подсказку внутри поля или иконку |
| Окно и меню | Определены правила открытия, закрытия и возврата фокуса | Закрывается мышью, но Escape и Tab не работают |
Проводите проверку, отключив мышь. Выполните основную задачу только с клавиатуры: перейдите из меню к услуге, отправьте форму, откройте основную ссылку в карточке, закройте модальное окно. Если где-то фокус исчезает, порядок перескакивает назад или имя не озвучивается, не хватает не «дополнения для доступности», а правил взаимодействия для этого компонента.
Любую задачу, выполняемую мышью, должно быть возможно выполнить и с клавиатуры — в том же порядке и с теми же названиями элементов.
Часто задаваемые вопросы
Доступность нужна только пользователям с постоянными ограничениями здоровья?
Нет. Сломанная рука, яркое солнце, неисправная мышь или привычка работать только с клавиатурой выявляют те же недостатки. Если дизайн устраняет их заранее, выполнение задачи не зависит от одного способа ввода.
Удаление рамки фокуса вредит бренду?
Вредит удаление рамки без какой-либо замены; единообразный индикатор фокуса в стиле бренда не вредит. Использовать стиль наведения вместо фокуса недостаточно. Рамку проверяют отдельно на тёмном и светлом фоне.
Нужно ли писать альтернативный текст для каждого изображения?
Нет. Для информативного изображения пишут краткую и точную альтернативу. Для декоративного оставляют её пустой. У кнопки-иконки указывают название элемента управления, а не описание картинки.
Делает ли использование Aria страницу доступной?
Само по себе — нет. Основную работу выполняют правильный HTML-элемент, видимая подпись, порядок навигации с клавиатуры и видимый фокус. Aria нужна, чтобы восполнить недостающую семантику в нестандартном компоненте; некорректная aria может запутать сильнее, чем безымянный элемент управления.
Когда нужно это тестировать?
При первом проектировании компонента. До утверждения меню, формы, модального окна и шаблона карточки пройдите их с клавиатуры. Одна проверка перед публикацией не позволит с малыми затратами исправить решения о фокусе и подписях, которые не были приняты вовремя.
Если Вы хотите с самого начала предусмотреть порядок навигации с клавиатуры, рамку фокуса и текстовые альтернативы при создании или обновлении сайта, уточните объём работ с командой KepezWeb. Чтобы получить предложение с учётом Ваших потребностей, достаточно оставить короткое сообщение.
