Когда окно «не модальное», оно не должно вести себя как ловушка
⠀
В Vaadin нашлась хорошая пара багов про один и тот же слой интерфейса: non-modal Dialog и Popover.
⠀
Визуально это выглядит как обычная плавающая панель поверх страницы. Но для клавиатуры и скринридера всё сложнее: диалог без затемняющего фона всё равно удерживал Tab внутри себя, а non-modal popover мог открыться без понятного объявления для NVDA и VoiceOver.
⠀
Для зрячего пользователя это часто просто «панель открылась». Для пользователя с клавиатурой это может стать тупиком: фокус уже перенесли в основную страницу, нажали Tab — и интерфейс снова утащил его назад. Для пользователя со скринридером popover может появиться, но не прозвучать как новое доступное содержимое.
⠀
Я выбрал этот кейс для недельного PR: он не про один атрибут, а про общий паттерн overlay-компонентов. В PR non-modal Dialog больше не включает focus trap, а non-modal Popover получает polite-объявление своего текста или accessible name при открытии без переноса фокуса. Плюс добавлены регрессионные тесты.
⠀
Хорошая проверка для команд: если компонент называется non-modal, проверьте не только мышь. Уведите фокус за панель и нажмите Tab. Потом откройте такой popover со скринридером и убедитесь, что пользователь понял: что-то появилось и что именно.
⠀
Кейс подготовлен с помощью Accessibility Auditor Skill.
⠀
Proof:
issue #11971
issue #11974
PR #11984
⠀
В Vaadin нашлась хорошая пара багов про один и тот же слой интерфейса: non-modal Dialog и Popover.
⠀
Визуально это выглядит как обычная плавающая панель поверх страницы. Но для клавиатуры и скринридера всё сложнее: диалог без затемняющего фона всё равно удерживал Tab внутри себя, а non-modal popover мог открыться без понятного объявления для NVDA и VoiceOver.
⠀
Для зрячего пользователя это часто просто «панель открылась». Для пользователя с клавиатурой это может стать тупиком: фокус уже перенесли в основную страницу, нажали Tab — и интерфейс снова утащил его назад. Для пользователя со скринридером popover может появиться, но не прозвучать как новое доступное содержимое.
⠀
Я выбрал этот кейс для недельного PR: он не про один атрибут, а про общий паттерн overlay-компонентов. В PR non-modal Dialog больше не включает focus trap, а non-modal Popover получает polite-объявление своего текста или accessible name при открытии без переноса фокуса. Плюс добавлены регрессионные тесты.
⠀
Хорошая проверка для команд: если компонент называется non-modal, проверьте не только мышь. Уведите фокус за панель и нажмите Tab. Потом откройте такой popover со скринридером и убедитесь, что пользователь понял: что-то появилось и что именно.
⠀
Кейс подготовлен с помощью Accessibility Auditor Skill.
⠀
Proof:
issue #11971
issue #11974
PR #11984
blinddev.xyz
Accessibility Auditor Skill | Blind Dev — Денис Скрипник
AI-agent workflow для быстрого первого слоя accessibility-аудита: сайты, мобильные и десктопные приложения, репозитории и backlog исправлений.
Когда ответ есть, но VoiceOver его не видит
⠀
В GitHub появился хороший сигнал по доступности Claude Desktop на macOS: полностью незрячий разработчик пишет, что может набрать и отправить запрос, но не может прочитать ответ ассистента через VoiceOver.
⠀
По описанию, это похоже на регрессию. Раньше тот же сценарий работал, а потом без явного обновления приложения ответы перестали озвучиваться и перестали надёжно находиться в стенограмме диалога. То есть поле ввода доступно, но результат работы продукта для скринридера как будто исчез.
⠀
Обходной путь у автора показательный: читать ответы через iPhone companion app или внешне проговаривать их через macOS
⠀
Здесь ломается не «удобная мелочь», а главный цикл интерфейса: вопрос → ответ → продолжение работы. Для ИИ-продукта доступность стенограммы важна не меньше, чем доступность поля ввода.
⠀
Командам стоит проверять не только «можно ли что-то отправить», а весь разговорный поток: новый ответ объявляется, текст ответа есть в дереве доступности, до последнего сообщения можно быстро дойти, фокус не застревает, а изменения после серверного рендера не выбрасывают содержимое из VoiceOver/NVDA.
⠀
В GitHub появился хороший сигнал по доступности Claude Desktop на macOS: полностью незрячий разработчик пишет, что может набрать и отправить запрос, но не может прочитать ответ ассистента через VoiceOver.
⠀
По описанию, это похоже на регрессию. Раньше тот же сценарий работал, а потом без явного обновления приложения ответы перестали озвучиваться и перестали надёжно находиться в стенограмме диалога. То есть поле ввода доступно, но результат работы продукта для скринридера как будто исчез.
⠀
Обходной путь у автора показательный: читать ответы через iPhone companion app или внешне проговаривать их через macOS
say. Для ежедневной работы это не решение. Человек пишет на Mac, ждёт ответ там же, а читать вынужден в другом месте или через отдельную самодельную озвучку.⠀
Здесь ломается не «удобная мелочь», а главный цикл интерфейса: вопрос → ответ → продолжение работы. Для ИИ-продукта доступность стенограммы важна не меньше, чем доступность поля ввода.
⠀
Командам стоит проверять не только «можно ли что-то отправить», а весь разговорный поток: новый ответ объявляется, текст ответа есть в дереве доступности, до последнего сообщения можно быстро дойти, фокус не застревает, а изменения после серверного рендера не выбрасывают содержимое из VoiceOver/NVDA.
GitHub
[BUG] macOS desktop app: VoiceOver cannot read assistant responses (no announcement, transcript unreachable) — apparent recent…
Summary In the Claude desktop app on macOS, a VoiceOver user can type and send messages normally, but cannot read the assistant's responses at all through VoiceOver. New responses are not annou...
Когда доступность ломается не на кнопке, а на скорости
⠀
В свежем issue по VS Code Insiders пользователь VoiceOver описал неприятную вещь: если открыть файл больше примерно 400 строк, редактор начинает сильно тормозить. С включённым VoiceOver и accessibility support процессор почти упирается в 100%, а задержка растёт вместе с размером файла. Расширения он отключал, то есть это не похоже на конфликт с плагином.
⠀
Для зрячего пользователя это может выглядеть как «редактор подлагивает». Для незрячего разработчика это быстро превращается в рабочий стоп: нельзя нормально читать код, перемещаться по файлу, проверять изменения и просто писать. Автор прямо пишет, что сейчас из-за этого невозможно работать.
⠀
Здесь простой урок для команд: доступность держится ещё и на скорости. Если интерфейс формально читается, но с экранным диктором начинает зависать на обычном рабочем файле, он всё равно недоступен.
⠀
Проверять нужно живой сценарий, а не маленькую демо-страницу. Возьмите большой файл, длинный список, таблицу, ленту, историю сообщений. Включите экранный диктор и посмотрите, остаётся ли интерфейс управляемым по скорости, фокусу и отклику. Иначе баг будет найден уже тем человеком, которому этот интерфейс нужен для работы.
⠀
В свежем issue по VS Code Insiders пользователь VoiceOver описал неприятную вещь: если открыть файл больше примерно 400 строк, редактор начинает сильно тормозить. С включённым VoiceOver и accessibility support процессор почти упирается в 100%, а задержка растёт вместе с размером файла. Расширения он отключал, то есть это не похоже на конфликт с плагином.
⠀
Для зрячего пользователя это может выглядеть как «редактор подлагивает». Для незрячего разработчика это быстро превращается в рабочий стоп: нельзя нормально читать код, перемещаться по файлу, проверять изменения и просто писать. Автор прямо пишет, что сейчас из-за этого невозможно работать.
⠀
Здесь простой урок для команд: доступность держится ещё и на скорости. Если интерфейс формально читается, но с экранным диктором начинает зависать на обычном рабочем файле, он всё равно недоступен.
⠀
Проверять нужно живой сценарий, а не маленькую демо-страницу. Возьмите большой файл, длинный список, таблицу, ленту, историю сообщений. Включите экранный диктор и посмотрите, остаётся ли интерфейс управляемым по скорости, фокусу и отклику. Иначе баг будет найден уже тем человеком, которому этот интерфейс нужен для работы.
GitHub
Extreme lag when VoiceOver is active · Issue #323492 · microsoft/vscode
Type: Performance Issue This issue happens when I open any file larger than about 400 lines and have VoiceOver open and active along with accessibility support enabled. If I open Activity Monitor, ...
Чатбот есть, а поговорить с ним нельзя
⠀
В issue по Frag Integreat проверяли чатбот сразу на Android, iOS и Windows. Для экранного диктора он местами превращается в один большой блок: нельзя пройти по ответу, нормально попасть в поле ввода, услышать новый ответ или удержать фокус внутри чата.
⠀
Проверять нужно весь разговор: открытие, поле вопроса, сообщения, объявление новых ответов, фокус и безопасное закрытие.
⠀
Источник: digitalfabrik/integreat-app#4223
⠀
В issue по Frag Integreat проверяли чатбот сразу на Android, iOS и Windows. Для экранного диктора он местами превращается в один большой блок: нельзя пройти по ответу, нормально попасть в поле ввода, услышать новый ответ или удержать фокус внутри чата.
⠀
Проверять нужно весь разговор: открытие, поле вопроса, сообщения, объявление новых ответов, фокус и безопасное закрытие.
⠀
Источник: digitalfabrik/integreat-app#4223
Чатбот есть, а поговорить с ним нельзя
⠀
В Integreat завели отдельный issue по экранному доступу к Frag Integreat - их чатботу помощи. Проверяли сразу Android, iOS и Windows, и проблема не сводится к одной подписи на кнопке.
⠀
На Android экранный диктор несколько раз произносит «Frag Integreat», а весь блок чата воспринимается как один элемент. Из-за этого нельзя нормально пройти по ответу бота, выбрать часть текста и, что хуже, доступно ввести вопрос в поле ввода.
⠀
На iOS фокус иногда попадает не на ту кнопку: например, вместо меню можно оказаться на Back и случайно закрыть чат. На Windows при открытии и после ответа диктор уходит в заголовки или даже начинает читать страницу за чатботом, а новое сообщение не объявляется.
⠀
Для пользователя это не косметика. Чат помощи обещает ответить на вопрос, но человек с экранным диктором может не добраться до поля ввода, не услышать новый ответ или потерять фокус внутри окна.
⠀
Я бы здесь проверял не «есть ли aria-label», а весь разговорный путь: фокус при открытии чата, отдельные элементы сообщения, доступное поле ввода, объявление новых ответов, удержание фокуса внутри чата и безопасное закрытие без случайного Back.
⠀
Источник: digitalfabrik/integreat-app#4223
⠀
В Integreat завели отдельный issue по экранному доступу к Frag Integreat - их чатботу помощи. Проверяли сразу Android, iOS и Windows, и проблема не сводится к одной подписи на кнопке.
⠀
На Android экранный диктор несколько раз произносит «Frag Integreat», а весь блок чата воспринимается как один элемент. Из-за этого нельзя нормально пройти по ответу бота, выбрать часть текста и, что хуже, доступно ввести вопрос в поле ввода.
⠀
На iOS фокус иногда попадает не на ту кнопку: например, вместо меню можно оказаться на Back и случайно закрыть чат. На Windows при открытии и после ответа диктор уходит в заголовки или даже начинает читать страницу за чатботом, а новое сообщение не объявляется.
⠀
Для пользователя это не косметика. Чат помощи обещает ответить на вопрос, но человек с экранным диктором может не добраться до поля ввода, не услышать новый ответ или потерять фокус внутри окна.
⠀
Я бы здесь проверял не «есть ли aria-label», а весь разговорный путь: фокус при открытии чата, отдельные элементы сообщения, доступное поле ввода, объявление новых ответов, удержание фокуса внутри чата и безопасное закрытие без случайного Back.
⠀
Источник: digitalfabrik/integreat-app#4223
GitHub
Accessibility issue with screen reader · Issue #4223 · digitalfabrik/integreat-app
Describe the Problem Android: The screen reader says “Frag Integreat” several times before reading the chatbot content The whole chatbot area is treated as one element instead of separate elements ...
Когда «следующее» сообщение оказывается предыдущим
В Expensify открыли issue про мобильный чат: с TalkBack включённым свайп к следующему элементу ведёт к предыдущему сообщению, а свайп назад - к следующему. То есть разговор читается в перевёрнутом порядке.
Это не просто «неудобная навигация». В чате порядок сообщений несёт смысл: кто на что ответил, где началась новая мысль, что было до действия, а что после. Если экранный диктор ведёт пользователя в обратную сторону, человек может понять диалог неправильно или постоянно держать в голове обходной приём: использовать жесты наоборот.
Причина завязана на список сообщений и порядок элементов в FlashList. Визуально такой чат может выглядеть нормально: новые сообщения снизу, прокрутка работает, кнопки на месте. Но для TalkBack и VoiceOver важен не внешний вид списка, а программный порядок фокуса и чтения.
Командам стоит проверять не только «можно ли дойти до сообщения», а как читается весь разговор. Откройте чат с несколькими сообщениями, включите TalkBack или VoiceOver и пройдите его обычными жестами вперёд-назад. Если «следующее» и «предыдущее» меняются местами, это уже сломанная последовательность, даже если интерфейс визуально кажется правильным.
Источник: Expensify/App#94165
В Expensify открыли issue про мобильный чат: с TalkBack включённым свайп к следующему элементу ведёт к предыдущему сообщению, а свайп назад - к следующему. То есть разговор читается в перевёрнутом порядке.
Это не просто «неудобная навигация». В чате порядок сообщений несёт смысл: кто на что ответил, где началась новая мысль, что было до действия, а что после. Если экранный диктор ведёт пользователя в обратную сторону, человек может понять диалог неправильно или постоянно держать в голове обходной приём: использовать жесты наоборот.
Причина завязана на список сообщений и порядок элементов в FlashList. Визуально такой чат может выглядеть нормально: новые сообщения снизу, прокрутка работает, кнопки на месте. Но для TalkBack и VoiceOver важен не внешний вид списка, а программный порядок фокуса и чтения.
Командам стоит проверять не только «можно ли дойти до сообщения», а как читается весь разговор. Откройте чат с несколькими сообщениями, включите TalkBack или VoiceOver и пройдите его обычными жестами вперёд-назад. Если «следующее» и «предыдущее» меняются местами, это уже сломанная последовательность, даже если интерфейс визуально кажется правильным.
Источник: Expensify/App#94165
GitHub
FlashList accessibility confusing order Native · Issue #94165 · Expensify/App
If you haven’t already, check out our contributing guidelines for onboarding. To join our Slack channel, fill out this form. Action Performed: Open Android build Open some chat with messages Turn o...
Открытый список - ещё не закрытый сценарий
⠀
Свежий issue в Forui: FSelect открыт, пользователь идёт по вариантам через TalkBack, доходит до конца - и следующий свайп уводит фокус на поле под списком. Поповер при этом остаётся открытым.
⠀
Вывод для команд: у выпадающих списков, меню и поповеров нужно проверять не только названия пунктов, а границу слоя. Пока слой открыт, TalkBack/VoiceOver не должны тихо проваливаться на страницу за ним.
⠀
Источник
⠀
Свежий issue в Forui: FSelect открыт, пользователь идёт по вариантам через TalkBack, доходит до конца - и следующий свайп уводит фокус на поле под списком. Поповер при этом остаётся открытым.
⠀
Вывод для команд: у выпадающих списков, меню и поповеров нужно проверять не только названия пунктов, а границу слоя. Пока слой открыт, TalkBack/VoiceOver не должны тихо проваливаться на страницу за ним.
⠀
Источник
Открытый список - ещё не закрытый сценарий
⠀
В Forui завели свежий issue про FSelect в Flutter. Сигнал конкретный: пользователь открывает выпадающий список, идёт по вариантам через TalkBack, доходит до последнего пункта - и следующий свайп уводит фокус на поле под списком. Сам список при этом остаётся открытым.
⠀
Визуально это может выглядеть нормально: поповер открыт, варианты на экране, рядом есть затемнение или барьер. Но для пользователя с экранным доступом граница слоя не сработала. Он уже оказался на странице под открытым списком и не может спокойно понять, где сейчас находится и к какому состоянию относятся действия.
⠀
Интересная деталь: поведение зависит от геометрии. Более широкий список слева после последнего пункта попадает на барьер, а узкий список справа перескакивает к следующему полю. То есть порядок чтения определяется не рабочим сценарием, а расположением элементов на экране.
⠀
Мейнтейнер Forui ответил, что это упирается в ограничение Flutter OverlayPortal: один FocusScope удерживает клавиатурный фокус, но сам по себе не удерживает линейную навигацию TalkBack/VoiceOver. Для экранного доступа нужно отдельно проверять, что фоновые узлы убраны из дерева или слой действительно ведёт себя как отдельный маршрут.
⠀
Проверка для команд простая: откройте select, меню, поповер или похожий слой с включённым TalkBack/VoiceOver и пройдите его свайпами до конца. Фокус не должен тихо уходить на страницу под слоем. Если уходит - у вас сломан не “лейбл”, а граница сценария.
⠀
В Forui завели свежий issue про FSelect в Flutter. Сигнал конкретный: пользователь открывает выпадающий список, идёт по вариантам через TalkBack, доходит до последнего пункта - и следующий свайп уводит фокус на поле под списком. Сам список при этом остаётся открытым.
⠀
Визуально это может выглядеть нормально: поповер открыт, варианты на экране, рядом есть затемнение или барьер. Но для пользователя с экранным доступом граница слоя не сработала. Он уже оказался на странице под открытым списком и не может спокойно понять, где сейчас находится и к какому состоянию относятся действия.
⠀
Интересная деталь: поведение зависит от геометрии. Более широкий список слева после последнего пункта попадает на барьер, а узкий список справа перескакивает к следующему полю. То есть порядок чтения определяется не рабочим сценарием, а расположением элементов на экране.
⠀
Мейнтейнер Forui ответил, что это упирается в ограничение Flutter OverlayPortal: один FocusScope удерживает клавиатурный фокус, но сам по себе не удерживает линейную навигацию TalkBack/VoiceOver. Для экранного доступа нужно отдельно проверять, что фоновые узлы убраны из дерева или слой действительно ведёт себя как отдельный маршрут.
⠀
Проверка для команд простая: откройте select, меню, поповер или похожий слой с включённым TalkBack/VoiceOver и пройдите его свайпами до конца. Фокус не должен тихо уходить на страницу под слоем. Если уходит - у вас сломан не “лейбл”, а граница сценария.
GitHub
FSelect popover does not contain screen reader (TalkBack/VoiceOver) focus; swipe navigation escapes to the page · Issue #1088 ·…
Summary When an FSelect popover is open, screen-reader linear (swipe) navigation is not contained within the popover. After reaching the last item, focus escapes to the next widget on the underlyin...
NVDA слышит «Data grid» - и на этом работа с субтитрами заканчивается
⠀
В Subtitle Edit v5.1.0-beta5 пользователь с NVDA описал редкий честный момент: часть доступности уже поправили, меню и многие подписи стали лучше. Но главный рабочий путь всё ещё ломается в месте, которое на вид может казаться обычной таблицей.
⠀
В окне горячих клавиш и других местах NVDA произносит только «Data grid». Дальше нельзя понять строки, выбранный пункт, текущую комбинацию клавиш или назначить новую. В обсуждении пользователь прямо пишет: из-за недоступной таблицы он не может даже проверить, какие клавиши отвечают за вставку субтитра и переход к полю редактирования.
⠀
Похожая проблема с выпадающими списками и числовыми полями: значение меняется визуально, но NVDA не произносит новое значение сразу. Для зрячего это мелкая шероховатость. Для человека с экранным доступом это состояние «я нажал стрелку, но не знаю, что выбрал».
⠀
Здесь проверка не заканчивается на «у кнопок есть имена». В редакторах, админках и любых сложных инструментах нужно пройти весь рабочий путь с экранным доступом: меню, таблицы, горячие клавиши, поля ввода, изменение значений и возврат фокуса. Если таблица говорит только свою роль, а не содержимое, пользователь не управляет интерфейсом - он угадывает его.
⠀
В Subtitle Edit v5.1.0-beta5 пользователь с NVDA описал редкий честный момент: часть доступности уже поправили, меню и многие подписи стали лучше. Но главный рабочий путь всё ещё ломается в месте, которое на вид может казаться обычной таблицей.
⠀
В окне горячих клавиш и других местах NVDA произносит только «Data grid». Дальше нельзя понять строки, выбранный пункт, текущую комбинацию клавиш или назначить новую. В обсуждении пользователь прямо пишет: из-за недоступной таблицы он не может даже проверить, какие клавиши отвечают за вставку субтитра и переход к полю редактирования.
⠀
Похожая проблема с выпадающими списками и числовыми полями: значение меняется визуально, но NVDA не произносит новое значение сразу. Для зрячего это мелкая шероховатость. Для человека с экранным доступом это состояние «я нажал стрелку, но не знаю, что выбрал».
⠀
Здесь проверка не заканчивается на «у кнопок есть имена». В редакторах, админках и любых сложных инструментах нужно пройти весь рабочий путь с экранным доступом: меню, таблицы, горячие клавиши, поля ввода, изменение значений и возврат фокуса. Если таблица говорит только свою роль, а не содержимое, пользователь не управляет интерфейсом - он угадывает его.
GitHub
Accessibility observations in Subtitle Edit v5.1.0-beta5: menu navigation, DataGrid accessibility, remaining unlabeled controls…
I tested Subtitle Edit v5.1.0-beta5 with NVDA and wanted to share a few observations. First, thank you for the accessibility improvements that have already been implemented. The labeling work in th...
VoiceOver не видит выбранные рубрики в WordPress iOS
⠀
В свежем issue по WordPress для iOS пользователь описал простой, но неприятный сценарий: при создании записи он открывает настройки статьи, доходит до рубрик и выбирает, куда отнести текст. Визуально выбранная рубрика есть, но VoiceOver не говорит, выбрана она или нет.
⠀
То есть человек слышит названия вроде «uncategorized», «books», «movies», но не получает состояния: какая рубрика уже выбрана, а какая нет. Для зрячего пользователя это мелкая отметка в списке. Для пользователя VoiceOver это риск опубликовать материал не туда или долго перепроверять действие вслепую.
⠀
Автор issue отдельно пишет важную вещь: не надо просто дописывать слова selected / unselected в текстовые метки. Правильнее сделать элемент нормальным переключателем или чекбоксом, чтобы состояние отдавалось через доступность как состояние элемента, а не как костыль в названии.
⠀
Для команд вывод простой: в списках выбора мало проверить, что пункт читается. Нужно пройти весь путь с экранным доступом и проверить имя, роль, значение и состояние: выбран / не выбран, отмечен / не отмечен. Особенно там, где ошибка меняет результат публикации, заказа, платежа или настройки.
⠀
Источник: wordpress-mobile/WordPress-iOS#25737
⠀
В свежем issue по WordPress для iOS пользователь описал простой, но неприятный сценарий: при создании записи он открывает настройки статьи, доходит до рубрик и выбирает, куда отнести текст. Визуально выбранная рубрика есть, но VoiceOver не говорит, выбрана она или нет.
⠀
То есть человек слышит названия вроде «uncategorized», «books», «movies», но не получает состояния: какая рубрика уже выбрана, а какая нет. Для зрячего пользователя это мелкая отметка в списке. Для пользователя VoiceOver это риск опубликовать материал не туда или долго перепроверять действие вслепую.
⠀
Автор issue отдельно пишет важную вещь: не надо просто дописывать слова selected / unselected в текстовые метки. Правильнее сделать элемент нормальным переключателем или чекбоксом, чтобы состояние отдавалось через доступность как состояние элемента, а не как костыль в названии.
⠀
Для команд вывод простой: в списках выбора мало проверить, что пункт читается. Нужно пройти весь путь с экранным доступом и проверить имя, роль, значение и состояние: выбран / не выбран, отмечен / не отмечен. Особенно там, где ошибка меняет результат публикации, заказа, платежа или настройки.
⠀
Источник: wordpress-mobile/WordPress-iOS#25737
GitHub
[ACCESSIBILITY] VoiceOver doesn't detect selected categories · Issue #25737 · wordpress-mobile/WordPress-iOS
Description Feature: when adjusting settings on an article, from "article settings", in taxonomy section there are categories. The default is selected, let's say "uncategorized&q...
Когда ошибка формы видна, но не слышна
⠀
На этой неделе я выбрал Indico - систему для конференций и событий. Там нашёлся хороший пример не одной «кнопки без подписи», а связанной проблемы в общих интерфейсных паттернах.
⠀
В формах ошибка могла подсвечиваться цветом и всплывающей подсказкой, но само поле не получало нормальной связи с текстом ошибки. Для зрячего пользователя это заметно. Для пользователя со скринридером поле может звучать почти как обычное, без понятного «что исправить».
⠀
Вторая часть - панели действий в списках. Кнопки вроде удаления, оценки или экспорта визуально отключены, пока ничего не выбрано. Но если такое состояние не отражено программно, клавиатура и скринридер могут всё равно приводить человека к нерабочим действиям.
⠀
Я сдела PR, который чинит это на уровне общих механизмов: ошибки связываются с полями через
⠀
Это хороший тест для любой команды: проверять нужно не только «есть ли текст ошибки на экране», а слышит ли пользователь связь между полем, ошибкой и следующим действием.
⠀
Кейс подготовлен с помощью Accessibility Auditor Skill.
⠀
Issue #7624: формы и ошибки
Issue #7625: панели действий
PR: indico/indico#7637
⠀
На этой неделе я выбрал Indico - систему для конференций и событий. Там нашёлся хороший пример не одной «кнопки без подписи», а связанной проблемы в общих интерфейсных паттернах.
⠀
В формах ошибка могла подсвечиваться цветом и всплывающей подсказкой, но само поле не получало нормальной связи с текстом ошибки. Для зрячего пользователя это заметно. Для пользователя со скринридером поле может звучать почти как обычное, без понятного «что исправить».
⠀
Вторая часть - панели действий в списках. Кнопки вроде удаления, оценки или экспорта визуально отключены, пока ничего не выбрано. Но если такое состояние не отражено программно, клавиатура и скринридер могут всё равно приводить человека к нерабочим действиям.
⠀
Я сдела PR, который чинит это на уровне общих механизмов: ошибки связываются с полями через
aria-invalid и aria-describedby, выпадающие меню получают состояние открытия, а действия, зависящие от выбранной строки, уходят из порядка Tab, пока они недоступны.⠀
Это хороший тест для любой команды: проверять нужно не только «есть ли текст ошибки на экране», а слышит ли пользователь связь между полем, ошибкой и следующим действием.
⠀
Кейс подготовлен с помощью Accessibility Auditor Skill.
⠀
Issue #7624: формы и ошибки
Issue #7625: панели действий
PR: indico/indico#7637
blinddev.xyz
Accessibility Auditor Skill | Blind Dev — Денис Скрипник
AI-agent workflow для быстрого первого слоя accessibility-аудита: сайты, мобильные и десктопные приложения, репозитории и backlog исправлений.
Когда голосовая клавиатура перестаёт быть доступной
⠀
В issue по Dictate Keyboard попал отзыв незрячего пользователя из Google Play: после обновления приложение «больше не доступно» с TalkBack и ещё одной программой экранного доступа, название которой, похоже, исказилось при переводе.
⠀
Здесь важна не сама фраза «не хватает подписей». Dictate Keyboard - это клавиатура для диктовки текста. Если пользователь не может найти микрофон, выбрать язык, запустить запись, проверить результат или воспользоваться плавающей кнопкой, он теряет не украшение интерфейса, а способ ввода.
⠀
В самом issue перечислены вероятные места поломки: кнопки-иконки без
⠀
Для команды вывод простой: после переработки клавиатуры нельзя проверять доступность только на экране настроек. Нужно пройти весь путь с TalkBack: добавить язык, открыть клавиатуру в другом приложении, начать диктовку, остановить запись, прочитать результат, открыть подсказки и закрыть плавающие элементы.
⠀
Особенно у голосовых и AI-интерфейсов доступность держится на мелочах состояния. Кнопка должна быть видимой, называться, фокусироваться, говорить, что сейчас происходит, и не исчезать из маршрута экранного доступа после очередного «красивого» обновления.
⠀
В issue по Dictate Keyboard попал отзыв незрячего пользователя из Google Play: после обновления приложение «больше не доступно» с TalkBack и ещё одной программой экранного доступа, название которой, похоже, исказилось при переводе.
⠀
Здесь важна не сама фраза «не хватает подписей». Dictate Keyboard - это клавиатура для диктовки текста. Если пользователь не может найти микрофон, выбрать язык, запустить запись, проверить результат или воспользоваться плавающей кнопкой, он теряет не украшение интерфейса, а способ ввода.
⠀
В самом issue перечислены вероятные места поломки: кнопки-иконки без
contentDescription, кастомные строки в настройках без роли и семантики, новый Smartbar, плавающая кнопка, диалоги и оверлеи, где фокус TalkBack может теряться или застревать.⠀
Для команды вывод простой: после переработки клавиатуры нельзя проверять доступность только на экране настроек. Нужно пройти весь путь с TalkBack: добавить язык, открыть клавиатуру в другом приложении, начать диктовку, остановить запись, прочитать результат, открыть подсказки и закрыть плавающие элементы.
⠀
Особенно у голосовых и AI-интерфейсов доступность держится на мелочах состояния. Кнопка должна быть видимой, называться, фокусироваться, говорить, что сейчас происходит, и не исчезать из маршрута экранного доступа после очередного «красивого» обновления.
GitHub
Accessibility regression: app not usable with TalkBack / screen readers · Issue #159 · DevEmperor/DictateKeyboard
Summary A blind user reports (via a Play Store review, translated from German) that the app is no longer accessible with screen readers: I would like to ask you to do something, as the app is no lo...
Форма есть, но в неё нельзя попасть
⠀
В BlueBubbles для Windows открыли баг про стартовую настройку клиента. Пользователь с NVDA не может пройти форму подключения к серверу: поля адреса и пароля не попадают в обычный порядок Tab, а если найти их через объектную навигацию NVDA, текст всё равно не вводится.
⠀
Это неприятный тип поломки: интерфейс визуально показывает форму, но для незрячего пользователя она не становится рабочей формой. В итоге человек не просто тратит лишнее время на настройку. Он не может подключить клиент и начать пользоваться приложением вообще.
⠀
В обсуждении появился ещё один похожий сигнал: голосовая диктовка Wispr Flow тоже не может корректно найти поле ввода нового сообщения в BlueBubbles и вставить продиктованный текст. То есть проблема бьёт не только по экранному доступу, но и по связке «диктовка + поле ввода».
⠀
Для команд вывод простой: форму нельзя проверять только глазами и мышью. Минимальный тест для Windows - пройти первичную настройку с клавиатуры и NVDA: Tab до каждого поля, понятное имя поля, настоящий фокус, ввод текста, ошибка, повторная попытка. Если поле видно, но не принимает ввод через доступный фокус, это не форма, а картинка формы.
⠀
Источник: BlueBubblesApp/bluebubbles-app#2965
⠀
В BlueBubbles для Windows открыли баг про стартовую настройку клиента. Пользователь с NVDA не может пройти форму подключения к серверу: поля адреса и пароля не попадают в обычный порядок Tab, а если найти их через объектную навигацию NVDA, текст всё равно не вводится.
⠀
Это неприятный тип поломки: интерфейс визуально показывает форму, но для незрячего пользователя она не становится рабочей формой. В итоге человек не просто тратит лишнее время на настройку. Он не может подключить клиент и начать пользоваться приложением вообще.
⠀
В обсуждении появился ещё один похожий сигнал: голосовая диктовка Wispr Flow тоже не может корректно найти поле ввода нового сообщения в BlueBubbles и вставить продиктованный текст. То есть проблема бьёт не только по экранному доступу, но и по связке «диктовка + поле ввода».
⠀
Для команд вывод простой: форму нельзя проверять только глазами и мышью. Минимальный тест для Windows - пройти первичную настройку с клавиатуры и NVDA: Tab до каждого поля, понятное имя поля, настоящий фокус, ввод текста, ошибка, повторная попытка. Если поле видно, но не принимает ввод через доступный фокус, это не форма, а картинка формы.
⠀
Источник: BlueBubblesApp/bluebubbles-app#2965
GitHub
Windows Client: Form Fields Not Keyboard Accessible with NVDA Screen Reader · Issue #2965 · BlueBubblesApp/bluebubbles-app
Description The Windows desktop client has critical keyboard accessibility issues that prevent blind users from using the application with the NVDA screen reader. Environment Platform: Windows Clie...
DBeaver: настройка «для NVDA» может сломать доступ к таблице
⠀
В открытом баге пользователь описывает странный сценарий: включаешь screen reader type = NVDA, открываешь View data - и редактор данных перестаёт быть доступным.
⠀
Фокус не попадает в таблицу, стрелки не работают, меню не вызывается. Проверять нужно не наличие «режима доступности», а весь рабочий путь после его включения.
⠀
Источник: dbeaver/dbeaver#39720
⠀
В открытом баге пользователь описывает странный сценарий: включаешь screen reader type = NVDA, открываешь View data - и редактор данных перестаёт быть доступным.
⠀
Фокус не попадает в таблицу, стрелки не работают, меню не вызывается. Проверять нужно не наличие «режима доступности», а весь рабочий путь после его включения.
⠀
Источник: dbeaver/dbeaver#39720
Когда настройка «для NVDA» ломает саму таблицу
⠀
В DBeaver открыт баг: пользователь с NVDA включает в настройках интерфейса режим screen reader type = NVDA, открывает таблицу через View data - и редактор данных перестаёт быть доступным.
⠀
По описанию, фокус не попадает в таблицу, стрелки не работают, контекстное меню не вызывается. То есть проблема не в том, что таблица «не очень удобно читается». Пользователь фактически не может обследовать данные и работать с ними через клавиатуру и экранный доступ.
⠀
Важно, что это происходит именно после включения настройки, которая должна помогать NVDA. Автор повторно подтвердил воспроизведение на DBeaver 25.3.0 и позже написал, что проблема всё ещё актуальна на DBeaver 26.0.3 с NVDA 2025.3.3.
⠀
Для интерфейсов тут хороший урок: специальные режимы доступности нельзя считать автоматически полезными. Их нужно проверять как отдельный сценарий.
⠀
Если в продукте есть настройка «NVDA», «экранный диктор», «клавиатурный режим» или любой похожий флажок, тест должен быть очень приземлённым: включили настройку, открыли реальную таблицу, прошли по ячейкам стрелками, вызвали меню, изменили фокус, вернулись назад.
⠀
Иначе может получиться неприятная ловушка: обычный режим ещё как-то работает, а режим, который пользователь включает ради доступности, отрезает ему основной рабочий экран.
⠀
Источник: dbeaver/dbeaver#39720
⠀
В DBeaver открыт баг: пользователь с NVDA включает в настройках интерфейса режим screen reader type = NVDA, открывает таблицу через View data - и редактор данных перестаёт быть доступным.
⠀
По описанию, фокус не попадает в таблицу, стрелки не работают, контекстное меню не вызывается. То есть проблема не в том, что таблица «не очень удобно читается». Пользователь фактически не может обследовать данные и работать с ними через клавиатуру и экранный доступ.
⠀
Важно, что это происходит именно после включения настройки, которая должна помогать NVDA. Автор повторно подтвердил воспроизведение на DBeaver 25.3.0 и позже написал, что проблема всё ещё актуальна на DBeaver 26.0.3 с NVDA 2025.3.3.
⠀
Для интерфейсов тут хороший урок: специальные режимы доступности нельзя считать автоматически полезными. Их нужно проверять как отдельный сценарий.
⠀
Если в продукте есть настройка «NVDA», «экранный диктор», «клавиатурный режим» или любой похожий флажок, тест должен быть очень приземлённым: включили настройку, открыли реальную таблицу, прошли по ячейкам стрелками, вызвали меню, изменили фокус, вернулись назад.
⠀
Иначе может получиться неприятная ловушка: обычный режим ещё как-то работает, а режим, который пользователь включает ради доступности, отрезает ему основной рабочий экран.
⠀
Источник: dbeaver/dbeaver#39720
GitHub
Accessibility: data editor is not accessible for NVDA screen reader if NVDA is selected in the preferences · Issue #39720 · dbeaver/dbeaver
Description With default settings, data editor in the DBEaver is accessible for the NVDA. If I open preferences>ui>accessibility and set screen reader type to NVDA, it stops working. Perhaps,...
GOV.UK: число и подпись должны звучать как одна фраза
⠀
VoiceOver и TalkBack читают текстовый Big number как два отдельных элемента. Визуально это один показатель, на слух - обрывки контекста.
⠀
VoiceOver и TalkBack читают текстовый Big number как два отдельных элемента. Визуально это один показатель, на слух - обрывки контекста.
Когда число и подпись распадаются на два элемента
⠀
В GOV.UK Publishing Components завели свежий issue про компонент Big number. Визуально он показывает одну фразу: например, «82 Open consultations». Но VoiceOver на iOS/macOS и TalkBack на Android читают текстовую версию как два отдельных элемента: сначала «82», потом «Open consultations».
⠀
Для зрячего пользователя это один показатель. Для пользователя экранного доступа это уже два фрагмента интерфейса, между которыми нужно догадаться о связи. В аудите GOV.UK прямо описали риск: человек может услышать «66», затем «Open consultations» и решить, что это разные ссылки или разные элементы, а не одно значение с подписью.
⠀
Интересная деталь: для JAWS и NVDA команда уже нашла отдельное исправление в PR #5458, но для VoiceOver и TalkBack текстовая версия всё ещё ведёт себя иначе. То есть «починили для одного набора экранных читалок» не равно «компонент стал доступным везде».
⠀
Если интерфейс собирает смысл из нескольких визуальных кусков - число, подпись, суффикс, статус, единицы измерения, - его нужно проверять на слух как одну пользовательскую фразу. Не только по HTML и не только в одном экранном доступе.
⠀
Хороший тест простой: закрыть глаза, пройти компонент VoiceOver/TalkBack/NVDA/JAWS и спросить себя: я слышу цельную мысль или набор обрывков, связь между которыми надо восстанавливать самому?
⠀
В GOV.UK Publishing Components завели свежий issue про компонент Big number. Визуально он показывает одну фразу: например, «82 Open consultations». Но VoiceOver на iOS/macOS и TalkBack на Android читают текстовую версию как два отдельных элемента: сначала «82», потом «Open consultations».
⠀
Для зрячего пользователя это один показатель. Для пользователя экранного доступа это уже два фрагмента интерфейса, между которыми нужно догадаться о связи. В аудите GOV.UK прямо описали риск: человек может услышать «66», затем «Open consultations» и решить, что это разные ссылки или разные элементы, а не одно значение с подписью.
⠀
Интересная деталь: для JAWS и NVDA команда уже нашла отдельное исправление в PR #5458, но для VoiceOver и TalkBack текстовая версия всё ещё ведёт себя иначе. То есть «починили для одного набора экранных читалок» не равно «компонент стал доступным везде».
⠀
Если интерфейс собирает смысл из нескольких визуальных кусков - число, подпись, суффикс, статус, единицы измерения, - его нужно проверять на слух как одну пользовательскую фразу. Не только по HTML и не только в одном экранном доступе.
⠀
Хороший тест простой: закрыть глаза, пройти компонент VoiceOver/TalkBack/NVDA/JAWS и спросить себя: я слышу цельную мысль или набор обрывков, связь между которыми надо восстанавливать самому?
GitHub
Big number text-only variant is announced as two separate items by VoiceOver and TalkBack · Issue #5563 · alphagov/govuk_publi…
What iOS and Mac VoiceOver, and Android TalkBack currently read the value (e.g., "82") and the label (e.g., "Open consultations") of the big number component text-only version a...
Кнопка «показать значение» должна говорить, что она уже включена
⠀
В Kibana завели свежий баг по VoiceOver: на странице Synthetics → Settings кнопка View parameter value показывает или скрывает значение параметра, но экранный доступ в обоих состояниях произносит одно и то же: «View parameter value, button».
⠀
Зрячий пользователь видит, что значок глаза поменялся и значение стало видимым или снова скрытым. Пользователь с VoiceOver этого состояния не получает. Он нажал кнопку, а дальше должен угадывать: значение уже открыто, закрыто или действие вообще не сработало.
⠀
В настройках мониторинга это не абстрактная мелочь. Там могут быть параметры окружения, адреса, токены, рабочие значения для проверок. Если интерфейс не сообщает состояние, человек не может уверенно управлять даже простой операцией «показать / скрыть».
⠀
Хорошо, что по issue уже открыт PR: в кнопку добавляют
⠀
Командам стоит отдельно проверять все такие переключатели: показать пароль, скрыть значение, включить фильтр, закрепить, заглушить, раскрыть блок. После активации экранный доступ должен сказать имя кнопки и новое состояние.
⠀
Источник: elastic/kibana#276962, связанный PR: #277162.
⠀
В Kibana завели свежий баг по VoiceOver: на странице Synthetics → Settings кнопка View parameter value показывает или скрывает значение параметра, но экранный доступ в обоих состояниях произносит одно и то же: «View parameter value, button».
⠀
Зрячий пользователь видит, что значок глаза поменялся и значение стало видимым или снова скрытым. Пользователь с VoiceOver этого состояния не получает. Он нажал кнопку, а дальше должен угадывать: значение уже открыто, закрыто или действие вообще не сработало.
⠀
В настройках мониторинга это не абстрактная мелочь. Там могут быть параметры окружения, адреса, токены, рабочие значения для проверок. Если интерфейс не сообщает состояние, человек не может уверенно управлять даже простой операцией «показать / скрыть».
⠀
Хорошо, что по issue уже открыт PR: в кнопку добавляют
aria-pressed, а подпись меняется между «View parameter value» и «Hide parameter value». Для такого действия мало иметь доступное имя кнопки - нужно озвучить состояние после нажатия.⠀
Командам стоит отдельно проверять все такие переключатели: показать пароль, скрыть значение, включить фильтр, закрепить, заглушить, раскрыть блок. После активации экранный доступ должен сказать имя кнопки и новое состояние.
⠀
Источник: elastic/kibana#276962, связанный PR: #277162.
GitHub
[Accessibility] View parameter value: Button does not announce state change when toggled, leaving screen reader users unaware whether…
What is broken? Behavior Details Actual The "View parameter value" button toggles the parameter value between hidden and visible, but VoiceOver announces "View parameter value, butto...