Карусель может быть доступной только на вид
⠀
В eBay Evo Web открыт баг про ebay-carousel: на Android Chrome с TalkBack виртуальный курсор внутри карточек «случайно» пропускает элементы, а свайпы TalkBack начинают прокручивать карусель вместо перехода по содержимому.
⠀
На практике это бьёт по задаче. Если в карточке есть цена, продавец, кнопка, условие доставки или действие «добавить», человек может услышать часть карточки и сразу улететь к следующему контейнеру. Визуально лента живёт, а маршрут обследования интерфейса ломается.
⠀
В комментарии разработчик нашёл два вероятных места: список карусели - настоящий горизонтальный scroll container со scroll-snap, а каждый li получает aria-hidden="true", если карточка не полностью видима с точностью примерно до сотых пикселя. Во время прокрутки карточка может то появляться, то исчезать из дерева доступности.
⠀
Что проверить командам:
- TalkBack/VoiceOver проходит все элементы каждой карточки по порядку;
- свайп экранного диктора не превращается в прокрутку карусели;
- частично видимые и анимирующиеся карточки не выдёргивают полезный контент из дерева доступности;
- у карусели есть понятная клавиатурная и экранная модель: где текущая карточка, куда движемся, что можно открыть.
⠀
Для товарных, новостных и обучающих каруселей это особенно важно. Карусель часто ставят туда, где лежит главный выбор пользователя. Если этот выбор нельзя последовательно прочитать и активировать без зрения, это уже не декор, а барьер в основном сценарии.
⠀
Источник: eBay/evo-web#333

MakeCode сделал блочные редакторы чуть менее закрытым клубом
⠀
В релизе 2026 для micro:bit появилась поддержка экранных дикторов в блочном редакторе. Важная деталь: они не просто подписали кнопки, а описали рабочий путь - клавиатура, структура блоков, вложенность, задания и материалы для учителей.
⠀
Полный разбор ниже.

MakeCode сделал блочные редакторы чуть менее закрытым клубом
⠀
В июльском релизе Microsoft MakeCode for micro:bit появилась поддержка экранных дикторов в блочном редакторе. Micro:bit отдельно описал, что это делали вместе с Blockly, учителями и незрячими или слабовидящими учениками.
⠀
Почему это больше, чем приятная новость? Блочное программирование часто выглядит как лёгкий вход в код: перетащи блоки, соедини, запусти. Но для человека с экранным диктором или без мыши это может быть не входом, а стеной. Если рабочее пространство живёт только как визуальная схема, ученик слышит отдельные элементы, но не может нормально понять структуру программы, вложенность, место блока и следующий шаг.
⠀
В MakeCode важна именно связка, а не одна галочка «доступно». Клавиатурное управление теперь включено по умолчанию. Поддерживаются NVDA, JAWS, Narrator, VoiceOver и ChromeVox. В режиме для экранного диктора есть жёсткие остановки при обходе блоков и звуковая подсказка при смене уровня вложенности. На стороне micro:bit добавили отдельные стартовые задания, подсказки для учителей, тактильные материалы и FAQ: как попасть в рабочую область, как скачать программу на устройство, что делать с браузерным caret browsing.
⠀
Вот что стоит забрать для интерфейсов с канвасом, карточками, drag-and-drop и визуальными схемами: нельзя ограничиться подписями кнопок. Нужно дать полноценный путь выполнения задачи без мыши и зрения: найти рабочую область, понять структуру, выбрать элемент, переместить или изменить его, проверить результат и вернуться назад без потери контекста.
⠀
Если продукт учит, настраивает, проектирует или собирает что-то из визуальных частей, тест должен быть простым: может ли человек пройти тот же урок или сценарий с клавиатурой, экранным диктором и, при необходимости, тактильной/текстовой опорой? Если нет - это не альтернативный способ использования, а отдельная дорожка для тех, кого основной интерфейс не пустил внутрь.

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

