Accessibility *

Привет, Хабр!

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

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

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

Давайте посмотрим, что я вам подготовил.

Уже более 10 лет мы сопровождаем Единый официальный сайт органов власти Ханты-Мансийского автономного округа — Югры (admhmao.ru, далее – сайт), в структуру которого входят ещё 36 сайтов органов власти округа. За это время требования к доступности государственных сайтов несколько раз менялись.

В этой статье мы рассказываем, как выполняли требования законодательства о доступности сайта для инвалидов по зрению, хотя между собой называем это просто «доступностью»: читать мелкий серый текст на белом фоне не любит никто. Покажем на реальном госпроекте, какие грабли ждут команду, когда большой legacy-сайт приводят к современным требованиям доступности. Большинство рекомендаций пригодятся при разработке любого сайта, не только государственного.

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

Меня зовут Антонина, я дизайнер интерфейсов ЮMoney. Мы изучили десятки исследований — от Baymard Institute до Google web.dev. Единого документа с лучшими практиками не нашлось: источники противоречили друг другу или оказывались слишком общими.

Тогда мы провели собственное исследование: сопоставили авторитетные материалы, разобрали реальные кейсы и сформулировали практические рекомендации. В этой статье разберём самые распространённые проблемы проектирования OTP-полей — от базовых до менее очевидных, — объясним, почему те или иные решения работают и к чему приводят ошибки. А в конце соберём все рекомендации в удобный чек-лист, который поможет быстро проверить ваше решение.

Девять чисел из научной статьи 2009 года сегодня работают у меня в четырёх местах: на HTML-странице, в canvas, в двух плагинах Figma и в чужом расширении для Chrome. Разбираю, как одна и та же матрица цветовосприятия ведёт себя в четырёх средах, где каждая среда сопротивляется по-своему — и почему честные ограничения инструмента важнее его возможностей.

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

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

Я долго думала, как это починить. И в итоге перестала объяснять словами. Я сделала штуку, которая даёт побыть тем самым пользователем — на несколько секунд. Расскажу, как она устроена и почему чек-листы не работают.

Свежее исследование Стэнфорда (Nature Health, январь 2026) связало дальтонизм с поздней диагностикой рака мочевого пузыря — у пациентов-дальтоников смертность за 20 лет на 52% выше. Причина в том, что главный ранний симптом, кровь в моче, они просто не видят: цвет для них не считывается. Это медицинская история, но она точно описывает ошибку, которую дизайнеры делают каждый день — кодируют критическую информацию одним только цветом. Разбираю, как устроена эта ошибка в интерфейсах и что с ней делать на практике.

Создание единой дизайн-системы для крупного кроссплатформенного продукта — это всегда вызов. А если процесс совпадает с масштабным ребрендингом компании, задача усложняется в разы. В этой статье мы разберем двухлетний кейс команды «Туту», которая прошла путь от полного отсутствия стандартов до гибкой, масштабируемой и строго контролируемой архитектуры токенов цвета.

Сотни строк кода, страницы документации, корпоративные чаты — и всё это каждый день. Когнитивная нагрузка не снижается. Внутри — система инструментов, которая помогает мне не тонуть: конфиги clang и специфичные настройки VSCode, приложения визуализации и др. С объяснением зачем каждый из них.

На этой неделе прочитала свежую статью Кьяры Пеллегрини из NN/g: «AI-агенты теперь тоже пользователи наших интерфейсов». Автор — серьёзный исследователь, статья хорошо аргументирована. У агента есть цели, агент сталкивается с интерфейсом, агент пытается достичь целей через наш дизайн. По функциональному определению — пользователь.

Я не согласна с этой рамкой. И думаю, что разница принципиальная.

Восемь лет я работала клиническим врачом, потом перешла в продуктовый дизайн. Сейчас веду UX/UI в крупной российской IT-компании. Этот переход дал мне странное двойное зрение: я постоянно вижу в дизайне проблемы, которые медицина решала десятилетиями. Вопрос с агентами — один из них.

Агент — это не новый пользователь. Это новый посредник.

Привет, меня зовут Алексей, я C# разработчик. Я разрабатывал библиотеку для автоматизации взаимодействия с различными UI‑элементами и их захвата. Одной из поддерживаемых сред в такой библиотеке обязательно должна быть Windows и в ней так же требуется: находить кнопки, поля, окна, списки, нажимать на них, читать значения, вводить текст и в целом обращаться с интерфейсом не как пользователь с мышкой, а как программа.

На первый взгляд задача звучит просто: нашли элемент, кликнули, пошли дальше. Но в реальных приложениях у элемента может не быть (считай не будет) нормального AutomationId, у нескольких окон может быть один и тот же заголовок, дерево интерфейса может прогружаться не сразу, а старое desktop‑приложение вообще не предназначено для взаимодействия с современными API для автоматизации.

В итоге в моей библиотеке появилось два основных Windows‑подхода:

О чём дизайн сегодня? Про украшение? Про управление вниманием или про помощь и заботу? Разберём чем мы занимались когда я работал в Лабсе, а именно главной страницей Госуслуг. Хоть со стороны и не заметно что изменения внушительны, когда ты находишься внутри этой структуры становится понятно что всё совсем не так.

