Я долго думал, аудит какого веб-приложения провести первым для своей небольшой заметки, чтобы показать наглядно подход из 5 шагов. С одной стороны, это должно быть что-то массовое, чем могут пользоваться большое количество людей с ограничениями. С другой стороны, владелец портала должен иметь достаточный бюджет для того, чтобы иметь возможность нанять высококвалифицированных веб-разработчиков, которые могут реализовать доступность.Наивно ожидать доступности от госучреждений, сайтов госполиклиник или порталов чиновников — там нет таких зарплат, как в частном секторе коммерческого ИТ. Также приложение должно быть хорошо известно обывателю и быть на слуху, даже если он им не пользуется.Кто же будет первым? Более 12 лет я являюсь клиентом Приорбанка (Беларусь, РБ). Банки — это важные сервисы, они определенно должны быть доступны людям с ограничениями. Я решил начать именно с него, это сервис который важен и для меня, поэтому в двойне интересно это сделать. Да простят меня сотрудники банка!)Методология аудитаЯ провел быстрый аудит из 5 шагов веб-приложения Приорбанка. Приложение большое, поэтому я выбрал проверить достаточно простой и популярный кейс — авторизироваться (или зарегистрироваться) и проверить свой счет на карте. Итак, пройдем быстро по всем пунктам и узнаем что получилось.1. Заявление о доступности и Skip LinksСразу отмечу отсутствие двух фундаментальных элементов:Заявление о доступности (Accessibility Statement)Ссылки для пропуска навигации (Skip Links)Подобные элементы — базовый шаг, и их отсутствие сигнализирует о поверхностном подходе. Отсутствие этих шаблонов — явные маркеры того, что подход к доступности у разработчиков и менеджеров продукта не очень серьезный, а значит можно ожидать явных проблем в этой области дальше. Подвал сайта Приорбанк2. Навигация с клавиатурыПытаюсь навигировать клавиатурой на главной странице и немного удивляюсь, что после верхнего меню попадаю на контролы управления динамической каруселью, которая рекламирует кредиты, реферальную программу и мобильное приложение. Только вот обо всем этом я не узнаю с плохим зрением, так как контент динамический и не размечен aria-live, а значит скринридер эти изменения озвучивать не будет.Кажется, что форма логина — это главная фича этого экрана, и я должен иметь возможность попасть на нее как можно раньше, но нет. Между шапкой и формой мне надо пройти рекламные сообщения. Карусель с рекламой акций банка Еще грустнее, что фокус на многих элементах выключен. На самой главной кнопке формы «Войти» нет стилизации фокуса (:focus-visible). Очевидно, это очень плохо, так как я не вижу, где нахожусь. Проблема стара как мир: дизайнеры и разработчики не уделили время дизайну фокуса, и он работает так, как получилось. Фокус на кнопке Войти формы логина А вот у соседней кнопки «Регистрация» фокус есть, но очень кривенький. А знаете почему? Потому что это не кнопка, а ссылка. На ссылках стилизация фокуса на сайте есть. Но странно, почему это ссылка, а не кнопка? Тут уже вопросы к проработке дизайн-системы. Кажется, что рядом с primary-кнопкой должна быть secondary. Причем ссылка обычно используется, когда ведет на физически другую страницу или маршрут, здесь же при регистрации открывается модальное окно. Фокус на кнопке Регистрация формы логина Между тем, закрыть модальное окно для русскоязычного пользователя непросто. Кнопка закрыть размечена английским словом «Close», хотя сайт на русском. Но в любом случае, наличие такого aria-label лучше, чем его полное отсутствие. Скорее всего, это что-то стандартное у UI Kit или просто разработчик на автомате вставил, чтобы кнопка с иконкой имела хоть какую-то подпись. Модальное окно регистрации и кнопка закрыть с подписью Close3. Контрастность цветовЧерный, желтый, белый — неплохое сочетание, достаточно контрастная комбинация.Узким местом стали несколько вторичных подписей и ссылок, а также плейсхолдеры инпутов. Тут текст серого цвета на белом, и он имеет плохой контраст. Соотношение, как видим на картинке, 2.4:1, что не попадает в WCAG Level AA.Вообще, даже без WCAG, можно просто прищуриться и попытаться разобрать текст, попробуйте, это будет сложновато. Проверка контраста цвета через CCA4. Работа со скринридером и клавиатуройВключаю плагин размытия, чтобы сэмулировать свое плохое зрение, и начинаю работать с сайтом через скринридер VoiceOver и клавиатуру. Вот тут самое интересное, потому что это реальная работа человека с ограничениями.Натыкаюсь опять на контролы управления каруселью вместо формы логина. Они никак не подписаны, сделаны ссылками, все это вводит в большое заблуждение конечного пользователя. Кажется, карусель сделана каким-то древним jQuery-плагином (вроде Owl Carousel) или руками с нуля, современные штуки, вроде Swiper, даже старых версий без настройки очень неплохо поддерживают доступность. Фокус на контролах управления каруселью в включенным VoiceOver Нажимаю на кнопку «Регистрация» — открывается модальное окно, и я не попадаю в него. Фокус остается под модальным окном, и чтобы переместиться в него, надо пройти весь контент подложки. Из позитивного: когда я все же попал внутрь окна, то там фокус замкнулся (focus trap) и из окна уже не выходил. Но то, что при открытии я никак не был уведомлен об окне и тем более тут же не попал в него, — это большая проблема. Она полностью ломает навигацию. Фокус остался на кнопке Регистрация после открытия модального окна Все это говорит о незрелой дизайн-системе и не очень качественной UI-библиотеке. Как правило, современные фреймворки и даже нативный HTML dialog умеют захватывать фокус при открытии окна и автоматически направлять его на первый элемент внутри окна. Тут модалка сделана обычными div-контейнерами. Фокус остался на кнопке Регистрация после открытия модального окна Ошибки внутри формы не размечены динамическим контентом (aria-live) и никак не связаны с полями ввода (aria-errormessage), поэтому при попытке нажать «Продолжить» и не заполнив обязательные поля, скринридер ничего мне не сообщает об ошибках. То же самое и на форме логина. Нет уведомления от скринридера о появившихся ошибках на форме регистрации Кстати, бывших тестировщиков не бывает, нашел баг, где плейсхолдер поля ввода наложился на маску: Плейсхолдер поля ввода номера телефона наложился на маску ввода Есть и другие проблемы для незрячих. Обнаружил несколько ссылок, которые были очень неинформативны. К примеру, номера для связи с диспетчером или обратной связью никак не связаны с подписями и озвучиваются просто как наборы цифр без контекста. Кнопка «Вверх» не имеет подписи и вводит в замешательство, так как непонятно, что она делает. Номер телефона диспетчера диктуется скринридером без контекста Кнопка подкрутки вверх не имеет подписи Ок, идем наконец внутрь. Попадаю в личный кабинет и... Ну, тут тоже так быстро шапку и меню не пропустить. Мне всегда было очень интересно, как сделать макеты дебетовых карт доступными. И каково мое разочарование, когда я узнаю, что не могу попасть на них клавиатурой, потому что это не контролы. Хотя курсором мыши они кликабельны, чтобы провалиться внутрь. Ну и контент в них — это просто несвязные символы и цифры, обернутые в div и span с очень странными аттрибутами title. Для скринридера это фиаско. Компоненты дебетовых карт Ладно. Идем в таблицу моих продуктов, может, тут я смогу понять, сколько денег на моей карте. Сразу же проблема с озвучиванием колонки с карточками: мне говорит, что ячейка пустая, хотя в ней отображается иконка типа карты (Visa, MasterCard, МИР и т.д.). Было бы хорошо это озвучить. Скринридер озвучивает таблицу моих продуктов - столбец тип карты Ок, в последнем столбце мне удается все-таки услышать, сколько денег у меня на счету. Скринридер озвучивает сумму на карте5. Сканирование инструментамиПоследний шаг — это сканирование инструментами. Axe DevTools показал 12 ошибок на странице логина и 14 ошибок на главном дашборде личного кабинета. В основном это проблемы контраста серого на белом, неверные роли ARIA и даже картинки без