Когда картинку нельзя спрятать от VoiceOver
⠀
В Expo завели свежую задачу по expo-image на iOS. Сценарий простой: внутри Pressable лежит Image, разработчик ставит accessible={false} и accessibilityElementsHidden={true}, чтобы VoiceOver не читал эту картинку. Но при фокусе VoiceOver произносит: hello world.
⠀
Для зрячего пользователя это почти незаметная деталь. Для пользователя VoiceOver это лишний шум внутри кнопки. Если картинка декоративная, она начинает конкурировать с настоящим названием действия. Если внутри изображение с текстом, экранный доступ может прочитать не ту подсказку, которую команда заложила в интерфейс.
⠀
Я бы здесь проверял свойства в коде и реальное поведение. Особенно внутри кликабельных контейнеров. Открыть устройство, включить VoiceOver и пройти сценарий фокусом: что произносится, в каком порядке и не вылезает ли в речь то, что должно было быть скрыто.
⠀
Источник: expo/expo#46039

Кейс доступности: важные сообщения должны быть услышаны

Коротко: новый разбор issue → audit → PR по доступности интерфейса. Полный текст — следующим сообщением.

Кейс доступности: важные сообщения должны быть услышаны

Нашёл в Ride The Lightning проблему из WCAG 4.1.3: динамические сообщения появлялись на экране, но не всегда объявлялись скринридером.

Было: пользователь вводит пароль, получает ошибку входа или видит состояние загрузки. Визуально сообщение есть, но для незрячего пользователя оно могло пройти мимо — приходилось вручную искать, что изменилось.

Что мешало: ошибки формы и статус загрузки не были оформлены как live regions/status messages. Скринридер не обязан автоматически озвучивать такие изменения, если интерфейс явно не сообщает их ассистивным технологиям.

Что изменили: добавил семантику для объявлений:


• загрузка RTL теперь имеет role="status", aria-live="polite" и понятное имя для спиннера;


• ошибки пароля в login/auth формах теперь объявляются как role="alert";


• сообщение об ошибке входа объявляется сразу, а logout/session-сообщение — в более спокойном polite-режиме.

Стало: пользователь со скринридером получает обратную связь в момент, когда она появилась: «пароль обязателен», «ошибка входа», «идёт загрузка». Это меньше неопределённости и меньше лишней навигации по странице.

Такие кейсы я разбираю с помощью Accessibility Auditor Skill: он помогает быстро пройтись по потоку, найти место, где интерфейс визуально работает, но программно молчит, и довести это до небольшого безопасного PR.

Доказательство:

Issue: Ride-The-Lightning/RTL#1561

PR: Ride-The-Lightning/RTL#1603

NVDA и быстрый Tab: когда озвучка догоняет фокус
⠀
В свежей задаче NVDA описали неприятную вещь: если быстро пройти по ссылкам клавишей Tab, NVDA может произнести текущий и предыдущий элемент подряд. На сайте NV Access автор останавливается на Get Help, а слышит сначала Download, потом Get Help. В Firefox, по отчёту, шум может быть ещё сильнее - до трёх-четырёх прошлых ссылок.
⠀
Для зрячего это легко недооценить: фокус-то уже на нужном месте. Для пользователя экранного доступа это сбивает навигацию. Если не дождаться конца речи, можно решить, что фокус остался на прошлой ссылке, нажать Enter не там или начать проверять страницу заново.
⠀
Для команд здесь простой урок: быстрые сценарии тоже надо тестировать. Медленный проход по Tab может выглядеть нормально, а быстрое движение по меню, формам, результатам поиска и диалогам - уже нет.
⠀
Источник: issue nvaccess/nvda#20197.

Маленький PR, который делает bottom sheet понятнее для screen reader

Коротко: новый разбор issue → audit → PR по доступности интерфейса. Полный текст — следующим сообщением.

Маленький PR, который делает bottom sheet понятнее для screen reader

Нашёл в Artigen open issue по доступности: bottom sheet открывался как меню, но при появлении не переводил фокус внутрь и не озвучивал заголовок.

Было: пользователь открывает список действий, а screen reader может оставаться «снаружи» — непонятно, что появилось и где теперь работать.

Что изменили: при открытии ActionSheet фокус переносится на заголовок, а название sheet дополнительно озвучивается. Для desktop-dialog и mobile bottom sheet сохранены существующие роли menu/menuitem и modal semantics.

Стало: клавиатурному и screen reader-пользователю проще понять контекст: открылось меню действий, фокус внутри, можно сразу выбирать пункт или закрыть.

Такие небольшие кейсы хорошо ловит и помогает разбирать Accessibility Auditor Skill: не абстрактный “a11y audit”, а конкретное “что мешает человеку и какой минимальный PR это исправит”.

Доказательство:
Issue: https://github.com/MukundaKatta/artigen/issues/204
PR: https://github.com/MukundaKatta/artigen/pull/455

Когда экранный доступ слышит «tab tab»
⠀
Свежий кейс ProgramAT: TalkBack читает нижние вкладки как «Chat tab tab», потому что слово «tab» попало и в подпись, и в роль элемента.
⠀
Полный разбор - ниже.

