Кнопка «показать значение» должна говорить, что она уже включена
⠀
В Kibana завели свежий баг по VoiceOver: на странице Synthetics → Settings кнопка View parameter value показывает или скрывает значение параметра, но экранный доступ в обоих состояниях произносит одно и то же: «View parameter value, button».
⠀
Зрячий пользователь видит, что значок глаза поменялся и значение стало видимым или снова скрытым. Пользователь с VoiceOver этого состояния не получает. Он нажал кнопку, а дальше должен угадывать: значение уже открыто, закрыто или действие вообще не сработало.
⠀
В настройках мониторинга это не абстрактная мелочь. Там могут быть параметры окружения, адреса, токены, рабочие значения для проверок. Если интерфейс не сообщает состояние, человек не может уверенно управлять даже простой операцией «показать / скрыть».
⠀
Хорошо, что по issue уже открыт PR: в кнопку добавляют aria-pressed, а подпись меняется между «View parameter value» и «Hide parameter value». Для такого действия мало иметь доступное имя кнопки - нужно озвучить состояние после нажатия.
⠀
Командам стоит отдельно проверять все такие переключатели: показать пароль, скрыть значение, включить фильтр, закрепить, заглушить, раскрыть блок. После активации экранный доступ должен сказать имя кнопки и новое состояние.
⠀
Источник: elastic/kibana#276962, связанный PR: #277162.

Меню видно, но экранный доступ его не открывает
⠀
В WordPress-теме Neve завели issue про выпадающее меню: пункт с подменю до него доходит, NVDA или TalkBack его озвучивает, но активация через экранный доступ может не раскрывать список. Мышью и обычной клавиатурой путь при этом выглядит рабочим.
⠀
По описанию, проблема не в одном пропущенном ярлыке. В desktop-варианте submenu control сделан как div role="button", обработчик клавиатуры слушает только Enter, click- и keyboard-состояния живут раздельно, а состояние раскрытия не отдано как aria-expanded. В итоге пользователь слышит контрол, нажимает его своим способом, но дочерние ссылки меню так и не становятся доступным маршрутом.
⠀
Это неприятный класс багов: интерфейс вроде бы «доступен», потому что элемент фокусируется и называется, но настоящая задача не выполняется. Для незрячего пользователя это значит простое: часть навигации сайта закрыта, хотя визуально она есть.
⠀
Что проверять командам: не только Tab и Enter в браузере, а активацию через NVDA/JAWS/TalkBack/VoiceOver. Если это меню, кнопка раскрытия должна быть настоящей кнопкой или вести себя как она: один общий механизм открытия, корректное aria-expanded, дочерние пункты доступны после открытия, состояние синхронизировано для мыши, клавиатуры и экранного доступа.

Когда список прокрутился, но экранный доступ молчит
⠀
В Flutter завели свежий issue про iOS и VoiceOver: пользователь делает обычную трёхпальцевую прокрутку в длинном списке, список действительно едет, но VoiceOver не говорит ничего вроде «страница 2 из 5» или «строки 6–10 из 43».
⠀
Для зрячего человека это легко не заметить: контент сдвинулся, значит прокрутка работает. Для незрячего пользователя это другая ситуация. Он сделал жест и не получил ответа, где теперь находится. В ленте, списке сообщений, настройках или аудиоприложении это быстро превращается в обследование вслепую: «я продвинулся? далеко? не перескочил ли нужный блок?»
⠀
Интересная деталь: автор сравнил iOS с Android. TalkBack получает события прокрутки и сам собирает объявление. На iOS строку статуса должен передать сам движок/приложение. В issue прямо указали место в Flutter engine, где для этого до сих пор стоит TODO. Комментарий участника Flutter подтвердил воспроизведение на iPhone: список прокручивается, но позиция не озвучивается.
⠀
Вывод для команд простой: проверять нужно не только «можно ли прокрутить». Нужно пройти реальный жест с VoiceOver/TalkBack и послушать, получает ли человек обратную связь после изменения позиции.
⠀
Если интерфейс меняет состояние молча, пользователь с экранным доступом остаётся без карты. В длинных списках это не косметика, а часть навигации.
⠀
Источник: flutter/flutter#189285

