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

У меня есть хобби — смотреть записи собеседований фронтенд-разработчиков. К моей радости, во многих из них встречаются вопросы про accessibility. На этом хорошие новости заканчиваются.

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

Я на практике покажу, в каких местах появляется accessibility. Дам несколько советов. Также важно сказать, что все термины, используемые в статье, моя вольная интерпретация. Пожалуйста, учтите это и больше обращайте внимание на смысл.

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

Невизуальная доступность

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

Данная категория пользователей взаимодействует с интерфейсом с помощью специальной программы. Называется она скринридер (screen reader). Пользователь с помощью неё перемещается по интерфейсу, а она в свою очередь озвучивает ему подсказки об элементе, на котором он находится. Например, кнопка, ссылка, навигация, форма и т.д.

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

В качестве результата пользователь получает список элементов одного вида. Например, список всех ссылок на странице. Далее он уже переключается между ними.

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

Для демонстрации я воспользуюсь скринридером NVDA. Я выберу режим, в котором должны отобразиться основные области страницы. Например, область навигации и основного контента.

В итоге мы получили только область «Баннер». Для скринридера нет области навигации и основного контента. Пользователь будет озадачен и пойдёт искать их самостоятельно.

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

Например, нельзя добавить товар в корзину, потому что скринридер не нашёл кнопку «Добавить в корзину».

Визуально мы можем увидеть кучу товаров, и у каждого есть кнопка «Добавить в корзину». Следовательно, скринридер должен был вывести их все в список. Но он не смог их найти.

Давайте ещё раз посмотрим на список кнопок. Хочу дополнительно обратить ваше внимание, что среди найденных есть кнопка с надписью «Без метки».

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

Скринридер скажет ему: «Кнопка». А дальше люди должны быть экстрасенсами и сами узнать, что она делает. На самом деле данная кнопка открывает чат поддержки.

В целом мы закончили. Рассмотренные проблемы сводятся к зоне ответственности разработчиков. Хорошо, что они решаются очень просто. Достаточно использовать HTML и ARIA атрибуты, и большинство трудностей будут решены.

Доступность размеров

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

Мои руки — это моя забота. По этой причине для меня целый челлендж — взаимодействие со смартфоном. Я «обожаю», когда мне нужно ввести данные в форму. Мой топ один — это вот такие поля для ввода даты рождения.

Я не спорю, что есть люди, которые ловко и быстро попадут по маленьким цифрам на виртуальной клавиатуре. Но это точно не я. После такого опыта я не могу держать в руке смартфон, потому что больно. Рука быстро устаёт и ноет.

Кроме ввода данных, ещё один камень преткновения — размеры интерактивных элементов. Если они маленького размера или стоят близко друг к другу, то мне сложно по ним попасть. Мне приходится дополнительно напрягать травмированную руку. Это вызывает боль.

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

Такое поведение я встретил при выборе города.

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

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

Визуальная доступность

Ранее мы рассмотрели сложности пользователей с тотальной или частичной слепотой. Но есть отдельная группа людей, у которых есть различные особенности зрения. А значит они по-другому взаимодействуют с интерфейсом.

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

По сути такое состояние интерфейса то же самое масштабирование. Только проблемы, с которыми сталкиваюсь я и она, разные.

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

Смогли догадаться, что означают «Меж...», «В дру...» и «Чаты ...»? Лично у меня с первого раза не получилось. Мама тоже не смогла.

Другой проблемой является то, что не весь текст масштабируется. Например, текст «Кешбэк до 50 000 ₽».

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

Типичным примером такого явления являются стилизация элементов форм после валидации. Например, добавление текста об ошибке.

Давайте посмотрим, каким цветом увидят пользователи с разными особенностями зрения. Для этого воспользуемся инструментами разработчика. Во вкладке «Rendering» есть специальный режим эмуляции «Emulate vision deficiencies».

Например, выберем «Protanopia» (Протанопия).

Или «Deuteranopia» (Дейтеранопия).

Также цвет может сильно влиять на зрение. Банально его интенсивность может вызвать неприятные ощущения или боль. Для этого были придуманы разные режимы отображения интерфейса. Их даже добавляли в браузеры.

Например, в браузере Google Chrome можно выбрать тёмную тему интерфейса.

Только разработчики веб-приложений мешают браузерам отобразить интерфейсы в выбранной теме. Например, при покупке авиабилетов.

Хотя сами дополнительно её реализовали и заставляют пользователя её выбирать через настройки.

Кроме браузеров, специальные режимы есть в операционных системах. Например, в Windows есть режим «High contrast mode» (режим высокой контрастности). Включается он с помощью сочетания клавиш Left Alt + Left Shift + Print Screen.

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

Так она отображается в обычном режиме (посмотрите, пожалуйста, в правый верхний угол).

А теперь попробуйте найти её в режиме высокой контрастности Windows.

К визуальной доступности также отношу различные состояния интерфейсов. Самый обычный пример — состояние «Фокус», вызывающееся при нажатии клавиши Tab.

Оно полезно для навигации по приложению, если пользователь использует только клавиатуру. Так они понимают, где находятся.

Часто приложения вообще никак не выделяют элементы. Но есть ещё более интересная проблема. Элементы выделены, но причудливо. Вот несколько примеров, как по-разному может выглядеть обозначение текущего элемента.

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

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

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

Подведём итог

Цель этой статьи — показать разработчикам, что цифровая доступность — это не только «про слепых». Конечно, я рассмотрел не все примеры — их очень много. Но то, что мы разобрали, уже значимая часть. Надеюсь, вы увидели, что цифровая доступность касается каждого из нас. И так будет до тех пор, пока существует взаимодействие человека с интерфейсом.

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

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

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

На этом у меня всё. Спасибо за чтение!

P.S. Помогаю фронтендерам больше узнать про хорошие интерфейсы в своём ТГ-канале UX + Dev = a11y. Присоединяйтесь. Ссылка в профиле.

© 2026 ООО «МТ ФИНАНС»