Когда экранный доступ слышит «tab tab»
⠀
В свежей задаче ProgramAT описали маленький, но очень показательный баг: на Android TalkBack читает нижние вкладки как «Chat tab tab» и «Settings tab tab».
⠀
Причина простая. В коде уже стоит роль tab, но в подпись элемента тоже руками добавили слово «tab». В итоге TalkBack озвучивает и текст подписи, и роль элемента. Получается шум вместо нормальной навигации.
⠀
На iOS там же заметили второй риск: VoiceOver может читать «Chat tab» не потому, что видит настоящую панель вкладок, а потому что это слово просто записано в подписи. То есть интерфейс визуально похож на вкладки, но для экранного доступа может не быть полноценной нативной навигацией.
⠀
Для пользователя это не косметика. Нижние вкладки - один из основных способов двигаться по приложению. Если они озвучиваются с мусором или держатся на ручной подписи вместо семантики, человек хуже понимает, где он находится и какой элемент сейчас выбирает.
⠀
Я бы здесь проверял очень приземлённо: подпись должна называть объект, а роль должна жить в метаданных. Не «Chat tab», а «Chat» + роль вкладки. И отдельно проверить платформу: на Android это один набор ролей, на iOS - другой.
⠀
Если кастомный компонент заменяет нативную вкладку, он должен вернуть пользователю не только похожий вид, но и такое же поведение для TalkBack и VoiceOver. Иначе это уже не дизайн-система, а ловушка с красивой оболочкой.

Доступность интерфейсов: маленькая правка, которая делает dropdown управляемым с клавиатуры

Коротко: новый разбор issue → audit → PR по доступности интерфейса. Полный текст — следующим сообщением.

Доступность интерфейсов: маленькая правка, которая делает dropdown управляемым с клавиатуры

Нашёл в WindoM проблему в компоненте выбора GlassSelect: визуально dropdown открывался, ARIA-атрибуты уже были, но клавиатурному пользователю не хватало самого главного — нормальной навигации внутри списка.

Было: список можно открыть, но дальше пользователь с клавиатурой или screen reader фактически застревал: нельзя было предсказуемо пройти по вариантам стрелками, быстро перейти в начало/конец, выбрать текущий пункт Enter/Space или закрыть список Escape с возвратом фокуса.

Что мешало: для зрячего мышиного сценария всё выглядело рабочим, но keyboard-only UX был неполным. Это типичная ловушка кастомных select/dropdown: роли и aria-expanded есть, а поведение клавиатуры не доведено до ожидаемого паттерна.

Что изменили: добавил обработку ArrowUp/ArrowDown, Home/End, Enter/Space и Escape, сделал фокусируемые пункты списка и возврат фокуса на кнопку после выбора или закрытия. Плюс добавил регрессионные тесты, чтобы это поведение не потерялось.

Стало: dropdown можно открыть, пройти по вариантам, выбрать нужный пункт и закрыть без мыши. Для screen reader и клавиатурной навигации это не «косметика», а переход от “формально есть компонент” к “им реально можно пользоваться”.

Для таких задач я использую Accessibility Auditor Skill: он помогает быстро разобрать интерфейс, найти практичную точку улучшения и довести её до маленького проверяемого PR.

Доказательство:

Issue: YehudaBriskman/WindoM#243

PR: YehudaBriskman/WindoM#270

Выбранная кнопка должна быть выбранной и для скринридера
⠀
В свежей задаче Learnova описали простой баг в ChatBot: категории-подсказки выглядят активными, но в разметке нет состояния для экранного доступа. Зрячий пользователь видит выделенную категорию, а скринридер не получает “выбрано”.
⠀
Для незрячего пользователя это ломает не весь чат, но ломает уверенность. Он может нажимать категории и не понимать, что реально изменилось: фильтр, тема вопроса или просто внешний стиль кнопки.
⠀
Исправление небольшое: для таких кнопок нужно передавать состояние через aria-pressed или aria-selected, а не только через цвет и активный класс.
⠀
Я бы проверял это отдельно во всех “пилюлях”, вкладках и переключателях. Если состояние влияет на следующий шаг, оно должно быть доступно не глазами, а через семантику интерфейса.
⠀
Источник: GitHub issue Learnova#1011

Daily accessibility PR case

Коротко: новый разбор issue → audit → PR по доступности интерфейса. Полный текст — следующим сообщением.

Daily accessibility PR case

Было: в калькуляторе напитков drinkup часть управления была понятна визуально, но хуже работала для клавиатуры и screen reader: слайдеры не проговаривали понятный контекст, группы пресетов и крепости выглядели как выбор, но не были объявлены как радиогруппы, а успешное копирование ссылки не озвучивалось.

Что мешало пользователю: незрячий человек мог слышать отдельные числа и кнопки без достаточного смысла, не понимать текущий выбранный вариант и не получать подтверждение после действия.

Что изменили: добавили понятные доступные имена и значения для полей, радиогруппы для выбора типа события и крепости, клавиатурное переключение стрелками, скрыли декоративные emoji от screen reader и добавили polite live region для статуса «ссылка скопирована».

