Когнитивная доступность: понятный язык, память, время и вход в систему

Четыре принципа WCAG — Perceivable, Operable, Understandable, Robust — в реальных проектах закрываются крайне неравномерно. Восприятие мы разбирали долго: семантика, визуальные параметры, текстовые альтернативы, медиа. Управляемость — тоже: клавиатура, компоненты. Третий принцип, понятность, обычно остаётся на уровне «ну, тексты вроде нормальные».

Между тем именно здесь живёт самая многочисленная группа пользователей. Нарушения внимания, памяти, чтения и понимания языка встречаются чаще, чем слепота и глухота вместе взятые, и — что важнее для инженерной интуиции — они не бинарны. Человек с СДВГ на второй час работы отличается от себя же утром. Носитель другого языка читает ваш интерфейс через дополнительный слой перевода. Пользователь, у которого списали деньги и он в панике ищет поддержку, находится в состоянии, физиологически близком к нарушению исполнительных функций. Отсюда рабочая формулировка, к которой стоит привыкнуть:

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

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

Почему сам стандарт здесь слабее

WCAG построен на проверяемых критериях: два независимых аудитора должны прийти к одному вердикту. Контраст 4,5:1 проверяется формулой, наличие alt — парсером. «Понятность» так не проверяется, поэтому в нормативную часть попало лишь то, что удалось формализовать, а основной массив знаний вынесен в отдельный документ — Making Content Usable for People with Cognitive and Learning Disabilities (COGA). Он не нормативен: это не критерии, а паттерны проектирования. Их не потребует аудитор, но именно они определяют, справится человек с вашим интерфейсом или нет.

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

Карта критериев: принцип «Понятность» и соседи

Три критерия из WCAG 2.2 — 3.2.6, 3.3.7 и 3.3.8 — появились именно потому, что комитет признал провал в когнитивной области. Все три бьют по устоявшимся практикам, и с 2023 года «мы всегда так делали» перестало быть аргументом.

Пять ресурсов, которые тратит ваш интерфейс

Полезная инженерная модель: у пользователя есть пять ограниченных ресурсов, и каждый элемент интерфейса что-то из них списывает.

Модель удобна на ревью: вместо спора «понятно / непонятно» задают вопрос «какой ресурс мы здесь тратим и зачем». Обратный отсчёт на странице оплаты тратит скорость обработки и внимание — ради чего? Обычно ради конверсии, а платит за это тот, кто читает медленно.

Понятный язык

Первое правило пишущего интерфейс: читатель не читает, он ищет. Он пришёл с задачей, сканирует экран и хочет найти следующий шаг. Всё, что не помогает найти шаг, — шум.

Приёмы, которые дают наибольший эффект:

• Главное — первым. «Заявка отправлена. Ответим в течение двух рабочих дней», а не «В связи с высокой загрузкой сроки рассмотрения могут увеличиваться; ваша заявка отправлена».
• Активный залог и подлежащее. «Мы вернём деньги за 5 дней» вместо «Возврат денежных средств осуществляется в срок до 5 дней».
• Короткое предложение — одна мысль. Ориентир: 15–20 слов. Длиннее — режем на два.
• Знакомые слова. «Отправить» вместо «Инициировать отправку», «счёт» вместо «расчётно-кассовый инструмент».
• Аббревиатуры при первом употреблении расшифровываются. «Единый налоговый счёт (ЕНС)».
• Никаких двойных отрицаний. «Не отключайте, если не хотите потерять доступ» — фраза, требующая логической операции. «Оставьте включённым, чтобы сохранить доступ» — не требует.
• Кнопка называется действием, а не согласием. «Удалить проект», а не «ОК».

Метрики читаемости. Формулы вроде Флеша — Кинкейда считают среднюю длину предложения и среднее число слогов в слове (для русского используют адаптированные коэффициенты, поскольку слова длиннее английских). Их польза реальна, но ограничена: формула меряет форму, а не понятность. Текст «Мы не можем не отметить, что отказ не исключён» короток и прост по формуле — и непроходим по смыслу. Пользуйтесь метрикой как сигнализацией на регресс (внезапный скачок сложности в релизе — повод посмотреть), а не как целью.

И одно важное различие. Plain language («ясный язык») — это обычный текст, написанный просто, для всех. Easy Read — отдельный формат для людей с серьёзными нарушениями понимания: короткие фразы по одной на строку, иллюстрация к каждому пункту, крупный шрифт. Второе не заменяет первое: Easy Read-версия — это дополнительный документ, а не редакция основного интерфейса. Глубже про текст — в статьях про микрокопирайтинг и про ясность в технических текстах.

