Всё про доступность интерфейсов

Когда экран «работает», но VoiceOver уже нет
⠀
В r/Blind пользователь после iOS 26.2 описал не косметику, а сломанный рабочий день: VoiceOver лагает, пропускает элементы, не читает часть кнопок и подписей, фокус прыгает в начало экрана. Zoom тоже сбоит: увеличивает не ту область и не всегда следует за фокусом VoiceOver.
⠀
Для зрячего это выглядит как неприятный баг. Для незрячего или слабовидящего пользователя это потеря управления телефоном: сложнее печатать, читать переписку, менять настройки и понимать, где ты сейчас находишься.
⠀
В комментариях добавили отдельный пример: на Reddit VoiceOver доходит до рекламы, сбивается и начинает чтение сначала. Обычный сценарий просто не проходится до конца.
⠀
После обновления нужно проверять основные пути с VoiceOver и Zoom вместе: фокус не прыгает, подписи читаются, жесты не отваливаются, реклама и всплывающие блоки не ломают поток.
⠀
Источник: r/Blind.

Reddit на iOS поймал неприятный баг с VoiceOver
⠀
Живой сигнал из r/bugs: незрячий пользователь после обновления Reddit до 2026.21.0 перестал читать текст поста в треде. VoiceOver доходил до тела исходного поста и вместо текста говорил только: «swipe up and down for more options».
⠀
Ответы ниже читались нормально. То есть экранный доступ не «сломался везде», а выпал главный кусок сценария: открыть обсуждение и понять, о чём пост.
⠀
Автор проверил с друзьями: на 2026.19.9 проблемы не было, на 2026.21.0 она повторялась. Позже он написал, что в 2026.21.1 баг исправили.
⠀
Визуально экран может выглядеть живым, кнопки и ответы могут работать, но для пользователя с VoiceOver основное содержание исчезло.
⠀
Я бы отсюда забрал тест перед релизом: после обновления пройти главный путь с экранным доступом и проверить саму суть экрана - читается ли пост, форма, чек, инструкция, ошибка.

Источник: r/bugs

Кнопка «закрыть» без контекста
⠀
В VS Code обсуждают не самый заметный, но понятный баг: панель поиска и замены ведёт себя почти как диалог, но для экранного диктора не называется диалогом.
⠀
Из-за этого пользователь NVDA, попадая на кнопку Close (escape), слышит примерно: «main landmark, Close, button». И не понимает из самой кнопки, что именно она закрывает: поиск, редактор, боковую панель или что-то ещё.
⠀
Предложение простое: дать контейнеру роль dialog и понятное имя вроде Find / Replace. Тогда кнопка оказывается внутри названной группы, а не висит в воздухе.
⠀
Для интерфейсов здесь хороший тест: если блок визуально выглядит как отдельная панель с несколькими действиями, его надо так же собрать и для экранного диктора. Иначе зрячий пользователь видит контекст глазами, а незрячий вынужден угадывать его по одной кнопке.
⠀
Источник: microsoft/vscode#172861

В WindoM нашёл понятный accessibility-баг: несколько элементов выглядели как кнопки, но в коде были обычными div с onClick.

Что ломалось: фокус дня, обновление цитаты и выбор фото работали мышью, но часть сценариев была недоступна с клавиатуры. Для скринридера такие элементы тоже хуже объясняли свою роль.

Что изменил: фокус и цитату перевёл на настоящие button, для фото добавил keyboard activation через Enter/Space без вложенных кнопок, а переключателю поисковика вернул Tab-доступ и состояние aria-expanded.

Стало: те же действия теперь доступны с клавиатуры, элементы получают нормальную семантику, а интерфейс меньше зависит от мыши.

Кейс найден и подготовлен с помощью Accessibility Auditor Skill — инструмента для поиска и упаковки практичных accessibility-улучшений.

Доказательство:

Issue: YehudaBriskman/WindoM#239

PR: YehudaBriskman/WindoM#271

Что ломалось:

Коротко: новый разбор issue → audit → PR по доступности интерфейса. Полный текст — следующим сообщением.

Когда проверка орфографии молчит
⠀
В свежей задаче Community-Access/quill#10 описан неприятный сценарий: включена проверка орфографии «по мере набора», пользователь с NVDA печатает слово с ошибкой, но не слышит ничего.
⠀
В интерфейсе меняется только строка состояния: Possible misspelling. Для зрячего пользователя это хоть какой-то след. Для скринридера почти пусто: NVDA обычно не читает такие изменения, а штатный звук ошибки не срабатывает, потому что приложение не помечает фрагмент текста через API доступности.
⠀
И здесь легко обмануться. Красное подчёркивание или «волнистая линия» не делают ошибку доступной сами по себе. Если пользователь не видит экран, ему нужен явный сигнал: звук, объявление или семантика ошибки.
⠀
Я бы это проверял отдельно: если интерфейс что-то подсвечивает глазами, он должен так же понятно сообщать это ушами или брайлевской строкой. Иначе проверка работает только для части пользователей.

