Когда “Continue” есть на экране, но его нет для VoiceOver
⠀
В OpenHuman вчера завели короткую, но очень показательную задачу: незрячий пользователь macOS проходит первый запуск приложения, VoiceOver читает тексты “Run Locally” и “Run on the Cloud”, но основную кнопку “Continue” не находит нормально. В итоге он не может пройти онбординг самостоятельно.
⠀
Это не про красивую доступность в настройках. Это входная дверь в продукт. Если кнопка не фокусируется с клавиатуры, не отдана в API доступности или не имеет понятной роли и подписи, пользователь просто не попадает внутрь.
⠀
Хорошая часть кейса - команда, судя по комментарию автора, быстро поправила проблему. Но сам сигнал всё равно полезный: экран может выглядеть готовым, текст может читаться, а сценарий всё равно будет сломан из-за одного элемента действия.
⠀
Я бы проверял онбординг отдельно и руками: Tab, VoiceOver, Enter/Space, имя кнопки, роль кнопки, порядок фокуса. Особенно в десктопных приложениях, где легко получить визуально нормальный интерфейс и пустоту для экранного доступа.
⠀
Для пользователя барьер простой: без доступной кнопки продолжения продукт не “частично неудобен”, а недоступен с первого шага.
⠀
Источник: GitHub issue tinyhumansai/openhuman#2584
⠀
В OpenHuman вчера завели короткую, но очень показательную задачу: незрячий пользователь macOS проходит первый запуск приложения, VoiceOver читает тексты “Run Locally” и “Run on the Cloud”, но основную кнопку “Continue” не находит нормально. В итоге он не может пройти онбординг самостоятельно.
⠀
Это не про красивую доступность в настройках. Это входная дверь в продукт. Если кнопка не фокусируется с клавиатуры, не отдана в API доступности или не имеет понятной роли и подписи, пользователь просто не попадает внутрь.
⠀
Хорошая часть кейса - команда, судя по комментарию автора, быстро поправила проблему. Но сам сигнал всё равно полезный: экран может выглядеть готовым, текст может читаться, а сценарий всё равно будет сломан из-за одного элемента действия.
⠀
Я бы проверял онбординг отдельно и руками: Tab, VoiceOver, Enter/Space, имя кнопки, роль кнопки, порядок фокуса. Особенно в десктопных приложениях, где легко получить визуально нормальный интерфейс и пустоту для экранного доступа.
⠀
Для пользователя барьер простой: без доступной кнопки продолжения продукт не “частично неудобен”, а недоступен с первого шага.
⠀
Источник: GitHub issue tinyhumansai/openhuman#2584
GitHub
VoiceOver accessibility issue: Continue button not detectable during onboarding on macOS Body · Issue #2584 · tinyhumansai/openhuman
Hello OpenHuman team, First of all, thank you for building such an ambitious and exciting AI project. I really want to use OpenHuman as part of my daily workflow. I am a totally blind macOS user us...
Кейс доступности: видимый фокус в светлой теме
Было: в dashboard-интерфейсе DevTrack часть кнопок и ссылок в светлой теме почти не показывала keyboard focus.
Что это ломало: человек, который идёт по странице клавишей Tab, не понимает, где сейчас находится. Для незрячих и keyboard-only пользователей это быстро превращает обычную навигацию в угадайку: можно нажать Enter не на тот элемент или просто потеряться в шапке интерфейса.
Что изменили: добавили общий стиль
Стало: кнопки, ссылки и другие фокусируемые элементы получают заметную 3px-обводку с отступом. Фокус виден именно при клавиатурной навигации и не мешает обычным кликам мышью.
Это маленький PR, но эффект практичный: интерфейс становится предсказуемее для пользователей клавиатуры и лучше соответствует WCAG 2.4.7 Focus Visible.
Для анализа использовала Accessibility Auditor Skill — он помогает быстро разложить проблему на пользовательский сценарий, WCAG-критерий и безопасное минимальное исправление.
Доказательство:
Issue: github.com/Priyanshu-byte-coder/devtrack/issues/1034
PR: github.com/Priyanshu-byte-coder/devtrack/pull/1114
Было: в dashboard-интерфейсе DevTrack часть кнопок и ссылок в светлой теме почти не показывала keyboard focus.
Что это ломало: человек, который идёт по странице клавишей Tab, не понимает, где сейчас находится. Для незрячих и keyboard-only пользователей это быстро превращает обычную навигацию в угадайку: можно нажать Enter не на тот элемент или просто потеряться в шапке интерфейса.
Что изменили: добавили общий стиль
:focus-visible для интерактивных элементов, отдельный контрастный цвет фокуса для светлой и тёмной темы, а также поддержку forced colors/high contrast mode.Стало: кнопки, ссылки и другие фокусируемые элементы получают заметную 3px-обводку с отступом. Фокус виден именно при клавиатурной навигации и не мешает обычным кликам мышью.
Это маленький PR, но эффект практичный: интерфейс становится предсказуемее для пользователей клавиатуры и лучше соответствует WCAG 2.4.7 Focus Visible.
Для анализа использовала Accessibility Auditor Skill — он помогает быстро разложить проблему на пользовательский сценарий, WCAG-критерий и безопасное минимальное исправление.
Доказательство:
Issue: github.com/Priyanshu-byte-coder/devtrack/issues/1034
PR: github.com/Priyanshu-byte-coder/devtrack/pull/1114
blinddev.xyz
Accessibility Auditor Skill | Blind Dev — Денис Скрипник
AI-agent workflow для быстрого первого слоя accessibility-аудита: сайты, мобильные и десктопные приложения, репозитории и backlog исправлений.
Когда поле есть, но его имени нет
⠀
В свежей задаче по SL Design System разобрали хороший пример из редактируемой таблицы: внутри грида есть поля ввода и выпадающие списки, рядом есть нормальные заголовки колонок, но сами поля не получают доступные имена.
⠀
Для зрячего пользователя контекст виден: вот строка, вот колонка, понятно, где ZIP, где статус. А пользователь скринридера, который идёт Tab только по активным полям, слышит в основном текущее значение поля или выбранный вариант. Названия поля рядом с этим может не быть.
⠀
В маленькой форме это раздражает. В большой таблице это уже ломает работу: чтобы изменить нужную ячейку, человеку приходится угадывать, где он находится, или постоянно восстанавливать контекст вручную.
⠀
Автор задачи предлагает связать поле с несколькими частями контекста через
⠀
Я бы проверял такие компоненты двумя способами. Сначала автоматикой, чтобы поймать пустое имя у
⠀
В свежей задаче по SL Design System разобрали хороший пример из редактируемой таблицы: внутри грида есть поля ввода и выпадающие списки, рядом есть нормальные заголовки колонок, но сами поля не получают доступные имена.
⠀
Для зрячего пользователя контекст виден: вот строка, вот колонка, понятно, где ZIP, где статус. А пользователь скринридера, который идёт Tab только по активным полям, слышит в основном текущее значение поля или выбранный вариант. Названия поля рядом с этим может не быть.
⠀
В маленькой форме это раздражает. В большой таблице это уже ломает работу: чтобы изменить нужную ячейку, человеку приходится угадывать, где он находится, или постоянно восстанавливать контекст вручную.
⠀
Автор задачи предлагает связать поле с несколькими частями контекста через
aria-labelledby: например, чтобы имя звучало как “Zip FIRST NAME LAST NAME” или “Status FIRST NAME LAST NAME”. Это важная деталь. В таблицах имя поля часто должно отвечать и на вопрос “что это за колонка?”, и на вопрос “к какой строке это относится?”.⠀
Я бы проверял такие компоненты двумя способами. Сначала автоматикой, чтобы поймать пустое имя у
input. Потом руками: пройти по редактируемым ячейкам только Tab-ом со скринридером и понять, можно ли без зрения уверенно сказать, какую именно запись ты сейчас меняешь.GitHub
[Grid - Editing] Form fields inside grids do not have labels/accessible names · Issue #3384 · sl-design-system/components
😯 Current Behavior Grids in stories Grid Editing Text Field and Grid Editing Select have form fields in columns with proper table headings but that form fields do not have accessible names announce...
Tab сработал, но скринридер молчит
⠀
В свежей задаче по Docs editor описан простой сценарий: пользователь ставит курсор в документ, нажимает Tab, текст визуально получает отступ, но скринридер ничего не сообщает. Не говорит ни сам факт изменения, ни уровень отступа.
⠀
Для зрячего пользователя это видно сразу. Для незрячего это изменение документа без обратной связи: непонятно, применился ли отступ, где сейчас уровень вложенности и не уехала ли структура текста.
⠀
Проблема не в клавише Tab. Проблема в том, что редактор меняет состояние документа и оставляет это только на экране.
⠀
Если интерфейс даёт форматирование с клавиатуры, он должен возвращать результат через доступный канал: «отступ добавлен», «уровень 2», «отступ убран». И проверять это надо не только глазами, а реальным проходом со скринридером.
⠀
Источник: issue suitenumerique/docs#2335
⠀
В свежей задаче по Docs editor описан простой сценарий: пользователь ставит курсор в документ, нажимает Tab, текст визуально получает отступ, но скринридер ничего не сообщает. Не говорит ни сам факт изменения, ни уровень отступа.
⠀
Для зрячего пользователя это видно сразу. Для незрячего это изменение документа без обратной связи: непонятно, применился ли отступ, где сейчас уровень вложенности и не уехала ли структура текста.
⠀
Проблема не в клавише Tab. Проблема в том, что редактор меняет состояние документа и оставляет это только на экране.
⠀
Если интерфейс даёт форматирование с клавиатуры, он должен возвращать результат через доступный канал: «отступ добавлен», «уровень 2», «отступ убран». И проверять это надо не только глазами, а реальным проходом со скринридером.
⠀
Источник: issue suitenumerique/docs#2335
Когда брайлевская строка отстаёт от фокуса
⠀
В 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