Как мы предложили сделать сайт МТС Live удобным для людей с особыми потребностями
Всем привет! Меня зовут Ксения Анисимова, я студентка ИТМО. Весной этого года наша команда ― Rangers of Accessibility ― победила в хакатоне МТС True Tech Hack в треке «Улучшение клиентского опыта витрины МТС Live для пользователей с особыми потребностями». В рамках конкурсного проекта мы придумали новый способ отображения карты зала, а также переработали пользовательский путь для скринридеров, чтобы незрячие и слабовидящие люди тоже могли покупать билеты. А еще добавили фильтрацию мероприятий (и площадок) по опциям доступности (наличию тифлокомментирования, маршрутов для маломобильных граждан и сопровождения на русском жестовом языке). В финале хакатона мы представили свой проект в рамках конференции True Tech Day.
В этой статье расскажу о деталях решения ― какие проблемы мы выявили и как их решали.
Мы в финале хакатона True Tech Hack. Фото: МТС
Предыстория
В последнее время на фоне хайпа ИИ дизайн как таковой, а тем более дизайн для пользователей с особыми потребностями, довольно редко становится центральной темой крупных хакатонов. Поэтому когда мы с ребятами увидели первые объявления МТС о конкурсе, сразу решили участвовать. Четверо из нас ― я, Даня, Лера и Даня ― учатся в одной группе на программе магистратуры «Мультимедиа-технологии, дизайн и юзабилити» факультета программной инженерии и компьютерной техники (ПИиКТ) в ИТМО. Бэкендера мы искали уже перед регистрацией и в последний момент к нам присоединился Дмитрий Сафенрейтер с бакалавриата ИТМО «Компьютерные системы и технологии». Консультировала нас Алена Джумагулова ― преподавательница в ИТМО, которая как раз специализируется на инклюзивных интерфейсах.
Наша команда
На хакатоне предлагали два трека, в том числе по разработке решения для улучшения сценариев подбора мероприятия, покупки билетов и посещения событий на витрине МТС Live для людей с особыми потребностями. Это мог быть отдельный сервис или функционал, интегрированный в существующий сайт. При этом организаторы никак не ограничивали группы людей, под которые необходимо было разработать интерфейс, то есть задачу надо было решать для всех людей с особыми потребностями.
Примерно с таких вводных мы начали погружаться в тему.
В чем была проблема
Первым делом мы попытались воспользоваться витриной МТС Live, как это сделал бы незрячий человек. Для этого использовали расширение Wave ― инструмент оценки доступности веб-контента.
По итогам такого тестирования на сайте определились три главные проблемы:
Отсутствие информации об элементах инклюзивности на площадках, где проводятся мероприятия. Даже если на площадке присутствовали пандусы, парковки для инвалидов, специально разработанные маршруты от парковки до зала или люди, готовые помочь попасть внутрь маломобильным посетителям, на витрине этих данных не было. Поэтому и искать мероприятия по опциям доступности было сложно. Приходилось находить эту информацию на сторонних сервисах для каждой отдельной площадки.
Неоптимизированные маршруты по сайту для пользователей, которые взаимодействуют с ним через скринридер. С помощью расширения Wave мы обнаружили, что человеку приходится слушать очень много не самой важной информации.
Незрячие люди попросту не могли покупать билеты на платформе, такой опции не было. Тест показал, что самую важную информацию скринридеры как раз не озвучивали, а когда пользователь пытался с помощью скринридера нажать на кнопку покупки билета, ничего не происходило.
Мы стали искать похожие решения, но поняли, что эти проблемы характерны практически для всех ресурсов по продаже билетов ― в том числе железнодорожных. Поэтому подсмотреть готовый ответ было негде.
Решение задачи
Мы довольно масштабно подошли к теоретической подготовке: изучили актуальные исследования в области проектирования интерфейсов для людей с особыми потребностями (причем сделали упор именно на русскоязычной аудитории), рассмотрели особенности цветовосприятия при различных формах дальтонизма, подробнее узнали про потребности слабовидящих и незрячих пользователей. Параллельно изучали международные стандарты в области доступности и смотрели, какие решения есть у зарубежных коммерческих компаний в области инклюзивных интерфейсов. Дополнительно мы руководствовались комментариями экспертов в области доступности.
Изначально у нас возникла идея сделать отдельную версию сайта для слабовидящих. Но после того, как мы пообщались с экспертами и изучили литературу по теме, поняли, что подход неоптимален: им мало пользуются в мире, поскольку такие решения искусственно отделяют людей с особыми потребностями от всех остальных.
Вот подборка материалов, поясняющих, почему отдельная версия ― не самый оптимальный путь:
Поэтому изменения необходимо было внедрить в основной сервис, причем так, чтобы они не «сломали» UX для обычных пользователей. Такой подход более правильный с точки зрения проектирования, поскольку инклюзивность и универсальность лучше закладывать на старте.
После глобального исследования приступили к разработке. В качестве «полигона» полностью скопировали сайт МТС Live и, используя React и node.js, начали преобразовывать UX, чтобы можно было не просто описать идею в тексте, но и пройтись по новой версии сайта.
Итак, что же мы сделали и почему…
Добавили элементы интерфейса
Разработали целый пакет иконок доступности в стилистике МТС Live. Для этого взяли дизайн-систему компании, детально ее изучили и построили пакет иконок в соответствии с существующими визуальными решениями, чтобы все смотрелось органично. Отчасти этот стиль напоминает Material Design от Google, поэтому некоторые иконки ― это доработанная версия изображений из этой библиотеки. Других же не существовало в принципе, поэтому их разрабатывали с нуля.
В главное меню сайта МТС Live внедрили раздел «Инклюзивные события», а в фильтры в разделах добавили возможность искать мероприятия по параметрам доступности. Чтобы не перегружать интерфейс, выбрали три параметра:
тифлокомментирование (словесные пояснения для незрячих) на мероприятии,
доступность помещения для маломобильных групп населения;
наличие переводчика на РЖЯ (русский жестовый язык).
Каждую карточку мероприятия снабдили дополнительными иконками доступности, которые читаются с помощью скринридера. Кроме того, карточки получили свои уникальные описания. В целом мы добавили атрибут aria-label почти во все интерактивные контентные элементы ― как раз для скринридера. Теперь описание, которое этот инструмент озвучит, есть даже у кнопок поделиться и лайкнуть.
На странице мероприятия добавили секцию «Доступная среда», где перечисляются все опции площадки и мероприятия: парковки, маршруты, особые туалетные комнаты, доступность для инвалидов по слуху и так далее. Теперь эту информацию не надо часами искать по разным сайтам.
Изменили пользовательские пути
Мы оптимизировали маршруты пользователя с особыми потребностями, чтобы ему было проще выбирать мероприятия и покупать билеты с помощью скринридера. Маршруты стали короче и удобнее.
На оригинальном сайте, чтобы добраться от первого элемента на странице до карточки с мероприятием, нужно было совершить более 70 шагов, пропуская весь фильтр по датам и дням недели (изначально было включено зачитывание дат на два месяца вперед). Чтобы обойти это, мы применили атрибут aria-hidden, позволяющий скрыть элементы интерфейса от скринридеров.
Доступ к этим фильтрам перенесли в уже существующую кнопку календаря: при нажатии на эту кнопку открывается модальное окно, где можно выбрать нужную дату. Чтобы посетитель, использующий скринридер, понимал, что включен фильтр по датам, мы применили атрибут aria-live.
Реализовали покупку билетов через скринридер
Изначально на сайте была реализована навигация только в графическом формате ― чтобы выбрать место в зале, нужно было открыть соответствующее окно с картой и кликнуть на нужный элемент мышкой. Повторить это действие с помощью скринридера было невозможно. Чтобы понять, насколько это сложно делать незрячему или слабовидящему пользователю, представьте, что вы ориентируетесь по карте огромного зала с помощью кнопки Tab, при этом никак не можете отличить места с принципиально разной стоимостью билетов.
Готовых сервисов, которые решали бы эту проблему, мы также не обнаружили. Поэтому искали свой вариант текстовой навигации и нашли, кажется, достаточно элегантное решение ― построили иерархическую структуру зала. Сначала пользователь выбирает ценовую категорию, далее ― ряд, а затем ― диапазон мест. С помощью этой структуры можно быстро понять, какие билеты доступны для покупки, и оформить все без графической карты зала.
Кстати, саму карту зала мы тоже переработали. Изначально на ней присутствовало только цветовое кодирование категорий мест: допустим, билеты за 6 тыс. обозначались желтым, а за 5,5 тыс. ― темно-желтым. Для людей с нарушенным цветовосприятием ориентироваться по такой карте сложно: они не могут различать цвета соседних категорий. Поэтому мы решили сделать представление более контрастным и добавили графическое кодирование. Раньше каждое место в зале отображалось квадратиком со скругленными углами, теперь же применяются различные цвета и соответствующие им фигуры (они же отражены в легенде схемы).
Архитектура решения
Бэкенд написан на связке JVM-Kotlin. Архитектура предложенной версии витрины выглядела так:
По сути мы реализовали три типа событий.
Первое ― запрос всех мероприятий. Переходя на главную страницу сайта, пользователь обращается к балансеру, работающему на L7 и распределяющему нагрузку между инстансами бэкенда. После логирования запроса балансер, используя API-договор между собой и бэкенд частью, обращается по протоколу http/https к серверу (к внутренней базе данных на PostgreSQL) для поиска мероприятия. Запрос имеет формат readonly, поэтому выполняется на readonly реплике БД.
Второй ― фильтрация мероприятий. Когда пользователь делает запрос через Search Events, опять же через балансер он отправляется к БД. В результате отображаются отфильтрованные карточки с мероприятиями.
Третий ― получение информации о конкретном мероприятии на его карточке. Пользователь получает от БД ответ со всей информацией о предстоящем событии (в том числе о том, каков его уровень доступности).
При этом в readonly реплику информация попадает из мастер-базы данных, куда ее заносят операторы.
Перед презентацией решения мы также провели юзабилити-тестирование с незрячим девопсом из VK Евгением Некрасовым. В ИТМО он руководит программой магистратуры «Программирование для незрячих и слабовидящих». И только после того, как стало понятно, что всё работает и купить билеты можно, решение отправили на оценку.
Вместо итогов
Мы очень довольны результатом. Мы глубже погрузились в тему инклюзивности, познакомились с новыми людьми и идеями. Проект помог рассмотреть проблему с различных сторон, изучить множество доступных инструментов.
Хакатон в целом и этот проект в частности показали, что и бизнес, и сообщество стали обращать больше внимания на тему доступности интерфейсов. По сути с ограничениями может столкнуться любой человек. Достаточно сломать ногу и придется выбирать площадки, предназначенные для маломобильных граждан. Таким образом, я считаю, что на самом деле предложенное нами решение охватывает более широкую аудиторию.
Нашу идею можно использовать не только для продажи билетов на концерты, но и на любых других похожих ресурсах ― даже на транспорте. И это хороший кейс в портфолио, который может в будущем пригодиться при устройстве на работу.
PS. Видео с награждения:
