Всё про доступность интерфейсов

Когда карточка выглядит как выбор, но не выбирается
⠀
В свежем issue по Chayn Tools letter generator описан хороший пример: пользователь начинает путь создания письма, доходит до выбора платформы, а дальше застревает. Карточки платформ и карточки следующих вопросов кликаются мышью, но нормально не выбираются с клавиатуры и экранным доступом.
⠀
Это не косметика. Инструмент помогает людям готовить запрос на удаление вредного контента. Если человек не может выбрать платформу через Tab, стрелки и Space, он может вообще не отправить запрос.
⠀
В issue перечислены и соседние поломки: на шагах нет нормального h1, заголовки перескакивают с h2 на h4, кнопки микрофона читаются просто как “button”, а состояния вроде “Analysing your responses” и ошибок не объявляются экранному доступу.
⠀
Рядом уже открыт PR #500 с понятной правкой: заменить кликабельные div на radio group, дать странице один h1, подписать кнопки микрофона, добавить aria-pressed, а загрузку и ошибки отдавать через role="status" и role="alert". Ещё отдельно сделали прогресс шагов читаемым для экранного доступа.
⠀
Я бы забрал отсюда простой тест для любых многошаговых форм: пройти весь сценарий без мыши и послушать его экранным доступом. Проверять нужно весь путь: можно ли выбрать вариант, понять текущий шаг, услышать загрузку, ошибку и продолжить без визуальных подсказок.

Когда карточка выглядит как выбор, но не выбирается
⠀
Свежий кейс из Chayn Tools letter generator: карточки выбора платформы кликаются мышью, но путь ломается для клавиатуры и экранного доступа.
⠀
Это форма для запроса на удаление вредного контента. Если вариант нельзя выбрать через Tab, стрелки и Space, человек не просто теряет удобство - он не может отправить запрос.
⠀
Полный разбор - следующим сообщением.

Когда «скрыть боковую панель» скрывает её только глазами
⠀
В Scratch, офлайн-приложении для заметок на Markdown, пользователь VoiceOver описал неприятную вещь: в режиме Focus и после команды Hide sidebar боковая панель визуально исчезает, но для экранного доступа остаётся в дереве доступности. То есть экран вроде очищен, а VoiceOver всё ещё натыкается на элементы, которые пользователь уже попросил убрать.
⠀
Контекст в отчёте конкретный: macOS Sequoia 15.7.4, VoiceOver, режим «только речь», без брайлевского дисплея. Рядом тот же пользователь завёл ещё один баг: при нажатии Return нет голосового подтверждения новой строки. Для зрячего это может выглядеть мелочью, но при работе с заметками такие сигналы держат в голове структуру текста.
⠀
Здесь ломается не декоративная доступность, а смысл самого Focus mode. Человек включает его, чтобы убрать шум и спокойно писать. Если скрытая панель продолжает читаться, фокус превращается в ещё один источник путаницы: надо на слух отличать рабочий текст от интерфейсного мусора.
⠀
Я бы проверял такие режимы после каждого «скрыть», «сфокусироваться», «свернуть»: пройти экран VoiceOver/NVDA/TalkBack и посмотреть, что реально осталось в порядке чтения и фокусе. Если элемент визуально убрали, он не должен продолжать жить для экранного доступа без причины.
⠀
И отдельно для редакторов: клавиши ввода, удаления, перехода между строками и изменения выделения должны давать понятную обратную связь. Иначе пользователь пишет текст, но постоянно не уверен, произошло ли действие.
⠀
Источник: erictli/scratch #176, рядом #177.

Когда обновился экранный доступ, таблица снова сломалась
⠀
В репозитории Freedom Scientific появился свежий баг: в JAWS 2026 таблицы перестали нормально читаться там, где в JAWS 2025 всё работало. При переходе по ячейкам звучит только содержимое ячейки, а число строк, столбцов и заголовки колонок больше не объявляются. NVDA на тех же примерах читает ожидаемо.
⠀
Для пользователя это не мелкая потеря подсказки. В таблице без заголовков быстро становится непонятно, что означает значение: цена, статус, дата, имя, действие. Если интерфейс построен на списках, сетках, отчётах или админских таблицах, человек с JAWS может просто потерять контекст задачи.
⠀
Здесь неприятный урок для команд: нельзя проверять таблицу один раз и считать её закрытой. Если вы убрали собственные объявления и полностью положились на поведение конкретного экранного доступа, нужно прогонять регрессию на новых версиях JAWS, NVDA и браузеров.
⠀
Я бы проверял не только «фокус ходит по ячейкам», а более простую вещь: понимает ли человек на слух, в какой строке и колонке он находится, и что именно означает текущее значение.
⠀
Источник: FreedomScientific/standards-support#947