Стало: интерфейс лучше объясняет, что именно меняется, какой вариант выбран, и подтверждает действие без необходимости видеть экран. Это маленький PR, но он закрывает сразу несколько практичных проблем keyboard/screen reader UX.

Такие кейсы я разбираю и чиню через Accessibility Auditor Skill: беру реальную проблему, проверяю пользовательский сценарий и делаю минимальное безопасное улучшение.

Доказательство:

Issue: johnnymackcodes/drinkup#5

PR: johnnymackcodes/drinkup#7

Когда “Continue” есть на экране, но его нет для VoiceOver
⠀
В OpenHuman незрячий пользователь macOS не смог пройти первый запуск: VoiceOver читал тексты, но не видел основную кнопку продолжения. Ниже - полный разбор кейса и вывод для интерфейсов.

Когда “Continue” есть на экране, но его нет для VoiceOver
⠀
В OpenHuman вчера завели короткую, но очень показательную задачу: незрячий пользователь macOS проходит первый запуск приложения, VoiceOver читает тексты “Run Locally” и “Run on the Cloud”, но основную кнопку “Continue” не находит нормально. В итоге он не может пройти онбординг самостоятельно.
⠀
Это не про красивую доступность в настройках. Это входная дверь в продукт. Если кнопка не фокусируется с клавиатуры, не отдана в API доступности или не имеет понятной роли и подписи, пользователь просто не попадает внутрь.
⠀
Хорошая часть кейса - команда, судя по комментарию автора, быстро поправила проблему. Но сам сигнал всё равно полезный: экран может выглядеть готовым, текст может читаться, а сценарий всё равно будет сломан из-за одного элемента действия.
⠀
Я бы проверял онбординг отдельно и руками: Tab, VoiceOver, Enter/Space, имя кнопки, роль кнопки, порядок фокуса. Особенно в десктопных приложениях, где легко получить визуально нормальный интерфейс и пустоту для экранного доступа.
⠀
Для пользователя барьер простой: без доступной кнопки продолжения продукт не “частично неудобен”, а недоступен с первого шага.
⠀
Источник: GitHub issue tinyhumansai/openhuman#2584

Кейс доступности: видимый фокус в светлой теме

Коротко: новый разбор issue → audit → PR по доступности интерфейса. Полный текст — следующим сообщением.

Кейс доступности: видимый фокус в светлой теме

Было: в 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

Редактируемая таблица может выглядеть понятной, но быть пустой для скринридера.
⠀
В SL Design System нашли поля без доступных имён: пользователь слышит значение, но не понимает, какую строку и колонку редактирует.

Когда поле есть, но его имени нет
⠀
В свежей задаче по SL Design System разобрали хороший пример из редактируемой таблицы: внутри грида есть поля ввода и выпадающие списки, рядом есть нормальные заголовки колонок, но сами поля не получают доступные имена.
⠀
Для зрячего пользователя контекст виден: вот строка, вот колонка, понятно, где ZIP, где статус. А пользователь скринридера, который идёт Tab только по активным полям, слышит в основном текущее значение поля или выбранный вариант. Названия поля рядом с этим может не быть.
⠀
В маленькой форме это раздражает. В большой таблице это уже ломает работу: чтобы изменить нужную ячейку, человеку приходится угадывать, где он находится, или постоянно восстанавливать контекст вручную.
⠀
Автор задачи предлагает связать поле с несколькими частями контекста через aria-labelledby: например, чтобы имя звучало как “Zip FIRST NAME LAST NAME” или “Status FIRST NAME LAST NAME”. Это важная деталь. В таблицах имя поля часто должно отвечать и на вопрос “что это за колонка?”, и на вопрос “к какой строке это относится?”.
⠀
Я бы проверял такие компоненты двумя способами. Сначала автоматикой, чтобы поймать пустое имя у input. Потом руками: пройти по редактируемым ячейкам только Tab-ом со скринридером и понять, можно ли без зрения уверенно сказать, какую именно запись ты сейчас меняешь.

Tab сработал, но скринридер молчит
⠀
В свежей задаче по Docs editor описан простой сценарий: пользователь ставит курсор в документ, нажимает Tab, текст визуально получает отступ, но скринридер ничего не сообщает. Не говорит ни сам факт изменения, ни уровень отступа.
⠀
Для зрячего пользователя это видно сразу. Для незрячего это изменение документа без обратной связи: непонятно, применился ли отступ, где сейчас уровень вложенности и не уехала ли структура текста.
⠀
Проблема не в клавише Tab. Проблема в том, что редактор меняет состояние документа и оставляет это только на экране.
⠀
Если интерфейс даёт форматирование с клавиатуры, он должен возвращать результат через доступный канал: «отступ добавлен», «уровень 2», «отступ убран». И проверять это надо не только глазами, а реальным проходом со скринридером.
⠀
Источник: issue suitenumerique/docs#2335

Когда брайлевская строка отстаёт от фокуса
⠀
В MuseScore Studio открыли свежую задачу: в версии 4.7 на Windows с NVDA навигация по партитуре и брайлевская панель не всегда показывают один и тот же элемент.
⠀
Полный разбор - ниже.