Предсказуемость и консистентная помощь

Человеку с ограниченным ресурсом внимания дороже всего обходятся сюрпризы. Отсюда группа критериев 3.2.

Ничего не происходит само. Критерии 3.2.1 и 3.2.2 запрещают смену контекста при получении фокуса и при изменении значения поля. Классика нарушения — <select>, который при выборе сразу переходит на другую страницу: человек, идущий стрелками по вариантам, улетает на первом же. Правильно: выбрал — нажал «Применить».

Одно и то же называется одинаково. Критерий 3.2.4 — про то, что кнопка выхода не может быть «Выйти» на одной странице, «Завершить сеанс» на второй и иконкой без подписи на третьей. Это не педантизм: человек, который опознаёт элементы по подписи, вынужден каждый раз решать задачу заново.

Помощь лежит на одном месте. Критерий 3.2.6 Consistent Help — новый и уровня A, то есть базовый. Если у набора страниц есть механизмы помощи (контакты, чат, форма обращения, ссылка на справку), они должны находиться в одном и том же относительном порядке на всех страницах. Причина простая: человек, который однажды нашёл кнопку помощи в правом нижнем углу, ищет её там же и в следующий раз. Плавающий чат-виджет, который на странице оплаты внезапно уезжает наверх, ломает единственную найденную стратегию.

Видно, где ты и что дальше. Заголовок страницы (2.4.2), хлебные крошки, «Шаг 2 из 4: доставка» текстом, а не только цветной полоской. Для многошаговых процессов — сохранение введённого при переходе назад; это же требование 3.3.7.

Память: не заставляйте помнить

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

• Повторный ввод — нарушение 3.3.7 (A). Уже спросили адрес — не спрашивайте снова: подставьте или дайте чекбокс «совпадает с адресом доставки». Исключения в критерии узкие (например, когда повторный ввод существенен для безопасности).
• Код из SMS не должен требовать запоминания. Одно поле с autocomplete="one-time-code", разрешённая вставка, никакого разбиения на шесть отдельных ячеек. Если код приходит письмом, а форма открыта в модалке поверх почты — человек физически не может прочитать письмо, не потеряв форму.
• Пароль можно показать. Кнопка «показать пароль» — не дыра в безопасности, а способ не заставлять вводить вслепую.
• Инструкция живёт рядом с полем, а не в тексте, который был двумя экранами выше. Требования к паролю показываются до ввода и остаются видны во время.
• Сводка перед отправкой. Длинную форму завершают экраном «проверьте данные» с возможностью вернуться в конкретный пункт, а не в начало.

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

Вход в систему: критерии 3.3.8 и 3.3.9

Аутентификация — место, где когнитивные требования сталкиваются с требованиями безопасности, и до 2023 года побеждала безопасность в самой ленивой трактовке. Критерий 3.3.8 Accessible Authentication (Minimum) уровня AA формулируется так: ни один шаг входа не должен требовать когнитивного теста, если только не предоставлена альтернатива или механизм помощи.

Что считается когнитивным тестом: запомнить и воспроизвести пароль; переписать код из другого приложения по памяти; решить головоломку или ребус; распознать искажённые символы; вспомнить «третью и седьмую букву кодового слова». Два исключения оставлены явно: распознавание объектов («выберите фотографии с автобусом») и личный контент, загруженный самим пользователем. На уровне AAA (3.3.9) исчезают и они.

Отсюда конкретные запреты, которые до сих пор встречаются в продакшене:

• блокировка вставки в поле пароля или кода — прямое нарушение: вставка и есть тот самый «механизм помощи»;
• autocomplete="off" на форме входа — ломает менеджеры паролей, вынуждает вводить руками или упрощать пароли;
• разбиение OTP на шесть отдельных полей — ломает автоподстановку и требует удерживать код в памяти;
• «введите символы с картинки» как единственный путь — и когнитивный тест, и нарушение 1.1.1 одновременно.

Целевая зона очевидна: passkeys и менеджеры паролей одновременно снижают когнитивную нагрузку и повышают безопасность. Это редкий случай, когда доступность и защита не конфликтуют, а совпадают: человек, которому не нужно ничего помнить, не пишет пароль на стикере и не переиспользует его на десяти сайтах. Устройство самих механизмов — в статье про аутентификацию.

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

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

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

