Когда поле есть, но его имени нет
⠀
В свежей задаче по 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
Когда кофемашина становится «тихим металлом»
⠀
В 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...