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

Когда список “говорит” неправильное число пунктов
⠀
В Radix UI завели баг по Select: в Chrome на macOS VoiceOver путает позицию пунктов или вообще не говорит “2 из 5”.
⠀
Для пользователя экранного доступа это не косметика. Так теряется ориентация в списке: сколько вариантов есть, где сейчас фокус и не пропущен ли нужный пункт.
⠀
Полный разбор ниже.

Дерево классов, которое видно только глазами
⠀
В AberOWL завели issue про дерево иерархии классов. Снаружи это обычный список: можно раскрывать узлы, выбирать класс, смотреть связи. Но в коде дерево было собрано из div/button без нормальной семантики дерева: без role="tree", role="treeitem", role="group", без aria-expanded/aria-selected и без навигации стрелками.
⠀
Для мыши такой интерфейс может выглядеть рабочим. Для пользователя с экранным доступом или только клавиатурой это уже другая задача: непонятно, где узел, раскрыт ли он, что выбрано, на каком уровне иерархии он находится и как пройти по дереву без угадывания.
⠀
Здесь важна не сама редкость продукта. В онтологиях дерево классов - не декор, а главный способ разобраться в данных. Если оно не читается как дерево, пользователь теряет не одну кнопку, а карту всей структуры.
⠀
В открытом PR к этому issue уже добавили роли tree/treeitem/group, aria-expanded, aria-selected, aria-level, видимый фокус и обработку стрелок: вверх/вниз для перехода, вправо/влево для раскрытия и сворачивания, Enter или пробел для выбора.
⠀
Хорошая проверка для команд простая: если в интерфейсе есть дерево, меню, список с уровнями или вложенная навигация, пройдите его без мыши и с экранным доступом. Должно быть понятно не только «на что можно нажать», но и где пользователь находится внутри структуры.
⠀
Источник: bio-ontology-research-group/aberowl2#25

Дерево классов, которое видно только глазами
⠀
В AberOWL нашли проблему с главным деревом иерархии: визуально узлы раскрываются, но для экранного доступа и клавиатуры не хватает семантики дерева и навигации стрелками.

Антивирус открылся, но молчит
⠀
В репозитории NVDA появился хороший пример того, как доступность может сломаться не на экране входа и не в редкой функции, а в защитном софте, которым человек пользуется каждый день.
⠀
Пользователь описал проблему с Avast Premium Security: после обновления до NVDA 2026.1.1 окно Avast визуально открывается, фокус по элементам ходит, но при переходе Tab или стрелками NVDA не произносит названия и типы элементов. Чтобы понять, где сейчас фокус, приходится отдельно нажимать NVDA+Tab или NVDA+Numpad 5. В NVDA 2025.3.3 такого не было.
⠀
В обсуждении нашли важную деталь: объект фокуса в Avast всё ещё виден, но у NVDA в новой версии не появляется нужная привязка к helper-коду, из-за этого виртуальный буфер не готов и обычное озвучивание фокуса может не доходить до пользователя. Отдельно всплыло подозрение на механизм «белого списка» экранных дикторов в Avast: если приложение безопасности разрешает доступность только знакомым версиям или процессам, обновление экранного диктора может внезапно превратить рабочий интерфейс в почти молчащий.
⠀
Для незрячего пользователя это не косметика. Антивирус - место, где нужно понимать предупреждения, разрешения, исключения, карантин, оплату, всплывающие окна. Если фокус есть только технически, но не озвучивается при обычной навигации, человек фактически не может спокойно управлять защитой своего компьютера.
⠀
Здесь вывод шире Avast и NVDA: если продукт ограничивает доступ assistive tech ради безопасности, это нельзя делать как вечный список «разрешённых» программ без проверки обновлений. После крупного обновления экранного диктора, перехода на другую архитектуру или смены UI нужно пройти главный путь с реальным NVDA/JAWS/Narrator: Tab, стрелки, диалоги, предупреждения, кнопки подтверждения. И проверять не только «видит ли инструмент элементы», а произносится ли фокус в обычном сценарии.
⠀
Источник: issue nvaccess/nvda#20286

