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

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

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

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

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

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

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

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

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

Когда урок по коду становится «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

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

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

В 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. И обязательно добавить регрессионные тесты на такие деревья результатов, иначе «починили» легко превращается в «снова сломали» через один релиз.

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

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

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

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

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

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

Когда меню есть глазами, но его нет для экранного доступа
⠀
В репозитории 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».

Когда форма ошибается молча
⠀
В 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