Инсталлятор тоже часть продукта
⠀
В issue FlyByWire Installer #550 пользователь экранного диктора BlindPilot93 описал не абстрактную «нужна доступность», а обычный путь установки.
⠀
В инсталляторе много переключателей сделаны не как стандартные чекбоксы. Для зрячего это может выглядеть как нормальный toggle. Для screen reader user это уже вопрос: что это за элемент, включён он или выключен, можно ли им управлять предсказуемо.
⠀
Второй пример ещё показательнее: диалоги с общим размером скачиваемых пакетов появляются визуально, но не как настоящие модальные окна. Они оказываются в начале документа, куда пользователь экранного диктора обычно не попадает в момент действия. То есть важное предупреждение вроде бы есть, но человек может его просто не услышать.
⠀
Это мешает не «красоте интерфейса», а установке и обновлению софта: выбрать нужные опции, понять объём загрузки, не пропустить подтверждение.
⠀
Что проверять командам: все переключатели — как реальные checkbox/switch с именем и состоянием; все подтверждения — как модальные диалоги с фокусом внутри, понятным заголовком, кнопками и возвратом фокуса назад. Особенно в инсталляторах, checkout, настройках и обновлениях: это места, где ошибка стоит дороже обычного клика.

Карта есть, маркера для TalkBack нет
⠀
В MapLibre React Native нашли баг: маркер рисуется на Android-карте, но его обёртка остаётся 0×0, поэтому TalkBack вообще не видит этот объект.
⠀
Полный разбор ниже.

Видимый маркер на карте может быть невидимым для TalkBack
⠀
В MapLibre React Native открыли хороший баг по Android: React-компонент внутри Marker рисуется на карте, но полностью отсутствует в дереве доступности. Пользователь TalkBack не может сфокусировать маркер, не слышит его название, а uiautomator dump вообще не показывает узел маркера.
⠀
Причина почти бытовая: обёртку маркера перемещают по координатам x/y, но ей не задают реальный layout-размер. Визуально дочерний компонент всё равно виден, потому что clipping отключён. А для Android accessibility это 0×0 view, и такой кусок интерфейса просто исчезает.
⠀
Для карт это не мелочь. Маркер может быть точкой доставки, автобусной остановкой, объектом на маршруте, аварией, рестораном, чем угодно. Зрячий пользователь видит точку и нажимает. Пользователь TalkBack слышит карту без этих объектов.
⠀
Что стоит проверять командам: не только “есть ли label у маркера”, а попадает ли маркер в accessibility tree с реальными bounds, можно ли дойти до него свайпами TalkBack, слышно ли название и не ломается ли нажатие после фикса. Особенно если маркеры, подсказки или карточки поверх карты рисуются через кастомные обёртки.

Пароль скрыт на экране, но VoiceOver читает его вслух
⠀
Свежий баг во Flutter: obscureText: true маскирует поле визуально, но экранный диктор на iOS может произносить вводимые символы. Проверять нужно не только точки в поле, а весь путь ввода с VoiceOver/TalkBack.
⠀
Полный разбор ниже.

Когда пароль скрыт на экране, но произносится вслух
⠀
В Flutter завели свежий баг: если в iOS-приложении поле сделано как пароль через obscureText: true, VoiceOver при вводе может читать реальные символы вслух. Визуально всё выглядит правильно: поле «замаскировано», на экране пароль не виден. Но для человека со включённым VoiceOver секрет уже может прозвучать рядом с другими людьми.
⠀
Это не просто «неудобное озвучивание». Парольное поле обычно используют в ситуации, где пользователь рассчитывает на приватность: вход в аккаунт, кошелёк, почта, рабочий сервис, медкарта. Если экранный диктор произносит вводимые символы, незрячий пользователь получает выбор без нормального выбора: либо вводить пароль и рисковать утечкой на слух, либо искать обходной путь.
⠀
Для команд вывод простой: недостаточно проверить, что пароль визуально закрыт точками. Нужно включить VoiceOver/TalkBack и пройти сам ввод: что произносится при фокусе, при наборе, при удалении, при автозаполнении, при ошибке и при повторном показе поля.
⠀
Особенно важно не доверять только свойству компонента вроде obscureText. В фреймворке, браузере или нативном мосте может быть баг, и тогда визуальная защита остаётся, а звуковая — ломается.
⠀
Источник: flutter/flutter#190320

