Субтитры могут сломаться без одной пропавшей строки
⠀
В 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

Комбобокс — отдельный интерфейсный сценарий

У Gradio был показательный баг: listbox/combobox в приложениях на Gradio почти не работал с NVDA/Narrator. Для AI-инструментов это критично: человек может открыть приложение, но застрять уже на выборе модели, голоса, файла или режима.

Полный разбор — следующим сообщением.

Комбобокс — отдельный интерфейсный сценарий

У Gradio в этом году был хороший показательный баг: незрячий пользователь Pinokio написал, что listbox/combobox в приложениях на Gradio почти не работает с NVDA/Narrator. Обход через object navigation есть, но сам автор прямо пишет: пользоваться так непрактично.

Почему это важно. Gradio стал стандартным UI-слоем для множества AI-инструментов. Если dropdown выбора модели, голоса, файла или режима не читается как нормальный combobox, человек может открыть приложение, но застрять на базовой настройке.

Команда признала проблему в кастомном multi-select combobox и позже закрыла issue через PR с ARIA-pattern для Dropdown/Listbox.

Что проверять у себя:
• элемент имеет понятные name/role/value;
• экранный диктор слышит выбранный пункт и количество вариантов;
• стрелки, Enter, Escape работают предсказуемо;
• состояние selected/expanded меняется и визуально, и в дереве доступности;
• старый скрытый select не торчит вторым «мусорным» listbox рядом с новым контролом.

Кастомный dropdown можно делать. Но тогда его надо тестировать как самостоятельный сценарий, а не как стилизованный div.

Источник: https://github.com/gradio-app/gradio/issues/12855

Не каждый фокус после клика — accessibility fix.

В Chakra UI / Zag завели issue про Splitter.ResizeTrigger: после перетаскивания разделителя мышью ручка остаётся в фокусе, и стрелки продолжают менять размер панели.

Полный разбор — следующим сообщением.

Не каждый фокус после клика — accessibility fix.

В Chakra UI / Zag завели issue про Splitter.ResizeTrigger: после перетаскивания разделителя мышью ручка остаётся в фокусе. Визуально это выглядит как активное keyboard-состояние, а следующие нажатия стрелок продолжают менять размер панели — хотя человек уже закончил drag и мог хотеть пролистать страницу или перейти по форме.

Автор важную вещь формулирует просто: ARIA window splitter должен быть доступен с клавиатуры, но это не значит, что pointer-drag обязан оставлять фокус на ручке.

Кому мешает: клавиатурным пользователям, людям с моторными ограничениями, пользователям увеличения и всем, кто смешивает мышь/тачпад и клавиатуру. Интерфейс начинает «залипать» в старом действии.

Что проверять в resize/splitter-компонентах: Tab → фокус → стрелки работают; после mouse drag фокус не притворяется keyboard-фокусом; :focus-visible не загорается от программного pointer-фокуса; если элемент был сфокусирован клавиатурой до drag, это состояние сохраняется аккуратно.

Доступность — это не “добавить фокус везде”. Иногда наоборот: не смешивать состояния.

Хороший маленький кейс из macOS-приложения Notify GCal Menu.

В приложении делали меню в строке macOS: кнопки с иконками, выпадающий выбор времени напоминания, подсказки горячих клавиш вроде ⌘S и ⌘Q.

Визуально всё аккуратно. Но для VoiceOver такая полировка легко превращается в шум или пустоту.

Что нашли в PR:

• Picker «Notify me» визуально имел подпись, но из-за .labelsHidden() сам контрол оставался без понятного контекста для VoiceOver. Исправили отдельным accessibilityLabel("Notify me").

• Заголовок «NOTIFICATIONS» сделали настоящим ориентиром для VoiceOver через .accessibilityAddTraits(.isHeader).

• Текстовые подсказки «⌘S» и «⌘Q» спрятали от экранного диктора: сами шорткаты уже подключены через .keyboardShortcut, а чтение символов вслух только мешает.

Отдельно проверили контраст скриптом. Там нашлась важная деталь: часть системных цветов Apple не проходит 4.5:1 для обычного текста в некоторых состояниях. Команда оставила их как есть, потому что это нативные semantic colors macOS, и переопределение могло бы сделать приложение менее похожим на остальную систему.

