О чём этот канал
⠀
Этот канал - про доступность интерфейсов без формальных галочек и без пустых лозунгов.
⠀
Я незрячий с рождения и регулярно сталкиваюсь с тем, как продукты выглядят "почти нормальными" для команды, но на практике оказываются неудобными или вообще недоступными для части пользователей.
⠀
Здесь я хочу собирать и разбирать такие вещи:
- сигналы из X и других источников про accessibility-проблемы
- реальные кейсы недоступных интерфейсов
- удачные решения, которые действительно помогают
- ошибки, которые разработчики и дизайнеры повторяют снова и снова
- то, что важно для незрячих, слабовидящих и других пользователей с ограничениями, а не только для отчёта по чек-листу
⠀
Для меня доступность - это не декоративная часть UX и не "добавим потом".
Это вопрос о том, может ли человек вообще пользоваться продуктом нормально.
⠀
Поэтому здесь будет акцент не на абстрактные правила, а на практику:
- что именно сломано
- кого это затрагивает
- почему это реально мешает
- как это можно исправить
⠀
Канал может быть полезен:
- дизайнерам
- разработчикам
- продуктовым командам
- accessibility-специалистам
- и всем, кому не всё равно, как интерфейс работает для живых людей, а не только на макете
⠀
Если вам интересна доступность не как формальность, а как реальное качество продукта, вы по адресу.
⠀
Здесь будет меньше шума.
И больше конкретики.

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

Когда в приложении нельзя увеличить шрифт, это не мелочь
⠀
Сегодня в X пользователь написал разработчику Mac app, что в приложении нельзя увеличить размер шрифта, и из-за этого продукт становится трудным для слабовидящих пользователей.
⠀
На первый взгляд это может показаться мелким UX-недочётом.
Но на практике такие вещи быстро становятся барьером доступа.
⠀
Проблема не в том, что интерфейс "чуть менее удобный".
Проблема в том, что часть людей просто перестаёт нормально читать содержимое экрана.
⠀
Для слабовидящего пользователя увеличение шрифта - не косметическая настройка.
Это способ вообще пользоваться продуктом без лишнего напряжения, боли и постоянного масштабирования всей системы в обход интерфейса.
⠀
И здесь важен простой вывод.
Если пользователь не может быстро подстроить текст под себя, значит доступность уже проигрывает удобству макета.
⠀
Обычно рядом всплывают и другие проблемы:
- слабый контраст
- тесные элементы
- фиксированные панели
- плохая работа с system scaling
⠀
То есть один сигнал про размер шрифта часто указывает не на одну ошибку, а на целую логику интерфейса.
⠀
Источник сигнала - asfi51.

Когда screen reader glitch ломает не комфорт, а сам доступ к продукту
⠀
В X снова всплыл знакомый сигнал: пользователь просит команду AI-продукта исправить accessibility glitches для blind people, которые используют screen reader.
⠀
Источник сигнала - hasantayem97.
⠀
Мне кажется, такие жалобы часто недооценивают.
Команда может услышать их как что-то уровня "есть шероховатости в UX".
Но для незрячего пользователя это нередко означает не ухудшенный опыт, а частичную потерю доступа к функции.
⠀
Если кнопка не озвучивается, если фокус прыгает, если интерфейс меняется без понятного объявления для screen reader, человек начинает не пользоваться продуктом, а угадывать его поведение.
⠀
И вот это уже другая проблема.
Не polishing. Не косметика. А базовая работоспособность интерфейса.
⠀
Потому что в сложных продуктах screen reader user быстро упирается в вещи, которые визуальная команда может вообще не заметить:
- неочевидный фокус
- пропущенные состояния
- немые кнопки
- плохо объявляемые ошибки
- динамический UI, который не объясняет, что изменилось
⠀
Именно поэтому accessibility-баги такого типа стоит разбирать не как "пожелания на будущее", а как часть core experience.
⠀
Если человек не может надёжно пройти сценарий с озвучкой, продукт нельзя считать по-настоящему доступным.
⠀
И, честно, мне кажется, что именно здесь проходит одна из самых важных границ.
Интерфейс доступен не тогда, когда про accessibility написали в roadmap.
А тогда, когда пользователь с assistive tech действительно может выполнить задачу без догадок и лишней борьбы.

Чек-лист по доступности ещё не делает интерфейс доступным
⠀
Контраст, alt text и statement могут быть на месте. Но если человек с assistive tech не может пройти сценарий от начала до конца, доступность остаётся формальной.
⠀
Гайды полезны как стартовая точка, а не как доказательство, что всё уже работает.

