Когда одинаковый aria-label ломает весь список

В свежем кейсе Skosmos экранный доступ в боковом списке перестал читать сами термины: вместо названий NVDA озвучивает одну и ту же фразу - «перейти на страницу понятия».

Для зрячего человека список ещё виден. Для незрячего он почти теряет смысл.

Когда одинаковый aria-label ломает весь список

В свежем кейсе Skosmos сломался боковой список терминов для пользователей экранного доступа. Проблема простая и очень показательная: ссылкам добавили aria-label с дополнительной подсказкой, но он перекрыл видимый текст ссылки.

В итоге NVDA читает не «aakkostus», «AA liike» и другие названия, а одну и ту же фразу вроде «Go to concept page». То есть человек слышит, что перед ним ссылка, но не понимает, куда она ведёт.

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

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

Такие ошибки особенно коварны тем, что визуально интерфейс выглядит нормальным. Поломка живёт только в слое доступности, а значит без реальной проверки NVDA, VoiceOver или TalkBack команда может долго её не замечать.

Источник: issue в GitHub, там же есть описание проблемы и ожидаемого поведения.

95.9% главных страниц популярных сайтов уже на старте ломают WCAG.
⠀
Свежий WebAIM Million 2026 показывает не абстрактную "недоступность", а повторяющиеся поломки: низкий контраст, изображения без alt, поля без подписей, пустые ссылки и кнопки.
⠀
Для пользователей скринридеров это означает простые вещи: кнопку не найти, форму не заполнить, навигацию не понять.
⠀
Ниже - короткий разбор и вывод для команд.

Когда почти весь веб ломает базовые вещи, это уже не мелкие огрехи.
⠀
В свежем отчёте WebAIM Million 2026 автоматическая проверка охватила 1 000 000 главных страниц. На 95.9% страниц нашли ошибки WCAG, а среднее число проблем выросло до 56.1 на страницу.
⠀
Самое показательное здесь не общий процент, а состав ошибок. 96% найденных проблем снова укладываются в шесть старых категорий:
- низкий контраст текста - 83.9% страниц
- изображения без alt - 53.1%
- поля формы без подписей - 51%
- пустые ссылки - 46.3%
- пустые кнопки - 30.6%
- не указан язык документа - 13.5%
⠀
Для незрячих и слабовидящих пользователей это не "формальные замечания". Это ситуации, где скринридер озвучивает кнопку без имени, ссылка ничего не объясняет, поле ввода нельзя понять без догадок, а структура страницы разваливается как способ навигации.
⠀
Отдельно тревожит рост сложности. В среднем на главной странице уже 1437 элементов, и за год это ещё +22.5%. Чем тяжелее интерфейс, тем больше точек, где команда может потерять имя элемента, подпись, порядок заголовков и смысловую структуру.
⠀
Практический вывод для команд простой:
- сначала чинить базовые имена и подписи элементов
- не выпускать пустые icon-only кнопки без доступного имени
- проверять формы и навигацию со скринридером, а не только глазами
- считать рост DOM и визуальной сложности не нейтральным фактом, а фактором риска
⠀
Если на сайте нельзя надёжно пройти по заголовкам, понять кнопку и заполнить поле, проблема уже не в "особых сценариях". Это сломанный базовый путь.
⠀
Источник: WebAIM Million 2026.

Когда колледж блокирует не вход, а доступ к учёбе

NPR вынес в заголовок жёсткий, но очень точный сигнал: незрячие студенты говорят, что цифровые системы колледжей буквально мешают получать образование. На этом фоне Минюст США уже перенёс сроки по правилу Title II, которое обязывает государственные и муниципальные сайты и приложения быть доступными.

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

Когда колледж блокирует не вход, а доступ к учёбе

Свежий сигнал пришёл сразу с двух сторон.

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

Вторая - фактшит Минюста США по правилу Title II. В нём прямо сказано, что недоступные сайты и мобильные приложения госструктур создают барьеры для людей с инвалидностью. Например, если на сайте есть важное изображение без alt-текста, экранный доступ просто не передаст его смысл. Если форма, документ или приложение не рассчитаны на экранный доступ, человек может потерять доступ к услуге, информации или учебному процессу.

Почему это важно для интерфейсов

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

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

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

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

Источники:
- NPR - материал о незрячих студентах и цифровых барьерах в колледжах
- DOJ Fact Sheet по правилу Title II

Когда новый ответ появляется, а screen reader уводит назад

В свежем issue по Codex Desktop незрячий пользователь описал поломку, которая хорошо знакома многим пользователям экранного доступа. После недавнего обновления NVDA не переводит фокус на новый ответ ассистента. Вместо этого чтение остаётся на старых сообщениях или прыгает назад по ветке.

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

Отдельно показательно, что автор сравнил это с ChatGPT в браузере. Там, по его словам, сообщения отделены друг от друга понятнее, и NVDA легче перемещается между блоками даже в длинных разговорах. Полезный ориентир для любой команды: проблема часто не в самом screen reader, а в том, как интерфейс собирает структуру диалога и что делает с фокусом после обновления.

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

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

Источник: GitHub issue

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

В свежем issue по EU Digital Identity Wallet для Android описан жёсткий сбой доступности: на шаге Security пользователь слышит кнопку Confirm и клавиатуру, но не воспринимает сами поля PIN. Цифры подставляются, шаг меняется, ошибки появляются - и всё это почти без озвучивания.

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

Когда 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