Когда PIN-код вводится, а экранный доступ не видит сами поля

В свежем issue от 23 апреля по EU Digital Identity Wallet для Android пользователь описал поломки, которые особенно опасны тем, что живут в сценарии безопасности, а не где-то на второстепенном экране.

Самый тяжёлый сбой - вкладка Security. Человек не воспринимает отдельные поля PIN. Экранный доступ озвучивает кнопку Confirm и клавиатуру, но не даёт понять, где именно находится ввод и какое поле сейчас заполняется. При этом цифры подставляются автоматически.

Дальше хуже: после ввода 6 цифр приложение само переводит пользователя на подтверждение PIN, но почти ничего не сообщает об этом. Если PIN не совпал, сообщение об ошибке не озвучивается. Если не сработала биометрия, ошибка тоже не объявляется.

В том же issue есть и другие сигналы: не озвучивается активный шаг в навигации Consent / Security / Verification, у видимых заголовков нет семантики заголовков, часть элементов не имеет правильных ролей, а верификация документа и QR-сценарии не дают нормальных уведомлений о ходе процесса.

Кого это бьёт:
- незрячих пользователей и всех, кто проходит сценарий через экранный доступ;
- людей с крупным шрифтом, у которых часть инструкций может уехать под блок захвата фото;
- пользователей, которым важно понимать состояние шага, ошибки и результат каждого действия без догадок.

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

Если человек не понимает, куда попал после ввода кода и что именно произошло, это уже поломка безопасности в пользовательском опыте, а не мелкий недочёт доступности.

Ещё один год ждать доступный школьный веб

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

Проверять надо не одну страницу, а весь путь: сайт, приложение, документы, формы и сервисы подрядчиков.

Источник: Education Week

Ещё один год ждать доступный школьный веб

В США школам и колледжам дали ещё год на внедрение новых требований к цифровой доступности. Для отчётности это выглядит как перенос срока. Для незрячих студентов - как ещё один год, когда учебные материалы, формы, расписания и личные кабинеты могут оставаться частично закрытыми.

Education Week напоминает, что правило охватывает не только обычные сайты, но и мобильные версии, приложения, документы, графики, видео и сервисы подрядчиков. То есть ломается не одна кнопка. Ломается весь учебный маршрут: открыть материал, заполнить форму, сдать задание, прочитать уведомление, зайти в кабинет.

Для пользователей программ экранного доступа это бьёт по базовым вещам:
- файл не читается;
- поле формы не подписано;
- таблица или график разваливаются в кашу;
- сторонняя платформа для обучения или сообщений не дружит с программой экранного доступа;
- мобильное приложение и сайт ведут себя по-разному.

В материале отдельно приведена позиция National Federation of the Blind: когда информация недоступна, незрячие студенты получают не просто менее удобный опыт, а задержки в учёбе, лишние барьеры и отставание от однокурсников.

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

Критическая ошибка в модальном окне

В VA.gov нашли кейс, где VoiceOver, TalkBack и Voice Control уходят за пределы окна обратной связи. Если окно открыто, фон должен быть недоступен не только визуально, но и для программ экранного доступа.

Когда модальное окно открыто, остальной экран не должен жить своей жизнью

В команде VA.gov нашли критическую проблему доступности: если открыть окно обратной связи Feedback, пользователи Voice Control, VoiceOver на iPhone и TalkBack на Android могут уйти фокусом за пределы модального окна и начать читать или нажимать элементы под ним.

Для зрячего пользователя затемнение фона подсказывает, что сейчас активен один слой. Для незрячего или слабовидящего пользователя это неочевидно, если программа экранного доступа продолжает видеть фон. В issue отдельно описано, что выйти за пределы окна можно через rotor в VoiceOver, через reading controls в TalkBack и через Voice Control.

Почему это реально мешает:
- человек теряет контекст и не понимает, где именно он сейчас находится;
- можно случайно активировать кнопку или ссылку под модальным окном;
- само окно обратной связи превращается в ловушку внимания, особенно на длинной странице.

