Слепой разработчик и небезопасный TUI
⠀
В issue к MiMo-Code пользователь описал проверку MiMoCode 0.1.0 на macOS с VoiceOver. Одноразовая команда mimo run ещё читается нормально: это обычный вывод в терминал. Но интерактивный TUI, attach-режим и веб-выбор проекта уже становятся ненадёжными.
⠀
Самая неприятная часть не в том, что «экранный доступ плохо читает интерфейс». Инструмент попытался открыть /Users/xiaopinpin/README.md вместо README внутри тестового проекта на внешнем диске, а потом показал запрос доступа к домашней папке. Если такой запрос трудно разобрать с VoiceOver, пользователь может случайно разрешить доступ шире, чем хотел.
⠀
То есть доступность здесь напрямую связана с безопасностью. Слепой разработчик должен понимать три вещи без угадывания: какой проект открыт, какой путь запрашивает агент и выходит ли этот путь за пределы проекта.
⠀
Вторая поломка похожая: веб-интерфейс открылся, но выбор проекта показал пустую папку ~/lfs/tmp/, а очевидного доступного способа перейти к нужному каталогу не было. Команда mimo web тоже не принимает путь проекта как аргумент.
⠀
Что я бы проверял в таких инструментах отдельно:
⠀
• можно ли открыть проект точной командой из терминала;
• проговаривается ли текущий корень проекта;
• запрос прав показывает действие, путь, корень проекта и безопасный вариант по умолчанию;
• есть ли простой текстовый режим без TUI;
• можно ли отказаться от доступа так же легко, как разрешить.
⠀
Для интерфейсов с ИИ-агентами доступность - это не только подписи кнопок. Если пользователь не может надёжно прочитать контекст и права, он теряет контроль над тем, что агенту разрешено делать.
⠀
Источник: XiaomiMiMo/MiMo-Code #472.

CiviForm: подсказка, до которой не дойти клавиатурой
⠀
В issue #13444 описали форму админки: значок Info открывается мышью, но не попадает в порядок Tab, а VoiceOver не читает текст подсказки. Полный разбор ниже.

Подсказка есть, но экранный доступ о ней не узнает
⠀
В CiviForm завели issue про всплывающие подсказки в админке. Пример простой: на экране создания вопроса рядом с полем Administrative Identifier есть значок Info. Мышью его можно открыть, а с клавиатуры до него не добраться. VoiceOver в Chrome на macOS эту подсказку тоже пропускает, поэтому пользователь даже не узнаёт, что рядом есть дополнительное объяснение.
⠀
Для зрячего пользователя это может выглядеть как мелкая справка рядом с полем. Для человека, который идёт по форме клавиатурой или слушает интерфейс через экранный доступ, это уже потерянный кусок инструкции. Особенно неприятно в административной форме: человек заполняет настройку, но часть правил спрятана в элементе, который для него фактически не существует.
⠀
У иконки может быть подпись, но этого мало. Нужно проверить весь путь: попадает ли значок в порядок Tab, понятно ли он назван, открывается ли с клавиатуры, связан ли текст подсказки с полем, можно ли прочитать его экранной читалкой и закрыть без мыши.
⠀
Если в продукте есть подсказки, не считайте их доступными только потому, что они видны на экране. Пройдите форму без мыши и со включённым VoiceOver, NVDA или другим экранным доступом. Если справка нужна для правильного заполнения поля, она должна быть достижима тем же способом, которым человек реально проходит форму.
⠀
Источник: civiform/civiform#13444

Кнопка оплаты не должна звучать как заевшая пластинка
⠀
В paypal-js открыли issue про PayPal-кнопки: в дереве доступности слово “PayPal” повторяется несколько раз, а действие всё равно названо неясно.