В модальном окне экспорта документов был маленький, но неприятный accessibility-баг.

Было: внутри выбора формата отдельная кнопка со стрелкой попадала в Tab-навигацию и озвучивалась скринридером как самостоятельный элемент.

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

Что изменили: декоративную кнопку стрелки скрыли от assistive technologies и убрали из порядка Tab-навигации. Сам select остаётся интерактивным, а лишний фокус больше не появляется.

Стало: навигация по модалке короче и понятнее: фокус идёт по реальным действиям, без дублирующей стрелки.

Кейс найден и подготовлен с помощью Accessibility Auditor Skill — инструмента для поиска и упаковки практичных accessibility-улучшений.

Доказательство:

Issue: suitenumerique/docs#2342

PR: suitenumerique/docs#2366

Было:

Коротко: новый разбор issue → audit → PR по доступности интерфейса. Полный текст — следующим сообщением.

Подсказка есть, но на слух её не разобрать
⠀
В Microsoft Aspire завели свежую задачу по Help-окну в Dashboard: NVDA читает горячие клавиши одной длинной строкой. Пример из issue: “Increase panel size + Decrease panel size - Reset panel sizes shift+r...”
⠀
Визуально это набор отдельных команд. Для пользователя скринридера - каша: где действие, где клавиша, сколько пунктов в списке, непонятно. Ещё и ломается навигация по спискам: например, быстрый переход к списку в JAWS не сработает, если элементов нет внутри нормального списка.
⠀
Причина простая: пункты выглядят как список, но в разметке не оформлены как ul, ol или dl. ARIA-роли тоже могут помочь, но лучше не терять нативную семантику HTML там, где она уже есть.
⠀
Если интерфейс показывает “набор пунктов”, скринридер тоже должен получить набор пунктов, а не слепленную строку текста.
⠀
Источник: microsoft/aspire#17650

Доступность в формах: ошибка должна быть услышана

Было: форма регистрации показывала ошибки и успешный результат визуально.

Что мешало пользователю: если человек работает со screen reader, новое сообщение могло появиться на экране, но не прозвучать автоматически. В итоге приходилось вручную искать, что изменилось и почему форма не отправилась.

Что изменили: добавили семантику для сообщений формы:
— ошибки полей и серверные ошибки теперь объявляются как alert;
— успешное завершение объявляется как status;
— добавили тесты, чтобы это поведение не потерялось.

Стало: обратная связь формы стала доступнее для незрячих пользователей — ошибка или успех доходят не только глазами, но и через assistive technology.

Инструмент, который помогает находить такие кейсы и готовить аккуратные PR: Accessibility Auditor Skill.

Proof:
Issue: https://github.com/mattstratton/conducky/issues/254
PR: https://github.com/mattstratton/conducky/pull/459

Доступность в формах: ошибка должна быть услышана

Коротко: новый разбор issue → audit → PR по доступности интерфейса. Полный текст — следующим сообщением.

Когда брайлевская строка отстаёт от фокуса
⠀
В MuseScore Studio открыли свежую задачу по доступности: в версии 4.7 на Windows с NVDA навигация по партитуре и брайлевская панель не всегда показывают один и тот же элемент.
⠀
Сценарий не экзотический. Пользователь идёт по нотам и элементам через Alt+стрелки: динамика, артикуляция, аппликатура, орнаменты, текст. Ноты, динамика и lyrics, по отчёту, чаще работают нормально. А на артикуляции, аппликатуре и части других символов брайлевский фокус может уехать на связанную ноту или вообще остаться на строке lyrics.
⠀
Для зрячего человека это может выглядеть как мелкая рассинхронизация. Для незрячего музыканта это уже ломает проверку партитуры: ты думаешь, что стоишь на конкретном знаке, а брайлевская строка показывает соседний или родительский объект. Исправлять такую нотацию вслепую становится рискованно.
⠀
Мне здесь нравится сам урок для интерфейсов: доступность - это не только “элемент озвучился”. Если в продукте есть две синхронные модели - визуальная область, дерево объектов, брайлевская строка, панель свойств - фокус должен быть точным между ними. Иначе пользователь получает не интерфейс, а угадайку.
⠀
Источник: MuseScore Studio issue #33606

Когда брайлевская строка отстаёт от фокуса
⠀
В MuseScore Studio открыли свежую задачу: в версии 4.7 на Windows с NVDA навигация по партитуре и брайлевская панель не всегда показывают один и тот же элемент.
⠀
Полный разбор - ниже.

Tab сработал, но скринридер молчит
⠀
В свежей задаче по Docs editor описан простой сценарий: пользователь ставит курсор в документ, нажимает Tab, текст визуально получает отступ, но скринридер ничего не сообщает. Не говорит ни сам факт изменения, ни уровень отступа.
⠀
Для зрячего пользователя это видно сразу. Для незрячего это изменение документа без обратной связи: непонятно, применился ли отступ, где сейчас уровень вложенности и не уехала ли структура текста.
⠀
Проблема не в клавише Tab. Проблема в том, что редактор меняет состояние документа и оставляет это только на экране.
⠀
Если интерфейс даёт форматирование с клавиатуры, он должен возвращать результат через доступный канал: «отступ добавлен», «уровень 2», «отступ убран». И проверять это надо не только глазами, а реальным проходом со скринридером.
⠀
Источник: issue suitenumerique/docs#2335