Почему чек-лист по доступности ещё не означает доступный интерфейс
⠀
В X регулярно появляются гайды и чек-листы по доступности сайтов и приложений.
Сами по себе они полезны. Но между "мы знаем стандарт" и "человек реально может пройти сценарий" всё ещё остаётся большая дистанция.
⠀
Хороший пример такого формального подхода - типичные публикации про соответствие требованиям, чек-листы и accessibility statements.
Например, вот свежий тред про запуск guide по website accessibility: NALC.
⠀
Проблема не в том, что такие материалы бесполезны.
Проблема в другом: они очень легко создают иллюзию, что доступность уже почти сделана.
⠀
Обычно в таких списках всё выглядит правильно:
- контраст
- клавиатура
- alt text
- структура
- statement
⠀
Но пользовательский сценарий ломается не там, где у вас красивый список требований.
Он ломается в более приземлённых местах:
- форма не даёт понять, где ошибка
- модалка уводит фокус
- интерфейс меняется, но не объясняет это screen reader
- кнопка названа формально, но не по смыслу
- нужное действие спрятано в неудобной последовательности
⠀
Поэтому для меня главный вопрос всегда не в том, "прошли ли вы чек-лист".
Главный вопрос другой:
может ли человек с assistive tech действительно выполнить задачу от начала до конца.
⠀
Вот здесь и проходит разница между формальной и живой доступностью.
Формальная доступность хорошо выглядит в отчёте.
Живая доступность позволяет человеку реально пользоваться продуктом.
⠀
Именно поэтому хорошие гайды полезны не как финальный ответ, а как стартовая точка.
Если команда на этом останавливается, почти всегда остаются невидимые проблемы, которые всплывают уже у реальных пользователей.
⠀
Мне кажется, в accessibility это одна из самых частых ошибок.
Люди проверяют требования.
А надо проверять прохождение сценария.

Когда ломается не просто экран, а сама самостоятельность

Пользователь VoiceOver на iPhone пожаловался, что после обновления PhonePe перестал работать экран ввода UPI PIN: приложение озвучивает только secure text field и не даёт ввести PIN. А встроенный раздел помощи тоже недоступен, поэтому баг нельзя нормально отправить из самого приложения.

Для незрячего пользователя это не просто неудобство. Это потеря возможности оплатить покупку без чужой помощи.

Практический вывод для команд простой:
- проверяйте не только главный сценарий, но и экраны PIN, OTP и другие защищённые поля;
- отдельно тестируйте раздел помощи и обратной связи;
- регресс в платёжном потоке - это потеря независимости, а не мелкий дефект.

Источник: тред в X

Когда незрячие пользователи уже не ждут фикс, а делают свой слой поверх продукта

Свежий сигнал из Double Tap: Стивен Скотт рассказал, как с помощью ИИ собрал скрипт для более доступной работы с Farrago под VoiceOver, сделал дополнение для NVDA и начал своё веб-приложение без классической разработки.

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

Это бьёт по незрячим, слабовидящим и по всем, кто зависит от клавиатуры, понятных ролей и предсказуемых состояний.

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

Когда alt-текстов нет, купить товар без зрения становится лотереей.
⠀
В Южной Корее Верховный суд обязал крупные маркетплейсы исправить работу со screen reader и добавить доступные описания товаров. Суд прямо связал отсутствие текстовой альтернативы с дискриминацией.
⠀
Для команд вывод простой: карточка товара - это не картинка с ценой рядом. Если название, состояние, опции и ключевые детали не читаются вслух последовательно и без догадок, пользователь теряет доступ к покупке.

Суд обязал маркетплейсы исправить доступность для незрячих пользователей
⠀
Свежий сигнал из Южной Кореи: Верховный суд оставил в силе решение против крупных площадок Gmarket, SSG.com и Lotte Shopping. Причина простая и очень знакомая: незрячие пользователи не могли нормально читать карточки товаров через screen reader, потому что у нетекстового контента не было доступных текстовых описаний.
⠀
По материалам The Korea Herald и The Asia Business Daily, суд потребовал исправить это в течение шести месяцев после вступления решения в силу. Отдельно важно, что площадки ссылались на продавцов: мол, контент загружают они. Но суд всё равно увидел обязанность платформы обеспечить разумную доступность.
⠀
Это важный практический момент. Во многих интерфейсах ответственность расползается между командами, CMS, продавцами, подрядчиками и шаблонами карточек. В итоге у изображения товара нет понятного текста, варианты товара не проговариваются, а screen reader читает страницу кусками, из которых нельзя собрать решение о покупке.
⠀
Для незрячего пользователя это не мелкая шероховатость. Если не слышно, что именно за товар, чем отличаются варианты, есть ли важные параметры или ограничения, покупка превращается в угадайку. А если ошибка обнаруживается только после оплаты или доставки, вред уже вполне реальный.
⠀
Вывод для команд такой:
- не перекладывайте доступность карточек на автора контента или продавца;
- проверяйте, как страница товара читается вслух целиком, от названия до выбора варианта и кнопки покупки;
- требуйте текстовые альтернативы и понятные подписи на уровне платформы, а не доброй воли отдельных поставщиков;
- тестируйте не только главную страницу и каталог, но и сам момент выбора товара.
⠀
Если платформа не даёт незрячему пользователю понять, что он покупает, это уже не просто недоработка интерфейса. Это ограничение доступа к услуге.

Когда доступность называют «фичей»

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

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

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

Источник в X

Когда доступность называют «фичей»

В X появился очень показательный сигнал по Toggl. Один из пользователей написал, что десктопное приложение не учитывает системный размер текста Windows, а в веб-версии много кнопок без подписей для экранного доступа.

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

