TGViewer
Channel Public Channel
Всё про доступность интерфейсов

Всё про доступность интерфейсов

@accessibilityofinterfaces

Subscribers
7
Photos
116
Videos
0
Links
193

Showing posts older than #232 · Back to latest

Older Posts 20 shown
Post #231 5
Терминал, который видно только глазами

В T3 Code открыли issue про встроенный терминал: он рисуется в canvas и помечен aria-hidden. Для NVDA это стена: вывод команды не читается, введённый текст выглядит пустым, а при нескольких терминалах непонятно, какая сессия активна.

Это не задача уровня «добавить пару подписей». В coding-инструменте терминал — часть основного рабочего пути. Если пользователь без зрения не может прочитать stdout, ошибку или свой ввод перед Enter, агентный интерфейс становится декоративным.

Минимально полезное решение: читаемый буфер со scrollback как обычный фокусируемый текст + ненавязчивый сигнал, что команда завершилась. VS Code пришёл к похожей модели через accessible view терминала.

Проверка для команды: запустить команду с NVDA/JAWS/VoiceOver и ответить честно — можно ли прочитать вывод, проверить ввод, понять активный терминал и вернуться к результату?

Источник: pingdotgg/t3code#5500
GitHub [Feature]: Terminal content is not exposed to screen readers · Issue #5500 · pingdotgg/t3code Before submitting I searched existing issues and did not find a duplicate. I am describing a concrete problem or use case, not just a vague idea. Area apps/web (equally affects apps/desktop, which ...
Post #230 6
Граф, который нельзя обойти с клавиатуры

В PatternFly React Topology завели issue: узлы и связи в topology-view визуально есть, но для клавиатуры и экранного диктора почти исчезают. `withSelection()` реагирует на мышь, а у узлов нет фокуса, клавиатурной активации и понятных имён для озвучивания.

Это не абстрактное «ARIA не проставили». Источник пишет, что в большом приложении на Ansible UI такие графы используются для workflow. Мышью можно ткнуть в шаг процесса. Человек, который работает с клавиатуры, switch control или NVDA/JAWS, может не попасть на этот шаг и не понять, где ошибка, куда двигаться дальше и что связано с чем.

Для графов, карт, схем, kanban-досок и pipeline-экранов проверка простая: можно ли пройти элементы Tab/стрелками, услышать имя и состояние каждого узла, активировать его Enter/Space и понять связи без картинки.

Если ответ «нет», интерфейс показывает структуру только тем, кто может пользоваться мышью.
Post #229 6
В 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
Post #228 6
Регрессия доступности — это тоже регрессия

В 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 уже нет — это такой же повод для блокирующего бага, как сломанная кнопка мышью.
GitHub TalkBack accessibility regression since v2.3.1 (worked well in v2.2.6) · Issue #6022 · 2dust/v2rayNG TalkBack compatibility has significantly regressed starting from version 2.3.1. In older versions such as 2.2.6, the app was fully usable with TalkBack. Since 2.3.1, many parts of the interface hav...
Post #227 4
В v2rayNG завели свежий issue: TalkBack работал в 2.2.6, а с 2.3.1 основные экраны стали заметно хуже. Хорошее напоминание: доступность тоже надо держать в regression-check перед релизом.
Post #226 3
Доступность нельзя проверить только глазами по разметке

В проекте The Infinity открыли хорошую задачу с честной формулировкой: «ни один экранный диктор ещё не был направлен на этот сайт».

До этого в коде уже были aria-*, role, фокус-стили и prefers-reduced-motion. На бумаге всё выглядело заботливо. Но проверка accessibility tree быстро нашла вещи, которые из разметки не очевидны.

Например, подтверждения формы создавались вместе с role="status". Для экранного диктора это может быть не «изменение уже существующей области», а новый кусок страницы — и сообщение легко не прозвучит. Таб-переключатель назывался tablist, но стрелки внутри него не работали. А математические обозначения вроде d_model превращались в слитное dmodel.

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

Хорошая проверка здесь простая: не только посмотреть DOM, а пройти главный путь клавиатурой и экранным диктором. И отдельно слушать динамические сообщения, переключатели, списки, формулы и цветовые статусы.
GitHub No screen reader has ever been pointed at this site · Issue #126 · opendroid/the-infinity Accessibility here has been written carefully and never verified. 22 files under web/src use aria-* or role=, the focus-ring rule is in the tokens, prefers-reduced-motion guards the one animation, ...
Post #225 4
Доступность нельзя проверить только глазами по разметке

В The Infinity открыли задачу с честной формулировкой: «ни один экранный диктор ещё не был направлен на этот сайт».

