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

В MakeCode нашли простую, но тяжёлую проблему: блоки видны, а с клавиатуры до них не добраться
⠀
В свежем issue по Microsoft MakeCode для micro:bit описали баг в редакторе проекта. Пользователь открывает раздел Music, а дальше не может перейти к внутренним элементам: вводу мелодии, темпу, тону, выпадающим спискам. Фокус просто не заходит в эти контролы.
⠀
Отдельно в issue сказано, что похожее замечено и в других деревьях редактора: Basic, Input, LED, Radio, Loops, Logic. То есть это не один кривой элемент, а риск на уровне навигации по целому типу интерфейса.
⠀
Кого это бьёт: людей, которые работают с клавиатуры, и пользователей screen reader. Для них “видимый блок в редакторе” ещё не значит “доступный блок”. Если фокус не попадает внутрь, человек не может поменять параметры и фактически теряет часть функциональности.
⠀
Для команд здесь проверка довольно приземлённая: после выбора раздела нужно не только смотреть, появился ли UI на экране. Нужно пройти его с клавиатуры по порядку и убедиться, что каждый внутренний контрол достижим, понятен и работает без мыши.
⠀
Особенно это важно в образовательных инструментах. Если ребёнок или преподаватель не может собрать пример с музыкой только потому, что фокус застрял снаружи, это уже не “мелкий баг доступности”. Это сломанный учебный сценарий.

Сегодняшний кейс — dropdown-меню в UI Kit La Suite.

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

Что мешало пользователю: клавиатурный пользователь мог потерять текущий пункт меню из-за слабого фокуса, а пользователь screen reader получал меньше информации о том, открыто ли меню и какие пункты уже выбраны.

Что изменили: добавили связь триггера с меню через ARIA-состояния, передали состояние выбранных пунктов через aria-checked и усилили видимый фокус на пунктах меню.

Стало: состояние dropdown стало понятнее для screen reader, а клавиатурная навигация — заметнее визуально. Это не закрывает весь большой issue целиком, но убирает несколько практичных барьеров небольшим PR.

Такие точечные исправления хорошо ложатся в подход Accessibility Auditor Skill: найти конкретный пользовательский барьер, проверить риск и отправить минимальную полезную правку.

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

Issue: suitenumerique/ui-kit#183

PR: suitenumerique/ui-kit#229

Когда ИИ-ответ есть на экране, но его нет для VoiceOver
⠀
В свежем issue по Warp описали неприятный сбой: VoiceOver не читает ответы агента и вывод терминала в панели агента. Вместо текста пользователь слышит внутреннюю строку вроде MaybeHoverSecret { secret_handle: None }.
⠀
Это не декоративная проблема. Если человек работает через экранный доступ, он не может прочитать ответ ИИ, проверить вывод команды или вернуться к результату. При этом документы в соседнем редакторе Warp читаются через системное чтение, значит проблема, похоже, в отрисовке панели агента/терминала.
⠀
Для команд вывод простой: текст в интерфейсе должен быть текстом и для API доступности. Если компонент показывает его зрячему пользователю, но не отдаёт VoiceOver, NVDA или системному чтению, экран превращается в чёрный ящик.
⠀
Я бы отдельно проверял все панели с потоковым текстом: ответы ИИ, терминал, логи, чат, уведомления.
⠀
Источник: warpdotdev/warp#11125.

Кейс дня: состояние dropdown стало понятнее для screen reader

В UI Kit La Suite numérique был открытый accessibility issue по DropdownMenu: триггер открывал меню, но не сообщал вспомогательным технологиям, что это именно меню и открыто оно сейчас или закрыто.

Было: пользователь доходил до кнопки, нажимал Enter — меню появлялось, но screen reader не получал явного состояния expanded/collapsed. При повторной навигации было сложнее понять, что произошло и куда дальше двигаться.

Что мешало: для зрячего пользователя изменение видно визуально, а для пользователя screen reader состояние компонента должно быть выражено программно. Без aria-expanded и связи с меню интерфейс хуже объясняет сам себя.

Что изменили: в DropdownMenu добавлены aria-haspopup="menu", aria-expanded и связь триггера с меню через aria-controls во время открытия.

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

Разбор и правка сделаны с помощью Accessibility Auditor Skill — инструмента для поиска и исправления accessibility-проблем в реальных интерфейсах.

Доказательство:
Issue: https://github.com/suitenumerique/ui-kit/issues/183
PR: https://github.com/suitenumerique/ui-kit/pull/228

Кейс дня: состояние dropdown стало понятнее для screen reader

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