Кнопка оплаты не должна звучать как заевшая пластинка
⠀
В paypal-js открыли issue про PayPal-кнопки: в дереве доступности слово “PayPal” повторяется несколько раз, а сама кнопка при этом не говорит нормально, что она делает.
⠀
Автор пишет, что на e-commerce сайтах screen reader может прочитать PayPal четыре раза подряд. Причина не в одном месте: у iframe title вроде PayPal-paypal, внутри ещё элемент с role="link" и aria-label="PayPal". В итоге пользователь слышит бренд, бренд, бренд, но не получает понятного действия.
⠀
Это неприятная мелочь ровно до момента оплаты. Если человек идёт по странице через экранный доступ, ему нужно быстро понять: это просто блок PayPal, ссылка на условия, кнопка выбора способа оплаты или действие “оплатить через PayPal”. Когда название повторяется, интерфейс начинает шуметь. А когда у действия нет нормального имени, растёт шанс выбрать не то или вообще уйти на другой способ оплаты.
⠀
Хорошая правка здесь довольно приземлённая: не пихать бренд в каждую оболочку виджета и называть действие человечески. Например, iframe может иметь короткий и уникальный title, а сама кнопка - имя вроде “Pay with PayPal”.
⠀
Для команд это хороший тест перед релизом платёжного блока: пройти путь оплаты с NVDA, VoiceOver или другим экранным доступом и послушать не только “есть ли имя у элемента”, а сколько лишнего шума попадает в речь. В оплате доступность - это не украшение. Это разница между понятным действием и нервным угадыванием.

Когда список есть на экране, но его нет для VoiceOver

В aMule пришёл хороший живой сигнал от незрячего пользователя macOS: во вкладке поиска VoiceOver сообщает общее число найденных результатов, но саму таблицу результатов не видит. Для клавиатуры и экранного доступа список как будто исчезает.

Там же сломался второй важный путь: в настройках VoiceOver показывает только раздел General. Боковая панель с Connection, Security и другими категориями недоступна, поэтому человек не может нормально перейти к нужным настройкам и включить, например, внешний доступ через aMuleGUI.

Разработчик подтвердил обе проблемы. Причина не в тексте кнопки и не в одном забытом aria-атрибуте: список результатов полностью custom-drawn, без нормального нативного аналога для macOS, Windows и Linux. Экранные читалки просто не получают элементы, строки, колонки и фокус. Для боковой панели путь понятнее - заменить виджет на компонент, который лучше отдаёт структуру в системные API доступности.

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

Визуально всё может быть на месте. Но если список не попал в дерево доступности, для незрячего пользователя это не список, а пустое место.

Источник: amule-org/amule#180

JAWS 2026 и таблицы
⠀
Свежий баг из Freedom Scientific: в JAWS 2026 таблица может читаться без строк, столбцов и заголовков колонок. Визуально данные на месте, но на слух контекст ячейки пропадает.
⠀
Полный разбор - ниже.

Когда обновился экранный доступ, таблица снова сломалась
⠀
В репозитории Freedom Scientific появился свежий баг: в JAWS 2026 таблицы перестали нормально читаться там, где в JAWS 2025 всё работало. При переходе по ячейкам звучит только содержимое ячейки, а число строк, столбцов и заголовки колонок больше не объявляются. NVDA на тех же примерах читает ожидаемо.
⠀
Для пользователя это не мелкая потеря подсказки. В таблице без заголовков быстро становится непонятно, что означает значение: цена, статус, дата, имя, действие. Если интерфейс построен на списках, сетках, отчётах или админских таблицах, человек с JAWS может просто потерять контекст задачи.
⠀
Здесь неприятный урок для команд: нельзя проверять таблицу один раз и считать её закрытой. Если вы убрали собственные объявления и полностью положились на поведение конкретного экранного доступа, нужно прогонять регрессию на новых версиях JAWS, NVDA и браузеров.
⠀
Я бы проверял не только «фокус ходит по ячейкам», а более простую вещь: понимает ли человек на слух, в какой строке и колонке он находится, и что именно означает текущее значение.
⠀
Источник: FreedomScientific/standards-support#947