В коде уже были aria-*, role, фокус-стили и prefers-reduced-motion. Но проверка accessibility tree нашла другое: role="status" создавался вместе с сообщением, tablist не реагировал на стрелки, а d_model превращался в слитное dmodel.

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

Полный разбор ниже.
Post #224 5
Когда «плавная прокрутка» реально укачивает

В issue к Lenis разработчик написал, что после сайта на популярной библиотеке плавной прокрутки почувствовал тошноту и головокружение. У него включён prefers-reduced-motion, но Lenis по умолчанию эту настройку не учитывал.

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

Мейнтейнер Lenis ответил: библиотека будет уважать prefers-reduced-motion по умолчанию. В режиме reduce прокрутка должна идти 1:1, без интерполяции; якоря и scrollTo - мгновенно. Игнорирование настройки станет явным выбором разработчика.

Командам стоит проверять весь motion-слой: CSS-анимации, плавную прокрутку, карусели, переходы и JS-таймеры. Всё это должно слушать Reduce Motion на реальной странице.

Источник: Lenis issue #534
Post #223 6
Субтитры могут сломаться без одной пропавшей строки

В ShouMeiPlayer, Android TV-клиенте для Jellyfin, открыли свежий баг: приложение читает системные настройки субтитров Android и сразу применяет их к mpv. Размер, цвет, обводка и язык перезаписываются даже тогда, когда системные субтитры выключены.

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

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

Источник: maik205/shoumeiplayer#97
Post #222 5
Когда пароль скрыт на экране, но произносится вслух

В Flutter завели свежий баг: если в iOS-приложении поле сделано как пароль через obscureText: true, VoiceOver при вводе может читать реальные символы вслух. Визуально всё выглядит правильно: поле «замаскировано», на экране пароль не виден. Но для человека со включённым VoiceOver секрет уже может прозвучать рядом с другими людьми.

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

Для команд вывод простой: недостаточно проверить, что пароль визуально закрыт точками. Нужно включить VoiceOver/TalkBack и пройти сам ввод: что произносится при фокусе, при наборе, при удалении, при автозаполнении, при ошибке и при повторном показе поля.

Особенно важно не доверять только свойству компонента вроде obscureText. В фреймворке, браузере или нативном мосте может быть баг, и тогда визуальная защита остаётся, а звуковая — ломается.

Источник: flutter/flutter#190320
GitHub VoiceOver read characters when we set `obscureText: true` in `TextField` · Issue #190320 · flutter/flutter Steps to reproduce turn on VoiceOver focus on a TextField with obscureText: true type characters Expected results VoiceOver does not read the plaintext password aloud Actual results VoiceOver reads...
Post #221 4
Пароль скрыт на экране, но VoiceOver читает его вслух

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

Полный разбор ниже.
Post #220 6
Видимый маркер на карте может быть невидимым для 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, слышно ли название и не ломается ли нажатие после фикса. Особенно если маркеры, подсказки или карточки поверх карты рисуются через кастомные обёртки.
GitHub Android: Marker content is invisible to accessibility services (content wrapper keeps 0x0 bounds) · Issue #1617 · maplibre/maplibre… Environment @maplibre/maplibre-react-native 11.3.4 (also present on current main) React Native 0.85.3, New Architecture, Expo SDK 56 dev client Android 16 emulator (Pixel), also reproduced on a phy...
Post #219 5
Карта есть, маркера для TalkBack нет

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

Полный разбор ниже.
Post #218 6
Инсталлятор тоже часть продукта

В issue FlyByWire Installer #550 пользователь экранного диктора BlindPilot93 описал не абстрактную «нужна доступность», а обычный путь установки.

В инсталляторе много переключателей сделаны не как стандартные чекбоксы. Для зрячего это может выглядеть как нормальный toggle. Для screen reader user это уже вопрос: что это за элемент, включён он или выключен, можно ли им управлять предсказуемо.

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

Это мешает не «красоте интерфейса», а установке и обновлению софта: выбрать нужные опции, понять объём загрузки, не пропустить подтверждение.

Что проверять командам: все переключатели — как реальные checkbox/switch с именем и состоянием; все подтверждения — как модальные диалоги с фокусом внутри, понятным заголовком, кнопками и возвратом фокуса назад. Особенно в инсталляторах, checkout, настройках и обновлениях: это места, где ошибка стоит дороже обычного клика.
GitHub Better Accessibility for Screen Readers in the Installer · Issue #550 · flybywiresim/installer Installer Version 3.7.2 Description Hello, I am a screen reader user and could really stand to have better accessibility in the installer. There are currently lots of toggles that are not implement...
Post #217 5
Инсталлятор тоже часть продукта

Если toggle и диалог видны на экране, это ещё не значит, что пользователь экранного диктора сможет выбрать опции и услышать важное подтверждение.
Post #216 4
MakeCode сделал блочные редакторы чуть менее закрытым клубом