Если подсказка спрятана через hidden, экранный доступ её тоже не видит
⠀
В Etherpad дошли до неприятного бага: редактор мог показывать клавиатурную подсказку в коде, но не отдавать её экранному доступу. Причина простая: элемент с подсказкой был создан с hidden=true, а aria-describedby ссылался уже на узел, которого нет в дереве доступности.
⠀
Для зрячего пользователя это выглядит как мелкая внутренняя деталь. Для пользователя NVDA, VoiceOver или другого экранного доступа это означает: редактор открывается, а нужный путь к содержимому и подсказкам не проговаривается. В исходной жалобе человек писал, что Etherpad фактически гоняет его по номерам строк и не даёт нормально читать документ.
⠀
Хорошая правка здесь не в том, чтобы «добавить ARIA». Команда убрала hidden, добавила запасной текст для подсказки, если переводы ещё не загрузились, и отдельно защитила skip link: доступность не должна быть настройкой, выключенной по умолчанию.
⠀
Я бы из этого вынес простую проверку: если элемент нужен экранному доступу, нельзя прятать его так, будто он декоративный. Проверять надо не только картинку на экране, а то, что реально попадает в дерево доступности.
⠀
Источник: жалоба в Etherpad и PR с исправлением.

Etherpad и экранный доступ: подсказка была в коде, но не в дереве доступности
⠀
Если элемент нужен NVDA, VoiceOver или другому экранному доступу, его нельзя прятать через hidden. Иначе aria-describedby может ссылаться в пустоту.
⠀
Полный разбор ниже.

Кейс по доступности: dropdown-меню в UI Kit.

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

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

Что изменили: добавили для триггера меню aria-haspopup, aria-expanded и связь с открытым меню через aria-controls. Для выбранных пунктов добавили доступное состояние, а декоративную галочку скрыли от скринридера.

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

Такой разбор и минимальную правку я делаю через Accessibility Auditor Skill: он помогает быстро найти пользовательскую проблему, проверить WCAG/RGAA-смысл и довести её до небольшого безопасного PR.

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

Issue: suitenumerique/ui-kit#183

PR: suitenumerique/ui-kit#227

Было:

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

Когда папки видны, но VoiceOver их не называет
⠀
В Nextcloud iOS открыли issue #4099: если отправлять файл из другого приложения через системное меню «Поделиться» и выбрать Nextcloud, экран выбора папки визуально показывает папки, но VoiceOver не читает их имена и детали.
⠀
Для зрячего пользователя это обычный выбор места сохранения. Для пользователя VoiceOver - угадайка: фокус двигается, папку можно выбрать, но непонятно, какую именно. Автор пишет, что из-за этого нельзя самостоятельно загрузить файл: приходится просить зрячего человека или полагаться на распознавание экрана, которое медленное и не всегда надёжное.
⠀
Здесь ломается не украшение интерфейса, а базовый сценарий: «поделиться файлом в облако». Если список папок доступен только глазами, приложение фактически забирает автономность у незрячего пользователя.
⠀
Я бы проверял такие места отдельно: системное меню отправки, модальные окна, выбор папки, любые списки назначения. Недостаточно протестировать главный экран приложения - часто баг живёт именно во втором сценарии, куда команда сама редко заходит с VoiceOver.

Когда папки видны, но VoiceOver их не называет
⠀
Свежий issue в Nextcloud iOS: при отправке файла через «Поделиться» VoiceOver не читает имена папок на экране выбора. Для незрячего пользователя это превращает загрузку файла в угадайку.
⠀
Полный разбор ниже.

Ежедневный accessibility PR

Было: в компоненте DropdownMenu пункт меню подсвечивался почти незаметным серым фоном, а кнопка открытия не сообщала скринридеру своё состояние.

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

Что changed: добавила для триггера меню состояние aria-expanded и связь с меню через aria-controls, а для пунктов меню — явный контрастный focus outline.

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

Такие кейсы я разбираю через Accessibility Auditor Skill: он помогает быстро находить места, где интерфейс виден глазами, но плохо доступен клавиатуре и скринридеру.

Proof:

Issue: https://github.com/suitenumerique/ui-kit/issues/183

PR: https://github.com/suitenumerique/ui-kit/pull/226

Ежедневный accessibility PR

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

