diff --git a/src/pages/ui-ux/index.md b/src/pages/ui-ux/index.md
index 64b816b6..dbfc0a91 100644
--- a/src/pages/ui-ux/index.md
+++ b/src/pages/ui-ux/index.md
@@ -2742,8 +2742,20 @@ Accessibility делает интерфейс usable для людей с раз
 
 **Полный ответ**
 
-Accessibility делает интерфейс usable для людей с разными возможностями, устройствами и контекстами. Это не отдельная
-надстройка, а часть качества пользовательского опыта.
+Accessibility влияет на возможность **выполнить пользовательскую задачу**, а не только на формальное соответствие
+стандартам. Интерфейс может быть визуально понятным, но непригодным для человека, который пользуется клавиатурой, screen
+reader или увеличенным масштабом страницы.
+
+Например, в форме регистрации недостаточно красиво подсветить ошибку: нужна связанная с полем подпись, текст ошибки и
+понятный способ перейти к исправлению. Иначе часть пользователей не сможет завершить сценарий, хотя его UI выглядит
+законченным.
+
+Доступность не ограничивается постоянной инвалидностью: интерфейс используют и со сломанной мышью, на ярком солнце или
+при временном ограничении подвижности. При этом одного checklist недостаточно — сложные сценарии проверяют вручную с
+реальными способами ввода.
+
+На интервью важно показать связь **accessibility → успешность сценария → UX**, а не описывать доступность как работу
+исключительно с ARIA.
 
 </td></tr></table>
 </details>
@@ -2759,8 +2771,21 @@ Keyboard navigation позволяет пользоваться интерфей
 
 **Полный ответ**
 
-Keyboard navigation позволяет пользоваться интерфейсом с клавиатуры без мыши. Это важно для доступности, power users и
-ситуаций, где мышь неудобна.
+Браузер управляет последовательностью фокуса для нативных интерактивных элементов. Обычно `Tab` и `Shift+Tab` перемещают
+фокус между контролами, `Enter` активирует ссылку или кнопку, `Space` активирует кнопку, а `Escape` закрывает
+поддерживающие это взаимодействие всплывающие элементы.
+
+Для составных виджетов, например tabs, listbox или menu, могут действовать другие правила: `Tab` вводит фокус в
+компонент, стрелки перемещают его внутри. Конкретный keyboard contract зависит от паттерна WAI-ARIA, а не придумывается
+отдельно для каждого проекта.
+
+Практическая проверка: пройти регистрацию от первого поля до подтверждения, не используя мышь; проверить порядок,
+видимость фокуса, открытие и закрытие диалогов, достижимость ошибок. `tabindex="0"` включит кастомный элемент в
+последовательность, но **не добавит** ему нативную активацию или семантику. Положительные значения `tabindex` обычно
+создают непредсказуемый порядок.
+
+На интервью полезно различать **tab sequence**, **keyboard activation** и **keyboard navigation внутри composite
+widget**.
 
 </td></tr></table>
 </details>
@@ -2776,8 +2801,19 @@ Focus state показывает, какой элемент сейчас акт
 
 **Полный ответ**
 
-Focus state показывает, какой элемент сейчас активен для клавиатуры. Без него пользователь не понимает, где находится в
-интерфейсе.
+DOM-фокус определяет элемент, который получает события клавиатуры: это можно проверить через `document.activeElement`.
+Визуальный focus state показывает пользователю положение этого фокуса, но не должен подменять фактическое управление им.
+
+Обычно браузер применяет `:focus` к сфокусированному элементу, а `:focus-visible` позволяет показывать заметный
+индикатор, когда он особенно нужен при клавиатурном взаимодействии. Однако правило не означает, что при каждом клике
+мышью индикатор обязательно скрывается: решение принимает браузер с учетом контекста.
+
+Например, после открытия modal dialog фокус нужно перенести на подходящий элемент внутри. После закрытия — вернуть
+инициатору, если он еще существует; если нет, выбрать логичное следующее место. Просто нарисовать рамку вокруг поля
+недостаточно.
+
+Распространенная ошибка — менять визуальный класс `.focused`, не вызывая реальное перемещение фокуса. На интервью
+свяжите **видимость, DOM-фокус и focus management**.
 
 </td></tr></table>
 </details>