Самая важная фраза в жалобе такая: просьба о базовой доступности - это не запрос на новую функцию. И это действительно так. Если интерфейс не уважает системный масштаб текста и не дает понятные имена элементам управления, проблема не в пожеланиях пользователя, а в сломанной основе.

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

Иначе человек упирается не в неудобство, а в запрет на использование продукта.

Источник в X

Суд обязал маркетплейс добавить alt-текст к карточкам товаров

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

Для незрячего пользователя это не косметика. Без такого описания карточка товара превращается в пустое место или в набор бессмысленных элементов.

Источник: CHOSUNBIZ

Когда у товара нет нормального описания, незрячий пользователь не может нормально купить его

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

Что здесь важно по сути.

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

Это бьёт не только по просмотру каталога. Ломается сама покупка: выбор товара, сравнение вариантов, проверка, того ли цвета или модели позиция добавлена в корзину.

Суд отдельно не принял логику "это заполняют продавцы, платформа не может отвечать за всё". Это важный сигнал для команд. Если интерфейс зависит от данных продавца, это не снимает ответственность с платформы. Значит, нужно строить процесс так, чтобы без качественного описания карточка не считалась готовой.

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

Пока многие спорят о "формальном соответствии", здесь ответ проще. Если человек не может понять, что именно продаётся, интерфейс не выполняет свою работу.

Источник: CHOSUNBIZ

Когда VoiceOver падает на прокрутке ленты, это уже не мелкий баг.

Аккаунт Meta Accessibility в X пишет, что команда разбирается с падением VoiceOver в iOS-приложении Facebook при прокрутке News Feed.

Для незрячего пользователя это поломка главного сценария, а не косметика.

Источник: Meta Accessibility

Если экранный доступ падает на главной ленте, приложение фактически перестаёт работать.

Аккаунт Meta Accessibility в X сообщил, что команда разбирается с падением VoiceOver в iOS-приложении Facebook при прокрутке ленты новостей.

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

Кого это задевает:
- незрячих пользователей iPhone, которые читают ленту через VoiceOver
- слабовидящих пользователей, которые зависят от озвучивания и стабильной навигации
- всех, кто пользуется ассистивными технологиями как основным способом работы с интерфейсом

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

Практический вывод для команд простой: тестировать нужно не только отдельные элементы, но и длинные живые сценарии со screen reader - прокрутка ленты, подгрузка новых карточек, возврат назад, открытие комментариев, повторное чтение после обновления экрана.

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

Источник: Meta Accessibility в X

Форумы ломают слепых пользователей. Вот почему.

Все комментарии — один голос. Не видно, кто автор, нет визуальной подписи у реплик, скринридер читает всё одинаково.

Зрячие видят: имя автора, аватар, иерархию ответов. Слепые слышат сплошной поток текста без ориентиров.

Исследование (14 участников): после первых сообщений — усталость и фрустрация. Люди перестают пытаться следить за дискуссией.

Источник: VoxVista, CHIIR 2026

Форумы ломают слепых пользователей. Вот почему.

Все комментарии на странице — один голос. Один. Не видно, кто автор, нет визуальной подписи у реплик, скринридер читает всё одинаково.

Это не мелочь. Это бардак, в котором невозможно понять:

— Кто сейчас говорит
— Кто кого цитирует
— Кому адресована реплика
— Где начинается ответ на конкретный комментарий

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

Исследование (14 участников, IRB-approved) показало: после первых нескольких сообщений — усталость и фрустрация. Люди просто перестают пытаться следить за дискуссией.

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

Источник: VoxVista, CHIIR 2026. Yash Prakash, Akshay Kolgar Nayak, Mohammed Shoaib Alyaan Sampath Jayarathna, Hae-Na Lee, Vikas Ashok.

Когда одинаковый aria-label ломает весь список

В свежем кейсе Skosmos экранный доступ в боковом списке перестал читать сами термины: вместо названий NVDA озвучивает одну и ту же фразу - «перейти на страницу понятия».

Для зрячего человека список ещё виден. Для незрячего он почти теряет смысл.

Когда одинаковый aria-label ломает весь список

В свежем кейсе Skosmos сломался боковой список терминов для пользователей экранного доступа. Проблема простая и очень показательная: ссылкам добавили aria-label с дополнительной подсказкой, но он перекрыл видимый текст ссылки.

В итоге NVDA читает не «aakkostus», «AA liike» и другие названия, а одну и ту же фразу вроде «Go to concept page». То есть человек слышит, что перед ним ссылка, но не понимает, куда она ведёт.

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

Практический вывод очень приземлённый:
- не подменяйте видимое имя элемента общим aria-label, если хотите добавить только уточнение;
- сначала проверяйте, что экранный доступ продолжает читать именно название элемента;
- дополнительный контекст лучше выносить в отдельный скрытый текст, а не затирать им основной смысл.

Такие ошибки особенно коварны тем, что визуально интерфейс выглядит нормальным. Поломка живёт только в слое доступности, а значит без реальной проверки NVDA, VoiceOver или TalkBack команда может долго её не замечать.

Источник: issue в GitHub, там же есть описание проблемы и ожидаемого поведения.