TalkBack после перелистывания теряет текст
⠀
Свежий багрепорт по Android-читалке Areada: страница визуально сменилась, а экранный диктор не может нормально читать новый текст. Для читалки это ломает главный сценарий - чтение после перехода на следующую страницу.

TalkBack перелистывает страницу, но потом не читает текст
⠀
В GitHub появился свежий багрепорт по Android-читалке Areada: после перелистывания страницы жестом двумя пальцами справа налево TalkBack перестаёт нормально читать текст на новой странице. Пользователю приходится уйти на домашний экран через переключатель приложений и вернуться обратно, чтобы чтение снова ожило.
⠀
Для обычного интерфейса это выглядело бы как мелкая странность. Для читалки это ломает главный сценарий: человек открыл книгу или документ, перевернул страницу и потерял доступ к содержимому.
⠀
Здесь важный момент не в том, что «нужно добавить подписи». В таких экранах надо проверять сам переход: обновилась ли accessibility tree после перелистывания, не остался ли экранный диктор на старом слое, куда попал фокус, можно ли сразу читать новый текст, есть ли понятный способ вернуться назад и продолжить.
⠀
Хороший тест простой: включить TalkBack, открыть длинный текст, несколько раз перелистнуть страницу жестом, прочитать новую страницу подряд и попробовать вернуться. Если после перехода нужен трюк с переключателем приложений - страница визуально сменилась, но интерфейс для экранного доступа не сменился нормально.

Когда кнопка есть, но у неё нет имени
⠀
Свежий кейс: в PTSBuilder левая панель инструментов видима, но важные icon-only кнопки не имеют доступных имён. Полный разбор ниже.

Когда кнопка есть, но у неё нет имени
⠀
В свежем issue по PTSBuilder нашли простой, но неприятный слом: вся левая панель инструментов сделана иконками без доступных имён.
⠀
Визуально там есть кнопки: открыть панель деталей, obstacle, erase, Clear All Parts, Clear All Obstacles. Но подписи живут только в hover-tooltip через div. Для screen reader это не имя кнопки. Для клавиатурного пользователя такой tooltip тоже бесполезен: фокус на кнопку пришёл, а что она делает - непонятно.
⠀
Особенно плохо, что две кнопки ещё и разрушительные. Если незрячий пользователь слышит просто «button» и не понимает, что это очистка всех деталей или всех препятствий, интерфейс уже не даёт безопасно работать.
⠀
Здесь вывод не в том, чтобы «добавить aria-label везде». Проверять надо сам рабочий путь: можно ли без мыши узнать назначение каждой иконки, отличить опасное действие от обычного, увидеть/услышать состояние вроде expanded, и не держится ли подсказка только на hover.
⠀
Хороший быстрый тест для команды: если getByRole("button", { name: ... }) не находит важную кнопку, скорее всего, пользователь с экранным диктором её тоже не найдёт нормально.

Когда доступность не ломается сразу, а уходит по кускам
⠀
В OPNsense открыли свежий issue: слепой пользователь пишет, что веб-интерфейс файрвола раньше был заметно доступнее, а в версиях перед 26 начал деградировать.
⠀
Конкретика неприятная. В выпадающих списках при выборе опции экранный диктор произносит только “section section”. В обзоре интерфейсов и сервисов пропали подписи статусов и кнопок restart/stop. То есть админ вроде бы видит те же таблицы, селекты и кнопки, но пользователь со screen reader уже не может уверенно понять, какой интерфейс в каком состоянии и какую службу он сейчас остановит или перезапустит.
⠀
Для панели управления сетью это не косметика. Ошибка здесь может стоить отключённого сервиса, неверной настройки или просто полной зависимости от зрячего помощника в момент, когда надо быстро чинить доступ.
⠀
Хороший тест для таких интерфейсов: после каждого крупного релиза пройти не только “страница открылась”, а реальные админские сценарии с экранным диктором. Селект должен объявлять выбранный пункт. Статус должен читаться вместе с названием объекта. Кнопка остановки или перезапуска должна говорить, что именно она изменит.
⠀
И ещё: если продукт уже был доступным, это не навсегда. Доступность надо держать регрессионными проверками, как авторизацию, миграции и безопасность.
⠀
Источник: opnsense/core#10605

Статус сообщения - не декоративная галочка
⠀
Свежий TalkBack-сигнал по bitchat-android: приватный чат может визуально показывать ✓, ✓✓, ○ или ⚠, но незрячему пользователю не объяснять, отправлено сообщение, доставлено или упало.
⠀
Полный разбор ниже.

В мессенджере статус сообщения - не декоративная галочка
⠀
В bitchat-android открыли issue: с TalkBack приватные сообщения можно отправлять, но статус «отправляется / отправлено / доставлено / ошибка» озвучивается как сырые значки ✓, ✓✓, ○, ⚠ или вообще непонятно. Новые входящие сообщения тоже не объявляются, если фокус стоит в поле ввода.
⠀
Для зрячего это мелкая иконка в пузыре. Для незрячего пользователя это ответ на базовый вопрос: сообщение ушло, дошло или надо повторить? В приватном чате эта разница важна.
⠀
Отдельно там всплыл хороший тревожный пример: «panic wipe» висит на тройном тапе по заголовку, без понятного имени и, вероятно, без нормальной альтернативы для TalkBack. Деструктивное действие нельзя прятать в жест, который часть пользователей не сможет надёжно выполнить или даже обнаружить.
⠀
Что проверять: статусы должны иметь человеческие labels, новые сообщения - аккуратное live-объявление, кастомные Canvas/WebView элементы - семантику, а опасные действия - доступный путь и подтверждение.
⠀
Источник: issue #747 в permissionlesstech/bitchat-android

Карусель может быть доступной только на вид
⠀
В 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, а пройти главный путь клавиатурой и экранным диктором. И отдельно слушать динамические сообщения, переключатели, списки, формулы и цветовые статусы.