Ниже сжатая, но практичная спецификация доступной и отзывчивой формы авторизации.
Структура и семантика
- Использовать нативные элементы: ``, ``, ``, ``, ``.
- Явные метки и описания: каждая `` — с ``; дополнительные пояснения через `aria-describedby` для вспомогательного текста.
- Видимые ошибки связать с полем через `aria-describedby` и пометить `aria-invalid="true"`. При появлении ошибки поместить текст в элемент с `role="alert"` или `aria-live="assertive"`.
- Минимальная валидация на клиенте + надёжная валидация на сервере; сообщать ошибки нейтрально, не раскрывая принадлежности аккаунта.
Клавиатурная навигация
- Логический порядок DOM = визуальный порядок; не менять порядок табуляции (`tabindex` обычно не нужен).
- Первичный элемент — поле логина; не ставить автоматический фокус, если это мешает экранным ридерам; при явном `autofocus` предусмотреть возможность отключения.
- Управление переключателями: кнопка «показать пароль» реализуется как `` (не ``), с `aria-pressed` и доступным текстовым именем.
- При ошибке перемещать фокус на первое невалидное поле (или на сводную область ошибок) и озвучивать её через `aria-live`.
- Клавишей Enter отправлять форму; Esc — отмена (если форма в модальном окне — сбрасывать/закрывать). При модальном окне — реализовать «trap focus» внутри модального слоя и вернуть фокус при закрытии.
Совместимость со вспомогательными технологиями
- Все интерактивные элементы имеют программируемые имена и роли (через семантику или ARIA).
- Для динамических изменений (успех/ошибка загрузки) использовать `aria-live` (политика `polite` для не критичных уведомлений, `assertive` для ошибок при отправке).
- Кнопки и ссылки — с явными видимыми и программируемыми метками; избегать только иконочных кнопок без `aria-label`.
- Текст подсказок должен быть доступен программно (не только через визуальные «placeholder»): `placeholder` не заменяет ``.
- Тестировать с популярными ридерами (NVDA, VoiceOver, TalkBack) и экранной клавиатурой.
Минимальный дизайн для мобильных устройств
- Одноколоночная верстка, поля на всю ширину контейнера, ответы в одну линию.
- Целевые размеры касаний не меньше $44\times 44$ пикселей; межэлементный вертикальный отступ минимум $8$–$12$ px.
- Шрифт не меньше $16$ px для полей ввода; контраст текста и фона соответствует WCAG AA.
- Минимизировать элементы: поля — логин, пароль, кнопка «Войти», ссылка «Забыл пароль» и опционально переключатель «Запомнить меня». Если нужен «Запомнить», не ставить его отмеченным по умолчанию.
- Использовать системные шрифты, простую иконографию и избегать тяжёлых веб-шрифтов; обеспечить адаптацию под ориентацию экрана и масштабирование браузера.
Защита от UX-ловушек и тёмных паттернов
- Никаких скрытых или предзаполненных маркетинговых чекбоксов; всё по умолчанию выключено.
- Прозрачные подписи для кнопок и ссылок; избегать похожих визуально кнопок с разными действиями.
- Не блокировать пользовательский поток постоянными модальными окнами; ошибки и предупреждения — не препятствовать повторной попытке.
- Ограничения и блокировки (например, после нескольких неудач) сообщать ясно: сколько попыток осталось, временная блокировка и длительность.
- Подтверждения и сообщения о безопасности формулировать понятно, без запугивания.
Производительность при слабых каналах связи
- Критический путь: минимальный HTML + CSS, без критичных JS-зависимостей для отправки формы (форму можно отправлять нативно; JS — для улучшений).
- Ограничить критический payload (HTML/CSS/JS, необходимый для отображения и отправки) до примерно $50$ KB gzip; общий начальный пакет — по возможности < $100$ KB.
- Время отображения: целевой FCP (First Contentful Paint) на $2$G — < $3$ s; TTI (Time to Interactive) — по возможности < $5$ s.
- Использовать серверный рендеринг или статический HTML, lazy-loading нефункциональных скриптов, defer/async и критический CSS inline.
- Использовать кеширование и ETags, CDN, сжатие (gzip/ Brotli), минимизацию изображений; избегать загрузки шрифтов до отрисовки (system fonts).
- Сеть-устойчивость: переключение на «offline»/медленную сеть — показывать понятное состояние; при неудаче отправки предлагать повторную попытку с экспоненциальным бэкоффом.
- Минимизировать количество запросов при отправке: компактный JSON/форм-encoded ответ, небольшие тела ответов и заголовков; использовать HTTP/2 или HTTP/3 для мультиплексирования.
Дополнительные рекомендации
- Автоподстановка и менеджеры паролей: поддерживать `autocomplete` и корректные атрибуты, чтобы менеджеры паролей могли работать.
- Логирование ошибок и тайминг-метрики для аналитики UX на слабых соединениях; но не логировать пароли.
- Тестировать доступность и производительность на реальных устройствах и эмулировать медленные сети (Throttling).
Если нужно, могу привести компактный пример разметки с ARIA-атрибутами и минимальным CSS/JS.