Антивирус открылся, но молчит
⠀
В NVDA обсуждают регрессию: после обновления до 2026.1.1 Avast Premium Security визуально работает, но при обычной навигации Tab/стрелками экранный диктор не произносит элементы.
⠀
Это хороший тест для защитного софта: мало «видеть» элементы технически. Пользователь должен слышать фокус в обычном пути - предупреждения, исключения, карантин, кнопки подтверждения.
⠀
Источник

Тост с Undo может быть недоступен именно тогда, когда он нужен
⠀
В GitHub issue по мобильному приложению Rollercoaster.dev разобрали обычный компонент: всплывающее уведомление с кнопкой Undo.
⠀
Визуально всё выглядит знакомо: появилось сообщение, рядом действие, через несколько секунд уведомление исчезло. Но в коде контейнер сделан одним доступным элементом, и из-за этого VoiceOver или TalkBack могут вообще не дать фокус на кнопку Undo. Пользователь слышит уведомление, но не может нажать действие, которое должно исправить ошибку.
⠀
Есть ещё одна неприятная деталь: тост сам закрывается через 5 секунд. Для человека с экранным доступом, моторными ограничениями или просто медленным чтением это может быть слишком мало. Особенно если действие одноразовое: не успел найти кнопку - потерял возможность отменить.
⠀
Отдельно автор issue отмечает, что accessibilityLiveRegion="assertive" помогает на Android, но iOS его игнорирует. Для VoiceOver нужно отдельно вызывать объявление через AccessibilityInfo.announceForAccessibility.
⠀
Я бы здесь проверял не только “есть ли роль alert”. Важнее весь сценарий: слышит ли пользователь сообщение, может ли добраться до действия, хватает ли времени, и что происходит, если уведомлений несколько подряд.
⠀
Кнопка Undo в тосте - не украшение интерфейса. Если она недоступна, пользователь теряет контроль над только что сделанным действием.
⠀
Источник: Rollercoaster.dev-mobile#264

Тост с Undo может быть недоступен именно тогда, когда он нужен
⠀
В issue по Rollercoaster.dev разобрали обычное уведомление с кнопкой Undo. Визуально действие есть, но VoiceOver или TalkBack могут не дать фокус на кнопку: контейнер склеен в один доступный элемент.
⠀
Проверять нужно весь сценарий: объявилось ли сообщение, доступна ли кнопка, хватает ли времени до автозакрытия.
⠀
Источник: GitHub issue

Qwen Chat: когда вход уже недоступен
⠀
В репозитории Qwen появился свежий issue от незрячего пользователя NVDA. Он пишет, что официальный Qwen Chat для него фактически блокируется сразу в нескольких местах: визуальная CAPTCHA при входе, недоступная загрузка файлов и кнопки, которые NVDA читает просто как button.
⠀
Самый жёсткий пункт здесь - CAPTCHA. Пользователю пришлось просить зрячего человека помочь пройти визуальную головоломку. Для сервиса с ИИ это выглядит особенно странно: продукт обещает самостоятельную работу с текстом и файлами, но на входе требует действие, которое экранная читалка не может выполнить.
⠀
Дальше проблема не заканчивается. Если кнопка не имеет доступного имени, человек не понимает, что она делает. Если загрузка файла не подписана и плохо держит фокус, пользователь не может нормально приложить документ. Интерфейс вроде есть, но рабочий путь разваливается.
⠀
Для команд здесь простой тест. Перед релизом нужно пройти вход, загрузку файла и основные действия с NVDA или другой экранной читалкой. Важно проверить не видимость элементов, а то, есть ли у каждого действия имя, роль, состояние и понятный порядок фокуса.
⠀
Источник: QwenLM/Qwen#2253

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

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

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

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

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

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

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

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

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

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

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

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

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