Когда VoiceOver падает на прокрутке ленты, это уже не мелкий баг.

Аккаунт Meta Accessibility в X пишет, что команда разбирается с падением VoiceOver в iOS-приложении Facebook при прокрутке News Feed.

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

Источник: Meta Accessibility

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

Аккаунт Meta Accessibility в X сообщил, что команда разбирается с падением VoiceOver в iOS-приложении Facebook при прокрутке ленты новостей.

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

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

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

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

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

Источник: Meta Accessibility в X

Форумы ломают слепых пользователей. Вот почему.

Все комментарии — один голос. Не видно, кто автор, нет визуальной подписи у реплик, скринридер читает всё одинаково.

Зрячие видят: имя автора, аватар, иерархию ответов. Слепые слышат сплошной поток текста без ориентиров.

Исследование (14 участников): после первых сообщений — усталость и фрустрация. Люди перестают пытаться следить за дискуссией.

Источник: VoxVista, CHIIR 2026

Форумы ломают слепых пользователей. Вот почему.

Все комментарии на странице — один голос. Один. Не видно, кто автор, нет визуальной подписи у реплик, скринридер читает всё одинаково.

Это не мелочь. Это бардак, в котором невозможно понять:

— Кто сейчас говорит
— Кто кого цитирует
— Кому адресована реплика
— Где начинается ответ на конкретный комментарий

Зрячие видят: имя автора слева, аватар, визуальную иерархию ответов. Слепые слышат сплошной поток текста без ориентиров.

Исследование (14 участников, IRB-approved) показало: после первых нескольких сообщений — усталость и фрустрация. Люди просто перестают пытаться следить за дискуссией.

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

Источник: VoxVista, CHIIR 2026. Yash Prakash, Akshay Kolgar Nayak, Mohammed Shoaib Alyaan Sampath Jayarathna, Hae-Na Lee, Vikas Ashok.

Когда одинаковый 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