@@ -2793,8 +2829,18 @@ style.
 
 **Полный ответ**
 
-Outline часто является единственным видимым индикатором фокуса. Если его убрать, нужно дать равноценный и заметный focus
-style.
+`outline` — стандартный способ показать keyboard focus без изменения геометрии элемента. Глобальное правило
+`*:focus { outline: none }` часто делает переходы по `Tab` невидимыми, даже если мышью интерфейс работает нормально.
+
+Если дизайн требует собственного индикатора, его можно задать через `:focus-visible`: например, контрастный
+`outline: 2px solid currentColor` с `outline-offset: 2px`. Но конкретные цвет и толщина должны подходить реальному фону,
+включая dark mode и разные состояния кнопки.
+
+Проверяйте индикатор на кнопках, ссылках, input, элементах внутри dialog и при системном режиме `forced-colors`. Один
+лишь `box-shadow` может исчезнуть в high-contrast mode, поэтому системный outline часто надежнее.
+
+На интервью объясните отличие **визуальной кастомизации focus style** от **отключения focus indication**: первое
+возможно, второе лишает пользователя ориентира.
 
 </td></tr></table>
 </details>
@@ -2810,8 +2856,19 @@ Semantic HTML использует элементы по смыслу: button д
 
 **Полный ответ**
 
-Semantic HTML использует элементы по смыслу: button для действия, a для ссылки, label для поля, heading для структуры.
-Это помогает браузеру, assistive technologies и разработчикам.
+Semantic HTML передает браузеру **назначение и структуру**, а не только внешний вид. Нативный `<button>` имеет роль
+кнопки, участвует в tab order и поддерживает клавиатурную активацию; `<a href="...">` предоставляет семантику навигации
+и привычные действия со ссылкой.
+
+Например, clickable `<div>` с обработчиком `click` не становится доступной кнопкой автоматически: потребуется роль,
+фокус, обработка клавиш, disabled behavior и тестирование. Обычный `<button type="button">` решает большинство этих
+задач без дополнительной логики.
+
+Семантика важна и за пределами controls: заголовки `h1–h6` и landmarks помогают screen reader переходить по странице, а
+`<label>` дает полю понятное имя. При этом выбор `h2` вместо `h3` нельзя основывать исключительно на размере шрифта —
+внешний вид задается CSS.
+
+На интервью приводите **конкретный нативный элемент и его встроенное поведение**, а не только перечисление тегов.
 
 </td></tr></table>
 </details>
@@ -2827,8 +2884,19 @@ Label связывает текстовое описание с полем вв
 
 **Полный ответ**
 
-Label связывает текстовое описание с полем ввода. Благодаря этому поле можно понять, сфокусировать кликом по подписи и
-корректно озвучить screen reader.
+Нативный `<label for="email">` связан с `<input id="email">` через совпадающий идентификатор. Браузер использует подпись
+как часть accessible name поля, а нажатие на подпись переводит фокус на соответствующий control. Поле также можно
+поместить внутрь `<label>` без `for`, если разметка позволяет.
+
+Placeholder не заменяет label: он исчезает при вводе, нередко имеет низкий контраст и не объясняет поле после
+заполнения. Для дополнительной инструкции или текста ошибки подойдет `aria-describedby`, который связывает поле с
+элементом пояснения.
+
+В динамических формах важно обеспечивать уникальность `id`: если два input используют один `id`, связь подписи может
+сломаться. Для группы radio нужны `<fieldset>` и `<legend>` либо эквивалентная доступная группировка.
+
+На интервью различайте **accessible name**, **описание** и **текст ошибки**: у них разные назначения, и одно не заменяет
+другое.
 
 </td></tr></table>
 </details>
@@ -2844,8 +2912,17 @@ Alt text описывает смысл изображения для польз
 
 **Полный ответ**
 