ИИ в проверке доступности не закрывает главный риск
⠀
Applause выпустил отчёт по доступности за 2026 год, и там хорошо видно противоречие: 78% организаций уже используют ИИ для улучшения доступности, но 56% пользователей assistive tech с начала года регулярно встречали недоступные приложения.
⠀
Для людей с экранным доступом, увеличением шрифта, субтитрами или альтернативной навигацией это не абстрактный дефект. Если приложение не работает с такими инструментами, 92% пользователей готовы его бросить.
⠀
Мне здесь важна не цифра сама по себе, а разрыв между «мы проверяем доступность» и «человек не может закончить задачу». Автопроверка может найти часть ошибок в коде. Но она легко пропускает контекст: странный порядок табуляции, лишний текст в screen reader, фильтр без понятного состояния, кнопку без смысла в реальном сценарии.
⠀
В отчёте есть и нормальная трезвость: только 10% организаций полагаются на ИИ-инструменты без ручной проверки. Остальные всё-таки сверяют результат людьми. Но ручная проверка тоже бывает разной. Одно дело - пройти чек-лист мышкой и клавиатурой. Другое - дать сценарий человеку, который каждый день пользуется NVDA, JAWS, VoiceOver, увеличением или head pointer.
⠀
Я бы из этого вынес простое правило для команд: ИИ можно использовать как быстрый первый слой, но не как финальный ответ. Если сценарий важный - регистрация, покупка, оплата, поиск, поддержка, медицинская запись - его нужно прогонять с реальными вспомогательными технологиями и реальными пользователями.
⠀
Иначе команда видит зелёный отчёт, а пользователь всё равно упирается в молчащую кнопку или форму, из которой невозможно выбраться.

ИИ в проверке доступности не закрывает главный риск
⠀
По свежему отчёту Applause, 78% организаций уже используют ИИ для доступности, но 56% пользователей assistive tech всё равно регулярно встречают недоступные приложения.
⠀
Полный разбор ниже.

Мини-кейс доступности: ошибки формы должны быть слышны

Было: форма показывала текст ошибки под полем, но для screen reader он не был явно связан с самим полем.

Что мешало пользователю: человек мог услышать поле как обычное, без понятного сигнала «здесь ошибка» и без надёжной связи с текстом подсказки. Визуально ошибка есть, а в озвучке контекст теряется.

Что изменили: в общих компонентах Input и Textarea добавили aria-invalid, связь с текстом ошибки через aria-describedby, а саму ошибку пометили role="alert". Теперь это работает сразу для форм, которые используют эти компоненты.

Стало: screen reader получает понятную структуру: поле отмечено как невалидное, а ошибка объявляется и связана с конкретным полем. Это меньше угадывания и меньше потерянного контекста при заполнении формы.

Кейс подготовлен через Accessibility Auditor Skill.

Доказательство:
Issue: github.com/Vets-Who-Code/vets-who-code-app/issues/895
PR: github.com/Vets-Who-Code/vets-who-code-app/pull/1120

Мини-кейс доступности: ошибки формы должны быть слышны

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

Когда интерфейс говорит слишком много
⠀
В pty-speak поймали хороший, очень практический баг: команда dir в preview-сборке могла отправить в NVDA один огромный кусок вывода. Дальше SAPI начинал озвучивать его как одну фразу на 5-10 минут.
⠀
Проблема не в том, что текста было много. Хуже другое: пользователь уже не может нормально остановить поток и быстро вернуться к работе. Для незрячего человека терминал в этот момент превращается из инструмента в ловушку ожидания.
⠀
В PR #293 предложили нормальный ремонт: автоматическое озвучивание режется до последних 800 символов, а полный вывод открывается отдельной командой Ctrl+Shift+O в текстовом редакторе.
⠀
Я бы здесь забрал простое правило для любых интерфейсов с озвучкой: не отправлять в экранный доступ бесконечные простыни как одно уведомление. Коротко озвучить главное - да. Дать отдельный способ открыть полный текст - обязательно.

Мини-кейс: вернули видимый фокус на сайте Joplin

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

Что это ломало: пользователь с клавиатурой или screen reader мог перейти на кнопку, но зрячий клавиатурный пользователь не понимал, где он находится. Это напрямую бьёт по WCAG 2.4.7 Focus Visible.

Что изменили: убрали глобальное подавление outline и добавили общий :focus-visible стиль для ссылок, кнопок, полей форм и custom tabindex-контролов.

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

Разбор и выбор правки делала через Accessibility Auditor Skill: он помогает быстро связать симптом, код и критерий WCAG, чтобы не чинить “на глаз”.

Доказательство:
Issue: https://github.com/laurent22/joplin/issues/15264
PR: https://github.com/laurent22/joplin/pull/15378

Мини-кейс: вернули видимый фокус на сайте Joplin

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