Как незрячие «видят» сайты: разговор о доступности, навигации и UX

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

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

А если первые 5–10 элементов подписаны, и по клавише «1» я сразу попадаю на H1, даже впервые на странице, — значит, разработчик сделал всё правильно, и ориентироваться будет удобно.

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

Евгений: Мой пользовательский опыт такой: я изначально предполагаю, что сайт сверстан с учётом доступности. И когда захожу на незнакомую страницу, стараюсь быстро оценить её двумя приёмами.

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

Второй — перемещение по областям и ориентирам. Если страница размечена, это помогает почти сразу сообразить, как она устроена.

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

Сергей: Я согласен с тем, что сказали Анатолий и Евгений, но хочу обратить внимание вот на что: почему вообще так получается. Когда вы открываете страницу и не видите её, первое, что нужно — сориентироваться. И как раз заголовки и ориентиры для этого и существуют: чтобы понять, где что находится, не проходя каждый элемент подряд.

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

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

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

Сергей: Кажется, что это общепринятый вариант, хотя исключения, конечно, бывают. Обычно ожидается, что у страницы есть верхняя часть — хедер, где чаще всего находится меню (свернутое или развернутое — это уже детали). И есть основная часть, где начинается содержимое страницы.

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

Вадим: Мы таким образом сразу затронули вопрос UX-паттернов. Отличаются ли сценарии у незрячего пользователя от сценариев зрячего — особенно в сложных интерфейсах вроде интернет-магазина: меню, фильтры, покупка? Что вы ожидаете от такого пути и каким он должен быть в идеале?

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

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

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

Анатолий: Удобство и доступность — разные вещи, и доступность всё-таки важнее. Если говорить про действительно удобный интерфейс интернет-магазина, я бы привёл в пример Яндекс Лавку — и мобильное приложение, и веб. Там на одной странице показан каталог, разделы отмечены заголовками. Каждый товар — это ссылка, причём ссылка содержит только название, а вся информация о товаре идёт сразу после неё. Никаких лишних элементов на странице нет.

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

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

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

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

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

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

Евгений: Да.

Вадим: Какие проблемы доступности чаще всего формально проходят по стандартам WCAG (Web Content Accessibility Guidelines) или ГОСТ, но при этом мешают реальному использованию сайта со скринридером? Есть ли у вас примеры, где стандарт соблюдён, но на практике лучше было бы сделать иначе?

Анатолий: Нет, как правило, то, что сделано в соответствии со стандартом, ведёт себя предсказуемо и ожидаемо. Если взять разные сайты и компоненты, например из ОС или крупных платформ, они формируют единый паттерн — и идеальный компонент работает именно так, как описано в спецификации.

Поэтому мысль вроде: «сделаешь по стандарту — будет формально доступно, но неудобно», я считаю сильно преувеличенной. Обычно стандарты наоборот задают понятный, проверенный способ поведения интерфейса.

Сергей: Да, я тоже думал над этим вопросом и не могу привести яркий пример, где всё по стандарту, но неудобно. Если стандарт соблюдён и всё сделано аккуратно, обычно проблем не возникает. Бывает, что есть внутренняя проблема, которую трудно сразу заметить, но это уже не случай «сделано по стандарту — неудобно». Когда элемент сделан чётко и выполняет свою функцию, с ним не должно быть проблем.

Вадим: На каком этапе проекта вас обычно подключают к тестированию доступности — проектирование, прототипы, ранние версии или финал? И как вы бы описали идеальный процесс?

Евгений: К сожалению, к нам чаще всего обращаются уже тогда, когда сайт или сервис готовы. И это создает лишнюю работу для разработчиков: дополнительное время, деньги и усилия, чтобы доработать уже сделанный продукт и привести его к требованиям цифровой доступности. Гораздо лучше, если доступность закладывать с самого начала, когда продукт только проектируется. Тогда экономятся и время, и ресурсы — и итог получается сразу более качественным.

