Ошибки доступности в редизайнах: формы, диалоги, клавиатура

Почему поспешные редизайны создают реальные проблемы с доступностью

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

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

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

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

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

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

Где формы ломаются при визуальной чистке

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

Самая частая ошибка — убрать видимые подписи и заменить их placeholder'ами. В макете это выглядит аккуратно, но как только человек что-то вводит, подсказка исчезает. В результате приходится запоминать, для чего было поле. Это же создаёт сложности для людей, которые пользуются скринридерами, вводом голосом или просто устали к концу дня.

Во время редизайна часто ухудшается и работа с ошибками. Команда может перенести текст ошибки в верх формы, чтобы сохранить чистую верстку, или показывать ошибки только после полной отправки. Звучит нестрашно, пока человек не пропускает сообщение и не понимает, какое поле не прошло проверку. Текст ошибки лучше всего работает рядом с полем, простым языком и в нужный момент.

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

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

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

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

Что идёт не так в диалогах

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

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

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

Кнопка закрытия часто ломается более тихо. Дизайнеры заменяют текстовую подпись маленькой иконкой «x», а потом никто не даёт этой кнопке понятное имя. Зрячий пользователь догадывается, что она значит. Пользователь со скринридером может услышать только «кнопка» или что-то столь же расплывчатое, и простой выход превращается в перебор вариантов.

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

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

Большую часть этого ловит быстрая проверка. Откройте диалог с клавиатуры, пройдите tab'ом по каждому элементу, закройте его и проверьте, куда вернулся фокус. Потом повторите то же самое, когда один диалог открывает другой. Если за 30 секунд это ощущается неудобно, в реальной работе будет ещё хуже.

Как ломается навигация с клавиатуры

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

Первый сбой обычно связан с порядком tab'ов. Команды переставляют карточки, кнопки и поля на экране, но клавиатура всё равно идёт по старой разметке под капотом. Человек проходит страницу в порядке кода, а не в визуальном порядке, и фокус может прыгать с шапки в боковую колонку, потом вниз в подвал, а затем снова в основную форму. Это ощущается хаотично, даже если технически все элементы по-прежнему работают.

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

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

Кастомные элементы добавляют ещё один слой проблем. Стилизованное меню может открываться по Enter, но игнорировать стрелки. Поповер может запирать фокус и не закрываться по Escape. Фальшивый select может выглядеть гладко в демо и при этом мешать реальному использованию с клавиатуры.

Фиксированные шапки и подвал создают более тихую проблему. Фокус переходит на следующую кнопку или ссылку, но закреплённая панель закрывает её. Пользователь продолжает табать, потому что думает, что ничего не изменилось. Команды пропускают это, когда тестируют только на больших экранах и коротких страницах.

Drag-and-drop — ещё одно слабое место. Если перемещать элементы можно только перетаскиванием, у задачи нет пути через клавиатуру. Обычно лучше работает простой запасной вариант: вверх, вниз, сохранить.

Тестировать клавиатуру не нужно сложными инструментами. Откройте редизайн, начните сверху, используйте Tab, Shift+Tab, Enter, Space, стрелки и Esc. Если человек не может дойти до каждого элемента, увидеть его, использовать и выйти из него таким способом, редизайн ещё не готов.

Как проверять редизайн шаг за шагом

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

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

Проверяйте в таком порядке:

1. Выберите три реальные задачи и запишите точную стартовую страницу для каждой. Не импровизируйте во время теста.
2. Пройдите каждый сценарий только с клавиатурой. Используйте Tab, Shift+Tab, Enter, Space, стрелки и Esc. Смотрите, куда уходит фокус, где он пропадает и можно ли добраться до каждого элемента в понятном порядке.
3. Откройте каждый диалог из каждого места, где он может запускаться. Модальное окно, которое работает из шапки, может ломаться, если тот же компонент открывается из формы или карточки глубже на странице.
4. Нарочно вызывайте ошибки валидации. Оставляйте поля пустыми, вводите неправильный формат и отправляйте слишком рано. Затем проверьте, ясно ли сообщение, легко ли его заметить и привязано ли оно к нужному полю.
5. Увеличьте масштаб до 200% и протестируйте на маленьком экране или узком окне браузера. Текст должен оставаться читаемым, кнопки — доступными, и ничего не должно заставлять прокручивать страницу по горизонтали.

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