Это не мелкая недоработка. В отчёте это помечено как WEB-212 No keyboard trap с критическим уровнем - блокер перед запуском.

Практический вывод для команд простой: модальные окна нужно проверять не только мышью и табом. Отдельно тестируйте, запирается ли фокус внутри окна, скрыт ли фон для программ экранного доступа, можно ли закрыть окно предсказуемо и не утекает ли доступ к фону через rotor, reading controls и голосовое управление.

Если модалка открыта, фон должен стать недоступным не только визуально, но и семантически.

Когда форма показывает ошибки, но не озвучивает их, это уже поломка сценария, а не косметика.

На VA.gov в конце марта завели отдельный epic по доступности ошибок на страницах проверки формы, а 22 апреля он ещё обновлялся. Сигнал очень живой и, к сожалению, типичный: сообщение об ошибке может не объявляться программой экранного доступа, фокус после нажатия Edit уходит не к полю для правки, а на кнопку ниже, а при нескольких ошибках пользователь может услышать только последнюю.

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

Отдельно показательно, что проблема там не одна, а целый набор:
- ошибки не всегда объявляются после отправки;
- нет нормальной сводки всех ошибок сверху страницы;
- ссылки к полям работают ненадёжно;
- динамические изменения внутри аккордеонов могут проходить для JAWS вообще без озвучивания.

Практический вывод для команд простой: недостаточно просто покрасить поле в красный и вставить alert в DOM. Нужно, чтобы после отправки фокус попадал в правильное место, сводка ошибок была наверху и вела к каждому проблемному полю, а весь сценарий проверялся руками с JAWS, NVDA, VoiceOver и клавиатурой.

Иначе форма формально сообщает об ошибке, но фактически оставляет человека разбираться с ней в одиночку.

Источник: VA.gov issue #6044

Когда список фильтруется, а программа экранного доступа молчит

В свежем разборе Accessibility.chat показан частый сбой: человек вводит запрос, список на экране меняется, а NVDA, JAWS или VoiceOver не сообщают, сколько результатов осталось и есть ли они вообще.

Для зрячего это мгновенная визуальная реакция. Для пользователя экранного доступа - тишина в том месте, где интерфейс уже изменился.

Когда список фильтруется, а программа экранного доступа молчит

В разборе Accessibility.chat разобран типичный сценарий: человек вводит текст в поле поиска, визуально список тут же сужается, но NVDA, JAWS или VoiceOver не сообщают, что изменилось.

Из-за этого пользователь не понимает, сколько совпадений найдено, сработал ли поиск вообще и почему список внезапно стал короче. Если совпадений нет, интерфейс часто тоже молчит. Человек остаётся гадать: запрос не подошёл, поиск ещё думает или страница просто сломалась.

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

Технически проблема обычно простая: список перерисовали, а статус не передали в слой доступности. Нет внятного сообщения о количестве результатов, нет озвученного пустого состояния, нет аккуратно настроенного aria-live для динамических изменений.

Практический вывод для команд очень приземлённый:
- любое динамическое обновление должно иметь текстовый статус;
- после фильтрации нужно сообщать, сколько элементов осталось;
- пустой результат нужно озвучивать явно, а не показывать только глазами;
- такие сценарии надо проверять руками в NVDA, JAWS, VoiceOver и TalkBack, а не полагаться только на автоматические проверки.

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

Когда чат недоступен уже на первом Tab

В новом issue к XMPP-клиенту Dino незрячий пользователь подробно описал, как приложение ведёт себя с Orca на Linux.

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

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

Практический вывод для команд простой: в чатах и мессенджерах мало проверить отдельные aria-метки. Нужно отдельно тестировать переход между областями интерфейса с клавиатуры, чтение истории как структуры «автор, время, текст», доступность действий без hover и озвучивание пустых состояний.

Если мышь остаётся единственным способом выбраться из поля ввода или открыть действие над сообщением, для пользователя программы экранного доступа это уже не запасной путь, а тупик.

