Артур Басак

Web UI/UX Engineer

Эта статья выросла из ростка моего цифрового сада.

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

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

Кто же будет первым? Более 12 лет я являюсь клиентом Приорбанка (Беларусь, РБ). Банки — это важные сервисы, они определенно должны быть доступны людям с ограничениями. Я решил начать именно с него, это сервис который важен и для меня, поэтому в двойне интересно это сделать. Да простят меня сотрудники банка!)

Методология аудита

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

1. Заявление о доступности и Skip Links

Сразу отмечу отсутствие двух фундаментальных элементов:

• Заявление о доступности (Accessibility Statement)

• Ссылки для пропуска навигации (Skip Links)

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

2. Навигация с клавиатуры

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

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

Еще грустнее, что фокус на многих элементах выключен. На самой главной кнопке формы «Войти» нет стилизации фокуса (:focus-visible). Очевидно, это очень плохо, так как я не вижу, где нахожусь. Проблема стара как мир: дизайнеры и разработчики не уделили время дизайну фокуса, и он работает так, как получилось.

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

Между тем, закрыть модальное окно для русскоязычного пользователя непросто. Кнопка закрыть размечена английским словом «Close», хотя сайт на русском. Но в любом случае, наличие такого aria-label лучше, чем его полное отсутствие. Скорее всего, это что-то стандартное у UI Kit или просто разработчик на автомате вставил, чтобы кнопка с иконкой имела хоть какую-то подпись.

3. Контрастность цветов

Черный, желтый, белый — неплохое сочетание, достаточно контрастная комбинация.
Узким местом стали несколько вторичных подписей и ссылок, а также плейсхолдеры инпутов. Тут текст серого цвета на белом, и он имеет плохой контраст. Соотношение, как видим на картинке, 2.4:1, что не попадает в WCAG Level AA.
Вообще, даже без WCAG, можно просто прищуриться и попытаться разобрать текст, попробуйте, это будет сложновато.

4. Работа со скринридером и клавиатурой

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

Натыкаюсь опять на контролы управления каруселью вместо формы логина. Они никак не подписаны, сделаны ссылками, все это вводит в большое заблуждение конечного пользователя. Кажется, карусель сделана каким-то древним jQuery-плагином (вроде Owl Carousel) или руками с нуля, современные штуки, вроде Swiper, даже старых версий без настройки очень неплохо поддерживают доступность.

Нажимаю на кнопку «Регистрация» — открывается модальное окно, и я не попадаю в него. Фокус остается под модальным окном, и чтобы переместиться в него, надо пройти весь контент подложки. Из позитивного: когда я все же попал внутрь окна, то там фокус замкнулся (focus trap) и из окна уже не выходил. Но то, что при открытии я никак не был уведомлен об окне и тем более тут же не попал в него, — это большая проблема. Она полностью ломает навигацию.

Все это говорит о незрелой дизайн-системе и не очень качественной UI-библиотеке. Как правило, современные фреймворки и даже нативный HTML dialog умеют захватывать фокус при открытии окна и автоматически направлять его на первый элемент внутри окна. Тут модалка сделана обычными div-контейнерами.

Ошибки внутри формы не размечены динамическим контентом (aria-live) и никак не связаны с полями ввода (aria-errormessage), поэтому при попытке нажать «Продолжить» и не заполнив обязательные поля, скринридер ничего мне не сообщает об ошибках. То же самое и на форме логина.

Кстати, бывших тестировщиков не бывает, нашел баг, где плейсхолдер поля ввода наложился на маску:

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

Ок, идем наконец внутрь. Попадаю в личный кабинет и... Ну, тут тоже так быстро шапку и меню не пропустить. Мне всегда было очень интересно, как сделать макеты дебетовых карт доступными. И каково мое разочарование, когда я узнаю, что не могу попасть на них клавиатурой, потому что это не контролы. Хотя курсором мыши они кликабельны, чтобы провалиться внутрь. Ну и контент в них — это просто несвязные символы и цифры, обернутые в div и span с очень странными аттрибутами title. Для скринридера это фиаско.