-Alt text описывает смысл изображения для пользователей, которые его не видят. Он должен передавать функцию или
-информацию изображения, а не просто перечислять детали.
+Атрибут `alt` определяет текстовую альтернативу содержимому `<img>`. Хорошая альтернатива передает **смысл изображения в
+текущем контексте**, а не механически описывает каждый цвет и объект.
+
+Например, если изображение — единственное содержимое ссылки на профиль, `alt="Профиль Анны"` дает ссылке понятное имя.
+Если рядом уже есть видимый текст «Профиль Анны», повторяющий его `alt` может создать избыточное озвучивание.
+
+Для информационной схемы короткого `alt` может не хватить: основное объяснение нужно дать рядом текстом или предоставить
+доступное подробное описание. Для графика важно передать ключевые данные и вывод, а не только «график продаж».
+
+Не начинайте без необходимости с «изображение» или «картинка»: screen reader обычно уже сообщает тип элемента. На
+интервью важно объяснить, как **функция картинки и окружающий текст** определяют `alt`.
 
 </td></tr></table>
 </details>
@@ -2860,7 +2937,18 @@ Alt text описывает смысл изображения для польз
 
 **Полный ответ**
 
-Когда изображение декоративное и не несет смысла. Пустой alt позволяет screen reader пропустить его и не создавать шум.
+`alt=""` используют, если изображение не добавляет информации или уже полностью дублируется соседним текстом. Например,
+декоративный орнамент рядом с заголовком или иконка внутри кнопки с видимым текстом «Сохранить» обычно не нуждаются в
+повторном озвучивании.
+
+Пустой `alt` — не то же самое, что отсутствие атрибута: при отсутствующем `alt` некоторые технологии могут попытаться
+озвучить имя файла или URL. Для декоративного `<img>` лучше задать явный `alt=""`.
+
+Есть важный edge case: иконка без видимой текстовой подписи внутри кнопки **не должна делать кнопку безымянной**.
+Доступное имя задают, например, через `aria-label` на кнопке или через содержательную альтернативу изображения.
+
+На интервью различайте **decorative**, **informative** и **functional** images. Если изображение сообщает критичную
+информацию, скрывать ее пустым `alt` нельзя.
 
 </td></tr></table>
 </details>
@@ -2876,8 +2964,20 @@ Alt text описывает смысл изображения для польз
 
 **Полный ответ**
 
-Хорошие подписи, контраст, keyboard navigation, понятные ошибки и предсказуемый фокус помогают не только людям с
-инвалидностью. Они улучшают продукт в плохом освещении, на мобильных устройствах и при спешке.
+Доступные паттерны уменьшают число ситуаций, в которых человек не может понять интерфейс или завершить действие. Крупная
+кликабельная область, отчетливая подпись и текстовый feedback полезны при моторных ограничениях, на маленьком экране и в
+спешке.
+
+Например, пользователь может временно работать без мыши; корректный tab order позволит продолжить задачу. Субтитры
+помогают при нарушении слуха и при просмотре видео без звука. Понятная текстовая ошибка полезнее красной рамки
+независимо от способа ввода.
+
+Однако нельзя полагаться только на аргумент «это полезно всем»: некоторые потребности требуют специализированных
+решений, например корректной модели screen reader для сложной таблицы. Их проверяют отдельно, а не выводят автоматически
+из хорошей визуальной эргономики.
+
+На интервью приведите **конкретную accessibility-механику**, ее результат для основного сценария и отдельную проверку
+потребностей пользователей assistive technologies.
 
 </td></tr></table>
 </details>
@@ -2893,8 +2993,19 @@ Alt text описывает смысл изображения для польз
 
 **Полный ответ**
 
-Порядок фокуса должен соответствовать визуальному и смысловому порядку экрана. Иначе пользователь клавиатуры теряет
-контекст и может пропустить важные действия.
+По умолчанию браузер следует DOM-порядку фокусируемых элементов. Если CSS визуально переставляет карточки через `order`
+или Grid, последовательность `Tab` может перестать совпадать с тем, что пользователь видит на экране.
+
+Например, визуально кнопка «Оплатить» расположена сразу после суммы, но по DOM находится в самом конце страницы.
+Пользователь клавиатуры пройдет десятки элементов, прежде чем достигнет действия, которое находится у него перед
+глазами.
+
+Для обычного контента лучший подход — **логичный DOM-порядок**, совпадающий с чтением и визуальной структурой.
+Положительный `tabindex` не исправляет архитектуру: он создает отдельные правила навигации и особенно плохо
+масштабируется в динамических списках.
+
+При открытии modal или удалении строки важен не только порядок, но и осмысленное восстановление фокуса. На интервью
+полезно проверить tab order до, во время и после изменения интерфейса.
 
 </td></tr></table>
 </details>