Источник: issue #1863 в Dino

Когда мессенджер открывается, а нормально пользоваться чатом всё равно нельзя

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

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

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

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

Список контактов читается как набор ссылок вроде «chat», потому что важная информация о человеке остаётся вокруг, а не входит в понятное имя элемента. Верхняя панель разговора набита кнопками и значками без ясных подписей. Часть действий в сообщениях и боковых блоках вообще не попадает в нормальную клавиатурную навигацию.

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

Отдельно полезно, что автор issue не просто пожаловался, а показал типичные причины:
- списки используются как контейнеры без внятной логики для доступности;
- значки не скрыты от озвучивания и засоряют речь;
- кликабельные элементы не становятся нормальными кнопками или ссылками с понятным именем;
- роль menu местами используется там, где по факту нет корректного меню и нет правильного управления фокусом.

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

Источник: Movim issue #1581

Если боковое меню молчит для NVDA, навигация уже сломана.

В открытом issue к Hiddify для Windows пользователь подробно описал проблему: пункты бокового меню Home, Profiles, Settings, Logs и About получают фокус и даже срабатывают по Enter, но NVDA не озвучивает там ни имя, ни роль, ни состояние.

То есть человек может попасть в навигацию, но дальше идёт почти вслепую даже для screen reader: приходится запоминать порядок пунктов и считать нажатия Tab.

Кого это задевает:
- незрячих пользователей Windows с NVDA и другими программами, которые читают дерево доступности через UI Automation
- слабовидящих пользователей, которым нужна надёжная озвучка фокуса и состояния элементов

Почему это реально мешает:
- боковое меню - это основной способ перехода между разделами
- если у пунктов нет доступного имени и роли, человек не понимает, где он находится
- клавиатурный фокус сам по себе не спасает, если assistive tech не видит элемент как элемент интерфейса

Практический вывод для команд: мало сделать кастомную навигацию, которая "формально работает" с клавиатуры. Нужно проверять, попадают ли её элементы в нативное дерево доступности на целевой платформе, и слышит ли screen reader имя, роль и состояние каждого пункта.

Если пользователь вынужден ориентироваться по памяти и считать Tab, навигация уже недоступна.

Источник: issue #2097 в Hiddify

Редизайн и старые баги снова бьют по доступности.

В свежем обзоре AppleVis сообщество незрячих, слепоглухих и слабовидящих пользователей дало Apple общую оценку 3.7 из 5. Годом раньше было 3.9.

Самый полезный сигнал там не в одной цифре, а в повторяющихся жалобах:
- пользователи VoiceOver и брайлевских дисплеев устали от старых багов и общего качества релизов;
- слабовидящие пользователи пишут, что новый визуальный слой Liquid Glass заметно ухудшил работу с интерфейсом;
- оценка Apple за исправление багов доступности просела до 3.0 из 5.

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

Практический вывод для продуктовых и интерфейсных команд очень прямой:
- крупный редизайн нужно отдельно гонять с незрячими и слабовидящими тестировщиками до релиза, а не после жалоб;
- баги доступности в основных сценариях нужно держать в том же приоритете, что падения и поломку навигации;
- качество доступности надо мерить стабильностью после обновлений, а не только списком новых функций.

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

Источники: Six Colors, 9to5Mac

Когда смена режима ломает ввод целиком

В свежем треде в r/Blind пользователь описал сбой на iPhone с iOS 26.4.2: в экранном брайлевском вводе внезапно поменялись местами точки 4 и 5. Для незрячего пользователя это не мелкая странность интерфейса, а поломка базового действия: в какой-то момент человек просто не может набрать текст.

Проблема ушла после разблокировки и повторной блокировки поворота экрана. Похоже, ввод застрял в настольном режиме. В комментариях другой пользователь тоже пишет, что после обновления брайлевский ввод начал сбоить.

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