Когда форма ошибается молча

Коротко: новый разбор issue → audit → PR по доступности интерфейса. Полный текст — следующим сообщением.

Когда форма ошибается молча
⠀
В OJS и OMP есть похожая проблема в формах регистрации и отправки материалов. Пользователь нажимает «отправить», форма показывает ошибки, но фокус может остаться на кнопке или улететь не туда. Для зрячего это неприятно. Для пользователя с JAWS или VoiceOver это уже риск потеряться: ошибка есть, но где именно чинить поле, непонятно.
⠀
Я выбрал для недельного PR не маленькую правку в одном месте, а общий слой валидации форм в pkp-lib. Там сходятся сразу три accessibility-issue: фокус после ошибки, связь поля с текстом ошибки и некорректный aria-invalid.
⠀
Что поменялось: после неудачной отправки фокус переходит к первому ошибочному полю, сообщение об ошибке получает стабильный id, поле связывается с ним через aria-describedby, а aria-invalid="true" ставится только пока поле реально невалидно.
⠀
Это не делает весь продукт автоматически доступным. Но убирает один типичный барьер: форма перестаёт просто «ругаться где-то на странице» и начинает вести пользователя к месту, которое нужно исправить.
⠀
Такие вещи хорошо ловятся не глазами, а обследованием интерфейса: что слышит экранный доступ, куда попадает фокус, понимает ли человек связь между полем и ошибкой. Для этого я и развиваю Accessibility Auditor Skill.
⠀
Issues: #12635, #12599, #12837
PR: pkp/pkp-lib#13031

Когда меню есть глазами, но его нет для экранного доступа
⠀
В репозитории OpenAI Codex появился свежий issue: в десктопном Codex на Windows меню подсказок открывается визуально, когда пользователь вводит /, но NVDA и JAWS его не видят.
⠀
Автор проверил это через Windows UI Automation: при открытии меню дерево доступности не меняется - 0 added, 0 removed, 0 changed. Фокус остаётся в поле ввода, стрелки двигают визуальное выделение, но экранный диктор не слышит ни список, ни текущий пункт.
⠀
Для зрячего пользователя это просто удобное меню команд. Для незрячего разработчика это превращается в угадайку: команда вроде бы есть, подсказки вроде бы работают, но выбрать нужный инструмент или режим без визуального контроля нельзя.
⠀
Исправление здесь не сводится к «добавьте подписи». Такой компонент нужно проверять как комбинированное поле: поле ввода знает, что управляет списком, список имеет роль, варианты имеют состояние, а активный пункт меняется так, чтобы экранный диктор это объявлял. В веб-интерфейсах это обычно означает aria-haspopup, aria-controls, aria-activedescendant, role="listbox" и role="option" - но важнее не набор атрибутов, а реальная проверка с NVDA/JAWS.
⠀
Хороший тест для командных палитр, автодополнения и AI-инструментов: открыть меню с клавиатуры, пройтись стрелками и спросить не «вижу ли я подсветку», а «слышит ли пользователь, какой пункт сейчас выбран и что произойдёт после Enter».

Видео с субтитрами — это ещё не доступный видеоплеер
⠀
В Stagebook открыли отдельный issue по MediaPlayer: в компоненте есть свои кнопки play/pause, перемотка, шаг, скорость и поддержка файла субтитров через captionsFile. Но это как раз тот случай, где «субтитры есть» не закрывает задачу.
⠀
Если человек не слышит звук, ему нужно не только увидеть текст реплик. Ему нужно включить субтитры, понять состояние плеера, добраться до скорости и перемотки, не потерять фокус и при необходимости получить текстовую версию. Если кнопки иконками без имён, а управление проверили только мышкой, часть людей просто не сможет нормально пройти эксперимент или обучение.
⠀
Хорошая проверка для команды простая: пройти медиасценарий без мыши и без звука. Видно ли, где фокус? Понятно ли экранному диктору, какая кнопка что делает? Можно ли включить субтитры и есть ли понятный путь к транскрипту? Учитывается ли prefers-reduced-motion, если в плеере есть движение?
⠀
Медиаплеер — это не один тег video. Это рабочий путь: управление, субтитры, текстовая альтернатива, клавиатура и состояние после каждого действия.