@@ -2910,8 +3021,19 @@ Alt text описывает смысл изображения для польз
 
 **Полный ответ**
 
-Фокус должен переходить внутрь dialog, оставаться внутри до закрытия и возвращаться на элемент, который его открыл.
-Нужны понятный заголовок, закрытие с клавиатуры и недоступность фонового контента для взаимодействия.
+Для модального сценария предпочтителен нативный `<dialog>` с `showModal()` или проверенный компонент, реализующий
+WAI-ARIA dialog pattern. Модальность означает, что фоновый интерфейс недоступен для взаимодействия, а фокус остается в
+допустимой области dialog.
+
+После открытия фокус перемещают внутрь на подходящий элемент; заголовок связывают с dialog через доступное имя, например
+`aria-labelledby`. `Escape` обычно закрывает обычный modal, но для сценариев с риском потери данных могут понадобиться
+отдельное подтверждение или явно описанная политика закрытия.
+
+После закрытия фокус возвращают на элемент-инициатор, если он сохранился. Если диалог удалил этот элемент, выбирают
+логичную альтернативу, например соседний элемент списка. Не стоит вручную строить trap вокруг случайного `div` без учета
+смены содержимого и вложенных popup.
+
+На интервью раскройте **открытие, keyboard flow, блокировку background, закрытие и восстановление фокуса**.
 
 </td></tr></table>
 </details>
@@ -2927,8 +3049,19 @@ Alt text описывает смысл изображения для польз
 
 **Полный ответ**
 
-Ошибка должна быть видимой, текстовой и связанной с полем или областью, где она возникла. Для динамических ошибок важно,
-чтобы assistive technologies могли узнать об изменении.
+Сообщение об ошибке должно объяснять **что произошло и как исправить проблему**, а не только менять цвет поля. Для поля
+можно показать видимый текст, установить `aria-invalid="true"` и связать пояснение через `aria-describedby` или
+`aria-errormessage` при подходящей поддержке.
+
+Если ошибки появляются после submit, полезно вывести summary в начале формы и перевести фокус на него или первое
+проблемное поле. Выбор зависит от длины формы: пользователь должен быстро найти действие и не потерять контекст.
+
+Для динамических сообщений помогают live regions: `role="alert"` подходит для важных ошибок, `role="status"` — для менее
+срочного feedback. Не следует одновременно перемещать фокус и дублировать тот же текст в нескольких live regions: screen
+reader может озвучить его несколько раз.
+
+На интервью приведите flow **submit → ошибка backend → связанное сообщение → исправление → повторная отправка**, включая
+keyboard-only использование.
 
 </td></tr></table>
 </details>
@@ -2944,8 +3077,18 @@ ARIA добавляет семантику там, где native HTML не хв
 
 **Полный ответ**
 
-ARIA добавляет семантику там, где native HTML не хватает. Она нужна для сложных custom components, но не должна заменять
-обычные HTML-элементы без причины.
+WAI-ARIA описывает роли, состояния и связи для accessibility tree: например, `aria-expanded` сообщает состояние
+раскрытия, `aria-controls` указывает связанный элемент, а `aria-labelledby` задает доступное имя через другой текстовый
+узел.
+
+ARIA не реализует поведение компонента. `role="button"` на `div` не добавляет обработку `Enter`/`Space`, фокус или
+disabled semantics. Поэтому нативные HTML-элементы обычно надежнее, а ARIA нужна для случаев, когда семантику нельзя
+адекватно выразить обычным HTML.
+
+Пример: кастомный combobox требует не только `role="combobox"`, но и управления фокусом, клавишами, состоянием popup,
+active option и озвучиванием выбранного значения. Слепое добавление атрибутов может сделать его менее доступным.
+
+На интервью различайте три слоя: **semantics (HTML/ARIA), behavior (JavaScript) и feedback (визуальный/озвучиваемый)**.
 
 </td></tr></table>
 </details>