Вывод: у поворота, способа ввода и других скрытых режимов нужны явное озвучивание состояния, быстрая проверка текущего режима и восстановление без квеста.

Когда сообщение видно в Slack, но не читается нормально
⠀
Свежий сигнал из GitHub: в проекте на Slack Bolt поймали предупреждение по chat.postMessage. Сообщения собирались из блоков, но без верхнего поля text и без fallback у вложений.
⠀
Для зрячего пользователя такое сообщение может выглядеть нормально: карточка, кнопки, секции, всё на месте. А вот для программы экранного доступа и системных уведомлений важен обычный текстовый слой. В документации Slack прямо сказано: программы экранного доступа по умолчанию читают верхнее поле text, а не внутренние блоки сообщения.
⠀
То есть проблема не в том, что «забыли необязательное поле». Если бот отправляет только красивую блочную разметку, часть людей может получить пустой или неполный смысл сообщения. Особенно неприятно это в рабочих сценариях: алерты, заявки, статусы задач, подтверждения действий.
⠀
Я бы здесь проверял не только внешний вид сообщения, но и запасной текст: что услышит человек в экранном доступе, что попадёт в уведомление, можно ли понять суть без визуальной карточки.
⠀
Хорошее правило для команд: генератор сообщений должен сам собирать короткий текст из блоков и не давать отправить сообщение без понятного текстового слоя. Это дешевле, чем потом чинить каждый бот и каждую карточку отдельно.
⠀
Источник: issue в GitHub и документация Slack по доступности сообщений.

Кнопка должна говорить действие и состояние
⠀
В свежем исправлении Joplin для iOS и Android поправили маленькую, но показательную вещь: переключатель просмотра и редактирования заметки раньше озвучивался как «toggle view/edit».
⠀
Для зрячего пользователя иконка может дать контекст. А пользователь VoiceOver или TalkBack слышит кнопку, но не понимает главное: он сейчас читает заметку или уже редактирует её. В редакторе это легко превращается в случайную правку или в попытку писать там, где правка не включена.
⠀
Исправление простое: кнопка теперь называется по текущему действию - «Edit» или «Stop editing», а при смене режима отдельно озвучивается «Viewing» или «Editing».
⠀
Я бы забрал отсюда правило для экранов с режимами. Если кнопка меняет состояние, одного глагола мало. Человеку нужно услышать текущее состояние и результат переключения. Особенно там, где режим влияет на ввод, оплату или удаление.
⠀
Источник: исправление Joplin.

Тайм-аут сессии может сломать весь сценарий
⠀
Если пользователь медленно вводит данные, читает форму через экранный доступ или дольше обрабатывает информацию, он не обязательно «бездействует». Но интерфейс часто решает иначе: выкидывает из сессии и стирает прогресс.
⠀
Ниже - полный разбор, почему это бьёт по доступности и что командам проверять.

Тайм-аут сессии может сломать весь сценарий
⠀
В Smashing Magazine вышел хороший разбор про тайм-ауты в формах и личных кабинетах. Тема кажется технической: ну истекла сессия, надо снова войти. Но для части пользователей это не мелкая неприятность, а потерянная заявка, покупка или обращение в поддержку.
⠀
Представьте длинную форму. Человек медленнее заполняет поля из-за моторных особенностей, читает форму через экранный доступ, ищет нужный блок с клавиатуры или просто дольше обрабатывает информацию. Для системы он может выглядеть «неактивным». По факту он всё ещё работает с интерфейсом.
⠀
Хуже всего, когда предупреждения нет, сессию нельзя продлить, а уже заполненные поля пропадают. Тогда пользователь платит за чужое решение своим временем и силами. Незрячий человек может заново проходить форму через заголовки, поля и кнопки. Человек с тремором или ДЦП - снова медленно вводить имя, адрес и другие поля. Пользователь с СДВГ или другой когнитивной особенностью - заново собирать контекст.
⠀
Отдельная ловушка - таймеры для экранного доступа. Богдан Церовац описывал случай, когда счётчик озвучивал оставшееся время каждую секунду. Визуально всё вроде нормально, а программа экранного доступа превращается в поток служебных сообщений. Навигация почти останавливается.
⠀
Я бы проверял такие места очень жёстко:
- предупредили ли пользователя заранее, что у формы есть ограничение по времени;
- есть ли понятное предупреждение до выхода из сессии;
- можно ли продлить сессию одним действием;
- сохраняется ли прогресс после повторного входа;
- не спамит ли таймер программу экранного доступа;
- действительно ли тайм-аут нужен именно здесь, а не просто стоит «по умолчанию».
⠀
У DWP в британской дизайн-системе есть простой ориентир: если сессия заканчивается автоматически, пользователя нужно предупредить минимум за 2 минуты и дать продлить время. Это часть доступности, а не украшение интерфейса.
⠀
Для команд вывод простой: «неактивность» в интерфейсе не всегда означает, что человек ушёл. Иногда он читает, ищет, думает, вводит медленнее или работает через вспомогательную технологию. Если тайм-аут стирает его прогресс, сломан не пользовательский темп. Сломан сценарий.
⠀
Источники: Smashing Magazine, DWP Design System, Bogdan Cerovac.

