Когда сообщение видно в Slack, но не читается нормально
⠀
Свежий сигнал из GitHub: в проекте на Slack Bolt поймали предупреждение по chat.postMessage. Сообщения собирались из блоков, но без верхнего поля text и без fallback у вложений.
⠀
Для зрячего пользователя такое сообщение может выглядеть нормально: карточка, кнопки, секции, всё на месте. А вот для программы экранного доступа и системных уведомлений важен обычный текстовый слой. В документации Slack прямо сказано: программы экранного доступа по умолчанию читают верхнее поле text, а не внутренние блоки сообщения.
⠀
То есть проблема не в том, что «забыли необязательное поле». Если бот отправляет только красивую блочную разметку, часть людей может получить пустой или неполный смысл сообщения. Особенно неприятно это в рабочих сценариях: алерты, заявки, статусы задач, подтверждения действий.
⠀
Я бы здесь проверял не только внешний вид сообщения, но и запасной текст: что услышит человек в экранном доступе, что попадёт в уведомление, можно ли понять суть без визуальной карточки.
⠀
Хорошее правило для команд: генератор сообщений должен сам собирать короткий текст из блоков и не давать отправить сообщение без понятного текстового слоя. Это дешевле, чем потом чинить каждый бот и каждую карточку отдельно.
⠀
Источник: issue в GitHub и документация Slack по доступности сообщений.

Кнопка должна говорить действие и состояние
⠀
В свежем исправлении Joplin для iOS и Android поправили маленькую, но показательную вещь: переключатель просмотра и редактирования заметки раньше озвучивался как «toggle view/edit».
⠀
Для зрячего пользователя иконка может дать контекст. А пользователь VoiceOver или TalkBack слышит кнопку, но не понимает главное: он сейчас читает заметку или уже редактирует её. В редакторе это легко превращается в случайную правку или в попытку писать там, где правка не включена.
⠀
Исправление простое: кнопка теперь называется по текущему действию - «Edit» или «Stop editing», а при смене режима отдельно озвучивается «Viewing» или «Editing».
⠀
Я бы забрал отсюда правило для экранов с режимами. Если кнопка меняет состояние, одного глагола мало. Человеку нужно услышать текущее состояние и результат переключения. Особенно там, где режим влияет на ввод, оплату или удаление.
⠀
Источник: исправление Joplin.

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

Тайм-аут сессии может сломать весь сценарий
⠀
В Smashing Magazine вышел хороший разбор про тайм-ауты в формах и личных кабинетах. Тема кажется технической: ну истекла сессия, надо снова войти. Но для части пользователей это не мелкая неприятность, а потерянная заявка, покупка или обращение в поддержку.
⠀
Представьте длинную форму. Человек медленнее заполняет поля из-за моторных особенностей, читает форму через экранный доступ, ищет нужный блок с клавиатуры или просто дольше обрабатывает информацию. Для системы он может выглядеть «неактивным». По факту он всё ещё работает с интерфейсом.
⠀
Хуже всего, когда предупреждения нет, сессию нельзя продлить, а уже заполненные поля пропадают. Тогда пользователь платит за чужое решение своим временем и силами. Незрячий человек может заново проходить форму через заголовки, поля и кнопки. Человек с тремором или ДЦП - снова медленно вводить имя, адрес и другие поля. Пользователь с СДВГ или другой когнитивной особенностью - заново собирать контекст.
⠀
Отдельная ловушка - таймеры для экранного доступа. Богдан Церовац описывал случай, когда счётчик озвучивал оставшееся время каждую секунду. Визуально всё вроде нормально, а программа экранного доступа превращается в поток служебных сообщений. Навигация почти останавливается.
⠀
Я бы проверял такие места очень жёстко:
- предупредили ли пользователя заранее, что у формы есть ограничение по времени;
- есть ли понятное предупреждение до выхода из сессии;
- можно ли продлить сессию одним действием;
- сохраняется ли прогресс после повторного входа;
- не спамит ли таймер программу экранного доступа;
- действительно ли тайм-аут нужен именно здесь, а не просто стоит «по умолчанию».
⠀
У DWP в британской дизайн-системе есть простой ориентир: если сессия заканчивается автоматически, пользователя нужно предупредить минимум за 2 минуты и дать продлить время. Это часть доступности, а не украшение интерфейса.
⠀
Для команд вывод простой: «неактивность» в интерфейсе не всегда означает, что человек ушёл. Иногда он читает, ищет, думает, вводит медленнее или работает через вспомогательную технологию. Если тайм-аут стирает его прогресс, сломан не пользовательский темп. Сломан сценарий.
⠀
Источники: Smashing Magazine, DWP Design System, Bogdan Cerovac.