Записывайте заметки во время проверки. Если не проходит хотя бы одна из трёх задач, считайте это проблемой дизайна и разработки, а не единичным багом. Сначала исправьте сам шаблон, потом перепроверьте всё, что его использует.

Ошибки, которые команды повторяют под дедлайном

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

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

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

Самые опасные «заплатки» перед дедлайном легко узнать:

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

Каждый такой shortcut ломает что-то по-своему. Положительный tabindex может показаться безобидным, но он превращает порядок клавиатуры в хрупкий ручной сценарий. Одно новое поле может всё нарушить. Div может выглядеть точно как кнопка, но не вести себя как кнопка, пока кто-то не восстановит недостающее поведение. Валидация только при blur — ещё одна тихая ошибка. Если пользователь не покинет поле ожидаемым способом, форма будет молчать до момента, когда он упрётся в стену.

Чаще всего такие ошибки появляются не из-за халатности. Они возникают, когда в конце редизайна спешат с последними 10 процентами: полируют поверхность и пропускают скучные проверки. Более строгий процесс ревью исправляет большую часть этого. Более медленный выпуск исправляет остальное.

Простой пример редизайна

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

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

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

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

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

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

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

На старте это занимает немного больше времени. Зато потом экономит гораздо больше спешных переделок.

Быстрая проверка перед релизом

Полированный экран всё равно может провалиться меньше чем за минуту. Прямо перед релизом сделайте один ручной проход, используя только клавиатуру. Он ловит ошибки доступности в редизайнах, которые визуальная проверка часто пропускает.

Используйте страницу так, как использовал бы её реальный человек, а не тестировщик, который уже знает, где всё находится.

• Нажмите Tab от начала страницы до конца. Каждое поле, чекбокс, кнопка и ссылка должны получать фокус в понятном порядке. Потом пройдите назад с Shift+Tab. Если фокус пропускает элемент, прыгает куда-то странно или застревает, страница не готова.
• Попробуйте Enter и Space на всём, что выглядит кликабельным. Кастомные элементы часто работают мышью и ломаются с клавиатуры, особенно после поспешного редизайна интерфейса, где нативные элементы заменили стилизованными.
• Отправьте форму с ошибками специально. Текст ошибки должен называть поле и объяснять, что исправить. «Email обязателен» или «Пароль должен быть не короче 12 символов» — понятно. «Неверный ввод» — нет.
• Следите за индикатором фокуса во всех состояниях, до которых можно добраться. Проверьте обычные поля, состояние ошибок, выбранные опции, кнопки с hover-стилями и тёмный фон. Если обводка фокуса растворяется в дизайне или исчезает, человек теряет ориентир.
• Откройте каждый диалог, пройдите по нему табом и закройте. Фокус должен вернуться точно на тот элемент, который открыл окно. Если он попадает в начало страницы или пропадает, человеку приходится начинать заново.

Небольшой пример показывает, почему это важно. Кто-то открывает диалог «Изменить email», решает не продолжать и нажимает Escape. Если фокус не возвращается на кнопку «Изменить email», следующий Tab может увести человека в подвал страницы или в интерфейс браузера. Это очень быстро ощущается как поломка.

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

Что делать дальше

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

Хорошо работает простая группировка:

• проблемы с полями
• работа с ошибками
• диалоги
• меню
• поведение фокуса

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

Исправляйте общие компоненты до визуальной полировки страниц. Именно этот шаг команды часто пропускают, когда новый UI уже выглядит готовым. Обычно лучше потратить день на ремонт компонентов input, select, button и modal, чем неделю вручную латать каждый экран.

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

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

Если команде нужна внешняя помощь, привлеките того, кто может посмотреть и на UI-систему, и на то, как работа переходит от дизайна к коду. Oleg Sotnikov делает это как fractional CTO и advisor. Он может посмотреть на общие компоненты, процесс ревью и поток поставки, а потом показать, где одни и те же ошибки продолжают возвращаться.

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