Кнопка оплаты не должна звучать как заевшая пластинка
⠀
В 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.

Календарь открылся - и NVDA начал читать всё подряд
⠀
В react-datepicker выбор диапазона дат внутри всплывающего окна привёл к странному эффекту: NVDA сразу зачитал все выбранные дни в случайном порядке.
⠀
Это не мелкая «болтливость» экранного диктора. Если календарь при открытии вываливает поток дат, пользователь ещё до выбора теряет контекст: где фокус, какой день активен и что делать дальше.

Календарь открылся - и NVDA начал читать всё подряд
⠀
В react-datepicker появился хороший пример неочевидной ошибки в календарях. Пользователь открыл выбор диапазона дат внутри всплывающего окна, а NVDA сразу начал зачитывать все выбранные дни в случайном порядке: 6 июня, 7 июня, 9 июня, потом 8 июня, потом снова дальше по сетке.
⠀
Фокус при этом мог стоять вообще не на календаре, а на другом элементе окна. Но для NVDA открылся диалог, он вошёл в режим чтения и прошёлся по содержимому. Календарь уже отрисовал много ячеек с aria-selected="true", поэтому пользователь получил поток дат вместо понятного состояния.
⠀
Почему это мешает: человек ещё не начал выбирать дату, а интерфейс уже нагружает его шумом. В календаре это особенно неприятно - нужно держать в голове дни, диапазон, текущий фокус и следующий шаг. Если экранный доступ читает выбранные даты не по порядку, доверять такому контролу трудно.
⠀
Вывод для команд простой: календарь надо проверять не только по стрелкам внутри сетки. Откройте его как реальный пользователь: из кнопки, поля, всплывающего окна, модального слоя. Послушайте, что NVDA или другой экранный диктор говорит в первые секунды после открытия.
⠀
Если при открытии календаря звучит простыня выбранных дат, проблема не в «болтливом скринридере». Проблема в управлении фокусом, состояниями ячеек и моментом, когда эти состояния попадают в дерево доступности.

Контекстное меню - это тоже часть интерфейса
⠀
В Parla, нативном GNOME-клиенте для Delta Chat, пользователь описал простую проблему: списки чатов и сообщений открывают нужные действия только правой кнопкой мыши. С клавиатуры меню не вызывается.
⠀
Ожидаемый путь знакомый: Shift+F10 или клавиша контекстного меню. Но в списке чатов эти клавиши почему-то открывают меню поля ввода, а в списке сообщений не делают ничего. Для человека без мыши это уже не «неудобство», а закрытая часть продукта: действия над чатом или сообщением есть на экране, но до них нельзя добраться.
⠀
Это задевает не только «клавиатурных» пользователей. Для многих пользователей экранного доступа клавиатура - основной способ дойти до элемента, понять, где фокус, и вызвать доступные действия.
⠀
Хорошая проверка здесь очень бытовая: поставить фокус на строку списка и попробовать открыть все те же действия без мыши. Если контекстное меню существует только для правого клика, значит команда протестировала видимый интерфейс, но не протестировала управление.
⠀
Источник: trufae/parla#40

VPN должен быть доступен без мыши
⠀
Свежий issue по AmneziaVPN: NVDA и TalkBack спотыкаются не только о подписи кнопок, а о весь путь управления VPN - серверы, вкладки, удаление профиля и split tunneling.