JAWS 2026 и таблицы
⠀
Свежий баг из Freedom Scientific: в JAWS 2026 таблица может читаться без строк, столбцов и заголовков колонок. Визуально данные на месте, но на слух контекст ячейки пропадает.
⠀
Полный разбор - ниже.

Когда список есть на экране, но его нет для VoiceOver

В aMule пришёл хороший живой сигнал от незрячего пользователя macOS: во вкладке поиска VoiceOver сообщает общее число найденных результатов, но саму таблицу результатов не видит. Для клавиатуры и экранного доступа список как будто исчезает.

Там же сломался второй важный путь: в настройках VoiceOver показывает только раздел General. Боковая панель с Connection, Security и другими категориями недоступна, поэтому человек не может нормально перейти к нужным настройкам и включить, например, внешний доступ через aMuleGUI.

Разработчик подтвердил обе проблемы. Причина не в тексте кнопки и не в одном забытом aria-атрибуте: список результатов полностью custom-drawn, без нормального нативного аналога для macOS, Windows и Linux. Экранные читалки просто не получают элементы, строки, колонки и фокус. Для боковой панели путь понятнее - заменить виджет на компонент, который лучше отдаёт структуру в системные API доступности.

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

Визуально всё может быть на месте. Но если список не попал в дерево доступности, для незрячего пользователя это не список, а пустое место.

Источник: amule-org/amule#180

Кнопка оплаты не должна звучать как заевшая пластинка
⠀
В paypal-js открыли issue про PayPal-кнопки: в дереве доступности слово “PayPal” повторяется несколько раз, а сама кнопка при этом не говорит нормально, что она делает.
⠀
Автор пишет, что на e-commerce сайтах screen reader может прочитать PayPal четыре раза подряд. Причина не в одном месте: у iframe title вроде PayPal-paypal, внутри ещё элемент с role="link" и aria-label="PayPal". В итоге пользователь слышит бренд, бренд, бренд, но не получает понятного действия.
⠀
Это неприятная мелочь ровно до момента оплаты. Если человек идёт по странице через экранный доступ, ему нужно быстро понять: это просто блок PayPal, ссылка на условия, кнопка выбора способа оплаты или действие “оплатить через PayPal”. Когда название повторяется, интерфейс начинает шуметь. А когда у действия нет нормального имени, растёт шанс выбрать не то или вообще уйти на другой способ оплаты.
⠀
Хорошая правка здесь довольно приземлённая: не пихать бренд в каждую оболочку виджета и называть действие человечески. Например, iframe может иметь короткий и уникальный title, а сама кнопка - имя вроде “Pay with PayPal”.
⠀
Для команд это хороший тест перед релизом платёжного блока: пройти путь оплаты с NVDA, VoiceOver или другим экранным доступом и послушать не только “есть ли имя у элемента”, а сколько лишнего шума попадает в речь. В оплате доступность - это не украшение. Это разница между понятным действием и нервным угадыванием.

Кнопка оплаты не должна звучать как заевшая пластинка
⠀
В paypal-js открыли issue про PayPal-кнопки: в дереве доступности слово “PayPal” повторяется несколько раз, а действие всё равно названо неясно.

Подсказка есть, но экранный доступ о ней не узнает
⠀
В CiviForm завели issue про всплывающие подсказки в админке. Пример простой: на экране создания вопроса рядом с полем Administrative Identifier есть значок Info. Мышью его можно открыть, а с клавиатуры до него не добраться. VoiceOver в Chrome на macOS эту подсказку тоже пропускает, поэтому пользователь даже не узнаёт, что рядом есть дополнительное объяснение.
⠀
Для зрячего пользователя это может выглядеть как мелкая справка рядом с полем. Для человека, который идёт по форме клавиатурой или слушает интерфейс через экранный доступ, это уже потерянный кусок инструкции. Особенно неприятно в административной форме: человек заполняет настройку, но часть правил спрятана в элементе, который для него фактически не существует.
⠀
У иконки может быть подпись, но этого мало. Нужно проверить весь путь: попадает ли значок в порядок Tab, понятно ли он назван, открывается ли с клавиатуры, связан ли текст подсказки с полем, можно ли прочитать его экранной читалкой и закрыть без мыши.
⠀
Если в продукте есть подсказки, не считайте их доступными только потому, что они видны на экране. Пройдите форму без мыши и со включённым VoiceOver, NVDA или другим экранным доступом. Если справка нужна для правильного заполнения поля, она должна быть достижима тем же способом, которым человек реально проходит форму.
⠀
Источник: civiform/civiform#13444

CiviForm: подсказка, до которой не дойти клавиатурой
⠀
В issue #13444 описали форму админки: значок Info открывается мышью, но не попадает в порядок Tab, а VoiceOver не читает текст подсказки. Полный разбор ниже.

