Экран — это не только картинка, которую рисует дизайнер, и не только текст, который пишет аналитик. Это артефакт на стыке проектирования, требований и разработки, и у него есть два взаимосвязанных измерения. Первое — форма передачи: что именно считается результатом проектирования интерфейса и в каком виде он уходит в разработку. Второе — доступность: набор критериев, которым экран должен соответствовать, чтобы им могли пользоваться разные люди, включая тех, кто работает с клавиатуры, с нарушениями зрения, моторики или когнитивных функций. Ниже разберём оба измерения и то, как они превращаются в проверяемые требования.
1. Суть темы
Постановка экрана — это описание того, как устроен интерфейс: структура расположения информации, управляющие элементы, их состояния и поведение, особенности отображения на разных платформах. Ключевой вопрос для аналитика — не «чем рисовать», а «что считать результатом и как передать его в разработку».
Доступность (accessibility) — это требования к интерфейсу, обеспечивающие его пригодность для людей с разными возможностями. Они формулируются как проверяемые критерии (например, в WCAG) и всё чаще касаются типовых паттернов: фокуса, размера кликабельных областей, перетаскивания, форм и сценариев входа.
Оба измерения сходятся в одной точке: статус артефакта. Если макет считается частью требований, к нему предъявляются те же претензии, что и к любому требованию — полнота, однозначность, проверяемость. Если макет лишь иллюстрация, то без текста, таблицы полей или кликабельного прототипа требования остаются неполными. Аналогично критерии доступности работают только тогда, когда они заложены в постановку экрана, а не проверяются «потом».
2. Кто отвечает за интерфейс
Распространённое заблуждение — что структуру экрана, цвета и расположение элементов описывает аналитик. На практике это зона UX/UI-дизайнера, тем более что для мобильных платформ существуют готовые гайдлайны. Вопрос аналитика — не «кто рисует», а как результат проектирования попадает в разработку и где проходит граница ответственности.
| Роль | Зона ответственности |
|---|---|
| UX/UI-дизайнер | Визуальное и взаимодействие-проектирование, вайрфреймы, мокапы, прототипы |
| Аналитик | Постановка задачи, требования к поведению, полнота и проверяемость, связь с бизнес-логикой |
| Разработчик | Реализация, «натягивание» прототипа на проект |
3. Форма передачи: прототип вместо текстовой спецификации
Практика показывает, что детали интерфейса — скругления, отступы, расположение элементов — не стоит описывать текстовой спецификацией: это трудоёмко и плохо проверяемо. Вместо этого делается UI-прототип (например, в Figma или на собственном полигоне, где можно что-то сверстать), а результат передаётся разработчику, чтобы тот «натянул» его на проект.
При этом выбор инструмента диктуется не только удобством, но и привычками команды — макеты исторически прилетали даже в Excel. Это напоминает, что инструмент вторичен по отношению к вопросу о статусе артефакта.
4. Макеты как требования, а не рекомендации
Ключевой тезис: при наличии хороших вайрфреймов и мокапов текстовое описание интерфейса часто оказывается бесполезной работой — кроме случаев, когда такое описание явно требуется для взаимодействия с заказчиком. В таком мировоззрении вайрфреймы и мокапы являются частью требований, а не рекомендациями — как минимум в небольших продуктовых командах.
Однако есть оговорки:
- На уровне передачи в разработку мокапы в некоторых случаях сойдут как самостоятельные требования.
- Многие особенности поведения всё равно придётся прописывать текстом либо делать кликабельный прототип.
- Сам факт важности мокапов не оспаривается — это очень важная часть требований.
5. Контраргумент: требования важнее картинки
Противоположная позиция: самая важная часть требований — это сами требования, а макеты лишь вариант их реализации. Показательный случай: заказчик принял один макет, разработчики сделали другое (по их словам, у них библиотека была удобнее), и заказчик принял результат разработчиков. Макеты были нужны лишь для проверки, все ли поля на месте, — а это можно было сделать обычной таблицей.
Отсюда практический вывод: картинка и таблица покрывают лишь часть реальных требований, но не заменяют их. Если вайрфрейм считается требованием, к нему применяются те же критерии качества, что и к любому требованию, и тогда «упороться» текстовой спецификацией действительно не нужно.
6. Уровень детализации зависит от проекта
Степень детализации макетов сильно варьируется — как по объективным, так и по субъективным причинам.
| Контекст | Уровень детализации |
|---|---|
| Аудитория в миллионы, стейкхолдеры-перфекционисты | Pixel perfect, строго как нарисовали дизайнеры |
| Внутренний продукт для опытных пользователей | Мокапов может не быть вовсе; в интерфейсе «оголённые провода и рычаги» |
Дополнительный ориентир — нормативный: часть требований к интерфейсам в том или ином виде приведена в стандартах серии ГОСТ Р ИСО 9241.
7. Доступность: WCAG 2.2
Доступность — это не «пожелание», а набор проверяемых критериев. В версии WCAG 2.2 появились новые критерии уровней A и AA, которые напрямую касаются привычных элементов интерфейса: модальных окон, кнопок, форм и сценариев входа.
7.1. Новые критерии уровня AA
| Критерий | Суть | Кому помогает в первую очередь |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | Сфокусированный с клавиатуры элемент не должен быть скрыт другим контентом (частый случай — баннеры cookies поверх модальных окон) | Люди с нарушениями моторики, СДВГ, когнитивными нарушениями |
| 2.5.7 Dragging Movements | Если действие требует перетаскивания, нужна альтернатива — тап или клик | Люди без рук, с тремором, незрячие пользователи |
| 2.5.8 Target Size (Minimum) | Кликабельная область — не менее 24 × 24 CSS-пикселя | Люди с нарушениями зрения или моторики |
| 3.3.8 Accessible Authentication (Minimum) | Ни на одном этапе аутентификации не должно требоваться теста на когнитивные способности (запоминание, вычисления, головоломки) | Люди с дислексией, деменцией, болезнью Альцгеймера, СДВГ, аутизмом |
7.2. Новые критерии уровня A
| Критерий | Суть | Кому помогает в первую очередь |
|---|---|---|
| 3.2.6 Consistent Help | Блоки подсказок и помощи должны консистентно располагаться и работать на любой странице | Люди с когнитивными нарушениями, проблемами с памятью; полезно всем |
| 3.3.7 Redundant Entry | Ранее введённая информация, требуемая повторно в рамках того же процесса, должна заполняться автоматически | Люди с когнитивными нарушениями, проблемами с памятью; экономит время всем |
Для критерия 3.3.7 Redundant Entry допустимые способы автозаполнения включают:
- выбор из выпадающего списка;
- копирование и вставку текста;
- флажок «заполнить входные данные теми же значениями, что были введены ранее».
7.3. Уровень AAA
В обзоре упоминаются ещё три пункта уровня AAA: два касаются фокуса и один — аутентификации. Конкретные номера и названия этих критериев не приводятся, поэтому детали уровня AAA остаются за рамками материала.
8. Практические выводы для аналитика
- Проверьте модальные окна и всплывающие баннеры: не перекрывают ли они сфокусированный элемент.
- Убедитесь, что все действия, требующие перетаскивания, имеют альтернативу в виде клика или тапа.
- Пересмотрите размеры интерактивных элементов: кликабельная область — не менее 24 × 24 CSS-пикселя.
- Приведите блоки помощи и подсказок к единому расположению и поведению на всех страницах.
- Настройте автозаполнение и повторное использование ранее введённых данных в многошаговых формах.
- Уберите из сценариев входа задания на запоминание, вычисления и головоломки.
- Закладывайте проверку доступности уже на этапе проектирования экрана, а не после разработки.
Важная оговорка: почти у каждого нового критерия WCAG есть свои нюансы и исключения, поэтому перед внедрением стоит сверяться с первоисточником — официальным текстом стандарта, а не только с обзорами.
9. Связь с другими темами
Постановка экрана и доступность — часть более широкой работы с интерфейсными требованиями. Полезно смотреть на них вместе с 02.02.04 Прототипирование и UI-UX-исследования и использовать 10.01.09 Шаблон описания экранной формы и логики на FE как рабочий каркас для фиксации структуры, поведения и требований доступности конкретного экрана.
Открытые вопросы
- Как называются три новых критерия уровня AAA и какие именно требования по фокусу и аутентификации они предъявляют?
- Какие исключения и граничные случаи предусмотрены для критериев Target Size (Minimum) и Accessible Authentication (Minimum)?
- Когда и каким образом организациям следует переходить на WCAG 2.2 и является ли соответствие этому стандарту обязательным (юридическим) требованием?