{
  "index": 206,
  "slug": "editorial-2022-04-mechanism-accessible-interface",
  "title": "Доступный control начинается с контракта состояния, имени и фокуса",
  "excerpt": "Как связать семантику, состояние и маршрут клавиатуры в одном интерактивном компоненте и не принять роль ARIA или учебный тест за доказательство доступности.",
  "contentHtml": "<p>Компонент может выглядеть исправным и ломаться уже на первом действии без мыши. Кнопка открывает панель, но после закрытия фокус исчезает. Выбор подсвечивается, но его доступное состояние не меняется. Ошибка в поле видна цветом, но сохранённое значение уже перезаписано. Человек теряет точку продолжения и не понимает, что произошло. Команда получает дефект, который трудно воспроизвести: глазами интерфейс выглядит готовым.</p>\n<p>Цена ошибки растёт на каждом слое. Пользователь повторяет действие или покидает сценарий. Тест проверяет только текст и пропускает потерянный фокус. Следующая правка добавляет ещё один эффект и ещё одну копию состояния. Разметка содержит <code>role=\"button\"</code>, но не содержит поведения, которое это слово обещает.</p>\n<p>Тезис статьи простой: доступный control нужно проектировать как единый контракт. Контракт отвечает на пять вопросов: какое имя услышит пользователь, какую роль и состояние получит технология, кто владеет значением, какие клавиши меняют его и куда переходит фокус после каждого исхода. Если ответ существует только в CSS или в отдельном обработчике, интерфейс уже имеет разрыв.</p>\n<h2>Сначала семантика, затем внешний вид</h2>\n<p>Нативный <code>button</code> обычно безопаснее произвольного <code>div</code>. Браузер уже знает, что элемент участвует в фокусе и активируется клавиатурой. Нативные <code>input</code>, <code>label</code>, <code>fieldset</code> и <code>legend</code> также дают связи, которые иначе придётся собрать вручную. Это не отменяет проверку имени, порядка и состояния. Это уменьшает число обязанностей автора.</p>\n<p>ARIA не превращает произвольный элемент в рабочий виджет. <code>role=\"button\"</code> сообщает семантику, но не добавляет обработку Enter и Space, видимый фокус, управление <code>tabindex</code> или возврат фокуса. <code>role=\"radio\"</code> не выбирает соседний вариант и не синхронизирует <code>aria-checked</code> с моделью. Поэтому custom control принимают целиком: разметка, обработчики, переходы состояния, клавиатурный маршрут и проверка входят в один набор изменений.</p>\n<p>Для группы каналов уведомлений достаточно сначала проверить, нужен ли custom widget. Если обычный <code>fieldset</code> с двумя radio подходит дизайну, он снимает часть риска. Если компонент обязан использовать ARIA-паттерн, его группа получает имя, каждый вариант получает имя и согласованное состояние, а клавиши следуют выбранному паттерну. Нельзя смешать поведение обычной группы и toolbar только потому, что так удобнее обработчику.</p>\n<h2>Механизм: одно состояние, несколько представлений</h2>\n<p>У панели есть два разных значения. <code>channel</code> — черновой выбор внутри открытой панели. <code>savedChannel</code> — последнее подтверждённое значение. Пока пользователь не нажал «Сохранить», черновик может меняться, а сохранённое значение должно оставаться прежним. Это правило защищает отрицательный путь: неверный выбор, закрытие без сохранения и отмена не должны менять результат.</p>\n<p>Отдельно хранится маршрут фокуса. В учебной модели это строка, например <code>preferences-trigger</code> или <code>notification-email</code>. Она не вызывает <code>HTMLElement.focus()</code> и не делает утверждений о браузере. Она фиксирует решение компонента: после открытия входом служит первый control, после ошибки — конкретное поле, после успешного закрытия — исходная кнопка. Реальный DOM и реальный accessibility tree требуют отдельной проверки.</p>\n<pre><code>const panel = {\n  open: false,\n  channel: 'email',\n  savedChannel: 'email',\n  focus: 'preferences-trigger',\n  status: ''\n};\n\nfunction choose(next) {\n  if (!['email', 'sms'].includes(next)) {\n    panel.focus = 'notification-email';\n    panel.status = 'Выберите доступный канал';\n    return false;\n  }\n\n  panel.channel = next;\n  panel.focus = 'notification-apply';\n  return true;\n}\n\nfunction save() {\n  panel.savedChannel = panel.channel;\n  panel.open = false;\n  panel.focus = 'preferences-trigger';\n  panel.status = `Канал сохранён: ${panel.savedChannel}`;\n}</code></pre>\n<p>Код показывает границу, а не готовый компонент. В нём нет DOM, таймеров, live region, браузера и screen reader. Он проверяет только порядок: недопустимое значение не коммитится, допустимое значение переводит маршрут к сохранению, а успешное сохранение возвращает пользователя к trigger. Если заменить <code>panel.savedChannel = panel.channel</code> на обновление до валидации, учебная проверка должна зафиксировать нарушение.</p>\n<p>В production обновление состояния и разметки должно иметь один источник истины. Визуальный selected, <code>aria-checked</code>, текст статуса и доступность кнопки сохранения не должны вычисляться из разных копий. Если UI показывает SMS, а семантическое состояние всё ещё говорит Email, проблема не в недостающем атрибуте. Проблема в том, что переход состояния разделили между владельцами.</p>\n<h2>Симптом → причина → проверка → действие</h2>\n<div class=\"table-scroll\"><table><caption>Диагностика разрыва контракта интерактивного компонента</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Причина</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td>Tab пропускает вход или фокус исчезает после закрытия</td><td>Custom host не имеет полного keyboard contract; return target не сохранён до unmount</td><td>Пройти Tab и Shift+Tab; записать вход, ошибку, закрытие и фактический focused element</td><td>Вернуть native host либо определить keyboard path и явный return target</td></tr><tr><td>Активный вариант виден, но технология получает старое значение</td><td>CSS-класс и semantic state читают разные источники</td><td>Сравнить visual state, accessible tree и значение state после одного выбора</td><td>Выводить оба представления из одного state owner</td></tr><tr><td>Неверный ввод меняет сохранённые настройки</td><td>Черновик и committed value склеены</td><td>Подать значение вне allow-list и проверить savedChannel до и после ветки ошибки</td><td>Валидировать до commit; вернуть фокус к исправляемому control</td></tr><tr><td>Toast виден, но результат не понятен без зрения</td><td>Сообщение существует только как цвет или визуальный popup</td><td>Проверить программно определяемый status в выбранной связке браузера и assistive technology</td><td>Связать сообщение с изменением состояния и зафиксировать среду проверки</td></tr><tr><td>Роль добавили, но Enter и Space ведут себя по-разному</td><td>Семантика скопирована без поведения паттерна</td><td>Сопоставить обработчики и порядок клавиш с выбранным APG-паттерном</td><td>Использовать native control или реализовать весь паттерн, включая фокус</td></tr></tbody></table></div>\n<h2>Иллюстрация маршрута</h2>\n<figure><img src=\"/assets/editorial/2022/accessible-interface-semantic-contract-2022.svg\" alt=\"Схема контракта доступного интерфейса: trigger, группа вариантов, общее состояние выбора, сохранение и возврат фокуса к trigger\" loading=\"lazy\" /><figcaption>Схема показывает, какие данные должны идти вместе: имя и роль control, выбранное состояние, результат сохранения и маршрут фокуса. Иллюстрация учебная. Она не является снимком accessibility tree и не доказывает, что screen reader произнесёт статус.</figcaption></figure>\n<p>Схему удобно читать слева направо. Trigger открывает панель. Группа получает имя «Канал уведомлений». Вариант меняет черновик и semantic state. Ошибка возвращает маршрут к control, который нужно исправить. Успешное сохранение обновляет committed value, закрывает панель и возвращает фокус к trigger. Если в коде нет одной из этих стрелок, её нельзя считать «само собой разумеющейся».</p>\n<h2>Порядок действий</h2>\n<ol><li><strong>Опишите сценарий.</strong> Назовите trigger, группу, варианты, действие сохранения, статус и точку возврата. Запишите нормальный и отрицательный путь.</li><li><strong>Выберите host.</strong> Проверьте, закрывает ли нативный элемент задачу. Не заменяйте его на <code>div</code> ради удобного CSS без оценки новой ответственности.</li><li><strong>Разведите состояния.</strong> Отделите draft от committed value. Опишите момент commit и условия, при которых он не происходит.</li><li><strong>Соберите semantic contract.</strong> Для каждого control зафиксируйте accessible name, role, state и связь с группой. Для статуса укажите, какое сообщение формируется.</li><li><strong>Опишите keyboard route.</strong> Укажите результат Tab, Shift+Tab, Enter, Space и стрелок только для тех ролей, которым они нужны. Укажите фокус после открытия, ошибки, отмены и сохранения.</li><li><strong>Защитите отрицательный путь.</strong> Подайте недопустимое значение, закройте панель без save и повторите действие undo, если оно предусмотрено. Сохранённое значение не должно измениться случайно.</li><li><strong>Проверьте реализацию.</strong> Сначала осмотрите DOM и доступное дерево выбранного браузера. Затем пройдите клавиатурный сценарий. После этого проверьте статус в согласованной связке браузера и assistive technology.</li><li><strong>Запишите границы.</strong> Укажите браузер, версию технологии, язык, сценарий и ограничения результата. Учебная модель может подсказать инвариант, но не заменяет эту запись.</li></ol>\n<h2>Ограничения и отрицательный путь</h2>\n<p>Контракт одной панели не описывает весь продукт. Он не проверяет контраст, размер цели касания, локализацию, виртуальный курсор, модальные окна, сложную таблицу или конфликт глобальных горячих клавиш. Паттерн radio group нельзя автоматически перенести на combobox, menu или grid: у них другие роли, клавиши и правила фокуса.</p>\n<p>Даже правильный <code>aria-label</code> не исправляет неясное действие. Даже пройденный автоматический аудит не доказывает удобство сценария. APG даёт практический паттерн, но не является единственным доказательством для конкретной реализации. Нельзя заявлять production-результат по учебному коду или по наличию атрибута.</p>\n<p>Отрицательный путь важнее красивого happy path. Если save падает, сервер отвечает с ошибкой или компонент размонтируется, команда должна знать, останется ли draft, что увидит пользователь и куда уйдёт фокус. Если ответа нет, это не «крайний случай». Это незаписанная часть контракта. Её лучше определить до интеграции с сетью и до широкого рефакторинга.</p>\n<h2>Критерий готовности</h2>\n<p>Компонент можно считать готовым к следующей проверке, когда для каждого интерактивного control записаны имя и роль, state имеет одного владельца, draft не меняет committed value до commit, а keyboard route покрывает вход, ошибку, отмену и успешное завершение. На реальной странице тест должен подтвердить ожидаемый порядок фокуса и согласованность visual state с доступным состоянием.</p>\n<p>Проверяемый результат выглядит так: недопустимое действие оставляет сохранённое значение прежним; допустимое действие меняет его ровно один раз; после закрытия фокус оказывается на объявленной точке; status существует в программно определяемой форме; повторный undo не откатывает новое состояние. Для каждого пункта есть шаг, наблюдаемый результат и среда. Если есть только фраза «компонент доступен», проверка ещё не закончена.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://www.w3.org/TR/WCAG22/\" target=\"_blank\" rel=\"noopener noreferrer\">W3C: Web Content Accessibility Guidelines (WCAG) 2.2</a> — нормативные критерии для keyboard, focus, name/role/value и status messages.</li><li><a href=\"https://www.w3.org/WAI/ARIA/apg/patterns/radio/\" target=\"_blank\" rel=\"noopener noreferrer\">W3C WAI: Radio Group Pattern в ARIA Authoring Practices Guide</a> — роли, имена, состояния и клавиатурное поведение группы radio.</li><li><a href=\"https://www.w3.org/WAI/ARIA/apg/patterns/button/\" target=\"_blank\" rel=\"noopener noreferrer\">W3C WAI: Button Pattern в ARIA Authoring Practices Guide</a> — семантика и поведение обычной и toggle-кнопки.</li></ul>"
}