Субтитры могут сломаться без одной пропавшей строки
⠀
В ShouMeiPlayer, Android TV-клиенте для Jellyfin, открыли свежий баг: приложение читает системные настройки субтитров Android и сразу применяет их к mpv. Размер, цвет, обводка и язык перезаписываются даже тогда, когда системные субтитры выключены.
⠀
Для глухого или слабослышащего человека субтитры - не украшение. Если он выставил крупный размер, контрастный цвет или нужный язык внутри приложения, а другой слой молча заменил это дефолтами системы, видео становится сложнее смотреть. Проблема выглядит не как «субтитров нет», а как «они есть, но стали нечитабельными или не на том языке».
⠀
Проверка простая: поменять настройки субтитров в системе, выключить их, потом поменять настройки внутри плеера и пройти воспроизведение. Команда должна заранее решить, кто главный в конфликте настроек, и не применять системный стиль, если пользователь его не включал.
⠀
Источник: maik205/shoumeiplayer#97

Когда «плавная прокрутка» реально укачивает
⠀
В issue к Lenis разработчик написал, что после сайта на популярной библиотеке плавной прокрутки почувствовал тошноту и головокружение. У него включён prefers-reduced-motion, но Lenis по умолчанию эту настройку не учитывал.
⠀
Для человека с вестибулярной чувствительностью это не «красивая анимация», а риск испортить себе несколько часов из-за страницы, где движение оторвано от пальца, колеса мыши или трекпада.
⠀
Мейнтейнер Lenis ответил: библиотека будет уважать prefers-reduced-motion по умолчанию. В режиме reduce прокрутка должна идти 1:1, без интерполяции; якоря и scrollTo - мгновенно. Игнорирование настройки станет явным выбором разработчика.
⠀
Командам стоит проверять весь motion-слой: CSS-анимации, плавную прокрутку, карусели, переходы и JS-таймеры. Всё это должно слушать Reduce Motion на реальной странице.
⠀
Источник: Lenis issue #534

Доступность нельзя проверить только глазами по разметке
⠀
В The Infinity открыли задачу с честной формулировкой: «ни один экранный диктор ещё не был направлен на этот сайт».
⠀
В коде уже были aria-*, role, фокус-стили и prefers-reduced-motion. Но проверка accessibility tree нашла другое: role="status" создавался вместе с сообщением, tablist не реагировал на стрелки, а d_model превращался в слитное dmodel.
⠀
Вывод простой: DOM может выглядеть заботливо, но главный путь всё равно нужно пройти клавиатурой и экранным диктором.
⠀
Полный разбор ниже.

Доступность нельзя проверить только глазами по разметке
⠀
В проекте The Infinity открыли хорошую задачу с честной формулировкой: «ни один экранный диктор ещё не был направлен на этот сайт».
⠀
До этого в коде уже были aria-*, role, фокус-стили и prefers-reduced-motion. На бумаге всё выглядело заботливо. Но проверка accessibility tree быстро нашла вещи, которые из разметки не очевидны.
⠀
Например, подтверждения формы создавались вместе с role="status". Для экранного диктора это может быть не «изменение уже существующей области», а новый кусок страницы — и сообщение легко не прозвучит. Таб-переключатель назывался tablist, но стрелки внутри него не работали. А математические обозначения вроде d_model превращались в слитное dmodel.
⠀
Это мешает не абстрактному «пользователю с особыми потребностями», а человеку, который пытается понять страницу, выбрать глубину объяснения, отправить форму или прочитать формулу вслух.
⠀
Хорошая проверка здесь простая: не только посмотреть DOM, а пройти главный путь клавиатурой и экранным диктором. И отдельно слушать динамические сообщения, переключатели, списки, формулы и цветовые статусы.