Когда «скрыть боковую панель» скрывает её только глазами
⠀
В Scratch, офлайн-приложении для заметок на Markdown, пользователь VoiceOver описал неприятную вещь: в режиме Focus и после команды Hide sidebar боковая панель визуально исчезает, но для экранного доступа остаётся в дереве доступности. То есть экран вроде очищен, а VoiceOver всё ещё натыкается на элементы, которые пользователь уже попросил убрать.
⠀
Контекст в отчёте конкретный: macOS Sequoia 15.7.4, VoiceOver, режим «только речь», без брайлевского дисплея. Рядом тот же пользователь завёл ещё один баг: при нажатии Return нет голосового подтверждения новой строки. Для зрячего это может выглядеть мелочью, но при работе с заметками такие сигналы держат в голове структуру текста.
⠀
Здесь ломается не декоративная доступность, а смысл самого Focus mode. Человек включает его, чтобы убрать шум и спокойно писать. Если скрытая панель продолжает читаться, фокус превращается в ещё один источник путаницы: надо на слух отличать рабочий текст от интерфейсного мусора.
⠀
Я бы проверял такие режимы после каждого «скрыть», «сфокусироваться», «свернуть»: пройти экран VoiceOver/NVDA/TalkBack и посмотреть, что реально осталось в порядке чтения и фокусе. Если элемент визуально убрали, он не должен продолжать жить для экранного доступа без причины.
⠀
И отдельно для редакторов: клавиши ввода, удаления, перехода между строками и изменения выделения должны давать понятную обратную связь. Иначе пользователь пишет текст, но постоянно не уверен, произошло ли действие.
⠀
Источник: erictli/scratch #176, рядом #177.

Когда карточка выглядит как выбор, но не выбирается
⠀
Свежий кейс из Chayn Tools letter generator: карточки выбора платформы кликаются мышью, но путь ломается для клавиатуры и экранного доступа.
⠀
Это форма для запроса на удаление вредного контента. Если вариант нельзя выбрать через Tab, стрелки и Space, человек не просто теряет удобство - он не может отправить запрос.
⠀
Полный разбор - следующим сообщением.

Когда карточка выглядит как выбор, но не выбирается
⠀
В свежем issue по Chayn Tools letter generator описан хороший пример: пользователь начинает путь создания письма, доходит до выбора платформы, а дальше застревает. Карточки платформ и карточки следующих вопросов кликаются мышью, но нормально не выбираются с клавиатуры и экранным доступом.
⠀
Это не косметика. Инструмент помогает людям готовить запрос на удаление вредного контента. Если человек не может выбрать платформу через Tab, стрелки и Space, он может вообще не отправить запрос.
⠀
В issue перечислены и соседние поломки: на шагах нет нормального h1, заголовки перескакивают с h2 на h4, кнопки микрофона читаются просто как “button”, а состояния вроде “Analysing your responses” и ошибок не объявляются экранному доступу.
⠀
Рядом уже открыт PR #500 с понятной правкой: заменить кликабельные div на radio group, дать странице один h1, подписать кнопки микрофона, добавить aria-pressed, а загрузку и ошибки отдавать через role="status" и role="alert". Ещё отдельно сделали прогресс шагов читаемым для экранного доступа.
⠀
Я бы забрал отсюда простой тест для любых многошаговых форм: пройти весь сценарий без мыши и послушать его экранным доступом. Проверять нужно весь путь: можно ли выбрать вариант, понять текущий шаг, услышать загрузку, ошибку и продолжить без визуальных подсказок.

Когда модальное окно видно, но для скринридера оно не окно

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