Но две проверки остались ручными: живой проход VoiceOver по popover и проверка крупного системного текста / Dynamic Type без обрезки и наложений.

Вывод простой: доступность нативного интерфейса не заканчивается на «у нас стандартные контролы». Нужно пройти реальный путь:

• что слышит VoiceOver у каждого контрола;

• не читаются ли декоративные символы как полезная информация;

• остаётся ли интерфейс usable при крупном тексте;

• не заменяет ли скрипт контраста живую проверку с ассистивной технологией.

Особенно это касается маленьких popover-меню: там мало места, и одна безымянная кнопка или обрезанный текст быстро ломают весь сценарий.

Календарь может быть «доступным» с клавиатуры — и всё равно ломаться на iPhone с VoiceOver.

Свежий пример: issue в Vaadin DatePicker. Подробности — следующим сообщением.

Календарь может быть «доступным» с клавиатуры — и всё равно ломаться на iPhone с VoiceOver.

В issue по Vaadin DatePicker описали неприятную штуку: с iOS VoiceOver пользователь не может нормально уйти дальше текущего месяца. Список месяцев не прокручивается как нужно, следующий календарь не получает фокус, а при движении по датам VoiceOver читает только число: «10», «11», «12». Без месяца и контекста это почти бесполезно.

Почему так вышло: компонент опирается на обычный DOM-фокус и roving tabindex. Но iOS VoiceOver в календарной сетке может двигаться своим способом, не передвигая DOM-фокус туда, где его ждёт компонент. В итоге часть календарей остаётся `aria-hidden`, хотя визуально интерфейс вроде бы есть.

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

Что проверять командам:

• реальные жесты VoiceOver на iOS, а не одни Tab/стрелки на десктопе;
• можно ли перейти на следующий месяц без визуального контроля;
• объявляется ли дата целиком, а не один день месяца;
• не прячете ли вы `aria-hidden` то, куда экранный доступ должен попасть;
• есть ли запасной путь: обычные select-поля месяца/года или текстовый ввод даты.

Roving tabindex — не гарантия доступности. Он работает только пока assistive technology действительно следует вашей модели фокуса. Если платформа навигирует иначе, нужен тест на реальном устройстве, а не только «правильная ARIA-схема» в коде.

График есть, а цифры для части пользователей исчезают

В Kibana завели issue про histogram на странице Discover: Tab полностью пропускает график, поэтому keyboard-only и screen-reader пользователи не могут добраться до смысла визуализации.

Это не про красивую подпись к картинке. В аналитическом интерфейсе график часто отвечает на главный вопрос: где пик, провал, всплеск, период. Если он доступен только мышью и глазами, часть продукта просто исчезает.

Источник: elastic/kibana#284830

График есть, а цифры для части пользователей исчезают

В Kibana завели показательный issue: на странице Discover histogram-график вообще не достигается с клавиатуры. Нажимаешь Tab - фокус просто проходит мимо. Для keyboard-only пользователя и для человека со скринридером это означает не «неудобно посмотреть график», а «невозможно получить смысл визуализации».

Здесь важная деталь: клавиатура может быть основным способом работы из-за моторных ограничений, травмы руки, тремора, switch control, удалённого рабочего окружения или просто потому, что мышью работать тяжело. Если график живёт только на hover, клике и зрении, он отсекает больше людей, чем кажется.

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

Ещё интереснее комментарий в обсуждении: недоступные charts/graphs в Kibana встречаются в разных местах, поэтому это завели как более общий platform issue. И это честная проблема многих интерфейсов: визуализация переиспользуется как компонент, но доступный контракт для неё не задан.

Что проверять командам:

1. Можно ли дойти до графика с клавиатуры?
2. Понятно ли, что это за график и что он показывает?
3. Можно ли прочитать значения без hover и без зрения?
4. Есть ли таблица, summary или другой текстовый путь к тому же смыслу?
5. Не ломается ли сценарий, если пользователь работает через VoiceOver, NVDA, JAWS или только клавиатурой?

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

Источник: elastic/kibana#284830