В v2rayNG завели свежий issue: TalkBack работал в 2.2.6, а с 2.3.1 основные экраны стали заметно хуже. Хорошее напоминание: доступность тоже надо держать в regression-check перед релизом.

Регрессия доступности — это тоже регрессия
⠀
В v2rayNG завели свежий issue: автор пишет, что Android-приложение нормально работало с TalkBack в версии 2.2.6, а начиная с 2.3.1 стало заметно хуже. Под экранный диктор плохо попадают основной экран, список серверов, кнопка подключения, настройки и меню.
⠀
Это не косметика. Для незрячего пользователя VPN-клиент — не просто «открыть приложение». Нужно выбрать сервер, понять текущий статус, подключиться или отключиться, не нажать случайно не тот профиль, открыть настройки. Если TalkBack перестаёт нормально видеть элементы, человек теряет контроль над сетевым инструментом.
⠀
Интересная деталь: в этом же репозитории уже был большой accessibility-issue в декабре 2025 года и несколько PR в феврале 2026-го — добавляли contentDescription, прятали декоративные иконки, подписывали кнопки. То есть часть доступности уже чинили. Но новый отчёт говорит о другом: однажды исправленное не становится вечным.
⠀
Командам стоит проверять доступность как обычную регрессию перед релизом. Не только «есть ли подписи у кнопок», а весь путь: TalkBack фокусируется на списке серверов, читает названия и состояния, озвучивает подключение/отключение, даёт открыть меню и настройки без зрения. Если версия 2.2.6 это умела, а 2.3.1 уже нет — это такой же повод для блокирующего бага, как сломанная кнопка мышью.

В Signal Desktop меню есть, но NVDA до него не добирается
⠀
В свежем issue к Signal Desktop пользователь описал Windows-кейс: с NVDA можно открыть «New chat», дойти до кнопки «Manage contact» рядом с контактом и нажать Enter. Визуально появляется pop-out menu, но экранный диктор его не видит: ни Tab, ни команды NVDA не дают выбрать пункты.
⠀
Это не падение приложения: мышью меню работает, и команда Signal уже подтвердила баг. Для зрячего пользователя действие есть, а для пользователя экранного диктора оно как будто исчезает.
⠀
Задевает это и тех, кто работает с клавиатуры, переключателями или голосом: открывшийся слой должен попасть в фокусный путь и дерево доступности.
⠀
После Enter/Space надо пройти сами пункты: фокус попал внутрь, роли и названия читаются, Escape закрывает слой, фокус возвращается на «Manage contact».
⠀
Источник: signalapp/Signal-Desktop#7982

Граф, который нельзя обойти с клавиатуры
⠀
В PatternFly React Topology завели issue: узлы и связи в topology-view визуально есть, но для клавиатуры и экранного диктора почти исчезают. `withSelection()` реагирует на мышь, а у узлов нет фокуса, клавиатурной активации и понятных имён для озвучивания.
⠀
Это не абстрактное «ARIA не проставили». Источник пишет, что в большом приложении на Ansible UI такие графы используются для workflow. Мышью можно ткнуть в шаг процесса. Человек, который работает с клавиатуры, switch control или NVDA/JAWS, может не попасть на этот шаг и не понять, где ошибка, куда двигаться дальше и что связано с чем.
⠀
Для графов, карт, схем, kanban-досок и pipeline-экранов проверка простая: можно ли пройти элементы Tab/стрелками, услышать имя и состояние каждого узла, активировать его Enter/Space и понять связи без картинки.
⠀
Если ответ «нет», интерфейс показывает структуру только тем, кто может пользоваться мышью.