Сергей: Я дополню. Когда уже есть готовый интерфейс, диалог становится предметным: видим конкретные элементы, понимаем, что в порядке, а что нет, и где нужно править. Это удобно, но требует больше работы и времени, чем если бы всё делалось заранее. У нас мало опыта на ранних стадиях, просто быть в чате — это одно, а выстроить процесс так, чтобы оперативно взаимодействовать по ходу разработки — другое. На практике чаще всего начинается с уже существующим сайтом или приложением, и это влияет на сложность для разработчиков.

Евгений: Недавно у нас был опыт, когда мы подключались к процессу разработки совсем с нуля. Это была работа над сайтом для музея — лендинг для посетителей с разными ограничениями.

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

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

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

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

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

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

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

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

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

Анатолий: Смотрите, задача разработчика интерфейса не входит лишить человека инвалидности. Это не ваша задача.

Вадим: То есть, если резюмировать, вы уверены, что путь тот же, а нужно сконцентрироваться на конкретных компонентах?

Все: Да.

Вадим: И нет смысла продумывать альтернативные пути, которые будут удобнее со скринридером и менее удобны визуально?

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

Во-вторых, практический пример: в каталоге магазина может быть много категорий и подкатегорий, что в некоторых случаях долго. Но если есть альтернативный путь — например, поиск, который позволяет прямо ввести название товара и сразу перейти к нему — это естественный вариант. Не надо придумывать отдельный путь только для скринридеров; важно дать несколько путей и дать человеку выбрать, что удобнее.

Анатолий: Вот смотрите, я проиллюстрирую две мысли. Вот первое, что Евгений говорит, как можно оптимизировать текст. Когда есть числовые данные, лучше ставить их перед постоянным текстом. Например, на иконке почты: «Почта 23 новых сообщения», а не «Почта новых сообщений 23».

Женя говорил ещё о том, что интерфейсные тексты не должны быть перегружены. Не надо вставлять в название элемента подсказку. Если в названии кнопки присутствует слово «нажмите», то это кривой интерфейс. Он кривой и для зрящих — они тоже не хотят читать «нажмите» в названии кнопки.

Вадим: Конечно.

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

Сергей: Да, отличный пример, действительно.

Евгений: Это, кстати, действительно хороший пример.

Сергей: Это, наверное, ответ на вопрос Вадима.

Вадим: Да, всё верно. Спасибо.

Вадим: Давайте перейдем тогда к следующему вопросу. Можете оценить, в каком состоянии сейчас находится доступность сайтов? Что изменилось года за 3? Что остается системной проблемой?

Евгений: Это моё субъективное впечатление, и оно может отличаться от мнений ребят. Но сейчас таких сайтов, которыми можно пользоваться так или иначе, стало гораздо больше. Почему так? Вероятно, потому что платформы и компоненты, на которых строятся сайты, стали доступнее, и потому что люди стали обращать внимание на цифровую доступность — пытаются сделать интерфейсы, которые могут использовать разные люди с разными ограничениями.

Тем не менее, у меня такое ощущение: несмотря на рост числа доступных сайтов, ещё многое нужно сделать — особенно в законодательной области и в просвещении менеджеров, разработчиков и дизайнеров. Даже когда я сейчас ищу примеры сайтов с явными проблемами доступности, чтобы показать их на вебинарах, найти что-то «наглядно плохое» уже сложнее, чем раньше.

Анатолий: Существует исследование WebAIM Million — это анализ самых популярных страниц интернета с помощью автоматизированных инструментов. Согласно ему, примерно 95–98 % таких страниц содержат как минимум одну ошибку доступности, а в среднем на страницу приходится около 50 ошибок. С точки зрения этих данных ситуация глобально почти не улучшается год от года.

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

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

Евгений: Да, я с Анатолием соглашусь. Если говорить про обычные информационные сайты, которые мы чаще всего посещаем, то по моим ощущениям явных проблем стало меньше. Но как только мы переходим к профессиональным инструментам, ситуация меняется. Там требования становятся выше — потому что это уже рабочая среда, и от доступности зависит не комфорт, а возможность нормально работать. И вот здесь проблем по-прежнему много.

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

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

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

