Когда чат недоступен уже на первом 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

Мини-кейс: вернули видимый фокус на сайте Joplin

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

Мини-кейс: вернули видимый фокус на сайте Joplin

Было: на сайте глобальный CSS-сброс убирал outline у всех элементов. Часть ссылок-кнопок при Tab-навигации получала фокус, но визуально это почти не было видно.

Что это ломало: пользователь с клавиатурой или screen reader мог перейти на кнопку, но зрячий клавиатурный пользователь не понимал, где он находится. Это напрямую бьёт по WCAG 2.4.7 Focus Visible.

Что изменили: убрали глобальное подавление outline и добавили общий :focus-visible стиль для ссылок, кнопок, полей форм и custom tabindex-контролов.

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

Разбор и выбор правки делала через Accessibility Auditor Skill: он помогает быстро связать симптом, код и критерий WCAG, чтобы не чинить “на глаз”.

Доказательство:
Issue: https://github.com/laurent22/joplin/issues/15264
PR: https://github.com/laurent22/joplin/pull/15378

Когда интерфейс говорит слишком много
⠀
В pty-speak поймали хороший, очень практический баг: команда dir в preview-сборке могла отправить в NVDA один огромный кусок вывода. Дальше SAPI начинал озвучивать его как одну фразу на 5-10 минут.
⠀
Проблема не в том, что текста было много. Хуже другое: пользователь уже не может нормально остановить поток и быстро вернуться к работе. Для незрячего человека терминал в этот момент превращается из инструмента в ловушку ожидания.
⠀
В PR #293 предложили нормальный ремонт: автоматическое озвучивание режется до последних 800 символов, а полный вывод открывается отдельной командой Ctrl+Shift+O в текстовом редакторе.
⠀
Я бы здесь забрал простое правило для любых интерфейсов с озвучкой: не отправлять в экранный доступ бесконечные простыни как одно уведомление. Коротко озвучить главное - да. Дать отдельный способ открыть полный текст - обязательно.

Мини-кейс доступности: ошибки формы должны быть слышны

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

Мини-кейс доступности: ошибки формы должны быть слышны

Было: форма показывала текст ошибки под полем, но для screen reader он не был явно связан с самим полем.

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

Что изменили: в общих компонентах Input и Textarea добавили aria-invalid, связь с текстом ошибки через aria-describedby, а саму ошибку пометили role="alert". Теперь это работает сразу для форм, которые используют эти компоненты.

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

Кейс подготовлен через Accessibility Auditor Skill.

Доказательство:
Issue: github.com/Vets-Who-Code/vets-who-code-app/issues/895
PR: github.com/Vets-Who-Code/vets-who-code-app/pull/1120

ИИ в проверке доступности не закрывает главный риск
⠀
По свежему отчёту Applause, 78% организаций уже используют ИИ для доступности, но 56% пользователей assistive tech всё равно регулярно встречают недоступные приложения.
⠀
Полный разбор ниже.

ИИ в проверке доступности не закрывает главный риск
⠀
Applause выпустил отчёт по доступности за 2026 год, и там хорошо видно противоречие: 78% организаций уже используют ИИ для улучшения доступности, но 56% пользователей assistive tech с начала года регулярно встречали недоступные приложения.
⠀
Для людей с экранным доступом, увеличением шрифта, субтитрами или альтернативной навигацией это не абстрактный дефект. Если приложение не работает с такими инструментами, 92% пользователей готовы его бросить.
⠀
Мне здесь важна не цифра сама по себе, а разрыв между «мы проверяем доступность» и «человек не может закончить задачу». Автопроверка может найти часть ошибок в коде. Но она легко пропускает контекст: странный порядок табуляции, лишний текст в screen reader, фильтр без понятного состояния, кнопку без смысла в реальном сценарии.
⠀
В отчёте есть и нормальная трезвость: только 10% организаций полагаются на ИИ-инструменты без ручной проверки. Остальные всё-таки сверяют результат людьми. Но ручная проверка тоже бывает разной. Одно дело - пройти чек-лист мышкой и клавиатурой. Другое - дать сценарий человеку, который каждый день пользуется NVDA, JAWS, VoiceOver, увеличением или head pointer.
⠀
Я бы из этого вынес простое правило для команд: ИИ можно использовать как быстрый первый слой, но не как финальный ответ. Если сценарий важный - регистрация, покупка, оплата, поиск, поддержка, медицинская запись - его нужно прогонять с реальными вспомогательными технологиями и реальными пользователями.
⠀
Иначе команда видит зелёный отчёт, а пользователь всё равно упирается в молчащую кнопку или форму, из которой невозможно выбраться.

Ежедневный accessibility PR

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