Когда форма ошибается молча
Коротко: новый разбор issue → audit → PR по доступности интерфейса. Полный текст — следующим сообщением.
Channel Public Channel
ВС Всё про доступность интерфейсов
@accessibilityofinterfaces
- Subscribers
- 7
- Photos
- 116
- Videos
- 0
- Links
- 193
Showing posts older than #192 · Back to latest
Older Posts 20 shown
Когда список прокрутился, но экранный доступ молчит
⠀
В Flutter завели свежий issue про iOS и VoiceOver: пользователь делает обычную трёхпальцевую прокрутку в длинном списке, список действительно едет, но VoiceOver не говорит ничего вроде «страница 2 из 5» или «строки 6–10 из 43».
⠀
Для зрячего человека это легко не заметить: контент сдвинулся, значит прокрутка работает. Для незрячего пользователя это другая ситуация. Он сделал жест и не получил ответа, где теперь находится. В ленте, списке сообщений, настройках или аудиоприложении это быстро превращается в обследование вслепую: «я продвинулся? далеко? не перескочил ли нужный блок?»
⠀
Интересная деталь: автор сравнил iOS с Android. TalkBack получает события прокрутки и сам собирает объявление. На iOS строку статуса должен передать сам движок/приложение. В issue прямо указали место в Flutter engine, где для этого до сих пор стоит TODO. Комментарий участника Flutter подтвердил воспроизведение на iPhone: список прокручивается, но позиция не озвучивается.
⠀
Вывод для команд простой: проверять нужно не только «можно ли прокрутить». Нужно пройти реальный жест с VoiceOver/TalkBack и послушать, получает ли человек обратную связь после изменения позиции.
⠀
Если интерфейс меняет состояние молча, пользователь с экранным доступом остаётся без карты. В длинных списках это не косметика, а часть навигации.
⠀
Источник: flutter/flutter#189285
GitHub [iOS][a11y] VoiceOver three-finger scroll never announces scroll status ("Page X of Y") · Issue #189285 · flutter/flutter Steps to reproduce Create any scrollable list (ListView.builder or CustomScrollView + SliverList) with more content than fits one screen. Run on a physical iOS device, enable VoiceOver. Three-finge... ⠀
В Flutter завели свежий issue про iOS и VoiceOver: пользователь делает обычную трёхпальцевую прокрутку в длинном списке, список действительно едет, но VoiceOver не говорит ничего вроде «страница 2 из 5» или «строки 6–10 из 43».
⠀
Для зрячего человека это легко не заметить: контент сдвинулся, значит прокрутка работает. Для незрячего пользователя это другая ситуация. Он сделал жест и не получил ответа, где теперь находится. В ленте, списке сообщений, настройках или аудиоприложении это быстро превращается в обследование вслепую: «я продвинулся? далеко? не перескочил ли нужный блок?»
⠀
Интересная деталь: автор сравнил iOS с Android. TalkBack получает события прокрутки и сам собирает объявление. На iOS строку статуса должен передать сам движок/приложение. В issue прямо указали место в Flutter engine, где для этого до сих пор стоит TODO. Комментарий участника Flutter подтвердил воспроизведение на iPhone: список прокручивается, но позиция не озвучивается.
⠀
Вывод для команд простой: проверять нужно не только «можно ли прокрутить». Нужно пройти реальный жест с VoiceOver/TalkBack и послушать, получает ли человек обратную связь после изменения позиции.
⠀
Если интерфейс меняет состояние молча, пользователь с экранным доступом остаётся без карты. В длинных списках это не косметика, а часть навигации.
⠀
Источник: flutter/flutter#189285
Меню видно, но экранный доступ его не открывает
⠀
В WordPress-теме Neve завели issue про выпадающее меню: пункт с подменю до него доходит, NVDA или TalkBack его озвучивает, но активация через экранный доступ может не раскрывать список. Мышью и обычной клавиатурой путь при этом выглядит рабочим.
⠀
По описанию, проблема не в одном пропущенном ярлыке. В desktop-варианте submenu control сделан как
⠀
Это неприятный класс багов: интерфейс вроде бы «доступен», потому что элемент фокусируется и называется, но настоящая задача не выполняется. Для незрячего пользователя это значит простое: часть навигации сайта закрыта, хотя визуально она есть.
⠀
Что проверять командам: не только Tab и Enter в браузере, а активацию через NVDA/JAWS/TalkBack/VoiceOver. Если это меню, кнопка раскрытия должна быть настоящей кнопкой или вести себя как она: один общий механизм открытия, корректное
GitHub Submenu toggle does not open through screen-reader activation · Issue #4539 · Codeinwp/neve Summary Dropdown submenu toggles can be reached and announced by screen readers, but activating them may not open the submenu even though mouse and physical-keyboard interaction works. Expected beh... ⠀
В WordPress-теме Neve завели issue про выпадающее меню: пункт с подменю до него доходит, NVDA или TalkBack его озвучивает, но активация через экранный доступ может не раскрывать список. Мышью и обычной клавиатурой путь при этом выглядит рабочим.
⠀
По описанию, проблема не в одном пропущенном ярлыке. В desktop-варианте submenu control сделан как
div role="button", обработчик клавиатуры слушает только Enter, click- и keyboard-состояния живут раздельно, а состояние раскрытия не отдано как aria-expanded. В итоге пользователь слышит контрол, нажимает его своим способом, но дочерние ссылки меню так и не становятся доступным маршрутом.⠀
Это неприятный класс багов: интерфейс вроде бы «доступен», потому что элемент фокусируется и называется, но настоящая задача не выполняется. Для незрячего пользователя это значит простое: часть навигации сайта закрыта, хотя визуально она есть.
⠀
Что проверять командам: не только Tab и Enter в браузере, а активацию через NVDA/JAWS/TalkBack/VoiceOver. Если это меню, кнопка раскрытия должна быть настоящей кнопкой или вести себя как она: один общий механизм открытия, корректное
aria-expanded, дочерние пункты доступны после открытия, состояние синхронизировано для мыши, клавиатуры и экранного доступа.Кнопка «показать значение» должна говорить, что она уже включена
⠀
В Kibana завели свежий баг по VoiceOver: на странице Synthetics → Settings кнопка View parameter value показывает или скрывает значение параметра, но экранный доступ в обоих состояниях произносит одно и то же: «View parameter value, button».
⠀
Зрячий пользователь видит, что значок глаза поменялся и значение стало видимым или снова скрытым. Пользователь с VoiceOver этого состояния не получает. Он нажал кнопку, а дальше должен угадывать: значение уже открыто, закрыто или действие вообще не сработало.
⠀
В настройках мониторинга это не абстрактная мелочь. Там могут быть параметры окружения, адреса, токены, рабочие значения для проверок. Если интерфейс не сообщает состояние, человек не может уверенно управлять даже простой операцией «показать / скрыть».
⠀
Хорошо, что по issue уже открыт PR: в кнопку добавляют
⠀
Командам стоит отдельно проверять все такие переключатели: показать пароль, скрыть значение, включить фильтр, закрепить, заглушить, раскрыть блок. После активации экранный доступ должен сказать имя кнопки и новое состояние.
⠀
Источник: 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... ⠀
В 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.
Kibana: кнопка показывает значение, но VoiceOver не слышит состояние
⠀
Свежий кейс про простую кнопку «показать / скрыть»: важно озвучивать не только имя действия, но и состояние после нажатия.
⠀
Свежий кейс про простую кнопку «показать / скрыть»: важно озвучивать не только имя действия, но и состояние после нажатия.
Когда число и подпись распадаются на два элемента
⠀
В 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... ⠀
В 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: число и подпись должны звучать как одна фраза
⠀
VoiceOver и TalkBack читают текстовый Big number как два отдельных элемента. Визуально это один показатель, на слух - обрывки контекста.
⠀
VoiceOver и TalkBack читают текстовый Big number как два отдельных элемента. Визуально это один показатель, на слух - обрывки контекста.
Когда настройка «для 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
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,... ⠀
В 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 - и редактор данных перестаёт быть доступным.
⠀
Фокус не попадает в таблицу, стрелки не работают, меню не вызывается. Проверять нужно не наличие «режима доступности», а весь рабочий путь после его включения.
⠀
Источник: dbeaver/dbeaver#39720
⠀
В открытом баге пользователь описывает странный сценарий: включаешь screen reader type = NVDA, открываешь View data - и редактор данных перестаёт быть доступным.
⠀
Фокус не попадает в таблицу, стрелки не работают, меню не вызывается. Проверять нужно не наличие «режима доступности», а весь рабочий путь после его включения.
⠀
Источник: dbeaver/dbeaver#39720
Форма есть, но в неё нельзя попасть
⠀
В 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... ⠀
В BlueBubbles для Windows открыли баг про стартовую настройку клиента. Пользователь с NVDA не может пройти форму подключения к серверу: поля адреса и пароля не попадают в обычный порядок Tab, а если найти их через объектную навигацию NVDA, текст всё равно не вводится.
⠀
Это неприятный тип поломки: интерфейс визуально показывает форму, но для незрячего пользователя она не становится рабочей формой. В итоге человек не просто тратит лишнее время на настройку. Он не может подключить клиент и начать пользоваться приложением вообще.
⠀
В обсуждении появился ещё один похожий сигнал: голосовая диктовка Wispr Flow тоже не может корректно найти поле ввода нового сообщения в BlueBubbles и вставить продиктованный текст. То есть проблема бьёт не только по экранному доступу, но и по связке «диктовка + поле ввода».
⠀
Для команд вывод простой: форму нельзя проверять только глазами и мышью. Минимальный тест для Windows - пройти первичную настройку с клавиатуры и NVDA: Tab до каждого поля, понятное имя поля, настоящий фокус, ввод текста, ошибка, повторная попытка. Если поле видно, но не принимает ввод через доступный фокус, это не форма, а картинка формы.
⠀
Источник: BlueBubblesApp/bluebubbles-app#2965
Когда голосовая клавиатура перестаёт быть доступной
⠀
В issue по Dictate Keyboard попал отзыв незрячего пользователя из Google Play: после обновления приложение «больше не доступно» с TalkBack и ещё одной программой экранного доступа, название которой, похоже, исказилось при переводе.
⠀
Здесь важна не сама фраза «не хватает подписей». Dictate Keyboard - это клавиатура для диктовки текста. Если пользователь не может найти микрофон, выбрать язык, запустить запись, проверить результат или воспользоваться плавающей кнопкой, он теряет не украшение интерфейса, а способ ввода.
⠀
В самом issue перечислены вероятные места поломки: кнопки-иконки без
⠀
Для команды вывод простой: после переработки клавиатуры нельзя проверять доступность только на экране настроек. Нужно пройти весь путь с 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... ⠀
В issue по Dictate Keyboard попал отзыв незрячего пользователя из Google Play: после обновления приложение «больше не доступно» с TalkBack и ещё одной программой экранного доступа, название которой, похоже, исказилось при переводе.
⠀
Здесь важна не сама фраза «не хватает подписей». Dictate Keyboard - это клавиатура для диктовки текста. Если пользователь не может найти микрофон, выбрать язык, запустить запись, проверить результат или воспользоваться плавающей кнопкой, он теряет не украшение интерфейса, а способ ввода.
⠀
В самом issue перечислены вероятные места поломки: кнопки-иконки без
contentDescription, кастомные строки в настройках без роли и семантики, новый Smartbar, плавающая кнопка, диалоги и оверлеи, где фокус TalkBack может теряться или застревать.⠀
Для команды вывод простой: после переработки клавиатуры нельзя проверять доступность только на экране настроек. Нужно пройти весь путь с TalkBack: добавить язык, открыть клавиатуру в другом приложении, начать диктовку, остановить запись, прочитать результат, открыть подсказки и закрыть плавающие элементы.
⠀
Особенно у голосовых и AI-интерфейсов доступность держится на мелочах состояния. Кнопка должна быть видимой, называться, фокусироваться, говорить, что сейчас происходит, и не исчезать из маршрута экранного доступа после очередного «красивого» обновления.
Когда ошибка формы видна, но не слышна
⠀
На этой неделе я выбрал 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
Когда ошибка формы видна, но не слышна
Коротко: новый разбор issue → audit → PR по доступности интерфейса. Полный текст — следующим сообщением.
Коротко: новый разбор issue → audit → PR по доступности интерфейса. Полный текст — следующим сообщением.
VoiceOver не видит выбранные рубрики в WordPress iOS
⠀
В свежем 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... ⠀
В свежем issue по WordPress для iOS пользователь описал простой, но неприятный сценарий: при создании записи он открывает настройки статьи, доходит до рубрик и выбирает, куда отнести текст. Визуально выбранная рубрика есть, но VoiceOver не говорит, выбрана она или нет.
⠀
То есть человек слышит названия вроде «uncategorized», «books», «movies», но не получает состояния: какая рубрика уже выбрана, а какая нет. Для зрячего пользователя это мелкая отметка в списке. Для пользователя VoiceOver это риск опубликовать материал не туда или долго перепроверять действие вслепую.
⠀
Автор issue отдельно пишет важную вещь: не надо просто дописывать слова selected / unselected в текстовые метки. Правильнее сделать элемент нормальным переключателем или чекбоксом, чтобы состояние отдавалось через доступность как состояние элемента, а не как костыль в названии.
⠀
Для команд вывод простой: в списках выбора мало проверить, что пункт читается. Нужно пройти весь путь с экранным доступом и проверить имя, роль, значение и состояние: выбран / не выбран, отмечен / не отмечен. Особенно там, где ошибка меняет результат публикации, заказа, платежа или настройки.
⠀
Источник: wordpress-mobile/WordPress-iOS#25737
NVDA слышит «Data grid» - и на этом работа с субтитрами заканчивается
⠀
В 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... ⠀
В Subtitle Edit v5.1.0-beta5 пользователь с NVDA описал редкий честный момент: часть доступности уже поправили, меню и многие подписи стали лучше. Но главный рабочий путь всё ещё ломается в месте, которое на вид может казаться обычной таблицей.
⠀
В окне горячих клавиш и других местах NVDA произносит только «Data grid». Дальше нельзя понять строки, выбранный пункт, текущую комбинацию клавиш или назначить новую. В обсуждении пользователь прямо пишет: из-за недоступной таблицы он не может даже проверить, какие клавиши отвечают за вставку субтитра и переход к полю редактирования.
⠀
Похожая проблема с выпадающими списками и числовыми полями: значение меняется визуально, но NVDA не произносит новое значение сразу. Для зрячего это мелкая шероховатость. Для человека с экранным доступом это состояние «я нажал стрелку, но не знаю, что выбрал».
⠀
Здесь проверка не заканчивается на «у кнопок есть имена». В редакторах, админках и любых сложных инструментах нужно пройти весь рабочий путь с экранным доступом: меню, таблицы, горячие клавиши, поля ввода, изменение значений и возврат фокуса. Если таблица говорит только свою роль, а не содержимое, пользователь не управляет интерфейсом - он угадывает его.
Открытый список - ещё не закрытый сценарий
⠀
В 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... ⠀
В Forui завели свежий issue про FSelect в Flutter. Сигнал конкретный: пользователь открывает выпадающий список, идёт по вариантам через TalkBack, доходит до последнего пункта - и следующий свайп уводит фокус на поле под списком. Сам список при этом остаётся открытым.
⠀
Визуально это может выглядеть нормально: поповер открыт, варианты на экране, рядом есть затемнение или барьер. Но для пользователя с экранным доступом граница слоя не сработала. Он уже оказался на странице под открытым списком и не может спокойно понять, где сейчас находится и к какому состоянию относятся действия.
⠀
Интересная деталь: поведение зависит от геометрии. Более широкий список слева после последнего пункта попадает на барьер, а узкий список справа перескакивает к следующему полю. То есть порядок чтения определяется не рабочим сценарием, а расположением элементов на экране.
⠀
Мейнтейнер Forui ответил, что это упирается в ограничение Flutter OverlayPortal: один FocusScope удерживает клавиатурный фокус, но сам по себе не удерживает линейную навигацию TalkBack/VoiceOver. Для экранного доступа нужно отдельно проверять, что фоновые узлы убраны из дерева или слой действительно ведёт себя как отдельный маршрут.
⠀
Проверка для команд простая: откройте select, меню, поповер или похожий слой с включённым TalkBack/VoiceOver и пройдите его свайпами до конца. Фокус не должен тихо уходить на страницу под слоем. Если уходит - у вас сломан не “лейбл”, а граница сценария.
Открытый список - ещё не закрытый сценарий
⠀
Свежий issue в Forui: FSelect открыт, пользователь идёт по вариантам через TalkBack, доходит до конца - и следующий свайп уводит фокус на поле под списком. Поповер при этом остаётся открытым.
⠀
Вывод для команд: у выпадающих списков, меню и поповеров нужно проверять не только названия пунктов, а границу слоя. Пока слой открыт, TalkBack/VoiceOver не должны тихо проваливаться на страницу за ним.
⠀
Источник
⠀
Свежий issue в Forui: FSelect открыт, пользователь идёт по вариантам через TalkBack, доходит до конца - и следующий свайп уводит фокус на поле под списком. Поповер при этом остаётся открытым.
⠀
Вывод для команд: у выпадающих списков, меню и поповеров нужно проверять не только названия пунктов, а границу слоя. Пока слой открыт, TalkBack/VoiceOver не должны тихо проваливаться на страницу за ним.
⠀
Источник
Когда «следующее» сообщение оказывается предыдущим
В 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... В Expensify открыли issue про мобильный чат: с TalkBack включённым свайп к следующему элементу ведёт к предыдущему сообщению, а свайп назад - к следующему. То есть разговор читается в перевёрнутом порядке.
Это не просто «неудобная навигация». В чате порядок сообщений несёт смысл: кто на что ответил, где началась новая мысль, что было до действия, а что после. Если экранный диктор ведёт пользователя в обратную сторону, человек может понять диалог неправильно или постоянно держать в голове обходной приём: использовать жесты наоборот.
Причина завязана на список сообщений и порядок элементов в FlashList. Визуально такой чат может выглядеть нормально: новые сообщения снизу, прокрутка работает, кнопки на месте. Но для TalkBack и VoiceOver важен не внешний вид списка, а программный порядок фокуса и чтения.
Командам стоит проверять не только «можно ли дойти до сообщения», а как читается весь разговор. Откройте чат с несколькими сообщениями, включите TalkBack или VoiceOver и пройдите его обычными жестами вперёд-назад. Если «следующее» и «предыдущее» меняются местами, это уже сломанная последовательность, даже если интерфейс визуально кажется правильным.
Источник: Expensify/App#94165
Чатбот есть, а поговорить с ним нельзя
⠀
В 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 ... ⠀
В Integreat завели отдельный issue по экранному доступу к Frag Integreat - их чатботу помощи. Проверяли сразу Android, iOS и Windows, и проблема не сводится к одной подписи на кнопке.
⠀
На Android экранный диктор несколько раз произносит «Frag Integreat», а весь блок чата воспринимается как один элемент. Из-за этого нельзя нормально пройти по ответу бота, выбрать часть текста и, что хуже, доступно ввести вопрос в поле ввода.
⠀
На iOS фокус иногда попадает не на ту кнопку: например, вместо меню можно оказаться на Back и случайно закрыть чат. На Windows при открытии и после ответа диктор уходит в заголовки или даже начинает читать страницу за чатботом, а новое сообщение не объявляется.
⠀
Для пользователя это не косметика. Чат помощи обещает ответить на вопрос, но человек с экранным диктором может не добраться до поля ввода, не услышать новый ответ или потерять фокус внутри окна.
⠀
Я бы здесь проверял не «есть ли aria-label», а весь разговорный путь: фокус при открытии чата, отдельные элементы сообщения, доступное поле ввода, объявление новых ответов, удержание фокуса внутри чата и безопасное закрытие без случайного Back.
⠀
Источник: digitalfabrik/integreat-app#4223
Чатбот есть, а поговорить с ним нельзя
⠀
В issue по Frag Integreat проверяли чатбот сразу на Android, iOS и Windows. Для экранного диктора он местами превращается в один большой блок: нельзя пройти по ответу, нормально попасть в поле ввода, услышать новый ответ или удержать фокус внутри чата.
⠀
Проверять нужно весь разговор: открытие, поле вопроса, сообщения, объявление новых ответов, фокус и безопасное закрытие.
⠀
Источник: digitalfabrik/integreat-app#4223
⠀
В issue по Frag Integreat проверяли чатбот сразу на Android, iOS и Windows. Для экранного диктора он местами превращается в один большой блок: нельзя пройти по ответу, нормально попасть в поле ввода, услышать новый ответ или удержать фокус внутри чата.
⠀
Проверять нужно весь разговор: открытие, поле вопроса, сообщения, объявление новых ответов, фокус и безопасное закрытие.
⠀
Источник: digitalfabrik/integreat-app#4223