@@ -2961,8 +3104,19 @@ Native элементы уже имеют встроенное поведени
 
 **Полный ответ**
 
-Native элементы уже имеют встроенное поведение, роли, keyboard support и совместимость. ARIA легко применить неправильно
-и получить интерфейс, который выглядит доступным только в коде.
+Нативные элементы уже участвуют в платформенных правилах: кнопка доступна с клавиатуры, ссылка имеет поведение
+навигации, input поддерживает ввод и базовые формы взаимодействия. При использовании кастомных элементов все эти
+контракты приходится поддерживать самостоятельно.
+
+Например, `<div role="checkbox" aria-checked="true">` сообщает роль и состояние, но без клавиатурной логики, управления
+фокусом и обработки переключения такой control не эквивалентен `<input type="checkbox">`.
+
+ARIA полезна, когда нативного элемента недостаточно: например, для отдельных состояний виджета или доступного имени
+icon-only кнопки. Но **no ARIA is better than bad ARIA**: неверная роль может ухудшить понимание интерфейса screen
+reader.
+
+На интервью предложите последовательность: найти нативный элемент → проверить его возможности → добавить минимально
+нужную ARIA → протестировать реальное взаимодействие.
 
 </td></tr></table>
 </details>
@@ -2978,8 +3132,20 @@ Native элементы уже имеют встроенное поведени
 
 **Полный ответ**
 
-Низкий контраст ухудшает чтение, особенно на мобильных устройствах, плохих экранах и при ярком свете. Контраст важен для
-текста, иконок, focus state и ошибок.
+Контраст определяет различимость текста и важных визуальных границ. По WCAG 2.2 для обычного текста обычно требуется
+минимум **4.5:1**, для крупного текста — **3:1**; для значимых графических элементов и границ controls часто применяется
+требование **3:1** при соответствующих критериях.
+
+Например, светло-серый placeholder на белом фоне может быть нечитабельным, а тонкая граница input — неразличимой. При
+этом для placeholder особенно важно не делать его единственным носителем инструкции: даже идеальный контраст не заменит
+label.
+
+Контраст нужно проверять во всех состояниях: default, hover, focus, validation error, dark theme и disabled. Для
+некоторых неактивных компонентов требования WCAG отличаются, но это не повод скрывать пользователю причину недоступности
+действия.
+
+На интервью объясните, **какие элементы измеряют**, почему одного брендового цвета недостаточно и как проверяют токены
+дизайн-системы на реальных фонах.
 
 </td></tr></table>
 </details>
@@ -2995,8 +3161,18 @@ Native элементы уже имеют встроенное поведени
 
 **Полный ответ**
 
-Не все пользователи различают цвета одинаково. Ошибку, успех или выбранное состояние нужно дополнительно передавать
-текстом, иконкой, формой или расположением.
+Цвет может быть незаметен при дальтонизме, низком качестве дисплея, ярком освещении или при выключенных пользовательских
+стилях. Кроме того, screen reader не сообщает различие между красным и зеленым состоянием автоматически.
+
+Например, поле с ошибкой нельзя обозначать только красной рамкой: добавьте текст «Введите корректный email» и свяжите
+его с input. В графике различайте серии не только цветом, но и подписями, маркерами или узорами; у выбранного tab должен
+быть явный state.
+
+Дополнительный сигнал не обязательно означает иконку рядом с каждым словом. Важнее, чтобы значение состояния было
+доступно **в тексте и семантике**; иначе просто добавленная иконка без подписи не решит проблему.
+
+На интервью сравните status badge, форму и график — во всех трех сценариях нужно сохранить смысл при потере цветового
+различия.
 
 </td></tr></table>
 </details>
@@ -3012,8 +3188,19 @@ Native элементы уже имеют встроенное поведени
 
 **Полный ответ**
 