Слепой разработчик и небезопасный TUI
⠀
В issue к MiMo-Code пользователь описал проверку MiMoCode 0.1.0 на macOS с VoiceOver. Одноразовая команда mimo run ещё читается нормально: это обычный вывод в терминал. Но интерактивный TUI, attach-режим и веб-выбор проекта уже становятся ненадёжными.
⠀
Самая неприятная часть не в том, что «экранный доступ плохо читает интерфейс». Инструмент попытался открыть /Users/xiaopinpin/README.md вместо README внутри тестового проекта на внешнем диске, а потом показал запрос доступа к домашней папке. Если такой запрос трудно разобрать с VoiceOver, пользователь может случайно разрешить доступ шире, чем хотел.
⠀
То есть доступность здесь напрямую связана с безопасностью. Слепой разработчик должен понимать три вещи без угадывания: какой проект открыт, какой путь запрашивает агент и выходит ли этот путь за пределы проекта.
⠀
Вторая поломка похожая: веб-интерфейс открылся, но выбор проекта показал пустую папку ~/lfs/tmp/, а очевидного доступного способа перейти к нужному каталогу не было. Команда mimo web тоже не принимает путь проекта как аргумент.
⠀
Что я бы проверял в таких инструментах отдельно:
⠀
• можно ли открыть проект точной командой из терминала;
• проговаривается ли текущий корень проекта;
• запрос прав показывает действие, путь, корень проекта и безопасный вариант по умолчанию;
• есть ли простой текстовый режим без TUI;
• можно ли отказаться от доступа так же легко, как разрешить.
⠀
Для интерфейсов с ИИ-агентами доступность - это не только подписи кнопок. Если пользователь не может надёжно прочитать контекст и права, он теряет контроль над тем, что агенту разрешено делать.
⠀
Источник: XiaomiMiMo/MiMo-Code #472.

Слепой разработчик и небезопасный TUI
⠀
В issue к MiMo-Code пользователь описал MiMoCode 0.1.0 на macOS с VoiceOver: обычный mimo run читается, а TUI, attach-режим и веб-выбор проекта уже ломают самостоятельную работу.
⠀
Главный риск: агент попытался открыть README вне тестового проекта и запросил доступ к домашней папке. Если запрос прав трудно прочитать с экранным доступом, это уже не просто неудобство, а потеря контроля над разрешениями.

Решил делать раз в неделю такие PR, чтоб не спамить ими каждый день, и находить качественные глобальные проблемы.

В течение недели происходит отбор репозиториев, а в воскресенье выбор из них и публикация.

В Quasar был неприятный баг на уровне формы.
⠀
Поле могло быть визуально красным, под ним показывалась ошибка, но сама связь для экранного доступа была неполной. Когда человек возвращался фокусом в неправильное поле, нативный input не говорил: «я сейчас невалидный» и не был связан с конкретным текстом ошибки.
⠀
Для зрячего пользователя это часто выглядит мелочью: сообщение же видно под полем. Для пользователя со скринридером это уже другая ситуация. Он может слышать название поля, но не понимать, что именно не так и где искать объяснение.
⠀
Я выбрала этот кейс для недельного PR, потому что это не правка одной страницы. Quasar - компонентный фреймворк, и такие поля потом расходятся по тысячам интерфейсов.
⠀
Что поменялось:
- у сообщения об ошибке появился стабильный id;
- QInput теперь добавляет aria-invalid, aria-errormessage и aria-describedby в состоянии ошибки;
- старые aria-describedby не затираются, а дополняются;
- для кастомных контролов через QField slot появились готовые ARIA-значения;
- добавлены тесты на оба сценария.
⠀
Это как раз тот тип доступности, который лучше чинить в базовом компоненте, а не вручную в каждом проекте. Один хороший фикс в библиотеке может закрыть десятки одинаковых ошибок в приложениях, которые на ней построены.
⠀
Инструмент, которым я пользуюсь для таких разборов: Accessibility Auditor Skill.
⠀
Issue: quasarframework/quasar#17306
PR: quasarframework/quasar#18323

Кейс доступности

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

