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

Пользователь VoiceOver на iPhone пожаловался, что после обновления PhonePe перестал работать экран ввода UPI PIN: приложение озвучивает только secure text field и не даёт ввести PIN. А встроенный раздел помощи тоже недоступен, поэтому баг нельзя нормально отправить из самого приложения.

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

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

Источник: тред в X

Когда незрячие пользователи уже не ждут фикс, а делают свой слой поверх продукта

Свежий сигнал из Double Tap: Стивен Скотт рассказал, как с помощью ИИ собрал скрипт для более доступной работы с Farrago под VoiceOver, сделал дополнение для NVDA и начал своё веб-приложение без классической разработки.

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

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

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

Когда alt-текстов нет, купить товар без зрения становится лотереей.
⠀
В Южной Корее Верховный суд обязал крупные маркетплейсы исправить работу со screen reader и добавить доступные описания товаров. Суд прямо связал отсутствие текстовой альтернативы с дискриминацией.
⠀
Для команд вывод простой: карточка товара - это не картинка с ценой рядом. Если название, состояние, опции и ключевые детали не читаются вслух последовательно и без догадок, пользователь теряет доступ к покупке.

Суд обязал маркетплейсы исправить доступность для незрячих пользователей
⠀
Свежий сигнал из Южной Кореи: Верховный суд оставил в силе решение против крупных площадок Gmarket, SSG.com и Lotte Shopping. Причина простая и очень знакомая: незрячие пользователи не могли нормально читать карточки товаров через screen reader, потому что у нетекстового контента не было доступных текстовых описаний.
⠀
По материалам The Korea Herald и The Asia Business Daily, суд потребовал исправить это в течение шести месяцев после вступления решения в силу. Отдельно важно, что площадки ссылались на продавцов: мол, контент загружают они. Но суд всё равно увидел обязанность платформы обеспечить разумную доступность.
⠀
Это важный практический момент. Во многих интерфейсах ответственность расползается между командами, CMS, продавцами, подрядчиками и шаблонами карточек. В итоге у изображения товара нет понятного текста, варианты товара не проговариваются, а screen reader читает страницу кусками, из которых нельзя собрать решение о покупке.
⠀
Для незрячего пользователя это не мелкая шероховатость. Если не слышно, что именно за товар, чем отличаются варианты, есть ли важные параметры или ограничения, покупка превращается в угадайку. А если ошибка обнаруживается только после оплаты или доставки, вред уже вполне реальный.
⠀
Вывод для команд такой:
- не перекладывайте доступность карточек на автора контента или продавца;
- проверяйте, как страница товара читается вслух целиком, от названия до выбора варианта и кнопки покупки;
- требуйте текстовые альтернативы и понятные подписи на уровне платформы, а не доброй воли отдельных поставщиков;
- тестируйте не только главную страницу и каталог, но и сам момент выбора товара.
⠀
Если платформа не даёт незрячему пользователю понять, что он покупает, это уже не просто недоработка интерфейса. Это ограничение доступа к услуге.

Когда доступность называют «фичей»

В X пожаловались на Toggl: десктопное приложение не реагирует на системный размер текста Windows, а в веб-версии много кнопок без подписей для экранного доступа.

Для слабовидящих это слишком мелкий интерфейс. Для незрячих - элементы, смысл которых экранный диктор не может прочитать.

Это не «хотелка», а базовая совместимость интерфейса с настройками системы и вспомогательными технологиями.

Источник в X

Когда доступность называют «фичей»

В X появился очень показательный сигнал по Toggl. Один из пользователей написал, что десктопное приложение не учитывает системный размер текста Windows, а в веб-версии много кнопок без подписей для экранного доступа.

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

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

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

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

Источник в X

Суд обязал маркетплейс добавить alt-текст к карточкам товаров

В Южной Корее Верховный суд оставил в силе требование к Gmarket: изображения товаров должны иметь текстовые описания, которые читают программы экранного доступа.

Для незрячего пользователя это не косметика. Без такого описания карточка товара превращается в пустое место или в набор бессмысленных элементов.

Источник: CHOSUNBIZ

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

Свежий сигнал из Южной Кореи: Верховный суд оставил в силе требование к Gmarket добавить альтернативный текст для изображений товаров. Поводом стал иск 32 пользователей с нарушением зрения, которые указали, что без таких описаний доступ к товарам и информации о них оказывается неравным.

Что здесь важно по сути.

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

Это бьёт не только по просмотру каталога. Ломается сама покупка: выбор товара, сравнение вариантов, проверка, того ли цвета или модели позиция добавлена в корзину.

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

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

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

Источник: CHOSUNBIZ

Когда 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, биометрия, переход между шагами, ошибки, загрузка и смена состояния должны быть озвучены и управляемы так же надёжно, как и обычные формы.

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