-Нужно пройти сценарий с клавиатуры, проверить focus states, labels, contrast, heading structure и сообщения об ошибках.
-Автоматические проверки полезны, но не заменяют ручной проход.
+Проверку удобно разделить на автоматическую и ручную. Axe, Lighthouse или accessibility lint находят часть проблем:
+missing names, некорректные атрибуты, отдельные нарушения contrast и структуры. Они не докажут, что пользователь
+способен завершить весь сценарий.
+
+Ручной smoke test начинается с клавиатуры: от загрузки страницы пройти `Tab`/`Shift+Tab`, проверить
+`Enter`/`Space`/`Escape`, видимый фокус, dialog, формы и сообщения об ошибках. Затем проверить масштабирование до 200%,
+увеличение текста, responsive reflow и, по возможности, основной flow со screen reader.
+
+Например, тест может подтвердить наличие `aria-label` на кнопке, но не заметить, что после удаления строки фокус
+исчезает или Escape неожиданно закрывает весь экран.
+
+На интервью покажите **матрицу: automated checks + keyboard + screen reader + critical business flow** и объясните
+ограничения каждого метода.
 
 </td></tr></table>
 </details>
@@ -3029,8 +3216,19 @@ Native элементы уже имеют встроенное поведени
 
 **Полный ответ**
 
-Частые проблемы: div вместо button, потеря фокуса, недоступные custom select, слабый контраст, ошибки без текста и modal
-без focus management. Большинство из них дешевле исправлять во время разработки.
+Типичная причина — замена встроенных browser semantics визуальными имитациями. `div` вместо button, обработчик только
+`click`, icon-only control без accessible name и модальный popup без focus management выглядят исправно при тестировании
+мышью, но ломают другие способы ввода.
+
+Вторая группа ошибок связана с динамическими состояниями: loading без announcement, форма с ошибкой без связанного
+пояснения, обновленная таблица с потерянным фокусом и dropdown, который нельзя закрыть клавиатурой.
+
+Например, при рефакторинге кнопки в «универсальную карточку» можно случайно потерять клавиатурную активацию. Лучший
+способ избежать этого — заранее определить семантический контракт компонента и проверять его в unit/component/E2E
+тестах.
+
+На интервью важно не только перечислить баги, но и назвать **первопричину, сценарий воспроизведения и защиту от
+регрессии**.
 
 </td></tr></table>
 </details>
@@ -3046,8 +3244,19 @@ Native элементы уже имеют встроенное поведени
 
 **Полный ответ**
 
-Нужно включить keyboard flow, focus state, labels, contrast, error handling и базовые проверки в критерии готовности.
-Так accessibility становится обычной частью разработки, а не отдельной фазой в конце.
+Definition of Done должен содержать проверяемые требования, привязанные к типу задачи. Для новой формы это labels,
+help/error descriptions и keyboard submit; для dialog — управление фокусом и закрытие; для таблицы — корректные
+заголовки, состояние сортировки и доступные действия.
+
+Базовые шаги можно автоматизировать: lint, axe в component/E2E smoke tests и проверку семантики при review. Ручной
+keyboard pass для критического сценария остается обязательным, потому что автоматические инструменты не оценивают
+понятность всего flow.
+
+Не стоит превращать DoD в гигантский универсальный checklist: набор применимых критериев зависит от компонента и
+изменения. При этом известные дефекты нужно фиксировать с владельцем и приоритетом, а не считать выполненными из-за
+отсутствия новых регрессий.
+
+На интервью предложите **небольшой обязательный набор, конкретные acceptance criteria и процесс для исключений**.
 
 </td></tr></table>
 </details>
@@ -3063,8 +3272,18 @@ Design system может централизовать доступные ком
 
 **Полный ответ**
 
-Design system может централизовать доступные компоненты, цветовые токены, focus styles, labels и примеры паттернов. Это
-снижает вероятность повторять одни и те же ошибки в каждом feature.
+Design system позволяет централизованно реализовать сложный доступный contract: семантику controls, focus styles,
+keyboard behavior, disabled states, подписи и проверенные сочетания контрастных цветовых токенов.
+
+Например, исправление keyboard navigation в общем select может устранить ошибку в десятках приложений, а не требовать
+локального workaround для каждой формы. Документация компонента должна показывать не только красивые состояния, но и
+правила его использования: обязательное accessible name, error text и edge cases.
+
+Однако библиотека не гарантирует доступность продукта автоматически. Неправильный label, порядок элементов, вложенность
+dialog или неуместный tooltip могут сломать сценарий даже на корректных primitives.
+
+На интервью разделите ответственность: **design system обеспечивает accessible building blocks**, а продуктовая команда
+отвечает за composition, content и end-to-end flow.
 
 </td></tr></table>
 </details>
