{
  "index": 206,
  "slug": "editorial-2022-04-mechanism-accessible-interface",
  "title": "Контракт доступного control: имя, состояние и фокус должны меняться вместе",
  "excerpt": "Почему role сам по себе не исправляет custom control и как связать name, state, focus route и declared status в одном контракте без заявления о реальном accessibility tree.",
  "contentHtml": "<p>Симптом часто выглядит как спор между фронтендом и дизайном: «кнопка уже есть, только добавим aria-атрибут». После этого в markup появляется role, но клавиатурный путь не появляется, визуальное selected не совпадает с declared state, а после ошибки фокус остаётся неизвестным. Цена такой частичной правки — компонент получает убедительную разметку и непредсказуемое поведение. Ошибку сложнее увидеть, потому что она скрыта за правильным словом <code>button</code>.</p>\n<p>Причина в раздельном владении. Визуальная ветка знает class и иконку, обработчик знает payload, а semantic state приклеен последним эффектом. Для интерактивного элемента этого недостаточно: имя, роль, текущее состояние, допустимое действие и маршрут фокуса образуют один контракт. В статье это контракт одной панели уведомлений. Он не описывает полноценную a11y-платформу, не строит реальное дерево доступности и не приписывает автору проведённый user study; он показывает, что можно проверить до таких работ.</p>\n<h2>Роль — обещание поведения</h2>\n<p>ARIA role сообщает потребительскому слою, какой вид взаимодействия заявлен. Она не добавляет его автоматически. Если non-native элемент объявлен кнопкой, автор кода отвечает за доступность с клавиатуры, фокус и активацию. Если элемент объявлен radiogroup, одного цвета недостаточно: нужен понятный group name и согласованное выбранное состояние. Именно поэтому нативная разметка обычно безопаснее как старт: браузер уже реализует часть стандартного поведения, а компоненту остаётся не сломать связь со своим state.</p>\n<p>Не стоит делать из этого правило «ARIA нельзя использовать». Паттерны нужны, когда нативной семантики не хватает. Но тогда изменение принимается как единый diff: DOM shape, обработчик, state transition, keyboard route, визуальный focus indicator и тест. Если PR содержит только <code>role=\"button\"</code>, reviewer ещё не знает, как элемент получает фокус, что делает Space, когда меняется state и куда вернётся человек после закрытия связанной панели.</p>\n<div class=\"table-scroll\"><table><caption>Четыре части контракта и типичный разрыв</caption><thead><tr><th scope=\"col\">Часть</th><th scope=\"col\">Проектное значение в fixture</th><th scope=\"col\">Разрыв</th><th scope=\"col\">Что проверить отдельно</th></tr></thead><tbody><tr><td>Name + role</td><td>«Настроить уведомления», button</td><td>иконка видна, текстового имени нет</td><td>семантику native host или явное доступное имя</td></tr><tr><td>State</td><td>email/sms, declared checked value</td><td>class active обновился, state нет</td><td>один source of truth для visual и semantic state</td></tr><tr><td>Focus route</td><td>trigger → email → apply → trigger</td><td>закрытие unmount удаляет focused node</td><td>точки входа, ошибки и return target</td></tr><tr><td>Status</td><td>declared text после save/undo</td><td>сообщение только меняет цвет</td><td>что разметка передаёт состояние; фактическое объявление проверяется вне модели</td></tr></tbody></table></div>\n<h2>Граница state: черновик не равен сохранённому значению</h2>\n<p>В панели два похожих значения: <code>channel</code> — текущий выбор внутри открытой панели, <code>savedChannel</code> — последний подтверждённый выбор. Если их склеить, invalid action или закрытие без save может изменить то, что интерфейс считает сохранённым. В учебной модели invalid <code>carrier-pigeon</code> не проходит список допустимых значений, получает named focus <code>notification-email</code> и не трогает <code>savedChannel</code>. Это не browser validation. Это маленький инвариант владения state.</p>\n<p>После правильного выбора <code>sms</code> focus route переносится на apply. Save переносит прежний saved value в <code>pendingUndo</code>, закрывает панель и возвращает маршруту trigger. Такое разделение полезно не потому, что каждый control обязан иметь undo. Оно даёт проверяемый ответ на вопрос «что именно откатится, если действие оказалось неверным?». Если команда не может назвать prior state, она не сможет честно реализовать ни отмену, ни безопасный retry.</p>\n<pre><code>const panel = {\n  open: true,\n  channel: &#039;email&#039;,\n  savedChannel: &#039;email&#039;,\n  pendingUndo: null,\n  focus: &#039;notification-email&#039;,\n  status: &#039;&#039;\n};\n\nfunction chooseChannel(next) {\n  if (!panel.open) return { ok: false, kind: &#039;panel-closed&#039; };\n  if (![&#039;email&#039;, &#039;sms&#039;].includes(next)) {\n    panel.focus = &#039;notification-email&#039;;\n    panel.status = &#039;Выберите канал: Email или SMS.&#039;;\n    return { ok: false, kind: &#039;invalid-channel&#039; };\n  }\n  panel.channel = next;\n  panel.focus = &#039;notification-apply&#039;;\n  return { ok: true, kind: &#039;channel-selected&#039; };\n}\n\nfunction save() {\n  if (!panel.open) return { ok: false, kind: &#039;panel-closed&#039; };\n  if (![&#039;email&#039;, &#039;sms&#039;].includes(panel.channel)) {\n    panel.focus = &#039;notification-email&#039;;\n    return { ok: false, kind: &#039;invalid-state&#039; };\n  }\n  const previous = panel.savedChannel;\n  panel.savedChannel = panel.channel;\n  panel.pendingUndo = previous;\n  panel.open = false;\n  panel.focus = &#039;preferences-trigger&#039;;\n  panel.status = &#039;Канал уведомлений сохранён: &#039; + panel.savedChannel + &#039;.&#039;;\n  return { ok: true, kind: &#039;saved&#039; };\n}\n\nfunction undoLastSave() {\n  if (panel.pendingUndo === null) return { ok: false, kind: &#039;nothing-to-undo&#039; };\n  const restored = panel.pendingUndo;\n  panel.savedChannel = restored;\n  panel.channel = restored;\n  panel.pendingUndo = null;\n  panel.focus = &#039;preferences-trigger&#039;;\n  return { ok: true, kind: &#039;undo-saved-change&#039; };\n}\n\nconst invalid = chooseChannel(&#039;carrier-pigeon&#039;);\nconst savedAfterInvalid = panel.savedChannel;\nconst chosen = chooseChannel(&#039;sms&#039;);\nconst saved = save();\nconst undone = undoLastSave();\nconst secondUndo = undoLastSave();\n\nconsole.assert(invalid.kind === &#039;invalid-channel&#039; &amp;&amp; savedAfterInvalid === &#039;email&#039;);\nconsole.assert(chosen.kind === &#039;channel-selected&#039; &amp;&amp; saved.kind === &#039;saved&#039;);\nconsole.assert(undone.kind === &#039;undo-saved-change&#039; &amp;&amp; panel.savedChannel === &#039;email&#039;);\nconsole.assert(secondUndo.kind === &#039;nothing-to-undo&#039;);\nconsole.log(panel);</code></pre>\n<p>Этот фрагмент можно запустить в Node.js: он оставляет сохранённое значение прежним после недопустимого ввода, коммитит <code>sms</code>, один раз восстанавливает <code>email</code> и отклоняет второй undo. Это модель переходов, а не готовый browser-компонент: она не создаёт DOM, не отправляет клавиши, не строит live region и не наблюдает accessibility tree.</p>\n\n<p>Пример можно прочитать как псевдокод границы, но не как copy-paste для browser. У <code>panel.state.focus</code> строковое значение; вызова <code>HTMLElement.focus()</code> нет. У <code>declaredAnnouncement</code> текст; live region не создан. За счёт этого тест не делает ложного вывода «клавиатура прошла путь». Он проверяет, что выбранный проектом путь не противоречит state transition. Реальный компонент получает второй слой тестов там, где есть выбранная платформа и конкретная разметка.</p>\n<h2>Семантический contract как схема</h2>\n<figure><img src=\"/assets/editorial/2022/accessible-interface-semantic-contract-2022.svg\" alt=\"Схема учебного semantic contract: trigger имеет имя и роль button; группа выбора имеет имя и role radiogroup; visual selection и declared checked state идут от одного состояния channel; результат save создаёт declared status. Внизу показана граница: фактический DOM и речь screen reader не наблюдаются.\" loading=\"lazy\" /><figcaption>Схема не заменяет accessibility tree. Она помогает reviewer увидеть, какие данные должны измениться вместе, прежде чем начинать проверку конкретного браузера.</figcaption></figure>\n<h2>Почему status нельзя сводить к всплывающему тексту</h2>\n<p>Видимый toast часто полезен, но он не гарантирует, что изменение стало понятным любому способу взаимодействия. Обратная ошибка — поставить <code>role=\"status\"</code> и считать задачу закрытой. W3C-критерий Status Messages говорит о программно определяемых сообщениях, но не обещает одну и ту же речь во всех сочетаниях. На результат влияют разметка, порядок изменения, язык, пользовательские настройки и конкретная технология. Поэтому в проектном контракте полезно разделить «какое сообщение сформировано» и «какой результат наблюдён в среде проверки».</p>\n<p>В fixture первое значение хранится как <code>declaredAnnouncement</code>, а второе намеренно отсутствует: <code>assistiveTechnology: not-observed</code>. Такое отсутствие — не дырка. Оно не даёт коду подменить факт. Когда у команды появится реальная проверка, к контракту можно добавить её протокол: браузер, версия, технология, язык, сценарий, результат и известное ограничение. Пока этих входов нет, они не должны появляться в статье как будто уже собраны.</p>\n<h2>Маршрут изменения без большой переделки</h2>\n<ol><li><strong>Симптом.</strong> Custom control визуально реагирует, но keyboard path, selected state или сообщение о результате не определены.</li><li><strong>Причина.</strong> CSS, event handler и accessibility properties владеют разными копиями состояния либо роль добавлена без поведения.</li><li><strong>Проверка модели.</strong> Назовите trigger, group, options, apply и status. Для каждого запишите name, role, state owner и переход focus.</li><li><strong>Проверка разрыва.</strong> Измените один option в локальном тесте: visual state, declared checked value и saved value должны либо меняться согласованно, либо явно оставаться разными до save.</li><li><strong>Действие.</strong> Верните native host, если дизайн не требует custom widget. Иначе оформите keyboard contract и focus route в том же изменении, а не в следующем тикете.</li><li><strong>Проверка реализации.</strong> На реальной странице отдельно проверьте семантику, keyboard sequence и заявленное status-поведение в согласованной матрице окружений; fixture даёт только основу для такого теста.</li></ol>\n<h2>Где граница между contract и тестом</h2>\n<p>Unit fixture хорошо ловит ошибки порядка и rollback: invalid value не должна сохраняться, save должен вернуть declared route, undo не должен сработать второй раз. Она также делает документацию состояния исполнимой: после будущей оптимизации нельзя случайно вынести update <code>savedChannel</code> раньше проверки. Но unit fixture не умеет доказать focus-visible CSS, tab order среди соседних компонентов, поведение портала, конфликт shortcut или реальный output screen reader.</p>\n<p>Поэтому разумно держать два артефакта. Первый — маленькая модель контракта рядом с компонентом. Второй — платформенная проверка, где есть DOM и где запись результата содержит условия. Не обязательно строить огромный framework, чтобы сделать это честно. Для одного критичного диалога достаточно зафиксировать сценарий, поддерживаемые среды и те проверки, которые команда реально может повторить. Главное — не выдавать один слой за другой.</p>\n<h2>Ограничение и следующий шаг</h2>\n<p>Паттерн панели не переносится автоматически на меню, grid, combobox или сложный редактор: у них другая модель фокуса и другие keyboard conventions. Даже в этой панели решение о том, оставлять ли disabled action в tab sequence, зависит от продукта и должно быть принято осознанно. Модель также не отвечает на вопрос, кто сформулировал понятное имя на всех языках. Она специально уже, чем настоящий интерфейс, чтобы не скрыть эти открытые вопросы словом «универсальный».</p>\n<p>Следующий шаг — завести для одного control ownership table: где хранится draft, где committed value, кто формирует status, где находится return target и какой test защищает invalid branch. После этого можно вынести общую helper-функцию только там, где два компонента действительно имеют один и тот же contract. Раннее «обобщение a11y» часто создаёт новую копию состояния; сначала полезнее закрепить одну понятную границу.</p>\n<h2>Историческая граница апреля 2022</h2>\n<p>Нормативная опора здесь — WCAG 2.1 Recommendation 2018 года; практические keyboard patterns — WAI-ARIA Authoring Practices 1.2, Group Note от 29 ноября 2021 года. Неизменяемый WAI-ARIA 1.2 Candidate Recommendation Draft от 8 декабря 2021 года задаёт исторический статус спецификации. Поэтому текст говорит о доступных тогда критериях и guidance, а не переносит назад будущие версии рекомендаций или современные инструменты аудита.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://www.w3.org/TR/2018/REC-WCAG21-20180605/\" target=\"_blank\" rel=\"noopener noreferrer\">WCAG 2.1, W3C Recommendation от 5 июня 2018 года</a> — неизменяемая нормативная версия. В ней есть проверяемые критерии Keyboard, Focus Order, Name, Role, Value и Status Messages; она не описывает поля учебной fixture.</li><li><a href=\"https://www.w3.org/TR/2021/NOTE-wai-aria-practices-1.2-20211129/\" target=\"_blank\" rel=\"noopener noreferrer\">WAI-ARIA Authoring Practices 1.2, W3C Group Note от 29 ноября 2021 года</a> — датированное официальное руководство с паттернами кнопок, клавиатурной навигацией и фокусом. Это guidance, а не запись о ручной проверке конкретного компонента.</li><li><a href=\"https://www.w3.org/TR/2021/CRD-wai-aria-1.2-20211208/\" target=\"_blank\" rel=\"noopener noreferrer\">WAI-ARIA 1.2, W3C Candidate Recommendation Draft от 8 декабря 2021 года</a> — неизменяемая версия периода. Она фиксирует статус Candidate Recommendation Draft; материал не приписывает апрелю 2022 будущую Recommendation 2023 года.</li></ul>"
}