Мне поэтому сложно однозначно сказать, стало лучше или хуже: меняется сам интернет. Если 10–15 лет назад мы в основном заходили что-то прочитать или посмотреть — то есть взаимодействовали со статичным контентом, — то сейчас мы приходим, чтобы выполнять действия: оформить документ, купить, заполнить, отправить, создать. И вот здесь важны все детали.

Бывает ситуация: всё шло нормально до последнего шага, а потом появляется выпадающий список — и с ним невозможно работать через скринридер. И это конец процесса. До этого всё было "почти доступно", но действие завершить невозможно.

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

Вадим: Спасибо, это очень важное замечание: иногда одного небольшого шага достаточно, чтобы весь процесс стал недоступным.

Сергей: Да, именно так.

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

Сергей: Есть довольно типичная ситуация: одна или несколько кнопок на сайте не подписаны. И вот здесь AI иногда реально помогает. У меня было несколько случаев, когда я делал скриншот и отправлял его в сервис Be My Eyes — чтобы распознать, что это за группа кнопок, и найти нужную.

В VoiceOver и TalkBack есть функция, когда система по значку пытается определить назначение кнопки: видит "шестерёнку" — предполагает, что это настройки, даже если кнопка не подписана. Это часто выручает, когда интерфейс "не совсем доступен". Но важно понимать: если интерфейс совсем плохой, AI уже не спасает.

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

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

Сергей: Да, обходные решения — это обычная часть опыта. Но здесь всё очень индивидуально. Например, какое-то время я пользовался веб-версией Telegram в дополнение к Telegram на iOS. Потом понял, что для меня эффективнее другое сочетание: Unigram на ноутбуке плюс Telegram на iOS. В итоге каждый незрячий пользователь подбирает свои комбинации инструментов.

Евгений: Кстати, пример с Telegram — очень показательный. На Windows мы часто используем Unigram, а вместе с ним — дополнение, которое сделали незрячие разработчики. Оно помогает сразу в двух вещах: повышает доступность и заметно ускоряет работу.

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

Сергей: Да, точно.

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

Сергей: И то и другое.

Евгений: Да, мне кажется, это и социальная ответственность, и бизнес. Эти вещи должны идти рядом — одно не исключает другое.

Вадим: А бизнес может измерить эффект от доступности? Если да — как именно?

Сергей: Если говорить про сервисы вроде интернет-магазина, эффект, конечно, есть. Другое дело, что измерить его в цифрах бывает непросто. Но я могу сказать за себя: если у меня есть выбор между сервисом, где интерфейс понятный и предсказуемый, и сервисом, где приходится наугад что-то искать и «тыкать», — как вы думаете, чем я буду пользоваться?

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

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

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

Если же спросить: «сколько денег принесёт доступность?», то если смотреть только на незрячих пользователей, кажется, что эффект небольшой — нас действительно мало, и пользователей скринридеров ещё меньше.

Но проблема в том, что доступность — это не только про слепых. Это и люди с разными видами инвалидности, и возрастные изменения, и временные ограничения. И если мы "выбрасываем" всех этих людей, мы теряем огромную часть аудитории.

Есть хороший пример: исследование Яндекса про настройки доступности. Там около 51% людей отмечали, что используют такие функции — кто-то увеличивает шрифт, кто-то включает тёмную тему, кто-то пользуется субтитрами. Это показывает, что доступность — не нишевая история, а массовая. И ещё важный момент — выбор. Если у меня есть два сервиса, которые решают одну задачу, я выберу тот, которым могу пользоваться. Даже если он дороже.

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

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

Вадим: Если я правильно вас понял, доступность — это не только про социальную ответственность. Забота о ней сопоставима с тем, как мы выстраиваем дизайн-систему и работаем над визуальной ясностью интерфейса: это инструменты, которые решают конкретные бизнес-задачи. Это не эфемерные вещи, а вклад в общий результат — через синергетический эффект качества, удобства и доверия.

Сергей: Да.

Евгений: В общем да.

Вадим: Понятно. Спасибо вам большое за ответы. Очень интересный разговор. Он получился точным и честным — и подсветил то, что обычно не попадает в обсуждение. Думаю, он будет полезен не только специалистам, но и тем, кто делает продукты.