Доступность в медицине снова отложили на год
⠀
HHS в США продлил сроки для сайтов и мобильных приложений организаций, которые получают федеральное финансирование в сфере здравоохранения.
⠀
Было: крупные получатели должны были соответствовать WCAG 2.1 AA к 11 мая 2026 года. Теперь срок сдвинули на 11 мая 2027 года. Для небольших организаций - на май 2028 года.
⠀
Формально причина понятная: клиники, больницы и центры первичной помощи не успевали. Но для пользователя это выглядит иначе. Если портал записи к врачу, форма регистрации, оплата, телемедицина или результаты анализов плохо работают с экранным доступом, человек не получает “чуть менее удобный интерфейс”. Он теряет самостоятельность в медицинском сценарии.
⠀
Особенно это бьёт по незрячим пользователям, людям со слабым зрением, пользователям клавиатуры, экранного доступа, увеличения и других вспомогательных технологий. В медицине цена ошибки выше: нельзя просто “зайти позже”, если нужно записаться, прочитать назначение или отправить данные врачу.
⠀
Я бы не воспринимал перенос срока как паузу. Для команд это скорее проверка зрелости: если доступность появляется только за месяц до юридического дедлайна, значит процесс уже сломан.
⠀
Что стоит проверить в первую очередь:
- вход и восстановление доступа;
- запись и отмену приёма;
- формы регистрации и согласий;
- результаты анализов и назначения;
- оплату и сообщения врачу;
- сторонние модули, которые встроены в продукт.
⠀
Нормальный тест здесь простой: пройти эти сценарии с VoiceOver, NVDA или TalkBack без мыши и без помощи зрячего человека. Если не получается, проблема уже не в стандарте и не в сроках. Проблема в том, что часть пациентов всё ещё не может пользоваться сервисом самостоятельно.

Кейс доступности: подсказки формы должны быть слышны, а не только видны

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

Кейс доступности: подсказки формы должны быть слышны, а не только видны

В форме инвентаря PPCollection рядом с полями были полезные подсказки: где ввести серийный номер, цену покупки, статус, тип оружия и гарантию.

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

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

Что изменили: для helper text и inline error добавлены стабильные id, а поля получили aria-describedby. Теперь видимая инструкция и сообщение об ошибке связаны с контролом не только визуально, но и для assistive technologies.

Стало: при переходе по форме screen reader может объявлять не только название поля, но и связанную подсказку или текст ошибки. Форма стала понятнее без изменения визуального интерфейса.

Разбор и PR подготовлены с помощью Accessibility Auditor Skill — инструмента для поиска и оформления практичных accessibility-улучшений.

Доказательства:
Issue: https://github.com/Gogorichielab/PPCollection/issues/437
PR: https://github.com/Gogorichielab/PPCollection/pull/470