Drag-and-drop в учебном задании: если нельзя перетащить — нельзя учиться
⠀
В CodeSignal появился хороший, очень приземлённый баг-репорт: незрячий пользователь с NVDA проходит курс по генеративному ИИ и доходит до задания «заполни пропуски». Варианты ответа он может прочитать через мышиные команды, но положить слово в нужный пропуск не может — интерфейс ждёт перетаскивание.
⠀
Пример из отчёта простой: в предложении “Generative AI … creates blank 1 content” пользователь понимает, что правильное слово — “new”. Но знание ответа не помогает, потому что единственный способ ответить завязан на drag-and-drop.
⠀
Это важный тип поломки не только для незрячих. Drag-and-drop без альтернативы часто ломает задания для людей, которые работают с клавиатуры, switch control, голосовым управлением, трекболом, с временной травмой руки или на устройстве, где точное перетаскивание неудобно.
⠀
Хорошая проверка для таких заданий: можно ли выбрать вариант, назначить его конкретному пропуску, услышать/увидеть подтверждение и исправить ответ без мыши. Это может быть pick-and-drop с клавиатуры, список/комбобокс у каждого пропуска или другой понятный fallback.
⠀
Если пользователь знает правильный ответ, но не может ввести его в систему, проблема уже не в обучении. Проблема в интерфейсе задания.

.NET MAUI: поле говорит значение, но теряет смысл
⠀
В свежем issue по .NET MAUI Entry описали неприятный баг: у поля есть подпись User ID, есть AutomationProperties.Name и LabeledBy, но TalkBack и VoiceOver при фокусе произносят только текущее значение — например, TNTEST, Edit box.
⠀
Зрячий пользователь видит подпись рядом с полем. Пользователь экранного диктора слышит значение, но не слышит, что это за поле. В форме с несколькими заполненными полями это превращается в угадайку: где логин, где номер, где код, где сумма.
⠀
Кейс шире .NET-разработки. В формах нельзя проверять доступность только по наличию видимой подписи или ARIA/semantic-свойства в коде. Нужно пройти реальный сценарий с TalkBack/VoiceOver: фокус на поле должен давать и назначение поля, и текущее значение.
⠀
Если базовый компонент фреймворка теряет имя поля, команда всё равно отвечает за рабочий обходной путь: handler, platform-specific настройка, другой компонент или хотя бы запрет релиза критичной формы до исправления.

Файловый менеджер, где файлы есть, но до них нельзя добраться
⠀
В OpenList появился свежий issue от слабовидящего пользователя Android: приложение открывает интерфейс через WebView, но с TalkBack основной путь почти разваливается. Список файлов читается кусками: имя, размер и дата идут отдельными фрагментами, элемент не объявлен как файл или папка, а чекбокс выбора не говорит, какой файл он выбирает.
⠀
Ещё хуже с действиями. Скачать, переименовать, удалить, переместить или поделиться — это меню по долгому нажатию / контекстное меню. Для пользователя TalkBack такого “правого клика” фактически нет. Меню не получает фокус, пункты не объявлены как действия, и человек не понимает, как выполнить обычную операцию с файлом.
⠀
Это хороший пример, почему WebView сам по себе не делает мобильный интерфейс доступным. Если внутри живёт веб-интерфейс без ролей, подписей, фокуса и нормальных состояний, экранный диктор получает не приложение, а набор разрозненных текстов.
⠀
Для файловых интерфейсов стоит проверять не только “видно ли имя файла”. Проверьте весь путь с TalkBack: найти нужный файл, понять тип и метаданные, выбрать его, открыть меню действий, выполнить действие, услышать прогресс и ошибку. Если любой из этих шагов доступен только мышью, long press или визуальной догадкой — файловый менеджер для части пользователей просто не работает.
⠀
Источник: OpenListTeam/OpenList#2801.

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