@@ -3080,8 +3299,19 @@ Design system может централизовать доступные ком
 
 **Полный ответ**
 
-Потому что проблемы часто встроены в компоненты, визуальный язык и сценарии. Поздняя правка может затронуть дизайн,
-архитектуру и уже привычное поведение продукта.
+Доступность часто зависит от исходных архитектурных решений. Если десятки экранов используют `div`-buttons, кастомный
+focus trap или компоненты без понятной структуры именования, поздний фикс затронет API компонентов, тесты, дизайн и
+пользовательские сценарии.
+
+Например, добавление доступной клавиатурной модели в самописный select может потребовать изменить состояние active
+option, управление прокруткой, поведение Escape и контракт form control. Это уже не локальная CSS-правка.
+
+Практичнее исправлять основу в design system, защищать ее contract tests и постепенно мигрировать потребителей. Для
+существующего продукта полезно ранжировать долг по критичности сценария, числу затронутых пользователей и стоимости
+регрессии.
+
+На интервью объясните, почему **поздняя accessibility-доработка может стать cross-cutting refactor**, и как избежать ее
+через раннее проектирование взаимодействий.
 
 </td></tr></table>
 </details>
@@ -3097,8 +3327,19 @@ Design system может централизовать доступные ком
 
 **Полный ответ**
 
-Лучше говорить через риск, охват, качество, скорость поддержки и конкретные сценарии пользователей. Полезно предлагать
-минимальный обязательный уровень, который команда может стабильно выполнять.
+Аргументируйте конкретными потерями для пользователя и продукта: нельзя завершить оплату с клавиатуры, ошибка формы не
+озвучивается, модальный диалог блокирует сценарий. Так задача становится воспроизводимым дефектом, а не абстрактным
+пожеланием.
+
+Полезно показать короткую демонстрацию и предложить измеримый минимум: доступный вход, регистрацию, покупку и другие
+критичные пути. Далее — добавить приемочные критерии и общий набор компонентов, чтобы каждый следующий экран не создавал
+такой же долг.
+
+Приоритизация зависит от аудитории, обязательств и масштаба проблемы, но наличие других задач не делает недоступный
+сценарий менее реальным. Не обещайте «однажды починить все» без владельца и плана.
+
+На интервью используйте рамку **сценарий → impact → минимальный fix → предотвращение регрессии** и покажите умение
+договариваться с продуктом.
 
 </td></tr></table>
 </details>
@@ -3114,8 +3355,19 @@ Design system может централизовать доступные ком
 
 **Полный ответ**
 
-Недоступный интерфейс может создавать юридические риски в некоторых рынках и отрезать часть аудитории. Даже без
-юридического давления accessibility является признаком зрелого продукта.
+Требования доступности зависят от страны, сектора, типа продукта и применимых норм. Например, в отдельных юрисдикциях
+обязательства могут распространяться на государственные сервисы или определенные категории коммерческих продуктов.
+Нельзя утверждать, что любой сайт в мире автоматически подпадает под одну и ту же норму.
+
+WCAG — технический стандарт с уровнями соответствия и критериями успеха; его использование в контракте или
+законодательстве нужно проверять отдельно. Соответствие checklist не гарантирует безошибочный пользовательский опыт, а
+юридическая оценка требует учета контекста.
+
+Для frontend-команды практический вывод один: закладывать доступность в компоненты и проверять критические сценарии
+раньше, чем проблемы станут дорогостоящим техническим и продуктовым долгом.
+
+На интервью разделяйте **стандарты, применимые юридические требования и фактическое качество UX**; не подменяйте одно
+другим.
 
 </td></tr></table>
 </details>