С недавних пор маме стало трудно пользоваться сотовым телефоном, в основном из-за проблем со зрением.
Даже простейший сотовый телефон требовал его разблокировать, выбрать нужный пункт меню, найти нужного адресата, нажать на кнопку вызова.
Кнопка «SOS», имеющаяся у некоторых телефонов, рассчитанных на пожилых людей, казалось бы, должна решить запутанность UX/UI. Но она также создаёт проблемы: требует долгого нажатия, и кроме дозвона на нужные номера, включает громкую сирену, которую отключить нельзя.
Есть и ещё одна сложность: сотовый телефон бывает просто трудно найти, он не всегда лежит на одном и том же месте.

Я стал искать альтернативу, в том числе в статьях на Хабре. В основном мысли людей были направлены на использование GSM-сигнализации и GPS-модулей. Сам думал о программе, которая бы по нажатию на кнопку мыши отсылала бы почтовое сообщение, в том числе на SMS-шлюз. Но как-то это выглядело тяжеловесно, а значит, ненадёжно.

Так как типичная LLM обучена работать с  текстом, первые попытки были просто давать модели чистый HTML. И как не странно, это даже работало, причём надёжнее, чем ожидалось скептиками.  

Одновременно в параллельной вселенной существовали E2E тесты, которые имитировали живых юзеров, нажимали на кнопки и заполняли поля. И этим тестам тоже как-то надо было отслеживать изменения на экране. Сравнение скиншотов оказалось крайне не надёжным методом. Тут разработчики Playwright – это известный open source фреймворк для E2E тестов, под крылом Microsoft - вспомнили про  ARIA и экранные читалки.

Мы часто думаем, что плохой интерфейс — это про кнопки, цвета или сетку. Но чаще он ломается не из-за пикселей. А из-за того, что дизайнер не учитывает, как на самом деле работает мозг.

Пользователь — не машина. Он устает. Спешит. Тревожится. Делает выводы на основе первых впечатлений.

И вот здесь включаются когнитивные искажения. Разберём 5 самых опасных для UX.

Привет, Хабр!

Мне нравятся красивые и удобные интерфейсы. С самого начала карьеры я всегда старался делать всё, что мог для комфорта пользователя. Этим я выделялся среди коллег. Большая часть из них не тратили время, продумывая взаимодействие пользователя с интерфейсом.

Я даже думал, что есть разработчики, которые специально хотели помучить пользователей. К сожалению, тогда я ничего не знал об ужасных интерфейсах, поэтому не мог помочь им. Хочу исправиться!

Сегодня я рассмотрю несколько практических ловушек, из-за которых пользователи вспомнят разработчиков не очень хорошим словом. Будьте в этом уверены. В основном мы будем использовать только HTML. Так что вы быстро сможете внедрить их в свои проекты.

Давайте посмотрим, что я вам подготовил.

Привет, Хабр!

Мне грустно, что вы не используете многие HTML- и CSS-фичи. Я не могу смотреть на это, бездействуя, поэтому пришёл к вам. Хочу поделиться своим списком фич, которые уже давно пора использовать.

Конечно, я подумал о кроссбраузерности. Поэтому все фичи хорошо поддерживаются во всех современных браузерах с 2023 года. Я специально проверил их в «Can I use».

Давайте посмотрим, что я вам подготовил.

Всем привет, мы пытаемся заниматься инфраструктурной доступностью.

Мы чуть-чуть уже копали в сторону когнитивных отличий, за последний неполный год нырнули чуть глубже, вот что у нас получилось.

Искусственный интеллект всё активнее входит в медицину и цифровые сервисы.

Он помогает диагностировать заболевания, персонализировать интерфейсы, анализировать поведение пользователей и даже формировать рекомендации по лечению.

Open Academy — это Telegram mini app для обучения финансам (в будущем и другим направлениям) прямо внутри Telegram и в удобном формате слайдов. В этой статье я разбираю доступность интерфейса Open Academy с точки зрения незрячего пользователя и показываю, какие элементы можно улучшить.

Это разбор реального опыта внедрения доступности в крупном веб-продукте с десятками микросервисов и сложным фронтендом. Без лозунгов, зато с кодом, ошибками, переработками дизайн-системы и неожиданными проблемами в CI. Поговорим про ARIA, серверный рендеринг, мобильные скринридеры, автоматическое тестирование и про то, почему доступность — это не про alt у картинок, а про архитектуру.

Когда я впервые услышал фразу сделаем доступность, я честно подумал: окей, добавим alt, поправим контраст, закроем задачу. Спойлер — это был самый наивный момент за весь проект.

Мы работали над крупной B2B-платформой. Много форм, таблиц, кастомных контролов, графиков, drag-and-drop, модалки внутри модалок. И в какой-то момент заказчик сказал: продукт должен соответствовать WCAG 2.1 AA. Причём не формально, а чтобы им реально могли пользоваться люди с ограничениями по зрению и моторике.

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

Давайте по порядку.