Когда редактор есть, а текста для NVDA нет
⠀
В TeXstudio появился свежий issue от полностью слепого пользователя NVDA: после создания файла основное поле редактора не читается нормально. NVDA не сообщает текст, нестабильно озвучивает ввод и не даёт надёжно понять, где стоит курсор.
⠀
Итог очень практичный: человек пишет LaTeX не в специализированной среде, а уходит в VS Code или даже Блокнот. Для студентов, исследователей и преподавателей, которые работают с формулами и большими документами, это не «неудобство», а потеря основного инструмента.
⠀
В связанной правке хорошо видно, где была проблема. Редактор TeXstudio - кастомный виджет с собственной отрисовкой. Визуально он существует, но для экранного диктора почти нет дерева доступности: нет текста документа, позиции курсора, выделения и событий при изменении содержимого.
⠀
Для команд вывод простой: если вы делаете свой редактор, консоль, лог, просмотрщик документов или любое поле с собственной отрисовкой, проверяйте не только фокус и подпись. Экранный диктор должен читать строку, символы при вводе, положение курсора, выделение и изменённый текст после обновления. Иначе пользователь видит интерфейс ушами как пустое место.

В VS Code снова сломался поиск для NVDA
⠀
На GitHub завели свежий issue по VS Code 1.129.0: пользователь открывает поиск по проекту через Ctrl+Shift+F, доходит до дерева результатов, слышит общее «48 results in 4 files», но дальше NVDA не может озвучить сами найденные строки. Даже object navigation не помогает. Визуально навигация работает, но для экранного диктора объектов будто нет.
⠀
Важно, что это не первая вспышка. В июне похожий баг уже закрывали и выпускали исправление для доступности результатов поиска. 17 июля пользователь написал, что проблема вернулась в 1.129.0, с нюансами: на больших выдачах результаты совсем не обследуются, на маленьких - часть доступна, часть нет. И там есть прямая фраза: «мой рабочий процесс зависит от VS Code; когда этот инструмент ломается, я не могу работать».
⠀
Вывод для команд простой: доступность поиска - это не только открыть поле и назвать количество результатов. Нужно пройти весь путь: запрос, список файлов, каждая найденная строка, переход к месту в коде, стабильное озвучивание при стрелках и object navigation. И обязательно добавить регрессионные тесты на такие деревья результатов, иначе «починили» легко превращается в «снова сломали» через один релиз.

График, до которого можно дойти, но нельзя нажать
⠀
В MUI X Charts открыли issue: элементы графика уже можно обходить с клавиатуры стрелками, но на сфокусированном столбце Enter и Space ничего не делают. Клик мышью вызывает onItemClick, а клавиатура - нет.
⠀
На бумаге это выглядит как почти готовая доступность: фокус есть, подсветка есть, перемещение есть. Но если график используется для фильтра, перехода в детализацию или выбора точки на графике, пользователь без мыши застревает в витрине. Он может добраться до активного элемента, но не может выполнить действие.
⠀
Это затрагивает незрячих пользователей, людей с моторными нарушениями, пользователей клавиатуры, switch control, голосового управления и тех, кто временно не может точно работать мышью или тачпадом.
⠀
Хороший тест для интерактивной визуализации простой: пройти до графика Tab-ом, перейти по элементам стрелками, нажать Enter/Space и проверить, что срабатывает ровно то же действие, что и при клике мышью. Если действие есть только для мыши, это не интерактивный компонент, а интерактивный компонент для части пользователей.
⠀
Для сложных графиков стоит дать ещё один путь к той же информации: текстовый список, таблицу или понятную сводку. Тогда график остаётся удобным слоем, а не единственной дверью к смыслу.
⠀
Источник: MUI X Charts issue #23148.

Код на экране есть, а NVDA слышит только «blank»
⠀
Свежий баг freeCodeCamp: в Responsive Web Design встроенный редактор постепенно теряет доступность с NVDA, а с первого CSS-урока становится почти непригодным.
⠀
Для курса программирования доступность редактора — не боковая настройка. Это сама возможность учиться.

