Подсказка есть, но на слух её не разобрать
⠀
В 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

Было:

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

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

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

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

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

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

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

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

Issue: suitenumerique/docs#2342

PR: suitenumerique/docs#2366

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

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

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

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

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

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

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

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

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

Issue: YehudaBriskman/WindoM#239

PR: YehudaBriskman/WindoM#271

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

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

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

В поиске видны колонки, но экранный доступ их не читает
⠀
В Zammad открыли баг по новой версии: в списке результатов поиска заголовки колонок визуально есть, но экранная читалка их не озвучивает. В тикете указан Zammad 7.0.1, окружение Openshift, а ожидаемое поведение простое: заголовки должны читаться при работе со списком.
⠀
Для зрячего пользователя это выглядит как небольшая проблема таблицы. Для незрячего или слабовидящего пользователя это ломает саму ориентацию в результатах: слышны значения, но непонятно, к чему они относятся. В интерфейсе поддержки это особенно больно, потому что поиск - рабочий инструмент, а не декоративный экран.
⠀
Хорошая проверка для команд: пройти таблицы и списки не глазами, а экранной читалкой. Если строка читается без понятных заголовков, интерфейс формально показывает данные, но не даёт человеку нормально ими пользоваться.
⠀
Источник: Zammad issue #6164

Кастомный интерфейс может выглядеть красиво, но для экранного доступа быть «тихим».
⠀
Кейс Decenza: пользователь с TalkBack каждый день управляет кофемашиной через приложение, а поля ввода и графики всё ещё ломают понятный сценарий.

Когда кофемашина становится «тихим металлом»
⠀
В GitHub у приложения Decenza для кофемашин Decent появился хороший, очень живой кейс про доступность. Пользователь с TalkBack написал, что без этого приложения его машина фактически превращается в «кусок тихого металла на столе»: он каждый день готовит через приложение и не может нормально обходить оставшиеся барьеры.
⠀
Сначала обсуждение было про общую проблему кастомного QML-интерфейса: красивые Rectangle, Item и MouseArea выглядят как кнопки, слайдеры и графики, но для экранного доступа они могут быть просто молчаливыми областями. Потом разговор сузился до конкретного бага: поля ввода сразу перехватывают фокус и открывают клавиатуру, не давая TalkBack спокойно прочитать название поля. При наборе и удалении символов тоже нет нормальной звуковой обратной связи.
⠀
Это не косметика. Если незрячий пользователь меняет название зерна, дату обжарки или заметку о шоте, он должен понимать, где находится, что ввёл и удалился ли символ. Без этого интерфейс вроде бы работает, но задача становится угадайкой.
⠀
Для команд здесь простой тест: пройти основной путь с экранным доступом и проверить не только подписи кнопок. Поля ввода не должны открывать клавиатуру до явного действия, слайдеры должны отдавать роль и значение, а живые графики должны иметь короткую текстовую сводку без речевой каши.
⠀
Источник: обсуждение Decenza #1300

Когда справка есть, но прочитать её нельзя
⠀
Свежий issue по SuperCollider IDE: пользователь экранных читалок проверил NVDA, Orca и Cthulhu и описал, как встроенная справка, Quarks-список, автодополнение и окно вывода становятся почти непроходимыми.
⠀
Главный тест для команды простой: может ли человек с экранной читалкой открыть справку, понять список, вернуться в редактор и продолжить задачу без блокнота как костыля.
⠀
Источник: supercollider#7541

Когда справка есть, но прочитать её нельзя
⠀
В SuperCollider завели свежий issue про доступность IDE для пользователей экранных читалок. Автор проверял NVDA на Windows и Orca/Cthulhu на Linux и описал не абстрактное «добавьте доступность», а несколько рабочих мест, где программа ломается именно в повседневной работе.
⠀
Самое критичное - встроенная справка. Раньше на Windows ещё можно было табом добраться до ссылок и полей, выделить текст и унести его в блокнот. Сейчас, по описанию автора, фокус на странице справки почти не получается нормально поймать. На Linux ситуация похожая. Для зрячего пользователя справка просто открылась. Для пользователя с экранной читалкой она фактически стала закрытой.
⠀
Есть и другие детали: экран Quarks читает в списке только кнопку выбора, автодополнение уводит фокус в недоступный список, окно вывода приходится читать обходными способами. Это не косметика. В среде для музыки и кода справка, редактор, список расширений и окно вывода - это основная работа.
⠀
Отдельно важен вывод про виджеты. Чем больше интерфейс собирается из внутренних веб-панелей и кастомных элементов, тем меньше можно надеяться на «само будет доступно». Стандартные элементы обычно уже умеют отдавать роль, имя, состояние и фокус. Самодельные - часто выглядят нормально только глазами.
⠀
Я бы проверял такие экраны не вопросом «видно ли кнопку», а другим: может ли человек с экранной читалкой открыть справку, понять список, вернуться в редактор, прочитать вывод и продолжить задачу без блокнота как костыля.
⠀
Источник: supercollider/supercollider#7541