Когда модальное окно видно, но для скринридера оно не окно
⠀
В IBM mcp-context-forge нашёлся хороший недельный кейс по доступности: большой epic по WCAG 2.1 AA уже открыт, но самая полезная точка входа — не «чинить всё», а поправить общие UI-хелперы, через которые повторяются одни и те же ошибки.
⠀
Что было проблемой: модалки в Admin UI открывались визуально, но общий helper не добавлял им роль dialog, не связывал окно с заголовком, не переводил фокус внутрь и не возвращал его обратно на кнопку открытия. Для клавиатуры и скринридера это легко превращается в ситуацию: интерфейс изменился, а пользователь не понимает, где он сейчас.
⠀
Вторая часть — ошибки в формах. Текст ошибки появлялся на экране, но поле не получало нормальную программную связь с этим текстом. Скринридер мог не прочитать, что именно не так и как это относится к текущему полю.
⠀
Что изменил в PR: общий modal-helper теперь выставляет dialog-семантику, aria-modal, подпись через заголовок, переводит фокус в окно и восстанавливает его после закрытия. Генерируемая copyable-modal тоже стала полноценным подписанным dialog. Валидация форм теперь ставит aria-invalid и связывает поле с текстом ошибки через aria-describedby; подсказки, которые уже были у поля, не затираются.
⠀
Это не «закрыли весь WCAG». Это нормальный маленький слой инфраструктуры: одна правка в общих помощниках улучшает сразу несколько будущих и существующих сценариев.
⠀
Кейс собран через Accessibility Auditor Skill.
⠀
Issue: IBM/mcp-context-forge #2274
PR: #5331

NVDA должен видеть не только ответ, но и ввод
⠀
В Command Code пользователь описал баг AI CLI: он печатает запрос, а экранный диктор не читает символы и текущую строку.
⠀
Для незрячего разработчика это ломает базовую безопасность: нельзя нормально проверить команду, путь к файлу или текст запроса до отправки.

Когда консоль «текстовая», но экранный доступ всё равно теряет ввод
⠀
В Command Code issue #509 пользователь с NVDA на Windows описал неприятную вещь: он печатает запрос в AI CLI, а экранный диктор не видит символы. Не читает текущую строку, не проговаривает буквы при движении стрелками, не даёт проверить уже набранный текст.
⠀
Это важная деталь именно для консольных AI-инструментов. Снаружи кажется: «ну это же текст, значит всё доступно». Но для незрячего разработчика доступность здесь не заканчивается на выводе ответа. Нужно ещё набрать запрос, перечитать его, поправить слово, проверить команду или путь к файлу до отправки.
⠀
Автор прямо пишет, что Claude Code раньше имел похожую проблему и её исправили. То есть это не абстрактная просьба «сделайте доступность», а конкретный рабочий сценарий: ввод в командной строке должен быть видим для NVDA так же надёжно, как обычное поле ввода.
⠀
Для команд вывод простой: если вы делаете терминальный интерфейс, проверяйте не только красивые ответы модели. Пройдите весь путь с NVDA или другим экранным диктором: набор текста, стрелки в строке, удаление, вставку, историю команд, подтверждение перед запуском. Иначе «просто текстовый интерфейс» может оказаться интерфейсом, где человек не может безопасно написать сам запрос.

В Nextcloud Talk для Android появился баг: TalkBack озвучивает время и статус сообщения, но не сам текст. Для мессенджера это ломает не «удобство», а сам разговор.

В чате главное - текст сообщения
⠀
В Nextcloud Talk для Android открыли простой, но неприятный баг: TalkBack и Select to Speak не читают текст сообщения.
⠀
По отчёту, проблема воспроизводится в Nextcloud Talk 24.0.1 на Android 12 и 14, на Xiaomi Redmi Note 9 и Motorola Moto G23. TalkBack озвучивает время и статус сообщения, а Select to Speak говорит, что в выбранной области нечего читать. То есть пользователь может понять, что элемент в чате есть, но не получить главное - саму фразу собеседника.
⠀
Для мессенджера это не косметика. Если экранный доступ читает обвязку сообщения, но пропускает тело, человек не может нормально вести разговор, проверить ответ, понять контекст и решить, что делать дальше. Интерфейс визуально живой, но смысловой слой чата для него фактически исчезает.
⠀
Командам здесь стоит проверять не один `contentDescription` и не общий фокус на строке, а реальный диалог с TalkBack: читается ли автор, текст сообщения, время, статус доставки, порядок этих данных и действия рядом с сообщением. И отдельно проверить Select to Speak: это другой пользовательский путь со своим поведением.