Жизнь без CAPTCHA

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

Современный подход — не улучшать головоломку, а убирать её из пути человека:

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

Время и таймауты

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

Критерий 2.2.1 Timing Adjustable (A) требует одного из трёх: ограничение можно выключить, настроить (минимум в десять раз больше исходного) или продлить простым действием после предупреждения. Критерий 2.2.6 Timeouts (AAA) добавляет: если бездействие грозит потерей данных, об этом нужно предупредить заранее — либо хранить данные не менее 20 часов.

Рабочий паттерн для сессий, который совмещается с требованиями безопасности:

// Предупреждаем ЗАРАНЕЕ, продлеваем одним действием, данные не теряем в любом случае.
const SESSION_MS = 30 * 60 * 1000;    // жёсткий лимит из требований безопасности
const WARN_BEFORE_MS = 3 * 60 * 1000; // окно на реакцию: не 20 секунд, а минуты

let warnTimer, endTimer;

const saveDraft = () => {
  // Черновик сохраняем НЕЗАВИСИМО от предупреждения: человек мог отойти
  localStorage.setItem('draft:application', JSON.stringify(collectFormState()));
};

const scheduleSession = () => {
  clearTimeout(warnTimer);
  clearTimeout(endTimer);
  warnTimer = setTimeout(() => {
    saveDraft();
    // Диалог с фокусом внутри и текстом, объясняющим последствие и остаток времени;
    // объявление дублируется в role="alert" для скринридера
    showExtendDialog({
      title: 'Сеанс скоро завершится',
      body: 'Через 3 минуты мы выйдем из аккаунта для безопасности. Данные формы сохранены.',
      confirmLabel: 'Продолжить работу',   // одно действие — и всё, никаких «подтвердите»
      onConfirm: () => { renewSession().then(scheduleSession); },
    });
  }, SESSION_MS - WARN_BEFORE_MS);
  endTimer = setTimeout(() => { saveDraft(); redirectToLogin({ restore: true }); }, SESSION_MS);
};

// Любая активность продлевает окно; ввод в форму — тоже активность
['pointerdown', 'keydown', 'input'].forEach((e) =>
  document.addEventListener(e, throttle(scheduleSession, 30_000)));

Три детали, которые чаще всего забывают: предупреждение должно переводить фокус в диалог и объявляться скринридеру (иначе человек его просто не заметит); кнопка продления должна быть одним действием, а не цепочкой «Продлить → Подтвердить → Ввести пароль»; после принудительного выхода данные должны восстановиться — это и есть настоящая защита от потери, в отличие от предупреждения.

Ошибки: предотвращение важнее сообщения

Критерий 3.3.4 Error Prevention (AA) касается юридических обязательств, финансовых транзакций и изменения данных: такое действие должно быть обратимым, проверяемым (сводка перед подтверждением) или подтверждаемым. В порядке предпочтения — именно так: отмена лучше подтверждения, потому что подтверждение люди нажимают не читая.

Формула хорошего сообщения об ошибке — три части: что случилось, где и что сделать. «Не удалось оплатить: банк отклонил операцию. Попробуйте другую карту или свяжитесь с банком — код отказа 05». Чего в сообщении быть не должно: обвинения («вы ввели неверно»), технических кодов без человеческого пояснения, и — отдельным пунктом — исчезновения. Тост с ошибкой, живущий три секунды, для человека, который читает медленно, не существует вовсе.

Как это тестировать

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

• Когнитивное прохождение (cognitive walkthrough). Идёте по сценарию и на каждом шаге отвечаете на четыре вопроса: человек понимает цель шага? он видит нужный элемент? он поймёт, что это тот самый элемент? он поймёт по отклику, что шаг удался? Метод дешёвый, делается командой за час и вылавливает большинство дефектов.
• Тест на понимание. Показать экран и попросить пересказать своими словами, что здесь происходит и что будет по нажатию кнопки. Расхождение с замыслом — дефект текста, а не пользователя.
• Тест первого клика и пятисекундный тест. Куда человек нажмёт первым делом? Что запомнил с экрана за пять секунд? Оба меряют именно когнитивную нагрузку.
• Прохождение в шуме. Дайте задачу под отвлекающий фактор (музыка, разговор, таймер): интерфейс, который проходится только в тишине, слишком дорог по вниманию.
• Исследования с участием людей с когнитивными особенностями. Требуют аккуратной подготовки: простые задачи по одной, перерывы, отсутствие оценочных формулировок, право не отвечать, оплата участия. Это исследование, а не бесплатное QA — то же правило, что в статье про тестирование и процесс.

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