Доступность в медицине снова отложили на год
⠀
HHS в США продлил сроки для сайтов и мобильных приложений организаций, которые получают федеральное финансирование в сфере здравоохранения.
⠀
Было: крупные получатели должны были соответствовать WCAG 2.1 AA к 11 мая 2026 года. Теперь срок сдвинули на 11 мая 2027 года. Для небольших организаций - на май 2028 года.
⠀
Формально причина понятная: клиники, больницы и центры первичной помощи не успевали. Но для пользователя это выглядит иначе. Если портал записи к врачу, форма регистрации, оплата, телемедицина или результаты анализов плохо работают с экранным доступом, человек не получает “чуть менее удобный интерфейс”. Он теряет самостоятельность в медицинском сценарии.
⠀
Особенно это бьёт по незрячим пользователям, людям со слабым зрением, пользователям клавиатуры, экранного доступа, увеличения и других вспомогательных технологий. В медицине цена ошибки выше: нельзя просто “зайти позже”, если нужно записаться, прочитать назначение или отправить данные врачу.
⠀
Я бы не воспринимал перенос срока как паузу. Для команд это скорее проверка зрелости: если доступность появляется только за месяц до юридического дедлайна, значит процесс уже сломан.
⠀
Что стоит проверить в первую очередь:
- вход и восстановление доступа;
- запись и отмену приёма;
- формы регистрации и согласий;
- результаты анализов и назначения;
- оплату и сообщения врачу;
- сторонние модули, которые встроены в продукт.
⠀
Нормальный тест здесь простой: пройти эти сценарии с VoiceOver, NVDA или TalkBack без мыши и без помощи зрячего человека. Если не получается, проблема уже не в стандарте и не в сроках. Проблема в том, что часть пациентов всё ещё не может пользоваться сервисом самостоятельно.

Кейс доступности: подсказки формы должны быть слышны, а не только видны

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

Кейс доступности: подсказки формы должны быть слышны, а не только видны

В форме инвентаря PPCollection рядом с полями были полезные подсказки: где ввести серийный номер, цену покупки, статус, тип оружия и гарантию.

Было: зрячий пользователь видел подсказку под полем, а пользователь screen reader при фокусе слышал в основном только название поля. Ошибки валидации тоже были видимы, но не были программно связаны с конкретным input.

Что мешало: человеку приходилось самому догадываться, какая инструкция или ошибка относится к текущему полю. Это особенно неприятно в длинных формах: выше риск пропустить формат цены, статус или причину ошибки.

Что изменили: для helper text и inline error добавлены стабильные id, а поля получили aria-describedby. Теперь видимая инструкция и сообщение об ошибке связаны с контролом не только визуально, но и для assistive technologies.

Стало: при переходе по форме screen reader может объявлять не только название поля, но и связанную подсказку или текст ошибки. Форма стала понятнее без изменения визуального интерфейса.

Разбор и PR подготовлены с помощью Accessibility Auditor Skill — инструмента для поиска и оформления практичных accessibility-улучшений.

Доказательства:
Issue: https://github.com/Gogorichielab/PPCollection/issues/437
PR: https://github.com/Gogorichielab/PPCollection/pull/470

Мини-кейс: вернули видимый фокус на сайте Joplin

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

Мини-кейс: вернули видимый фокус на сайте Joplin