Терминал, который видно только глазами
⠀
В T3 Code открыли issue про встроенный терминал: он рисуется в canvas и помечен aria-hidden. Для NVDA это стена: вывод команды не читается, введённый текст выглядит пустым, а при нескольких терминалах непонятно, какая сессия активна.
⠀
Это не задача уровня «добавить пару подписей». В coding-инструменте терминал — часть основного рабочего пути. Если пользователь без зрения не может прочитать stdout, ошибку или свой ввод перед Enter, агентный интерфейс становится декоративным.
⠀
Минимально полезное решение: читаемый буфер со scrollback как обычный фокусируемый текст + ненавязчивый сигнал, что команда завершилась. VS Code пришёл к похожей модели через accessible view терминала.
⠀
Проверка для команды: запустить команду с NVDA/JAWS/VoiceOver и ответить честно — можно ли прочитать вывод, проверить ввод, понять активный терминал и вернуться к результату?
⠀
Источник: pingdotgg/t3code#5500

Когда доступность включает тяжёлый режим приложения
⠀
В Status App завели issue: на Redmi A5 Android-приложение после логина может зависнуть, если включён TalkBack, Switch Access или другой accessibility service.
⠀
Без такого сервиса тот же путь медленный, но стабильный. С ним приложение перестаёт отвечать больше чем на 5 секунд, Android показывает ANR, а TalkBack в этот момент тоже молчит. Для зрячего пользователя это «приложение подвисло». Для пользователя экранного диктора это ещё и потеря ориентации: экран не отвечает и ничего не говорит.
⠀
Сильная деталь: проблема не в подписи кнопок. Похоже, Qt-слой доступности синхронно ждёт дерево элементов, пока основной интерфейс занят тяжёлой работой после логина. Доступность добавляет настоящую нагрузку к сценарию.
⠀
Командам стоит прогонять первый запуск и логин на слабом устройстве с TalkBack/Switch Access: слабое железо, включённый экранный доступ, первые 30 секунд после входа. Иначе интерфейс может быть формально доступным, но зависать как раз у тех, кому он нужен.

Когда интерфейс говорит слишком точно

В MuseScore обсуждают маленькую, но очень показательную проблему: при навигации по нотам экранный диктор может произносить позицию так: «measure 1, beat 3.666667».

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

Хороший вывод для любых интерфейсов: текст для assistive tech не обязан быть буквальной копией того, что видно на экране. Если на экране можно показать техническое значение, то в речи лучше дать короткую, понятную форму: округлить число, заменить машинную дробь словами или вынести отдельную фразу специально для screen reader users.

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

Видео в компоненте: не только субтитры
⠀
Нашла хороший свежий сигнал в Visual Framework: для компонента vf-video завели issue про доступность YouTube-вставок.
⠀
С виду всё обычно: компонент получает ссылку на видео и рисует iframe. Но в аудите нашли простую вещь - у iframe нет title. Для зрячего пользователя это просто ролик на странице. Для screen reader user это может быть безымянная рамка: непонятно, что открылось, зачем оно здесь и стоит ли в это заходить.
⠀
Интересно, что issue не сводится к «добавьте один атрибут». Там отдельно обсуждают:

- сделать название видео обязательным или хотя бы явно предупреждать авторов;
- как связать компонент с транскриптом;
- убрать autoplay из разрешений по умолчанию и включать его только осознанно.
⠀
Это уже затрагивает не одну группу пользователей. Незрячему человеку нужен понятный объект в дереве доступности. Глухому или слабослышащему - нормальный путь к текстовой версии. Человеку, чувствительному к резкому звуку или движению, не нужен компонент, который заранее разрешает автозапуск просто «на всякий случай».
⠀
Вывод для команд простой: если у вас есть общий video/embed-компонент, проверяйте не только сам плеер. Проверьте контракт компонента:

1. есть ли у iframe понятное имя;
2. есть ли рядом ссылка на транскрипт или понятный способ её задать;
3. не включён ли autoplay по умолчанию;
4. говорит ли документация авторам, что именно они обязаны передать.
⠀
Иначе доступность видео каждый раз перекладывается на автора страницы. А общий компонент как раз нужен для обратного - чтобы безопасный шаблон был по умолчанию.
⠀
Источник: visual-framework/vf-core#2427