Когда брайлевская строка отстаёт от фокуса
⠀
В MuseScore Studio открыли свежую задачу по доступности: в версии 4.7 на Windows с NVDA навигация по партитуре и брайлевская панель не всегда показывают один и тот же элемент.
⠀
Сценарий не экзотический. Пользователь идёт по нотам и элементам через Alt+стрелки: динамика, артикуляция, аппликатура, орнаменты, текст. Ноты, динамика и lyrics, по отчёту, чаще работают нормально. А на артикуляции, аппликатуре и части других символов брайлевский фокус может уехать на связанную ноту или вообще остаться на строке lyrics.
⠀
Для зрячего человека это может выглядеть как мелкая рассинхронизация. Для незрячего музыканта это уже ломает проверку партитуры: ты думаешь, что стоишь на конкретном знаке, а брайлевская строка показывает соседний или родительский объект. Исправлять такую нотацию вслепую становится рискованно.
⠀
Мне здесь нравится сам урок для интерфейсов: доступность - это не только “элемент озвучился”. Если в продукте есть две синхронные модели - визуальная область, дерево объектов, брайлевская строка, панель свойств - фокус должен быть точным между ними. Иначе пользователь получает не интерфейс, а угадайку.
⠀
Источник: MuseScore Studio issue #33606
⠀
В MuseScore Studio открыли свежую задачу по доступности: в версии 4.7 на Windows с NVDA навигация по партитуре и брайлевская панель не всегда показывают один и тот же элемент.
⠀
Сценарий не экзотический. Пользователь идёт по нотам и элементам через Alt+стрелки: динамика, артикуляция, аппликатура, орнаменты, текст. Ноты, динамика и lyrics, по отчёту, чаще работают нормально. А на артикуляции, аппликатуре и части других символов брайлевский фокус может уехать на связанную ноту или вообще остаться на строке lyrics.
⠀
Для зрячего человека это может выглядеть как мелкая рассинхронизация. Для незрячего музыканта это уже ломает проверку партитуры: ты думаешь, что стоишь на конкретном знаке, а брайлевская строка показывает соседний или родительский объект. Исправлять такую нотацию вслепую становится рискованно.
⠀
Мне здесь нравится сам урок для интерфейсов: доступность - это не только “элемент озвучился”. Если в продукте есть две синхронные модели - визуальная область, дерево объектов, брайлевская строка, панель свойств - фокус должен быть точным между ними. Иначе пользователь получает не интерфейс, а угадайку.
⠀
Источник: MuseScore Studio issue #33606
GitHub
Braille and Score Navigation do not sync to each element · Issue #33606 · musescore/MuseScore
Issue type Accessibility issue (e.g. for keyboard-only or screen reader users) Description with steps to reproduce When you navigate to an articulation, fingering and various other elements on Brai...
Доступность в формах: ошибка должна быть услышана
Было: форма регистрации показывала ошибки и успешный результат визуально.
Что мешало пользователю: если человек работает со screen reader, новое сообщение могло появиться на экране, но не прозвучать автоматически. В итоге приходилось вручную искать, что изменилось и почему форма не отправилась.
Что изменили: добавили семантику для сообщений формы:
— ошибки полей и серверные ошибки теперь объявляются как alert;
— успешное завершение объявляется как status;
— добавили тесты, чтобы это поведение не потерялось.
Стало: обратная связь формы стала доступнее для незрячих пользователей — ошибка или успех доходят не только глазами, но и через assistive technology.
Инструмент, который помогает находить такие кейсы и готовить аккуратные PR: Accessibility Auditor Skill.
Proof:
Issue: https://github.com/mattstratton/conducky/issues/254
PR: https://github.com/mattstratton/conducky/pull/459
Было: форма регистрации показывала ошибки и успешный результат визуально.
Что мешало пользователю: если человек работает со screen reader, новое сообщение могло появиться на экране, но не прозвучать автоматически. В итоге приходилось вручную искать, что изменилось и почему форма не отправилась.
Что изменили: добавили семантику для сообщений формы:
— ошибки полей и серверные ошибки теперь объявляются как alert;
— успешное завершение объявляется как status;
— добавили тесты, чтобы это поведение не потерялось.
Стало: обратная связь формы стала доступнее для незрячих пользователей — ошибка или успех доходят не только глазами, но и через assistive technology.
Инструмент, который помогает находить такие кейсы и готовить аккуратные PR: Accessibility Auditor Skill.
Proof:
Issue: https://github.com/mattstratton/conducky/issues/254
PR: https://github.com/mattstratton/conducky/pull/459
blinddev.xyz
Accessibility Auditor Skill | Blind Dev — Денис Скрипник
AI-agent workflow для быстрого первого слоя accessibility-аудита: сайты, мобильные и десктопные приложения, репозитории и backlog исправлений.
Подсказка есть, но на слух её не разобрать
⠀
В Microsoft Aspire завели свежую задачу по Help-окну в Dashboard: NVDA читает горячие клавиши одной длинной строкой. Пример из issue: “Increase panel size + Decrease panel size - Reset panel sizes shift+r...”
⠀
Визуально это набор отдельных команд. Для пользователя скринридера - каша: где действие, где клавиша, сколько пунктов в списке, непонятно. Ещё и ломается навигация по спискам: например, быстрый переход к списку в JAWS не сработает, если элементов нет внутри нормального списка.
⠀
Причина простая: пункты выглядят как список, но в разметке не оформлены как
⠀
Если интерфейс показывает “набор пунктов”, скринридер тоже должен получить набор пунктов, а не слепленную строку текста.
⠀
Источник: microsoft/aspire#17650
⠀
В Microsoft Aspire завели свежую задачу по Help-окну в Dashboard: NVDA читает горячие клавиши одной длинной строкой. Пример из issue: “Increase panel size + Decrease panel size - Reset panel sizes shift+r...”
⠀
Визуально это набор отдельных команд. Для пользователя скринридера - каша: где действие, где клавиша, сколько пунктов в списке, непонятно. Ещё и ломается навигация по спискам: например, быстрый переход к списку в JAWS не сработает, если элементов нет внутри нормального списка.
⠀
Причина простая: пункты выглядят как список, но в разметке не оформлены как
ul, ol или dl. ARIA-роли тоже могут помочь, но лучше не терять нативную семантику HTML там, где она уже есть.⠀
Если интерфейс показывает “набор пунктов”, скринридер тоже должен получить набор пунктов, а не слепленную строку текста.
⠀
Источник: microsoft/aspire#17650
В модальном окне экспорта документов был маленький, но неприятный accessibility-баг.
Было: внутри выбора формата отдельная кнопка со стрелкой попадала в Tab-навигацию и озвучивалась скринридером как самостоятельный элемент.
Что мешало пользователю: человек проходил по модальному окну с клавиатуры и получал лишнюю остановку фокуса там, где фактически есть один контрол — выбор формата. Это сбивает структуру интерфейса и делает короткий сценарий заметно шумнее.
Что изменили: декоративную кнопку стрелки скрыли от assistive technologies и убрали из порядка Tab-навигации. Сам select остаётся интерактивным, а лишний фокус больше не появляется.
Стало: навигация по модалке короче и понятнее: фокус идёт по реальным действиям, без дублирующей стрелки.
Кейс найден и подготовлен с помощью Accessibility Auditor Skill — инструмента для поиска и упаковки практичных accessibility-улучшений.
Доказательство:
Issue: suitenumerique/docs#2342
PR: suitenumerique/docs#2366
Было: внутри выбора формата отдельная кнопка со стрелкой попадала в Tab-навигацию и озвучивалась скринридером как самостоятельный элемент.
Что мешало пользователю: человек проходил по модальному окну с клавиатуры и получал лишнюю остановку фокуса там, где фактически есть один контрол — выбор формата. Это сбивает структуру интерфейса и делает короткий сценарий заметно шумнее.
Что изменили: декоративную кнопку стрелки скрыли от assistive technologies и убрали из порядка Tab-навигации. Сам select остаётся интерактивным, а лишний фокус больше не появляется.
Стало: навигация по модалке короче и понятнее: фокус идёт по реальным действиям, без дублирующей стрелки.
Кейс найден и подготовлен с помощью Accessibility Auditor Skill — инструмента для поиска и упаковки практичных accessibility-улучшений.
Доказательство:
Issue: suitenumerique/docs#2342
PR: suitenumerique/docs#2366
GitHub
Export modal: combobox arrow button independently focusable · Issue #2342 · suitenumerique/docs
Observed behavior The button containing the down arrow icon inside the format selection dropdown is independently focusable. It receives distinct focus and is announced by screen readers, even thou...
Когда проверка орфографии молчит
⠀
В свежей задаче Community-Access/quill#10 описан неприятный сценарий: включена проверка орфографии «по мере набора», пользователь с NVDA печатает слово с ошибкой, но не слышит ничего.
⠀
В интерфейсе меняется только строка состояния:
⠀
И здесь легко обмануться. Красное подчёркивание или «волнистая линия» не делают ошибку доступной сами по себе. Если пользователь не видит экран, ему нужен явный сигнал: звук, объявление или семантика ошибки.
⠀
Я бы это проверял отдельно: если интерфейс что-то подсвечивает глазами, он должен так же понятно сообщать это ушами или брайлевской строкой. Иначе проверка работает только для части пользователей.
⠀
В свежей задаче Community-Access/quill#10 описан неприятный сценарий: включена проверка орфографии «по мере набора», пользователь с NVDA печатает слово с ошибкой, но не слышит ничего.
⠀
В интерфейсе меняется только строка состояния:
Possible misspelling. Для зрячего пользователя это хоть какой-то след. Для скринридера почти пусто: NVDA обычно не читает такие изменения, а штатный звук ошибки не срабатывает, потому что приложение не помечает фрагмент текста через API доступности.⠀
И здесь легко обмануться. Красное подчёркивание или «волнистая линия» не делают ошибку доступной сами по себе. Если пользователь не видит экран, ему нужен явный сигнал: звук, объявление или семантика ошибки.
⠀
Я бы это проверял отдельно: если интерфейс что-то подсвечивает глазами, он должен так же понятно сообщать это ушами или брайлевской строкой. Иначе проверка работает только для части пользователей.
В WindoM нашёл понятный accessibility-баг: несколько элементов выглядели как кнопки, но в коде были обычными
Что ломалось: фокус дня, обновление цитаты и выбор фото работали мышью, но часть сценариев была недоступна с клавиатуры. Для скринридера такие элементы тоже хуже объясняли свою роль.
Что изменил: фокус и цитату перевёл на настоящие
Стало: те же действия теперь доступны с клавиатуры, элементы получают нормальную семантику, а интерфейс меньше зависит от мыши.
Кейс найден и подготовлен с помощью Accessibility Auditor Skill — инструмента для поиска и упаковки практичных accessibility-улучшений.
Доказательство:
Issue: YehudaBriskman/WindoM#239
PR: YehudaBriskman/WindoM#271
div с onClick.Что ломалось: фокус дня, обновление цитаты и выбор фото работали мышью, но часть сценариев была недоступна с клавиатуры. Для скринридера такие элементы тоже хуже объясняли свою роль.
Что изменил: фокус и цитату перевёл на настоящие
button, для фото добавил keyboard activation через Enter/Space без вложенных кнопок, а переключателю поисковика вернул Tab-доступ и состояние aria-expanded.Стало: те же действия теперь доступны с клавиатуры, элементы получают нормальную семантику, а интерфейс меньше зависит от мыши.
Кейс найден и подготовлен с помощью Accessibility Auditor Skill — инструмента для поиска и упаковки практичных accessibility-улучшений.
Доказательство:
Issue: YehudaBriskman/WindoM#239
PR: YehudaBriskman/WindoM#271
GitHub
a11y: replace non-button divs with accessible button elements · Issue #239 · YehudaBriskman/WindoM
Finding: A11Y-H1 Files: `web/src/components/focus/FocusInput.tsx:72-84` — `` `web/src/components/photos/PhotoGrid.tsx:19` — `<div onClick={() => onSelect(photo)}>` `web/src/components/widg...
Кнопка «закрыть» без контекста
⠀
В VS Code обсуждают не самый заметный, но понятный баг: панель поиска и замены ведёт себя почти как диалог, но для экранного диктора не называется диалогом.
⠀
Из-за этого пользователь NVDA, попадая на кнопку Close (escape), слышит примерно: «main landmark, Close, button». И не понимает из самой кнопки, что именно она закрывает: поиск, редактор, боковую панель или что-то ещё.
⠀
Предложение простое: дать контейнеру роль
⠀
Для интерфейсов здесь хороший тест: если блок визуально выглядит как отдельная панель с несколькими действиями, его надо так же собрать и для экранного диктора. Иначе зрячий пользователь видит контекст глазами, а незрячий вынужден угадывать его по одной кнопке.
⠀
Источник: microsoft/vscode#172861
⠀
В VS Code обсуждают не самый заметный, но понятный баг: панель поиска и замены ведёт себя почти как диалог, но для экранного диктора не называется диалогом.
⠀
Из-за этого пользователь NVDA, попадая на кнопку Close (escape), слышит примерно: «main landmark, Close, button». И не понимает из самой кнопки, что именно она закрывает: поиск, редактор, боковую панель или что-то ещё.
⠀
Предложение простое: дать контейнеру роль
dialog и понятное имя вроде Find / Replace. Тогда кнопка оказывается внутри названной группы, а не висит в воздухе.⠀
Для интерфейсов здесь хороший тест: если блок визуально выглядит как отдельная панель с несколькими действиями, его надо так же собрать и для экранного диктора. Иначе зрячий пользователь видит контекст глазами, а незрячий вынужден угадывать его по одной кнопке.
⠀
Источник: microsoft/vscode#172861
Reddit на iOS поймал неприятный баг с VoiceOver
⠀
Живой сигнал из r/bugs: незрячий пользователь после обновления Reddit до 2026.21.0 перестал читать текст поста в треде. VoiceOver доходил до тела исходного поста и вместо текста говорил только: «swipe up and down for more options».
⠀
Ответы ниже читались нормально. То есть экранный доступ не «сломался везде», а выпал главный кусок сценария: открыть обсуждение и понять, о чём пост.
⠀
Автор проверил с друзьями: на 2026.19.9 проблемы не было, на 2026.21.0 она повторялась. Позже он написал, что в 2026.21.1 баг исправили.
⠀
Визуально экран может выглядеть живым, кнопки и ответы могут работать, но для пользователя с VoiceOver основное содержание исчезло.
⠀
Я бы отсюда забрал тест перед релизом: после обновления пройти главный путь с экранным доступом и проверить саму суть экрана - читается ли пост, форма, чек, инструкция, ошибка.
Источник: r/bugs
⠀
Живой сигнал из r/bugs: незрячий пользователь после обновления Reddit до 2026.21.0 перестал читать текст поста в треде. VoiceOver доходил до тела исходного поста и вместо текста говорил только: «swipe up and down for more options».
⠀
Ответы ниже читались нормально. То есть экранный доступ не «сломался везде», а выпал главный кусок сценария: открыть обсуждение и понять, о чём пост.
⠀
Автор проверил с друзьями: на 2026.19.9 проблемы не было, на 2026.21.0 она повторялась. Позже он написал, что в 2026.21.1 баг исправили.
⠀
Визуально экран может выглядеть живым, кнопки и ответы могут работать, но для пользователя с VoiceOver основное содержание исчезло.
⠀
Я бы отсюда забрал тест перед релизом: после обновления пройти главный путь с экранным доступом и проверить саму суть экрана - читается ли пост, форма, чек, инструкция, ошибка.
Источник: r/bugs
Когда экран «работает», но VoiceOver уже нет
⠀
В r/Blind пользователь после iOS 26.2 описал не косметику, а сломанный рабочий день: VoiceOver лагает, пропускает элементы, не читает часть кнопок и подписей, фокус прыгает в начало экрана. Zoom тоже сбоит: увеличивает не ту область и не всегда следует за фокусом VoiceOver.
⠀
Для зрячего это выглядит как неприятный баг. Для незрячего или слабовидящего пользователя это потеря управления телефоном: сложнее печатать, читать переписку, менять настройки и понимать, где ты сейчас находишься.
⠀
В комментариях добавили отдельный пример: на Reddit VoiceOver доходит до рекламы, сбивается и начинает чтение сначала. Обычный сценарий просто не проходится до конца.
⠀
После обновления нужно проверять основные пути с VoiceOver и Zoom вместе: фокус не прыгает, подписи читаются, жесты не отваливаются, реклама и всплывающие блоки не ломают поток.
⠀
Источник: r/Blind.
⠀
В r/Blind пользователь после iOS 26.2 описал не косметику, а сломанный рабочий день: VoiceOver лагает, пропускает элементы, не читает часть кнопок и подписей, фокус прыгает в начало экрана. Zoom тоже сбоит: увеличивает не ту область и не всегда следует за фокусом VoiceOver.
⠀
Для зрячего это выглядит как неприятный баг. Для незрячего или слабовидящего пользователя это потеря управления телефоном: сложнее печатать, читать переписку, менять настройки и понимать, где ты сейчас находишься.
⠀
В комментариях добавили отдельный пример: на Reddit VoiceOver доходит до рекламы, сбивается и начинает чтение сначала. Обычный сценарий просто не проходится до конца.
⠀
После обновления нужно проверять основные пути с VoiceOver и Zoom вместе: фокус не прыгает, подписи читаются, жесты не отваливаются, реклама и всплывающие блоки не ломают поток.
⠀
Источник: r/Blind.
В поиске видны колонки, но экранный доступ их не читает
⠀
В Zammad открыли баг по новой версии: в списке результатов поиска заголовки колонок визуально есть, но экранная читалка их не озвучивает. В тикете указан Zammad 7.0.1, окружение Openshift, а ожидаемое поведение простое: заголовки должны читаться при работе со списком.
⠀
Для зрячего пользователя это выглядит как небольшая проблема таблицы. Для незрячего или слабовидящего пользователя это ломает саму ориентацию в результатах: слышны значения, но непонятно, к чему они относятся. В интерфейсе поддержки это особенно больно, потому что поиск - рабочий инструмент, а не декоративный экран.
⠀
Хорошая проверка для команд: пройти таблицы и списки не глазами, а экранной читалкой. Если строка читается без понятных заголовков, интерфейс формально показывает данные, но не даёт человеку нормально ими пользоваться.
⠀
Источник: Zammad issue #6164
⠀
В Zammad открыли баг по новой версии: в списке результатов поиска заголовки колонок визуально есть, но экранная читалка их не озвучивает. В тикете указан Zammad 7.0.1, окружение Openshift, а ожидаемое поведение простое: заголовки должны читаться при работе со списком.
⠀
Для зрячего пользователя это выглядит как небольшая проблема таблицы. Для незрячего или слабовидящего пользователя это ломает саму ориентацию в результатах: слышны значения, но непонятно, к чему они относятся. В интерфейсе поддержки это особенно больно, потому что поиск - рабочий инструмент, а не декоративный экран.
⠀
Хорошая проверка для команд: пройти таблицы и списки не глазами, а экранной читалкой. Если строка читается без понятных заголовков, интерфейс формально показывает данные, но не даёт человеку нормально ими пользоваться.
⠀
Источник: Zammad issue #6164
Когда кофемашина становится «тихим металлом»
⠀
В GitHub у приложения Decenza для кофемашин Decent появился хороший, очень живой кейс про доступность. Пользователь с TalkBack написал, что без этого приложения его машина фактически превращается в «кусок тихого металла на столе»: он каждый день готовит через приложение и не может нормально обходить оставшиеся барьеры.
⠀
Сначала обсуждение было про общую проблему кастомного QML-интерфейса: красивые Rectangle, Item и MouseArea выглядят как кнопки, слайдеры и графики, но для экранного доступа они могут быть просто молчаливыми областями. Потом разговор сузился до конкретного бага: поля ввода сразу перехватывают фокус и открывают клавиатуру, не давая TalkBack спокойно прочитать название поля. При наборе и удалении символов тоже нет нормальной звуковой обратной связи.
⠀
Это не косметика. Если незрячий пользователь меняет название зерна, дату обжарки или заметку о шоте, он должен понимать, где находится, что ввёл и удалился ли символ. Без этого интерфейс вроде бы работает, но задача становится угадайкой.
⠀
Для команд здесь простой тест: пройти основной путь с экранным доступом и проверить не только подписи кнопок. Поля ввода не должны открывать клавиатуру до явного действия, слайдеры должны отдавать роль и значение, а живые графики должны иметь короткую текстовую сводку без речевой каши.
⠀
Источник: обсуждение Decenza #1300
⠀
В GitHub у приложения Decenza для кофемашин Decent появился хороший, очень живой кейс про доступность. Пользователь с TalkBack написал, что без этого приложения его машина фактически превращается в «кусок тихого металла на столе»: он каждый день готовит через приложение и не может нормально обходить оставшиеся барьеры.
⠀
Сначала обсуждение было про общую проблему кастомного QML-интерфейса: красивые Rectangle, Item и MouseArea выглядят как кнопки, слайдеры и графики, но для экранного доступа они могут быть просто молчаливыми областями. Потом разговор сузился до конкретного бага: поля ввода сразу перехватывают фокус и открывают клавиатуру, не давая TalkBack спокойно прочитать название поля. При наборе и удалении символов тоже нет нормальной звуковой обратной связи.
⠀
Это не косметика. Если незрячий пользователь меняет название зерна, дату обжарки или заметку о шоте, он должен понимать, где находится, что ввёл и удалился ли символ. Без этого интерфейс вроде бы работает, но задача становится угадайкой.
⠀
Для команд здесь простой тест: пройти основной путь с экранным доступом и проверить не только подписи кнопок. Поля ввода не должны открывать клавиатуру до явного действия, слайдеры должны отдавать роль и значение, а живые графики должны иметь короткую текстовую сводку без речевой каши.
⠀
Источник: обсуждение Decenza #1300
GitHub
Issue · Kulitorum/Decenza
Alternative app for DE1 machines. Contribute to Kulitorum/Decenza development by creating an account on GitHub.
Когда справка есть, но прочитать её нельзя
⠀
Свежий issue по SuperCollider IDE: пользователь экранных читалок проверил NVDA, Orca и Cthulhu и описал, как встроенная справка, Quarks-список, автодополнение и окно вывода становятся почти непроходимыми.
⠀
Главный тест для команды простой: может ли человек с экранной читалкой открыть справку, понять список, вернуться в редактор и продолжить задачу без блокнота как костыля.
⠀
Источник: supercollider#7541
⠀
Свежий issue по SuperCollider IDE: пользователь экранных читалок проверил NVDA, Orca и Cthulhu и описал, как встроенная справка, Quarks-список, автодополнение и окно вывода становятся почти непроходимыми.
⠀
Главный тест для команды простой: может ли человек с экранной читалкой открыть справку, понять список, вернуться в редактор и продолжить задачу без блокнота как костыля.
⠀
Источник: supercollider#7541
Когда справка есть, но прочитать её нельзя
⠀
В SuperCollider завели свежий issue про доступность IDE для пользователей экранных читалок. Автор проверял NVDA на Windows и Orca/Cthulhu на Linux и описал не абстрактное «добавьте доступность», а несколько рабочих мест, где программа ломается именно в повседневной работе.
⠀
Самое критичное - встроенная справка. Раньше на Windows ещё можно было табом добраться до ссылок и полей, выделить текст и унести его в блокнот. Сейчас, по описанию автора, фокус на странице справки почти не получается нормально поймать. На Linux ситуация похожая. Для зрячего пользователя справка просто открылась. Для пользователя с экранной читалкой она фактически стала закрытой.
⠀
Есть и другие детали: экран Quarks читает в списке только кнопку выбора, автодополнение уводит фокус в недоступный список, окно вывода приходится читать обходными способами. Это не косметика. В среде для музыки и кода справка, редактор, список расширений и окно вывода - это основная работа.
⠀
Отдельно важен вывод про виджеты. Чем больше интерфейс собирается из внутренних веб-панелей и кастомных элементов, тем меньше можно надеяться на «само будет доступно». Стандартные элементы обычно уже умеют отдавать роль, имя, состояние и фокус. Самодельные - часто выглядят нормально только глазами.
⠀
Я бы проверял такие экраны не вопросом «видно ли кнопку», а другим: может ли человек с экранной читалкой открыть справку, понять список, вернуться в редактор, прочитать вывод и продолжить задачу без блокнота как костыля.
⠀
Источник: supercollider/supercollider#7541
⠀
В SuperCollider завели свежий issue про доступность IDE для пользователей экранных читалок. Автор проверял NVDA на Windows и Orca/Cthulhu на Linux и описал не абстрактное «добавьте доступность», а несколько рабочих мест, где программа ломается именно в повседневной работе.
⠀
Самое критичное - встроенная справка. Раньше на Windows ещё можно было табом добраться до ссылок и полей, выделить текст и унести его в блокнот. Сейчас, по описанию автора, фокус на странице справки почти не получается нормально поймать. На Linux ситуация похожая. Для зрячего пользователя справка просто открылась. Для пользователя с экранной читалкой она фактически стала закрытой.
⠀
Есть и другие детали: экран Quarks читает в списке только кнопку выбора, автодополнение уводит фокус в недоступный список, окно вывода приходится читать обходными способами. Это не косметика. В среде для музыки и кода справка, редактор, список расширений и окно вывода - это основная работа.
⠀
Отдельно важен вывод про виджеты. Чем больше интерфейс собирается из внутренних веб-панелей и кастомных элементов, тем меньше можно надеяться на «само будет доступно». Стандартные элементы обычно уже умеют отдавать роль, имя, состояние и фокус. Самодельные - часто выглядят нормально только глазами.
⠀
Я бы проверял такие экраны не вопросом «видно ли кнопку», а другим: может ли человек с экранной читалкой открыть справку, понять список, вернуться в редактор, прочитать вывод и продолжить задачу без блокнота как костыля.
⠀
Источник: supercollider/supercollider#7541
GitHub
Screen reader accessibility for the supercollider IDE · Issue #7541 · supercollider/supercollider
Motivation I have suggested an accessibility related improvement in #7527, for an option to disable the currently inaccessible and thus more distracting autocompletion popups. Since there fortunate...
В Flutter нашли неприятный iOS-баг для экранного доступа
⠀
В свежем issue в flutter/flutter описали воспроизводимый сценарий: приложение на iOS использует
⠀
Проблема задевает не один выпадающий список. Из дерева пропадают текст, кнопка и сам список. Для VoiceOver такой экран фактически перестаёт существовать до конца сессии.
⠀
Автор свёл баг к минимальному примеру, сравнил два варианта и показал разницу: обычный
⠀
Для команд здесь простой урок: видимый путь «тапнул - выбрал - работает» недостаточен. После выбора, модалки, навигации и переиспользования экранов стоит заново смотреть, что осталось в дереве доступности. Лучше проверять это через Accessibility Inspector, VoiceOver или автоматический тест, который видит интерфейс как пользователь с экранным доступом.
⠀
Если дерево доступности исчезло, красивый экран уже не помогает. Для незрячего пользователя это не мелкая ошибка в подписи, а потерянный экран.
⠀
В свежем issue в flutter/flutter описали воспроизводимый сценарий: приложение на iOS использует
MaterialApp.router / go_router, пользователь открывает DropdownMenu и выбирает любой пункт. После этого дерево доступности в iOS становится пустым.⠀
Проблема задевает не один выпадающий список. Из дерева пропадают текст, кнопка и сам список. Для VoiceOver такой экран фактически перестаёт существовать до конца сессии.
⠀
Автор свёл баг к минимальному примеру, сравнил два варианта и показал разницу: обычный
MaterialApp выдерживает, а связка с Router API ломается. Ещё важная деталь: уже открытый фикс по похожей проблеме, похоже, этот путь не покрывает. Мейнтейнер оставил issue открытым как отдельный воспроизводимый случай.⠀
Для команд здесь простой урок: видимый путь «тапнул - выбрал - работает» недостаточен. После выбора, модалки, навигации и переиспользования экранов стоит заново смотреть, что осталось в дереве доступности. Лучше проверять это через Accessibility Inspector, VoiceOver или автоматический тест, который видит интерфейс как пользователь с экранным доступом.
⠀
Если дерево доступности исчезло, красивый экран уже не помогает. Для незрячего пользователя это не мелкая ошибка в подписи, а потерянный экран.
GitHub
[iOS] DropdownMenu selection tears down the entire iOS accessibility tree when the app uses the Router API (go_router / MaterialApp.router)…
Steps to reproduce Note: as you can tell, I had a lot of help from Claude on this one. It's very similar to #186582, but is different enough (specific to a Gorouter setup) that I'm entering...
Приватность не помогает, если до экрана нельзя добраться
⠀
В SimpleX Chat появился свежий баг-репорт от пользователя VoiceOver на iOS: после начальных экранов кнопки часто плохо подписаны, а закрытие экрана может стать недоступным.
⠀
Для мессенджера это не мелочь. Если человек не может уверенно открыть чат, понять кнопку и выйти из экрана, приватность остаётся где-то за дверью.
⠀
В SimpleX Chat появился свежий баг-репорт от пользователя VoiceOver на iOS: после начальных экранов кнопки часто плохо подписаны, а закрытие экрана может стать недоступным.
⠀
Для мессенджера это не мелочь. Если человек не может уверенно открыть чат, понять кнопку и выйти из экрана, приватность остаётся где-то за дверью.
Приватность не помогает, если до экрана нельзя добраться
⠀
В SimpleX Chat появился свежий баг-репорт от пользователя VoiceOver на iOS. Проблема шире одной кнопки: человек пишет, что почти все экраны после старта приложения либо плохо подписаны для VoiceOver, либо ведут себя непредсказуемо.
⠀
По описанию, нормально пройти удалось только начальный экран и экран имени профиля. Дальше начинаются обычные для зрячего интерфейса, но очень жёсткие для экранного доступа вещи: кнопки без понятных названий, элементы с неясным поведением, закрытие экрана, которое может «исчезнуть», из-за чего приходится закрывать приложение целиком.
⠀
Это особенно неприятно именно для мессенджера. Автор пишет, что хотел пользоваться SimpleX для общения с человеком за границей, потому что тот рекомендует его для приватной связи. Но если пользователь с VoiceOver не может уверенно открыть чат, понять кнопку и выйти из экрана, приватность остаётся где-то за дверью.
⠀
Для команд здесь простая проверка. Не ограничиваться экраном входа и парой видимых кнопок. Пройти весь основной путь с VoiceOver: создание профиля, список чатов, чат, поиск, звонки, настройки, закрытие модальных окон. У каждой иконки должно быть человеческое имя, а у каждого действия - понятный результат.
⠀
И да, это касается любого продукта, который обещает безопасность, здоровье, деньги или связь с людьми. Доступность там нужно проверять как часть базового сценария. Иначе часть пользователей просто не доходит до обещанной пользы.
⠀
В SimpleX Chat появился свежий баг-репорт от пользователя VoiceOver на iOS. Проблема шире одной кнопки: человек пишет, что почти все экраны после старта приложения либо плохо подписаны для VoiceOver, либо ведут себя непредсказуемо.
⠀
По описанию, нормально пройти удалось только начальный экран и экран имени профиля. Дальше начинаются обычные для зрячего интерфейса, но очень жёсткие для экранного доступа вещи: кнопки без понятных названий, элементы с неясным поведением, закрытие экрана, которое может «исчезнуть», из-за чего приходится закрывать приложение целиком.
⠀
Это особенно неприятно именно для мессенджера. Автор пишет, что хотел пользоваться SimpleX для общения с человеком за границей, потому что тот рекомендует его для приватной связи. Но если пользователь с VoiceOver не может уверенно открыть чат, понять кнопку и выйти из экрана, приватность остаётся где-то за дверью.
⠀
Для команд здесь простая проверка. Не ограничиваться экраном входа и парой видимых кнопок. Пройти весь основной путь с VoiceOver: создание профиля, список чатов, чат, поиск, звонки, настройки, закрытие модальных окон. У каждой иконки должно быть человеческое имя, а у каждого действия - понятный результат.
⠀
И да, это касается любого продукта, который обещает безопасность, здоровье, деньги или связь с людьми. Доступность там нужно проверять как часть базового сценария. Иначе часть пользователей просто не доходит до обещанной пользы.
GitHub
[Bug]: VoiceOver accessibility nearly non-existent · Issue #7051 · simplex-chat/simplex-chat
Is there an existing issue for this? I have searched the existing issues Platform iOS OS version 26.6 beta one App version Multiple versions, including current Current Behavior Many screens contain...