Было: на сайте глобальный CSS-сброс убирал outline у всех элементов. Часть ссылок-кнопок при Tab-навигации получала фокус, но визуально это почти не было видно.

Что это ломало: пользователь с клавиатурой или screen reader мог перейти на кнопку, но зрячий клавиатурный пользователь не понимал, где он находится. Это напрямую бьёт по WCAG 2.4.7 Focus Visible.

Что изменили: убрали глобальное подавление outline и добавили общий :focus-visible стиль для ссылок, кнопок, полей форм и custom tabindex-контролов.

Стало: при клавиатурной навигации интерактивные элементы получают заметное кольцо фокуса. Это маленькая правка, но она делает сайт ощутимо безопаснее для keyboard UX.

Разбор и выбор правки делала через Accessibility Auditor Skill: он помогает быстро связать симптом, код и критерий WCAG, чтобы не чинить “на глаз”.

Доказательство:
Issue: https://github.com/laurent22/joplin/issues/15264
PR: https://github.com/laurent22/joplin/pull/15378

Когда интерфейс говорит слишком много
⠀
В pty-speak поймали хороший, очень практический баг: команда dir в preview-сборке могла отправить в NVDA один огромный кусок вывода. Дальше SAPI начинал озвучивать его как одну фразу на 5-10 минут.
⠀
Проблема не в том, что текста было много. Хуже другое: пользователь уже не может нормально остановить поток и быстро вернуться к работе. Для незрячего человека терминал в этот момент превращается из инструмента в ловушку ожидания.
⠀
В PR #293 предложили нормальный ремонт: автоматическое озвучивание режется до последних 800 символов, а полный вывод открывается отдельной командой Ctrl+Shift+O в текстовом редакторе.
⠀
Я бы здесь забрал простое правило для любых интерфейсов с озвучкой: не отправлять в экранный доступ бесконечные простыни как одно уведомление. Коротко озвучить главное - да. Дать отдельный способ открыть полный текст - обязательно.

Мини-кейс доступности: ошибки формы должны быть слышны

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

Мини-кейс доступности: ошибки формы должны быть слышны

Было: форма показывала текст ошибки под полем, но для screen reader он не был явно связан с самим полем.

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

Что изменили: в общих компонентах Input и Textarea добавили aria-invalid, связь с текстом ошибки через aria-describedby, а саму ошибку пометили role="alert". Теперь это работает сразу для форм, которые используют эти компоненты.

Стало: screen reader получает понятную структуру: поле отмечено как невалидное, а ошибка объявляется и связана с конкретным полем. Это меньше угадывания и меньше потерянного контекста при заполнении формы.

Кейс подготовлен через Accessibility Auditor Skill.

Доказательство:
Issue: github.com/Vets-Who-Code/vets-who-code-app/issues/895
PR: github.com/Vets-Who-Code/vets-who-code-app/pull/1120

ИИ в проверке доступности не закрывает главный риск
⠀
По свежему отчёту Applause, 78% организаций уже используют ИИ для доступности, но 56% пользователей assistive tech всё равно регулярно встречают недоступные приложения.
⠀
Полный разбор ниже.

ИИ в проверке доступности не закрывает главный риск
⠀
Applause выпустил отчёт по доступности за 2026 год, и там хорошо видно противоречие: 78% организаций уже используют ИИ для улучшения доступности, но 56% пользователей assistive tech с начала года регулярно встречали недоступные приложения.
⠀
Для людей с экранным доступом, увеличением шрифта, субтитрами или альтернативной навигацией это не абстрактный дефект. Если приложение не работает с такими инструментами, 92% пользователей готовы его бросить.
⠀
Мне здесь важна не цифра сама по себе, а разрыв между «мы проверяем доступность» и «человек не может закончить задачу». Автопроверка может найти часть ошибок в коде. Но она легко пропускает контекст: странный порядок табуляции, лишний текст в screen reader, фильтр без понятного состояния, кнопку без смысла в реальном сценарии.
⠀
В отчёте есть и нормальная трезвость: только 10% организаций полагаются на ИИ-инструменты без ручной проверки. Остальные всё-таки сверяют результат людьми. Но ручная проверка тоже бывает разной. Одно дело - пройти чек-лист мышкой и клавиатурой. Другое - дать сценарий человеку, который каждый день пользуется NVDA, JAWS, VoiceOver, увеличением или head pointer.
⠀
Я бы из этого вынес простое правило для команд: ИИ можно использовать как быстрый первый слой, но не как финальный ответ. Если сценарий важный - регистрация, покупка, оплата, поиск, поддержка, медицинская запись - его нужно прогонять с реальными вспомогательными технологиями и реальными пользователями.
⠀
Иначе команда видит зелёный отчёт, а пользователь всё равно упирается в молчащую кнопку или форму, из которой невозможно выбраться.