Ладно. Идем в таблицу моих продуктов, может, тут я смогу понять, сколько денег на моей карте. Сразу же проблема с озвучиванием колонки с карточками: мне говорит, что ячейка пустая, хотя в ней отображается иконка типа карты (Visa, MasterCard, МИР и т.д.). Было бы хорошо это озвучить.

Ок, в последнем столбце мне удается все-таки услышать, сколько денег у меня на счету.

5. Сканирование инструментами

Последний шаг — это сканирование инструментами. Axe DevTools показал 12 ошибок на странице логина и 14 ошибок на главном дашборде личного кабинета. В основном это проблемы контраста серого на белом, неверные роли ARIA и даже картинки без alt-текста (среди них есть и не декоративные).

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

WAVE насчитал 16 ошибок на главной и 49 на дашборде (почему так много? 47 из них связаны с отсутствием href у ссылок, т.е. это просто так сверстаны кнопки).

Интересно глянуть на структуру заголовков: H1, а потом сразу H4 и H5. Причем именно второй уровень — это H5, а H4 — это заголовок третьего уровня в одном из виджетов. Такая ситуация это классика — встречается очень часто, так как на таких больших проектах над разными виджетами работают разные команды, и в семантике полный хаос и никто не думает про информационную архитектуру (IA).

Lighthouse показал 81% доступности. Из интересного в дополнение к другим инструментам он подсветил, что контролы карусели на главной должны быть большего размера, чтобы на них было легче попасть курсором.

Выводы

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

У банка, несомненно, есть ресурсы для формирования сильной фронтенд-команды и привлечения экспертов по доступности. Однако текущее состояние приложения говорит о том, что этот аспект пользовательского опыта либо не приоритизирован, либо реализуется бессистемно. Пользователям с инвалидностью пользоваться этим сервисом крайне неудобно, а в случае с банковскими операциями — практически невозможно.
Скорее всего, проблема в том, что этот фронтенд жутко старое легаси, которое было немного разукрашено и подштопано под современный визуал. Мой анализатор показывает следующий стэк: jQuery UI, jQuery Mobile, Kendo UI, Bootstrap, Font Awesome, RequireJS, Animate.css.

Стэк явно очень старый и отчасти это основная проблема. Взять тот же Font Awesome, он уже давно критикуется за свою любовь вставлять иконки тэгом <i>, что нарушает семантику и может плохо сказываться на доступности. У Приорбанка именно такие иконки, хотя Font Awesome можно настроить и на более нейтральный тэг вроде <span>.
В таком легаси будет титанически сложно навести порядок. Уровень доступности jQuery UI по умолчанию очень низкий и безнадёжно устарел. Создание доступных интерфейсов с этой библиотекой требует огромных дополнительных усилий. А ведь я посмотрел очень маленький кусок приложения. С другой стороны, выглядит как отличный кейс для ИИ.

Основные проблемы:

1. Отсутствие базовых элементов доступности: нет заявления о доступности и skip links

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

3. Низкий контраст: вторичный текст и плейсхолдеры не соответствуют WCAG Level AA

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

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

Рекомендации:

• Внедрить skip links и заявление о доступности, что само собой будет служить уже ориентиром и дорожной картой по улучшения этого функционала

• Переработать дизайн фокуса для всех интерактивных элементов

• Улучшить контрастность вторичного текста и плейсхолдеров

• Исправить работу модальных окон (использовать нативный dialog или правильно управлять фокусом)

• Добавить aria-live регионы для динамического контента и другую ARIA-разметку подкрепляя это тестированием на основных популярных скринридерах VoiceOver, JAWS, NVDA

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

• Добавить альтернативный текст для всех значимых изображений и скрыть декоративные через роль role="presentation"

P.S.

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

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

Меня всегда радуют такие штуки. Хотя, искренне не знаю, каков процент тех, кто знает шрифт Брайля из тех кто плохо видит или не видит совсем. На мой взгляд аудио-дикторы и Voice UI будут более востребованы в будущем.

P.P.S.

Подумываю сделать серию таких вот легких аудитов, без какого-то rocket science с очень простыми и очевидными советами как что-то улучшить. Если тема интересна, то обязательно пишите кто мог бы быть следующим кандидатом на аудит.