Проверка за пять минут

1. Прочитайте вслух главный экран и сообщения об ошибках. Есть слова, которые вы не сказали бы человеку голосом? Это правки.
2. Найдите помощь на трёх разных страницах. Она в одном месте? (3.2.6)
3. Пройдите ключевую форму, ничего не запоминая: всё нужное видно на экране шага? Вставка работает? Требования к паролю показаны до ввода?
4. Войдите без менеджера паролей, потом с ним. Вставка в поля кода и пароля разрешена? (3.3.8)
5. Оставьте вкладку на полчаса. Что случилось с сессией и с введёнными данными? Было ли предупреждение и одно ли действие нужно для продления? (2.2.1)
6. Посчитайте перебивания: сколько раз за сценарий интерфейс сам захватил внимание — баннер, модалка, чат, автообновление. Каждое стоит ресурса.

Типичные ошибки — сводка

Мини-итог

• Когнитивная доступность — запас прочности интерфейса по отношению к человеку с малым ресурсом внимания, памяти и времени. В этом состоянии периодически находятся все, поэтому выигрыш здесь массовый.
• WCAG покрывает эту область слабее всего по устройству: критерии обязаны быть проверяемыми. Соответствие AA не равно понятности; основной массив паттернов лежит в ненормативном документе COGA.
• Модель пяти ресурсов (внимание, рабочая память, скорость обработки, язык, исполнительные функции) переводит спор «понятно или нет» в инженерный вопрос «что мы здесь тратим и ради чего».
• Понятный язык — это главное первым, активный залог, короткие предложения, знакомые слова и кнопки, названные действием. Метрики читаемости годятся как сигнализация на регресс, но не как цель.
• Предсказуемость: ничего не меняется само (3.2.1, 3.2.2), одинаковое называется одинаково (3.2.4), помощь всегда на одном месте (3.2.6, уровень A).
• Память экономят три вещи: не спрашивать дважды (3.3.7), показывать на экране всё нужное для шага, разрешать вставку и автозаполнение.
• Вход не должен требовать когнитивного теста (3.3.8, AA). Passkeys и менеджеры паролей одновременно снижают нагрузку и усиливают защиту — редкий случай, когда доступность и безопасность совпадают. CAPTCHA не улучшают, а убирают из пути человека.
• Таймаут без предупреждения и без сохранения черновика — барьер для всех, кто работает медленнее вас. Обратимость лучше подтверждения: «Отменить» работает там, где «Вы уверены?» нажимают не читая.
• Автоматика здесь не находит ничего. Работают когнитивное прохождение, тест на понимание, пятисекундный тест и исследования с участием людей с когнитивными особенностями.

Источники

• WCAG 2.2: Understandable — критерии 3.1–3.3; отдельно 3.2.6 Consistent Help, 3.3.7 Redundant Entry, 3.3.8 Accessible Authentication (Minimum), 2.2.1 Timing Adjustable.
• Making Content Usable for People with Cognitive and Learning Disabilities — основной свод паттернов COGA; W3C Cognitive Accessibility.
• Inaccessibility of CAPTCHA — разбор альтернатив от W3C; Web Authentication (WebAuthn) и passkeys.dev.
• Nielsen Norman Group: Plain Language, plainlanguage.gov — практические руководства по ясному письму; Cognitive Walkthrough.
• Смежное на портале: формы, визуальная доступность, микрокопирайтинг, ясность текста, аутентификация.

Что дальше

На этом трек закончен. Путь был такой: кто и как пользуется интерфейсами и зачем это нужно → семантика как фундамент и ARIA как точечная надстройка → клавиатура и фокус, скринридеры, визуальная доступность → формы и компоненты → тестирование и процесс → содержание: текстовые альтернативы, мультимедиа и понятность. Сводный свод правил под рукой — Гайд по accessibility. Куда идти дальше:

• Пишете интерфейсы. Фронтенд-трек — семантика HTML, формы и валидация, фронтенд-архитектура.
• Отвечаете за качество. Трек тестирования — проектирование тестов, стратегия автоматизации, тесты в CI.
• Проектируете. Доступность на этапе дизайна, микрокопирайтинг, юзабилити-тестирование.
• Строите процесс. Качество и поставка, UX и требования, приоритизация, основы CI.

Общая карта портала и порядок изучения треков — в роадмапе.