Кейс дня: кнопки, которые «видны», но не называются

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

Кейс дня: кнопки, которые «видны», но не называются

Нашёл в Personal Planner типичную проблему доступности: часть действий была понятна только визуально — по иконке, эмодзи, цветному кружку или закрашенной клетке.

Было
Screen reader мог встретить кнопку без понятного имени. Например: ячейка привычки, день тренировки, выбор настроения или цвета выглядели нормально на экране, но для незрячего пользователя звучали как безымянные элементы управления.

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

Что изменили
Добавил понятные accessible names и состояние для toggle-кнопок:

• «Delete Morning run» вместо безымянной иконки корзины
• «Mark gym attendance for May 19» / «Remove gym attendance for May 19»
• «Set mood to Happy»
• «Choose blue accent color»
• aria-pressed там, где кнопка работает как переключатель

Стало
Теперь пользователь screen reader слышит не просто «button», а конкретное действие и текущее состояние. Интерфейс остаётся тем же визуально, но становится понятнее для клавиатуры и ассистивных технологий.

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

Доказательство
Issue: https://github.com/TemaDeveloper/personal_planner/issues/25
PR: https://github.com/TemaDeveloper/personal_planner/pull/28

Когда вход ломается для VoiceOver, это уже не мелкий баг
⠀
В Notesnook открыли GitHub-задачу #9845: на iOS VoiceOver не может активировать поля «имя пользователя» и «пароль» на экране входа. На вебе часть кнопок в навигации и панелях редактора остаётся без понятных подписей для NVDA, JAWS и VoiceOver.
⠀
Это задевает не только удобство. Если незрячий пользователь не может войти, продукт для него фактически закрыт. А если кнопка озвучивается без смысла, в редакторе приходится угадывать действие на ощупь.
⠀
Я бы здесь проверял две вещи до релиза: можно ли пройти вход только с экранным доступом и клавиатурой; понятно ли называется каждый интерактивный элемент.
⠀
Источник: streetwriters/notesnook#9845

Кейс доступности: выпадающий список, которым нельзя нормально управлять с клавиатуры

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

Кейс доступности: выпадающий список, которым нельзя нормально управлять с клавиатуры

В WindoM был кастомный GlassSelect: визуально он выглядел как обычный dropdown, но для пользователя клавиатуры и screen reader всё было хуже, чем кажется.

Было:
• Dropdown открывался с клавиатуры.
• Но ArrowUp / ArrowDown не перемещали активный пункт.
• Home / End не прыгали в начало и конец списка.
• Escape не закрывал список с возвратом фокуса на кнопку.
• Enter / Space не выбирали текущий пункт после навигации.

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

Что изменили:
• Добавили управление ArrowUp / ArrowDown, Home / End, Enter / Space и Escape.
• Сохранили фокус на trigger-кнопке и возвращаем его туда после выбора или закрытия.
• Добавили связь trigger ↔ listbox через ARIA.
• Добавили визуальное состояние активного пункта при клавиатурной навигации.

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

Такие проверки удобно раскладывать по компонентам с помощью Accessibility Auditor Skill: он помогает быстро понять, где проблема в UX для клавиатуры и screen reader, а где достаточно маленького точечного PR.

Доказательство:
Issue: https://github.com/YehudaBriskman/WindoM/issues/243
PR: https://github.com/YehudaBriskman/WindoM/pull/269

Когда картинку нельзя спрятать от 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 по доступности интерфейса. Полный текст — следующим сообщением.