В июльском релизе Microsoft MakeCode for micro:bit появилась поддержка экранных дикторов в блочном редакторе. Micro:bit отдельно описал, что это делали вместе с Blockly, учителями и незрячими или слабовидящими учениками.

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

В MakeCode важна именно связка, а не одна галочка «доступно». Клавиатурное управление теперь включено по умолчанию. Поддерживаются NVDA, JAWS, Narrator, VoiceOver и ChromeVox. В режиме для экранного диктора есть жёсткие остановки при обходе блоков и звуковая подсказка при смене уровня вложенности. На стороне micro:bit добавили отдельные стартовые задания, подсказки для учителей, тактильные материалы и FAQ: как попасть в рабочую область, как скачать программу на устройство, что делать с браузерным caret browsing.

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

Если продукт учит, настраивает, проектирует или собирает что-то из визуальных частей, тест должен быть простым: может ли человек пройти тот же урок или сценарий с клавиатурой, экранным диктором и, при необходимости, тактильной/текстовой опорой? Если нет - это не альтернативный способ использования, а отдельная дорожка для тех, кого основной интерфейс не пустил внутрь.
Microsoft MakeCode MakeCode for the micro:bit 2026 – Accessible Blocks are here! <strong>Posted on July 13, 2026 by <a target="_blank" rel="nofollow noopener" href="https://github.com/jaqster">Jaqster</a></strong>
Post #215 4
MakeCode сделал блочные редакторы чуть менее закрытым клубом

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

Полный разбор ниже.
Post #214 5
Карусель может быть доступной только на вид

В eBay Evo Web открыт баг про ebay-carousel: на Android Chrome с TalkBack виртуальный курсор внутри карточек «случайно» пропускает элементы, а свайпы TalkBack начинают прокручивать карусель вместо перехода по содержимому.

На практике это бьёт по задаче. Если в карточке есть цена, продавец, кнопка, условие доставки или действие «добавить», человек может услышать часть карточки и сразу улететь к следующему контейнеру. Визуально лента живёт, а маршрут обследования интерфейса ломается.

В комментарии разработчик нашёл два вероятных места: список карусели - настоящий горизонтальный scroll container со scroll-snap, а каждый li получает aria-hidden="true", если карточка не полностью видима с точностью примерно до сотых пикселя. Во время прокрутки карточка может то появляться, то исчезать из дерева доступности.

Что проверить командам:
- TalkBack/VoiceOver проходит все элементы каждой карточки по порядку;
- свайп экранного диктора не превращается в прокрутку карусели;
- частично видимые и анимирующиеся карточки не выдёргивают полезный контент из дерева доступности;
- у карусели есть понятная клавиатурная и экранная модель: где текущая карточка, куда движемся, что можно открыть.

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

Источник: eBay/evo-web#333
GitHub ebay-carousel: mWEB TALKBACK the virtual cursor randomly skips certain elements inside carousel tiles, TalkBack gestures scroll… I verified there's no existing issue for this bug. There are no existing issues Current behavior While navigating ebay-carousel, the virtual cursor randomly skips certain elements inside carous...
Post #213 4
В мессенджере статус сообщения - не декоративная галочка

В bitchat-android открыли issue: с TalkBack приватные сообщения можно отправлять, но статус «отправляется / отправлено / доставлено / ошибка» озвучивается как сырые значки ✓, ✓✓, ○, ⚠ или вообще непонятно. Новые входящие сообщения тоже не объявляются, если фокус стоит в поле ввода.

Для зрячего это мелкая иконка в пузыре. Для незрячего пользователя это ответ на базовый вопрос: сообщение ушло, дошло или надо повторить? В приватном чате эта разница важна.

Отдельно там всплыл хороший тревожный пример: «panic wipe» висит на тройном тапе по заголовку, без понятного имени и, вероятно, без нормальной альтернативы для TalkBack. Деструктивное действие нельзя прятать в жест, который часть пользователей не сможет надёжно выполнить или даже обнаружить.

Что проверять: статусы должны иметь человеческие labels, новые сообщения - аккуратное live-объявление, кастомные Canvas/WebView элементы - семантику, а опасные действия - доступный путь и подтверждение.

Источник: issue #747 в permissionlesstech/bitchat-android
GitHub Accessibility: TalkBack cannot convey delivery status, new messages, or several custom-drawn UI surfaces · Issue #747 · permis… Checklist I am able to reproduce the bug with the latest version given here: CLICK THIS LINK. I made sure that there are no existing issues - open or closed - which I could contribute my informatio...
Post #212 5
Статус сообщения - не декоративная галочка

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

Полный разбор ниже.
Older posts →
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →