Я долго думал, аудит какого веб-приложения провести первым для своей небольшой заметки, чтобы показать наглядно подход из 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 даже старых версий без настройки очень неплохо поддерживают доступность.
Нажимаю на кнопку «Регистрация» — открывается модальное окно, и я не попадаю в него. Фокус остается под модальным окном, и чтобы переместиться в него, надо пройти весь контент подложки. Из позитивного: когда я все же попал внутрь окна, то там фокус замкнулся и из окна уже не выходил. Но то, что при открытии я никак не был уведомлен об окне и тем более тут же не попал в него, — это большая проблема. Она полностью ломает навигацию.
Все это говорит о незрелой дизайн-системе и не очень качественной 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 — это заголовок третьего уровня в одном из виджетов. Кстати, такая ситуация встречается очень часто, так как на таких больших проектах над разными виджетами работают разные команды, и в семантике полный хаос.
Lighthouse показал 81% доступности. Из интересного в дополнение к другим инструментам он подсветил, что контролы карусели на главной должны быть большего размера.
Выводы
Результаты аудита разочаровывают. Для такого крупного и финансово успешного банка, каким является «Приорбанк», уровень доступности его ключевого цифрового продукта недопустимо низок. Обнаруженные проблемы — от отсутствия базовой навигации до полной недоступности критического функционала для скринридеров — создают непреодолимые барьеры для людей с ограниченными возможностями.
У банка, несомненно, есть ресурсы для формирования сильной фронтенд-команды и привлечения экспертов по доступности. Однако текущее состояние приложения говорит о том, что этот аспект пользовательского опыта либо не приоритизирован, либо реализуется бессистемно. Пользователям с инвалидностью пользоваться этим сервисом крайне неудобно, а в случае с банковскими операциями — практически невозможно.
Скорее всего, проблема в том, что этот фронтенд жутко старое легаси, которое было немного разукрашено и подштопано под современный визуал. Мой анализатор показывает следующий стэк: jQuery UI, jQuery Mobile, Kendo UI, Bootstrap, Font Awesome, RequireJS, Animate.css.
Стэк явно очень старый и отчасти это основная проблема. В таком легаси будет титанически сложно навести порядок. Уровень доступности jQuery UI по умолчанию очень низкий и безнадёжно устарел. Создание доступных интерфейсов с этой библиотекой требует огромных дополнительных усилий. А ведь я посмотрел очень маленький кусок приложения.
Основные проблемы:
- Отсутствие базовых элементов доступности: нет заявления о доступности и skip links
- Проблемы с навигацией клавиатурой: неправильный порядок табуляции, отсутствие видимого фокуса на ключевых элементах
- Низкий контраст: вторичный текст и плейсхолдеры не соответствуют WCAG Level AA
- Проблемы со скринридерами: модальные окна не захватывают фокус, отсутствие
aria-liveдля динамического контента, неинформативные ссылки, плохая поддержка валидации форм скринридером - Семантические ошибки: неправильная структура заголовков, использование изображений вместо кнопок, отсутствие альтернативного текста
Рекомендации:
- Внедрить skip links и заявление о доступности
- Переработать дизайн фокуса для всех интерактивных элементов
- Улучшить контрастность вторичного текста и плейсхолдеров
- Исправить работу модальных окон (использовать нативный
dialogили правильно управлять фокусом) - Добавить
aria-liveрегионы для динамического контента и другую ARIA-разметку подкрепляя это тестированием на основных популярных скринридерах VoiceOver, JAWS, NVDA - Исправить семантику: правильная структура заголовков, использование кнопок вместо изображений для интерактивных элементов
- Добавить альтернативный текст для всех значимых изображений и скрыть декоративные через роль
role="presentation"