Markdown должен читаться целиком
⠀
Свежий баг в react-native-enriched-markdown: iOS VoiceOver пропускает обычные абзацы и жирный текст, хотя на Android TalkBack сценарий работает. Если через markdown идут инструкции или справка, это ломает не оформление, а доступ к содержанию.

Когда VoiceOver пропускает текст, это уже не «мелочь в markdown»
⠀
В react-native-enriched-markdown открыли свежий баг: на iOS VoiceOver не выбирает обычные абзацы и жирный текст. Автор приложил минимальный пример: заголовок, несколько абзацев, список, ссылка и выделенный текст. На Android с TalkBack этот же сценарий работает, а на iOS VoiceOver читает не всё.
⠀
Почему это важно: markdown часто используют не для украшения. Через него показывают инструкции, справки, правила, описания заказов, юридический текст, подсказки в приложении. Если экранный доступ видит ссылку, но пропускает соседний абзац или выделенный фрагмент, незрячий пользователь получает куски документа вместо документа.
⠀
В этом репозитории уже были старые исправления по VoiceOver: навигация по смысловым блокам, ссылки внутри абзацев, точность фокуса. Поэтому новый issue особенно показательный. Доступность rich text нельзя проверить один раз и забыть. После изменений в рендеринге, выборе текста, ссылках, списках и нативных слоях нужно снова пройтись экранным доступом.
⠀
Я бы проверял такие компоненты не только по «ссылка нажимается». Минимальный тест: обычный абзац читается целиком, заголовок объявляется как заголовок, список идёт пунктами, ссылка остаётся отдельным действием, выделенный текст не исчезает, а порядок чтения совпадает с тем, что видит зрячий пользователь.
⠀
Если приложение показывает важный текст через markdown, экранный доступ должен читать сам текст, а не случайно выбранные интерактивные островки.

Скрытый select тоже может мешать
⠀
В NetBox после аудита нашли неприятную вещь: скрытые нативные <select> за стилизованными выпадающими списками всё ещё попадают в дерево доступности.
⠀
Для JAWS это превращается в лишний listbox перед реальным combobox. На форме фильтров такой «призрак» сбивает понимание: где настоящее поле, что выбрано и куда попал фокус.
⠀
Полный разбор ниже.

Скрытый select тоже может мешать
⠀
В NetBox после аудита завели свежую задачу: в форме фильтров скрытые нативные <select>, которые стоят за стилизованными выпадающими списками, всё ещё попадают в дерево доступности.
⠀
Для зрячего пользователя это выглядит как обычный красивый комбобокс. А JAWS при проходе по форме слышит лишний listbox, потом combobox, причём скрытый элемент ещё и без понятного имени. На длинной форме фильтров такой шум мешает: человек начинает сомневаться, где реальное поле, что сейчас выбрано и куда вообще попал фокус.
⠀
Рядом в том же аудите есть похожая проблема: у Saved Filter не озвучивается подпись, вероятно из-за дублей id и сломанной связи label → control. Вместе это хорошо показывает один класс ошибок: визуальная замена стандартного элемента не должна оставлять за собой «призрак» старого элемента для экранного доступа.
⠀
Что я бы проверял в таких местах: после инициализации Select2, Tom Select или любого своего комбобокса пройти форму с экранным диктором и инспектором доступности. В дереве должен остаться один понятный контрол: с именем, ролью, текущим значением и нормальным состоянием. Всё техническое, что больше не служит пользовательским полем, нужно убрать из дерева доступности или корректно скрыть.
⠀
Источник: NetBox issue #22530, смежная задача: #22531.