Когда поле есть, но его имени нет
⠀
В свежей задаче по SL Design System разобрали хороший пример из редактируемой таблицы: внутри грида есть поля ввода и выпадающие списки, рядом есть нормальные заголовки колонок, но сами поля не получают доступные имена.
⠀
Для зрячего пользователя контекст виден: вот строка, вот колонка, понятно, где ZIP, где статус. А пользователь скринридера, который идёт Tab только по активным полям, слышит в основном текущее значение поля или выбранный вариант. Названия поля рядом с этим может не быть.
⠀
В маленькой форме это раздражает. В большой таблице это уже ломает работу: чтобы изменить нужную ячейку, человеку приходится угадывать, где он находится, или постоянно восстанавливать контекст вручную.
⠀
Автор задачи предлагает связать поле с несколькими частями контекста через aria-labelledby: например, чтобы имя звучало как “Zip FIRST NAME LAST NAME” или “Status FIRST NAME LAST NAME”. Это важная деталь. В таблицах имя поля часто должно отвечать и на вопрос “что это за колонка?”, и на вопрос “к какой строке это относится?”.
⠀
Я бы проверял такие компоненты двумя способами. Сначала автоматикой, чтобы поймать пустое имя у input. Потом руками: пройти по редактируемым ячейкам только Tab-ом со скринридером и понять, можно ли без зрения уверенно сказать, какую именно запись ты сейчас меняешь.

Редактируемая таблица может выглядеть понятной, но быть пустой для скринридера.
⠀
В SL Design System нашли поля без доступных имён: пользователь слышит значение, но не понимает, какую строку и колонку редактирует.

Кейс доступности: видимый фокус в светлой теме

Было: в dashboard-интерфейсе DevTrack часть кнопок и ссылок в светлой теме почти не показывала keyboard focus.

Что это ломало: человек, который идёт по странице клавишей Tab, не понимает, где сейчас находится. Для незрячих и keyboard-only пользователей это быстро превращает обычную навигацию в угадайку: можно нажать Enter не на тот элемент или просто потеряться в шапке интерфейса.

Что изменили: добавили общий стиль :focus-visible для интерактивных элементов, отдельный контрастный цвет фокуса для светлой и тёмной темы, а также поддержку forced colors/high contrast mode.

Стало: кнопки, ссылки и другие фокусируемые элементы получают заметную 3px-обводку с отступом. Фокус виден именно при клавиатурной навигации и не мешает обычным кликам мышью.

Это маленький PR, но эффект практичный: интерфейс становится предсказуемее для пользователей клавиатуры и лучше соответствует WCAG 2.4.7 Focus Visible.

Для анализа использовала Accessibility Auditor Skill — он помогает быстро разложить проблему на пользовательский сценарий, WCAG-критерий и безопасное минимальное исправление.

Доказательство:
Issue: github.com/Priyanshu-byte-coder/devtrack/issues/1034
PR: github.com/Priyanshu-byte-coder/devtrack/pull/1114

Кейс доступности: видимый фокус в светлой теме

Коротко: новый разбор issue → audit → PR по доступности интерфейса. Полный текст — следующим сообщением.

Когда “Continue” есть на экране, но его нет для VoiceOver
⠀
В OpenHuman вчера завели короткую, но очень показательную задачу: незрячий пользователь macOS проходит первый запуск приложения, VoiceOver читает тексты “Run Locally” и “Run on the Cloud”, но основную кнопку “Continue” не находит нормально. В итоге он не может пройти онбординг самостоятельно.
⠀
Это не про красивую доступность в настройках. Это входная дверь в продукт. Если кнопка не фокусируется с клавиатуры, не отдана в API доступности или не имеет понятной роли и подписи, пользователь просто не попадает внутрь.
⠀
Хорошая часть кейса - команда, судя по комментарию автора, быстро поправила проблему. Но сам сигнал всё равно полезный: экран может выглядеть готовым, текст может читаться, а сценарий всё равно будет сломан из-за одного элемента действия.
⠀
Я бы проверял онбординг отдельно и руками: Tab, VoiceOver, Enter/Space, имя кнопки, роль кнопки, порядок фокуса. Особенно в десктопных приложениях, где легко получить визуально нормальный интерфейс и пустоту для экранного доступа.
⠀
Для пользователя барьер простой: без доступной кнопки продолжения продукт не “частично неудобен”, а недоступен с первого шага.
⠀
Источник: GitHub issue tinyhumansai/openhuman#2584

Когда “Continue” есть на экране, но его нет для VoiceOver
⠀
В OpenHuman незрячий пользователь macOS не смог пройти первый запуск: VoiceOver читал тексты, но не видел основную кнопку продолжения. Ниже - полный разбор кейса и вывод для интерфейсов.