Ежедневный accessibility PR

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

Ежедневный accessibility PR

Было: в компоненте DropdownMenu пункт меню подсвечивался почти незаметным серым фоном, а кнопка открытия не сообщала скринридеру своё состояние.

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

Что changed: добавила для триггера меню состояние aria-expanded и связь с меню через aria-controls, а для пунктов меню — явный контрастный focus outline.

Стало: состояние dropdown лучше озвучивается, а текущий пункт меню заметнее при навигации с клавиатуры. Это небольшой PR, но он закрывает реальную часть проблемы: меньше угадывания, больше понятной обратной связи.

Такие кейсы я разбираю через Accessibility Auditor Skill: он помогает быстро находить места, где интерфейс виден глазами, но плохо доступен клавиатуре и скринридеру.

Proof:

Issue: https://github.com/suitenumerique/ui-kit/issues/183

PR: https://github.com/suitenumerique/ui-kit/pull/226

Когда папки видны, но VoiceOver их не называет
⠀
Свежий issue в Nextcloud iOS: при отправке файла через «Поделиться» VoiceOver не читает имена папок на экране выбора. Для незрячего пользователя это превращает загрузку файла в угадайку.
⠀
Полный разбор ниже.

Когда папки видны, но VoiceOver их не называет
⠀
В Nextcloud iOS открыли issue #4099: если отправлять файл из другого приложения через системное меню «Поделиться» и выбрать Nextcloud, экран выбора папки визуально показывает папки, но VoiceOver не читает их имена и детали.
⠀
Для зрячего пользователя это обычный выбор места сохранения. Для пользователя VoiceOver - угадайка: фокус двигается, папку можно выбрать, но непонятно, какую именно. Автор пишет, что из-за этого нельзя самостоятельно загрузить файл: приходится просить зрячего человека или полагаться на распознавание экрана, которое медленное и не всегда надёжное.
⠀
Здесь ломается не украшение интерфейса, а базовый сценарий: «поделиться файлом в облако». Если список папок доступен только глазами, приложение фактически забирает автономность у незрячего пользователя.
⠀
Я бы проверял такие места отдельно: системное меню отправки, модальные окна, выбор папки, любые списки назначения. Недостаточно протестировать главный экран приложения - часто баг живёт именно во втором сценарии, куда команда сама редко заходит с VoiceOver.

Было:

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

Кейс по доступности: dropdown-меню в UI Kit.

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

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

Что изменили: добавили для триггера меню aria-haspopup, aria-expanded и связь с открытым меню через aria-controls. Для выбранных пунктов добавили доступное состояние, а декоративную галочку скрыли от скринридера.

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

Такой разбор и минимальную правку я делаю через Accessibility Auditor Skill: он помогает быстро найти пользовательскую проблему, проверить WCAG/RGAA-смысл и довести её до небольшого безопасного PR.

Доказательство:

Issue: suitenumerique/ui-kit#183

PR: suitenumerique/ui-kit#227

Etherpad и экранный доступ: подсказка была в коде, но не в дереве доступности
⠀
Если элемент нужен NVDA, VoiceOver или другому экранному доступу, его нельзя прятать через hidden. Иначе aria-describedby может ссылаться в пустоту.
⠀
Полный разбор ниже.