Flutter iOS: экран есть, а для VoiceOver он пропал
⠀
В свежем issue по Flutter описали баг: после выбора пункта в DropdownMenu у приложения на go_router пустеет всё дерево доступности iOS.
⠀
Для незрячего пользователя это не «плохо подписали список», а экран, который фактически исчез.

В Flutter нашли неприятный iOS-баг для экранного доступа
⠀
В свежем issue в flutter/flutter описали воспроизводимый сценарий: приложение на iOS использует MaterialApp.router / go_router, пользователь открывает DropdownMenu и выбирает любой пункт. После этого дерево доступности в iOS становится пустым.
⠀
Проблема задевает не один выпадающий список. Из дерева пропадают текст, кнопка и сам список. Для VoiceOver такой экран фактически перестаёт существовать до конца сессии.
⠀
Автор свёл баг к минимальному примеру, сравнил два варианта и показал разницу: обычный MaterialApp выдерживает, а связка с Router API ломается. Ещё важная деталь: уже открытый фикс по похожей проблеме, похоже, этот путь не покрывает. Мейнтейнер оставил issue открытым как отдельный воспроизводимый случай.
⠀
Для команд здесь простой урок: видимый путь «тапнул - выбрал - работает» недостаточен. После выбора, модалки, навигации и переиспользования экранов стоит заново смотреть, что осталось в дереве доступности. Лучше проверять это через Accessibility Inspector, VoiceOver или автоматический тест, который видит интерфейс как пользователь с экранным доступом.
⠀
Если дерево доступности исчезло, красивый экран уже не помогает. Для незрячего пользователя это не мелкая ошибка в подписи, а потерянный экран.

Приватность не помогает, если до экрана нельзя добраться
⠀
В SimpleX Chat появился свежий баг-репорт от пользователя VoiceOver на iOS: после начальных экранов кнопки часто плохо подписаны, а закрытие экрана может стать недоступным.
⠀
Для мессенджера это не мелочь. Если человек не может уверенно открыть чат, понять кнопку и выйти из экрана, приватность остаётся где-то за дверью.

Приватность не помогает, если до экрана нельзя добраться
⠀
В SimpleX Chat появился свежий баг-репорт от пользователя VoiceOver на iOS. Проблема шире одной кнопки: человек пишет, что почти все экраны после старта приложения либо плохо подписаны для VoiceOver, либо ведут себя непредсказуемо.
⠀
По описанию, нормально пройти удалось только начальный экран и экран имени профиля. Дальше начинаются обычные для зрячего интерфейса, но очень жёсткие для экранного доступа вещи: кнопки без понятных названий, элементы с неясным поведением, закрытие экрана, которое может «исчезнуть», из-за чего приходится закрывать приложение целиком.
⠀
Это особенно неприятно именно для мессенджера. Автор пишет, что хотел пользоваться SimpleX для общения с человеком за границей, потому что тот рекомендует его для приватной связи. Но если пользователь с VoiceOver не может уверенно открыть чат, понять кнопку и выйти из экрана, приватность остаётся где-то за дверью.
⠀
Для команд здесь простая проверка. Не ограничиваться экраном входа и парой видимых кнопок. Пройти весь основной путь с VoiceOver: создание профиля, список чатов, чат, поиск, звонки, настройки, закрытие модальных окон. У каждой иконки должно быть человеческое имя, а у каждого действия - понятный результат.
⠀
И да, это касается любого продукта, который обещает безопасность, здоровье, деньги или связь с людьми. Доступность там нужно проверять как часть базового сценария. Иначе часть пользователей просто не доходит до обещанной пользы.

Когда ошибка есть на экране, но её не слышно

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

Когда ошибка есть на экране, но её не слышно
⠀
На этой неделе я выбрал для PR не отдельную кнопку, а семейство форм в smrt-svelte. Это библиотека компонентов: если там поправить базовые поля, улучшение потом расходится по многим интерфейсам.
⠀
Проблема была простая и неприятная. Поле могло показать подсказку, ошибку или статус обработки, но само поле не было связано с этим текстом через aria-describedby. Для зрячего пользователя сообщение видно под инпутом. Для пользователя со скринридером это уже не так очевидно: фокус стоит в поле, а важный текст живёт отдельно.
⠀
Я открыл PR, который добавляет устойчивую связь между полями и сообщениями в TextInput, TextareaInput, SelectInput, NumberInput и MoneyInput. Ошибочные состояния теперь получают aria-invalid, а динамические сообщения объявляются аккуратно, без переноса фокуса.
⠀
Это не заменяет полноценное тестирование со скринридером, но убирает типичный барьер: “форма ругается, а я не понимаю, на что именно”. Такие вещи хорошо ловятся через Accessibility Auditor Skill: он помогает не остановиться на визуальной проверке и посмотреть на связи, состояния и объявления.
⠀
Доказательства:
issue #1420
PR #1440

Теперь раз в неделю, но более обширные проблемы.