Когда урок по коду становится «blank»
⠀
В freeCodeCamp появился свежий баг: пользователь проходит Responsive Web Design с NVDA 2026.1.1, Windows 11 и Chrome. В ранних HTML-уроках встроенный редактор ещё читается. Дальше начинаются сбои: стрелки перестают нормально читать код, Ctrl+E уже ненадёжно включает режим доступности редактора, а Alt+F1 обещан, но не открывает дополнительные настройки.
⠀
С первого CSS-урока всё ломается жёстче: при фокусе на редакторе NVDA говорит только «blank». Для зрячего ученика это всё ещё поле с кодом. Для незрячего — место, где нельзя прочитать текущую строку, проверить символ, исправить ошибку и продолжить обучение.
⠀
Здесь важен не только сам Monaco editor. Если продукт учит программированию, доступность редактора — это не второстепенная настройка. Это сама дверь в курс.
⠀
Командам стоит проверять такие редакторы не на первом пустом примере, а на всём пути: разные уроки, уже заполненный код, Ctrl+E, стрелки, удаление, вставка, подсказки, ошибки и переходы между разделами. И отдельно — что после смены шаблона урока экранный диктор не начинает видеть вместо кода пустоту.
⠀
Источник: freeCodeCamp/freeCodeCamp#68957

Список может быть доступен — и всё равно читаться в неправильном порядке
⠀
В Shopify FlashList нашли Android-баг: inverted-чат визуально выглядит нормально, но TalkBack идёт по сообщениям наоборот. Причина — переворот через transform: экран поменялся, accessibility-иерархия осталась в старом порядке.
⠀
Полный разбор ниже.

Когда список визуально перевернули, TalkBack тоже начал читать его наоборот
⠀
В Shopify FlashList появился хороший продолжение истории про чаты на Android. Проблема не в том, что сообщения вообще недоступны. Они доступны, но жест «следующий элемент» у TalkBack ведёт к предыдущему сообщению, а жест «предыдущий» — к следующему.
⠀
Для зрячего пользователя чат выглядит нормально. Для человека с TalkBack разговор превращается в ленту, которую надо читать против привычных жестов. Это особенно плохо в переписке: порядок сообщений — не украшение, а часть смысла.
⠀
Интересная деталь из PR с исправлением: причина связана с тем, как inverted-список делали через `rotate(180deg)`. Визуальный порядок поменялся, а порядок детей в нативной accessibility-иерархии на Android остался прежним. В итоге интерфейс на экране и интерфейс для экранного диктора разошлись.
⠀
Что проверять командам: если список, чат, таблицу или карусель переворачивают через transform, virtualization или хитрый layout, надо пройти не только глазами и мышью. Включить TalkBack/VoiceOver, пройти жестами «следующий/предыдущий» и проверить, совпадает ли смысловой порядок с тем, что пользователь считает порядком на экране.
⠀
Фокус на элементе ещё не означает, что порядок чтения правильный.

Reduce Motion - это не «выключить красоту»
⠀
В SurveyJS открыли issue: библиотека умеет глобально выключать анимации через настройку разработчика, но не слушает системное prefers-reduced-motion. То есть человек уже включил «уменьшить движение» в ОС, а анкета всё равно может показывать переходы, smooth scroll, появление/исчезновение элементов и будущий focus mode с полноэкранными слайдами.
⠀
Это бьёт не только по «визуальному комфорту». Для людей с вестибулярной чувствительностью движение после каждого ответа может вызвать тошноту, головокружение или просто сорвать прохождение формы. А форма часто не развлечение: запись, заявка, обучение, обратная связь, госуслуга.
⠀
Хорошая деталь в issue SurveyJS: CSS-медиа-запроса мало. Если анимация управляет ещё и JS-таймерами удаления DOM-элементов, надо синхронизировать оба слоя. Иначе визуально всё «замерло», а интерфейс всё равно ждёт невидимую паузу.
⠀
Для команд простой тест: включить Reduce Motion в системе и пройти главный сценарий заново. Движение должно исчезнуть без отдельной настройки в приложении, а переключение системной настройки должно срабатывать без перезагрузки страницы.

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

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