Модальное окно должно забирать фокус при открытии
⠀
В GitHub появился хороший маленький кейс по Yeliztli: в приложении есть семь выезжающих панелей с деталями генетических вариантов. Визуально они ведут себя как модальные окна: открываются поверх страницы, есть затемнение и закрытие по Escape.
⠀
Но в issue #703 автор показывает неприятную разницу: четыре панели вообще не объявлены как role="dialog" и aria-modal="true", а ни одна из семи не управляет фокусом.
⠀
Что это значит на практике: пользователь с клавиатурой или экранным доступом открывает панель, а фокус не переходит внутрь. Дальше Tab может увести его в затемнённую страницу под панелью. Для зрячего человека это выглядит как один активный слой, а для пользователя ассистивных технологий получается два смешанных слоя: панель открыта, но навигация уже гуляет по фону.
⠀
Это особенно неприятно в интерфейсах с важными данными. Если панель показывает детали варианта, лекарства, риска или другого сложного объекта, пользователь должен понимать: где он сейчас, что открылось, как пройти по содержимому и как безопасно вернуться назад.
⠀
Я бы проверял такие компоненты не по признаку «оно красиво открылось», а по полному сценарию:
⠀
- экранный доступ объявляет диалог;
- фокус при открытии попадает внутрь панели;
- Tab не уходит в фон;
- Escape и кнопка закрытия работают предсказуемо;
- после закрытия фокус возвращается на элемент, который открыл панель.
⠀
Если этого нет, модальное окно существует только для глаз. Для части пользователей это не слой интерфейса, а ловушка или, наоборот, дырка, через которую фокус проваливается в старую страницу.
⠀
Источник: bioedca/Yeliztli#703

Модальное окно должно забирать фокус при открытии
⠀
Новый кейс из Yeliztli: часть выезжающих панелей выглядит как модальные окна, но не объявляется как диалог и не управляет фокусом.
⠀
Для пользователя с клавиатурой или экранным доступом это значит: панель открыта, а навигация может уйти в затемнённый фон.

Кнопка есть, но VoiceOver до неё не доходит

В Expensify поймали свежий баг на iOS: в настройках Workspace → Accounting кнопка Connect рядом с NetSuite не получает отдельный фокус VoiceOver. Экранный диктор попадает на всю строку провайдера целиком, а не на саму кнопку. Значит, пользователь не может просто дойти до действия и дважды тапнуть, чтобы подключить интеграцию.

В отчёте указаны версия 9.4.6-0, iPhone 12, iOS 26.5; ошибка воспроизводится и на staging, и в production. В комментариях быстро разобрали вероятную механику: строка собрана как неинтерактивный MenuItem, но родительский контейнер всё равно остаётся accessible=true. На iOS такой контейнер схлопывает потомков в один доступный элемент, и вложенная кнопка исчезает как отдельная цель для VoiceOver.

Вот неприятная часть: визуально интерфейс выглядит нормально. Есть строка провайдера, есть кнопка, мышкой или пальцем без VoiceOver путь может казаться рабочим. Но для незрячего пользователя это уже не рабочая кнопка, а действие, до которого нельзя добраться.

Для команд здесь хороший тест: если внутри строки, карточки или пункта меню лежит отдельная кнопка, проверьте не только подпись кнопки. Проверьте порядок фокуса с VoiceOver/TalkBack: строка и вложенная кнопка должны быть разными доступными элементами, а кнопка должна активироваться как кнопка.

И отдельно - не стоит считать interactive=false равным «для экранного диктора всё безопасно». Родительская доступность и группировка потомков могут сломать главный сценарий даже там, где визуальная вёрстка не изменилась.

Источник: Expensify/App#93461

Кнопка есть, но VoiceOver до неё не доходит

В Expensify поймали свежий баг на iOS: в настройках Workspace → Accounting кнопка Connect рядом с NetSuite не получает отдельный фокус VoiceOver.

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

Источник: Expensify/App#93461

Когда список “говорит” неправильное число пунктов
⠀
В Radix UI завели свежий баг по компоненту Select: в Chrome на macOS VoiceOver неправильно озвучивает позицию пункта в списке.
⠀
Если значение уже выбрано, при движении по списку можно услышать что-то вроде “Banana, 1 of 3”, хотя пунктов больше. Если значения ещё нет, VoiceOver может сказать только “Banana” - без “2 из 5” и вообще без контекста. В Safari с VoiceOver и в NVDA на Windows автор этого не воспроизвёл.
⠀
Снаружи выглядит мелко: ну, список же открывается, пункты читаются. Но для пользователя экранного доступа это часть ориентации. Он должен понимать, где находится в наборе вариантов, сколько их всего и не пропустил ли он нужный пункт.
⠀
Такие баги особенно неприятны в библиотеках компонентов. Один Select потом разъезжается по формам, фильтрам, настройкам и админкам. Ошибка в озвучке становится не локальным дефектом одного экрана, а повторяемым дефектом во многих продуктах.
⠀
Я бы здесь проверял не только “работает ли выбор мышью”. Для списков и выпадающих меню нужен отдельный прогон с VoiceOver, NVDA и разными браузерами: метка пункта, позиция, общее число, выбранное состояние и поведение до выбора значения. Если часть этой информации видна глазами, но не слышна в экранном доступе, компонент ещё не готов.
⠀
Источник: radix-ui/primitives#3962