25 июня 2020 года в 16:00 USABILITYLAB представила результаты сравнительной оценки доступности мобильных приложений российских банков. В вебинаре приняли участие 168 человек.

Докладчики:

• Юрий Божор (Банк России)
  
• Михаил Кузьмин (Сбербанк)
  
• Фамил Гаджиев (Альфа-Банк)
  
• Алексей Любимов (Эксперт по доступности в IT)
  
• Анна Минаева (USABILITYLAB)
  

Модератор: Дмитрий Сатин (USABILITYLAB)

Видео


Презентации

Сравнительное исследование доступности мобильных банковских приложений iOS и Android для физических лиц 2020

Accessibility Альфа-Банк

Гайдлайн Сбербанка по доступности

Об исследовании доступности 2020:
Проведена оценки доступности Android- и iOS-приложений для физических лиц. За основу методологии должны быть взяты требования доступности для инвалидов по зрению ГОСТ Р 52872-2012, а также лучшие практики и дополнения:
Информационные письма от ЦБ РФ (от 12.05.2017 и от 23.10.2017)
WCAG 2.1 Руководство по обеспечению доступности веб-контента

Каждое приложение оценивалось по набору базовых сценариев, создавались профили доступности и рассчитывался  рейтинг доступности iOS- и Android-приложений.

Бесплатная демо-версия отчета о доступности


Рейтинг доступности мобильных банковских приложений для физических лиц 2020

1. Сбербанк
   
2. Альфа-Банк
   
3. РОСБАНК
   
4. МТС Банк
   
5. Россельхозбанк
   
6. Тинькофф Банк
   
7. Райффайзенбанк
   
8. ЮниКредит Банк
   
9. Промсвязьбанк
   
10. ВТБ
    
11. Банк Хоум Кредит
    
12. Банк Открытие
    
13. Газпромбанк
    
14. Банк Санкт-Петербург
    
15. Банк Русский Стандарт
    

Стенограмма вебинара

Дмитрий Сатин. Дорогие друзья, здравствуйте! Сегодня у нас необычный вебинар банковского UX, потому что сегодня мы представляем результаты первого исследования, которое распространяют среди подписчиков банковского UX. Об этом чуть подробнее. Сегодняшний наш вебинар посвящен исследованию оценки доступности российских банков, USABILITYLAB проводит такие исследования не первый год. Мы обычно включаем это исследование доступности в свои рейтинги. Но это носило не очень системный характер. С прошлого года, благодаря усилию Юрия Анатольевича Божора, который здесь присутствует, была проделана большая работа. В рабочей группе, которую модерировал Юрий, была создана методика, по которой в 2019 году провели первый скрининг 14-ти банков. Сам список банков был выбран тоже при участии этой рабочей группы. В этом году список чуть-чуть расширился.

Сегодня мы представляем результаты этого исследования. И чтобы сделать его более интересным, мы подключили коллег. Вы здесь видите Алексея Любимова, который является евангелистом общедоступности в России, эксперт во многих IT-компаниях, помогает делать ресурсы более доступными. Сегодня Алексей, как представитель незрячих пользователей, согласился показать нам, как он пользуется мобильными приложениями, как мне кажется, до сих пор не все это хорошо представляют.

Юрий Анатольевич нам расскажет о позиции Банка России. Моя коллега Анна Минаева, автор нашего исследования, которое мы сегодня будем обсуждать. И представители двух банков-лидеров наших рейтингов, это Сбербанк и Альфа-Банк, Михаил Кузьмин и Фамил Гаджиев, которые завершат наше мероприятие рассказом о своих кейсах. Я видел их презентации и, мне кажется, после этого все захотят делать accessibility.

В качестве небольшой затравки я хотел бы вам показать результаты опроса, который мы провели две недели назад. Две недели назад мы проводили вебинар, посвященный юзабилити-лабораториям. И на этом вебинаре мы задали вопрос: «Как Сбербанк, планируете ли вы включать оценку доступности в свои исследования?» Результат, который мы получили, меня чуть-чуть расстроил. Если сложить два позитивных ответа справа, то они в сумме дают примерно 44%, но есть большой серый сегмент – 34%, это те, кто ответил «мы пока разбираемся с юзабилити» и 20% наших респондентов ответили: «Нет, мы не видим в этом большого смысла».

Это конкретные люди отвечали, я не хочу их обижать, но у меня на языке вертится слово «позор». Потому что не уделять внимания общедоступности, это значит исповедовать какую-то бесчеловечную политику. Я хотел бы с вами такую мысль обсудить: а зачем вообще нужны все эти старания с общедоступностью, все ассистивные, вспомогательные технологии? Я вам дам сейчас свой ответ, это цитата: «Смысл в том, чтобы предоставить людям возможность жить независимой жизнью». То есть сделать их самостоятельными. И причин, по которым мы становимся несамостоятельными, их масса. Это как проблемы со здоровьем. По всем модальностям восприятия, в том числе моторике, в том числе возрастные особенности. Среди пятерых наших спикеров, только Михаил не носит очки. Все остальные сидят в очках. И наличие этого предмета на лице говорит о том, что у нас уже есть особенности, которые нам нужно чем-то компенсировать. Поэтому очень важно делать приложения доступными.

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

Алексей Любимов. Добрый день!

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

Алексей Любимов. Сейчас вы видите на экранах совершенно стандартный айфон, это айфон 8, если кому интересно. В нем нет ничего специфического, кроме специальных возможностей, которые я сейчас включаю. Сейчас было сказано, что Voice Over включен, и жесты вправо/влево/вверх/вниз/двойной тап, они будут озвучиваться, и будет читаться то, что под курсором находится. Сейчас я захожу на главный экран. И здесь вы можете видеть, у меня все стандартные приложения, даже включая Instagram. Ну, кому интересно, буквально минут 40 назад я сделал фотографию в Instagram без помощи окружающих.

Открыт Telegram. Это канал UsabilityLab. Жестом вправо я перемещаюсь, ну, что называется, для меня это сверху вниз. Не подписанная кнопка.

И далее, соответственно, идет переписка. Нажимаем на неподписанную кнопку. В надежде узнать, что же там такое. И при жесте вправо, когда идет перелистывание по контролам, которые имеются, происходят только щелчки. То есть вот этот экран на 100% недоступен для того, чтобы здесь что-то сделать. Нужно обратиться к третьим лицам, чтобы сказали, что же на этом экране. И потом, с помощью этих же третьих лиц, сделать те или иные манипуляции, которые экран предусматривает.

А от себя добавлю: так делать не надо, пожалуйста.

Возвращаемся на главный экран и для наглядности, для контраста, Facebook, стандартное приложение. Вот, «Создать публикацию», «Прямой эфир», «Фотография», «Комната», «Дмитрий Сатин», «Фото профиля». Нажимаю «Создать публикацию».

Двойным тапом активировали редактирование. И можно набрать.

Вот, собственно говоря, элементарнейшая публикация в Facebook. Я бы мог воспользоваться диктовкой, это было бы несколько быстрее, но тогда вы бы не увидели. Это не самая быстрая скорость набора, на практике я и другие пользователи обычно набираем гораздо быстрее, как минимум в 2 раза.

Видео с Voice Over

Дмитрий Сатин. Нам прислали комментарий: «Меня зовут Светлана Цветкова, я инвалид по зрению, эксперт по безбарьерной среде. Сейчас поставила приложение Альфа-банка, там есть неподписанные кнопки. Если в банковском приложении незрячий слышит неподписанную кнопку, он рискует, работая с приложением. Неизвестно, что это за кнопка».

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

Алексей, спасибо за демонстрацию. Смотреть на то, как незрячие люди мучаются с нашими программными продуктами, конечно, сердце кровью обливается. Но, чтобы не потерять рассудок, нужно шутить. А такие шутки очень бодро сами же незрячие эксперты подкидывают. В прошлый раз, когда мы проводили созвон с Алексеем, я ему крикнул: «О, Лёша, здравствуй! Я так рад тебя видеть!» Он немножко помолчал и сказал: «Я, к сожалению, не могу ответить Вам взаимностью». Ответ получился такой двусмысленный. Это просто гениальнейшая шутка. Потому что можно было бы обидеться, что он не рад меня видеть.

Алексей Михалёв пишет, что у банков есть колл-центр, легко, быстро и удобно осуществлять операции в телефонном разговоре. Так ли это, Лёша?

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

Дмитрий Сатин. Да, это как раз про ту независимую жизнь, о которой я говорил в начале. Алексей Михалёв говорит, что «а как же голосовая биометрия?»

Алексей Любимов. Здесь, наверное, прокомментируют уже коллеги , потому что они составляют бланки, а не я.

Дмитрий Сатин. Тебе шлют слова поддержки. Наша очень активная участница Полина Авдонина из казахстанского Альфа-Банка пишет, что после твоей демонстрации ее мир перевернулся: «спасибо за такую демонстрацию, есть над чем подумать». И Виталий пишет: «Я даже не знал о таком режиме».

Юрий Божор. Алексей, я видел, что незрячие набирают пятиточечный брайлем, а вы набираете по клавиатуре. Скажите, пожалуйста, это удобно? Нужно ли для этого что-то дополнительно делать в интерфейсе? И как вообще решается вопрос набора текста?

Алексей Любимов. Я бы здесь развел эти понятия. Во-первых, брайлевский набор на смартфоне, на тач-устройстве — это, грубо говоря, другой вид клавиатуры. То есть это всего-навсего способ. Кто владеет Брайлем, те прекрасно пользуются и довольны. Скорость выше, чем на виртуальной клавиатуре. Я Брайлем не владею, поэтому я этим способом не пользуюсь. Что касается того, что для этого нужно сделать. Вопрос больше технический, это, наверное, скорее к нашим коллегам из «Сбера» и «Альфы», которые сегодня присутствуют, потому что, в моем понимании, если приложение сделано грамотно в соответствии со стандартами, неважно чьими, со стандартами и спецификацией языков, на которых приложение написано, то всё это будет работать. Потому что брайлевский ввод — это все-таки специальные возможности, функционал iOS или Android, которые там имеются.

Юрий Божор. Спасибо. То есть это просто еще некая дополнительная клавиатура. И от разработчика, требуется, чтобы это просто корректно работало и никаких дополнительных усилий, не нужно. Я правильно понимаю?

Алексей Любимов. Да. То есть как только я переключаюсь на брайлевскую клавиатуру, важно, чтобы а) курсор никуда не сбежал из поля редактирования, б) поле редактирования не закрылось, вдруг ни с того ни с сего, или не перестало быть активным. И, соответственно, ввод осуществлялся корректно. Вот и всё, на мой нетехнический взгляд.

Юрий Божор. Спасибо!

Дмитрий Сатин. Лёша, огромное тебе спасибо, низкий тебе поклон. Надеюсь, этот вебинар сделает твою жизнь лучше.

Алексей Любимов. Нашу жизнь сделает лучше, мы же все стараемся.

Дмитрий Сатин. Спасибо! Мы, между тем, говорим про доступность именно банковских приложений. Здесь я хотел в качестве некоторой прелюдии к словам Юрия Божора сказать, что Банк России — первый из российских регуляторов, которые вслед за ратификацией Конвенции ООН о защите инвалидов выпустил соответствующие поправки к нормативным документам. В нормативный документ начал вносить правки и рассылать банкам, подотчетным организациям рекомендательные информационные письма. Поэтому мне кажется, что финансовая область в вопросах accessibility наиболее продвинутая. Юрий, считаете ли Вы, что это так, или нет?

Юрий Божор. Спасибо большое, Дмитрий. Ну, всё-таки нет, потому что мы не делали нормативки, мы делали информационные письма. Потому что только недавно был расширен закон «О банках и банковской деятельности» и у нас появилась возможность заниматься финансовой доступностью. Раньше мы тоже этим занимались, но в законе о Центральном Банке вот такой строки не было. Сейчас у нас появилось больше возможностей, и мы, конечно, будем ими пользоваться. Тема интересна тем, что выпуск достаточно большого количества, уже 4 или 5 информационных писем, на самом деле очень благосклонно воспринимается банковской средой. Есть там один банк, ну, полтора, достаточно крупных, у которых еще есть проблемы юзабилити, коллеги этим тоже занимаются. И мы видим жалобы и пишем эти письма.

Но в целом я хочу сказать, что банковское сообщество довольно неплохо это воспринимает. И вся эта история началась в 2016 году, когда Гурцкая Диана пришла к председателю, они поговорили, и мы начали работать в рамках нашей рабочей группы. Я, честно говоря, получил массу удовольствия от того, как это было, от работы, потому что действительно в самом начале было достаточно сложно. Вот для меня этот мир, мир людей с инвалидностью, был немножечко в стороне. И, безусловно, я, во-первых, за это время узнал массу замечательных людей. И проблема accessibility действительно очень важна.

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

Как правильно сказал Дмитрий, мы движемся именно в направлении информационных писем. Сейчас мы готовим еще одно информационное письмо. Оно в той или иной мере стимулировано или спровоцировано выходом нового ГОСТа по доступности интернет-ресурсов. Соответственно, в рамках этого ГОСТа, который вступил в действие с 1 апреля, мы делаем информационное письмо: «Коллеги, давайте пользоваться этим ГОСТом, там есть ряд вещей».

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

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

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

И я коротко скажу по поводу пандемии. У нас будет в июле рабочая группа, где мы будем специально этот вопрос обсуждать. Но в целом я хочу сказать, может, Алексей меня тогда поправит, если я ошибаюсь, я не заметил какого-то радикального снижения доступности дистанционных каналов, доступности финансовых услуг. То есть люди не смогли ходить в банки, но они смогли продолжать свои переводы, система СБП (система быстрых переводов) была запущена. Были какие-то вопросы, но в целом это же позволило людям фактически переводить деньги на карты разных банков, переводить родственникам. Вот мне у Сбербанка нравится в этом плане простой смс-перевод. Пользовались для волонтеров, мы с волонтерами взаимодействовали. Очень удобно небольшую сумму перебросить, отправив просто смс. Это можно с кнопочной Нокии сделать. Это тоже удобно для небольших операций.

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

Что я хотел бы сказать: мы за этим следим, информационное письмо выйдет — посмотрите. Но мы, конечно, смотрим на доступность дистанционных каналов и просим вас тоже, когда вы пишете, иметь в виду людей с разными особенностями. Это касается и капчи, в том числе. Там, где есть капча фокус может не переводится на поле ввода. И для незрячего замечательный интерфейс становится недоступным. Поэтому, коллеги, думайте об этом. Думайте о людях с особенностями, думайте о пожилых людях и старайтесь делать простой и удобный интерфейс. Спасибо!

Дмитрий Сатин. Спасибо, Юрий! Пока Вы говорили, Алексей там творит чудеса за кадром: он отвечает на вопросы письменно. Я вообще не понимаю, как эту магию он творит.

Екатерина Свищова спрашивает: «Спасибо большое за демонстрацию! Назовите, пожалуйста, пример приложения, которое бы полностью устраивало Вас с точки зрения accessibility». Алексей отвечает, что 100%-но идеальных приложений нет, но максимально приближены Сбербанк Онлайн, Яндекс.Метро, Яндекс. Погода, Яндекс. Электрички. Он перечисляет приложения для iOS.

И Никита Жучков спрашивает у Алексея: «Насколько голосовые ассистенты в банковских приложениях видятся удобным интерфейсом?» Алексей не понял вопроса, что имеется в виду под голосовым интерфейсом. Имеется в виду некоторые банки. Например, у Альфы, Фамил меня поправит, если я ошибаюсь, но вот Владимир Китляр из питерского офиса разработки много говорил о разработке голосовых ассистентов, то есть можно, условно, нажать на кнопку, как Siri, как Алиса, и начинать разговаривать с голосовым помощником. Такой же помощник есть у Тинькофф, голосовой помощник Олег. То есть можно прямо в мобильном приложении вызвать и голосом пообщаться с ними.

Алексей Любимов. Здесь есть два момента. Во-первых, все голосовые интерфейсы, когда девайс с тобой начинает разговаривать как живой, и вообще история этих голосовых интерфейсов, появилась не для инвалидов и не для слепых, а для тех, кто за рулем. Они больше нуждаются. Уже инвалиды потом эту технологию под себя подключили, сделали ее удобной для себя.

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

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

Алексей Любимов. Не знаю, мне сложно ответить на этот вопрос, потому что задачи бывают разные. Но вот недавно я общался с «Альфа-страхованием», мне нужно было уточнить о вписании человека в страховку автомобиля. Я не за рулем, если что. И меня очень быстренько в целях экономии времени операторы переключили на автоматическую систему, от которой я просто повесился. И я таки всё равно добился, чтобы меня перевели на оператора, задал ему те вопросы, которые интересуют меня, и получил те ответы, которые я понял. Поэтому бот ботом, это, конечно, снижение нагрузки с колл-центра и с других каналов, но это не панацея. Все-таки живой голос лучше.

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

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

Юрий Божор. Дмитрий, пока отвечают, я хочу сказать. Я забыл сказать, что мне сегодня утром позвонили люди из очень крупного сервиса, который комплексное обслуживание обеспечивает, транспорт, всё прочее, — и заинтересовались вопросами доступности. Этот опрос тоже запустим. Как раз там во время кризиса какие-то заявки делал, и сказали, что это надо.

Дмитрий Сатин. Раз Вы решили упомянуть отдельно компании, мы заметили, что очень большое количество сотрудников «Лаборатории Касперского» присутствует на нашем вебинаре. Я через вторые руки слышал о том, что «Лаборатория» сейчас реально собирается заняться вопросами общедоступности. Это, конечно, здорово. И видите, что эти банковские мероприятия затрагивают, в общем, и смежные области тоже.

Проголосовало 55% людей, посмотрим на результаты, стало ли лучше. Пока нет — 19%, не видим смысла — 2%, 23% и 21% — да, либо делают, либо вот-вот начнут. В общем, с небольшим перевесом мы начали побеждать. Мне кажется, мы прошли через экватор.

Спасибо вам большое за ваши ответы! Аня, подключайся. Мы сейчас расскажем, что в этом году произошло. Пока Аня подключается, я сразу хочу одну интригу, поддержать слова Юрия Анатольевича относительно того, что он видит положительную динамику. Я сразу скажу, что по сравнению с исследованием 2019 года, исследование 2020 года показывает, что проблем становится меньше. Поэтому все большие молодцы, все стараются. Но еще непаханое поле.

Анна Минаева. Спасибо большое. Рада приветствовать всех участников и зрителей нашего вебинара. Сегодня я хочу рассказать о том исследовании, которое мы провели. Исследование проводилось в течение нескольких месяцев силами специалистов USABILITYLAB. В нашем исследовании в этом году участвовали 15 банков. Список банков участников составлен с учетом рекомендаций рабочей группы Банка России. В этом году присоединились еще несколько новых банков, все больше людей проявляют интерес к этой теме, потому что она действительно важна, насколько мы увидели сейчас из выступлений предыдущих ораторов.

Мы исследовали 5 пользовательских задач, 2 платформы: iOS и Android. Было проверено более 700 экранов. Под экранами мы подразумеваем переходы, которые пользователи должны осуществить, чтобы пройти пользовательские сценарии. Мы обнаружили более 2000 проблем. Но, как Дмитрий отметил, их стало немного меньше, чем в прошлом году.

Дмитрий Сатин. Сегодня к нам присоединилось много экспертов по доступности, в том числе с проблемами зрения. Наши пользовательские задачи: вход в приложение, просмотр баланса, перевод между своими счетами, оплата мобильной связи и оплата коммунальных услуг. Это те 5 сценариев, которые на совещаниях в рабочей группе «Банка России» были признаны наиболее частотными и требующими особого внимания.

Анна Минаева. Да, то есть без таких вещей, как вход в приложение и просмотр баланса, вряд ли обходится любое использование банковского приложения. Если исходить даже из нашего опыта общения с пользователями, то многие говорили, «мы иногда заходим в приложение, только чтобы посмотреть баланс, и всё, больше ничего не делаем».

Дмитрий Сатин. Здесь упоминается ГОСТ, но Юрий не об этом говорил, да? ГОСТ, который 52872, он 2012 года.

Анна Минаева. Да, здесь упоминается предыдущая версия этого ГОСТа. Мы когда начинали разрабатывать эту методологию, опирались именно на этот ГОСТ, а также на WCAG 2.1 и информационные письма Банка России. Естественно, эта методология не жесткая, мы ее постоянно дорабатываем, обновляем.

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

Анна Минаева. Инструменты, которые мы использовали для оценки доступности: экранные дикторы — как раз один из них, VoiceOver, нам сегодня продемонстрировали. Для Android это TalkBack, который входит в стандартный Accessibility Suite для Android. И чекеры контрастности, например Color Contrast Analyser. Это программа для проверки контрастности текста по отношению к фону в соответствии с рекомендациями WCAG 2.1.

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

Анна Минаева. Уровни критичности проблем. Как я уже говорила, у нас было 5 пользовательских сценариев. Каждый из этих сценариев мы оценивали, могут ли пользователи пройти его до конца без посторонней помощи при включенном экранном дикторе. В процессе выявлялись проблемы. Проблемы высокой критичности не позволяют пользователям решить какую-то задачу. И, соответственно, если в сценарии такая проблема встречалась, то мы присваивали 0 баллов, и сценарий считали провальным. Потому что в таком случае пользователь не сможет что-то выполнить, ему придется кого-то просить помочь. Либо он может совершить ошибку.

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

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

И если проблем доступности не обнаружено, то присваивали 1.

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

Типы проблем. В нашей методологии мы классифицировали проблемы по 4 типам. Практически все проблемы, которые мы находили, можно было к одному из этих типов отнести. Ну, бывали, конечно, такие проблемы, которые мы относили к «прочим», но эти — основные.

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

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

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

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

Самые распространенные проблемы — это проблемы, связанные с кодом. Их сейчас было около 68%. В целом ситуация сильно не изменилась за несколько лет —  количество проблем этой категории всегда оставалось примерно на уровне 70%. То есть этих проблем всегда было много, их много и сейчас.

Дмитрий Сатин. То есть больше всего пострадают люди тотально незрячие пользователи. Потому что они могут взаимодействовать с экраном только через озвучку.

Анна Минаева. Проблем, связанных с дизайном и оформлением, было порядка 20%. То есть их тоже достаточно много, но не настолько, как проблем с кодом.

Проблем с взаимодействием было около 10%. И проблем с текстами около 1%. Их всегда было мало. Такой порядок распределения на протяжении нескольких лет практически не меняется. Всегда было первое — код, второе — оформление, третье — взаимодействие, четвертое — тексты.

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

Давайте теперь перейдем к примерам проблем.

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

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

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

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

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

Анна Минаева. Да, это как раз очень яркая иллюстрация того, как могут такие проблемы с кодом возникать.

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

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

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

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

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

И теперь немножко развлечения. Хотели бы показать, как такие проблемы решаются удачно.

Дмитрий Сатин. Посмотрим, тут должно быть видео.

Анна Минаева. На экране будет коротенькое видео, давайте послушаем.

Видео с Voice Over.

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

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

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

Дмитрий Сатин. Я всё время думаю о тех незрячих слушателях нашего вебинара, которые не видят этих картинок. На всех этих экранах написано серыми небольшими буквами, и нужно всматриваться в них. Особенно если у вас не очень большое устройство, то есть не такой как iPhone 6+ или 11-я модель большая, PRO.  Или если со зрением что-то не так. У меня небольшая дальнозоркость, и я прочитать без очков это не могу. И тогда человек попадает в очень неприятные ситуации. Потому что иногда в банках вот такими маленькими серенькими буквами, как в известных шутках про маленький серый текст в кредитных договорах, иногда там появляется сообщение о комиссии, которую ты заплатишь за перевод. И пользователь либо вообще не узнает, что с него списали комиссию, либо узнает, если она окажется больше его ожиданий, когда платеж в истории операций окажется больше. Он начнет скандалить, а зачем нам этот скандал? Я же верю в то, что люди, которые комиссию показывают маленькими серенькими буквами, не хотят никого обманывать. Просто вот такой дизайн приложения. Хотя не знаю, почему этот стиль так нравится дизайнерам, почему они не пишут просто для людей, чтобы было нормально, читабельно.

Анна Минаева. Добавлю, что эти оценки контрастности построены на стандарте доступности WCAG 2.1.

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

Дмитрий Сатин. Ниже тоже темный шрифт на белом фоне. Он тоже с высокой контрастностью.

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

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

И теперь проблемы, связанные с текстами. Во всех банках встречаются такие вещи как аббревиатуры. На данном примере много аббревиатур, связанных с оплатой жилищно-коммунальных услуг. Это названия всевозможных получателей платежей. Когда экранный диктор читает аббревиатуру, это звучит как «жку» (без выделения отдельных букв). И это на слух воспринимается достаточно тяжеловато, хоть и можно понять, что он читает. Поэтому критичность у этой проблемы низкая. Но все равно людям может быть не очень удобно и не все могут их знать.

Дмитрий Сатин. Таких людей может быть довольно много и среди очень развитых людей. Сегодня, когда вычитывали именно эти слайды, некоторые наши сотрудники сказали: «Я не знаю, что такое ЕИРЦ. Я не знаю, что такое ЕПД». Государство очень любит всякие аббревиатуры, эти аббревиатуры потом просачиваются в потребительские продукты. Пришлось выучить, что такое СНИЛС. Но вообще это бесчеловечный подход. Мне кажется, что здесь есть поле для маневра, чтобы эти надписи делать более понятными. Спасибо!

Анна Минаева. Так, и теперь мы переходим к тому, чего, наверное, все ждали. Это результаты рейтинга доступности приложений.

Дмитрий Сатин. В прошлом году у нас был один рейтинг, по пожеланиям рабочей группы. Но в этом году я посчитал, что необходимо показать вот эти рейтинги в разных измерениях. Поэтому сейчас вы на слайде видите три списка, соответственно, эти списки закодированы. «Код iOS» — насколько хорошо или плохо для экранного диктора iOS. Вторая колонка, аналогично, для Android, и третья — по контрастности. Есть еще два измерения, которые не показали на этом слайде, но они будут в расширенном отчете. Это еще по текстам и по моторике. Но там очень похожие показатели, поэтому это не столь драматический список.

А вот этот список для меня очень важен. Потому что, смотрите, Сбербанк лидирует по чтению экранного диктора, но уступает другим банкам по уровню контрастности. На втором месте по iOS, по проговариванию экранного диктора, вышел Россельхозбанк. Мы не раздаем сегодня никаких медалей, но Россельхозбанку я бы точно что-нибудь памятное подарил. Потому что эти люди за 2019 год сильно улучшили свое iOS приложение.

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

Ну, вот три измерения. И, соответственно, три призера, три рейтинга. Мы видим, некоторые приложения драматично перескакивают из конца в верх. Например, у Тинькофф Банка 4ое место по iOS, 2ое по Android по проговариванию диктора, но они находятся на 11м месте по контрастности. Ну, потому что приложение Тинькофф Банка — оно вот такое, серым по серому, тонким по тонкому.

Если суммировать все эти рейтинги и агрегировать их в один какой-то, люди любят, чтобы было что-то одно, то получится следующий список, я его озвучу. На первом месте у нас находится Сбербанк Онлайн, на втором месте Альфа-Банк с приложением Альфа-Мобайл, РОСБАНК на третьем месте, на четвертом МТС Банк, Россельхозбанк, на пятом Тинькофф, я остановлюсь, всех, наверное, читать не буду.

Обратите внимание: некоторые из банков помечены звездочками. Здесь нужно дать комментарий, потому что уже задавали вопросы, пока Аня выступала: «А будет ли презентация, которую Аня показывает, доступна слушателям?» Да, она будет разослана по окончании вебинара, как и ссылки на запись, и сопутствующие презентации ссылки. Но есть, также существует расширенный отчет, который предоставляется по платной подписке по «Банковскому UX», и звездочками здесь показаны те банки, которые оформили эту подписку. Они получат расширенную версию. Я это говорю не для того, чтобы другие испытали зависть. Но сотрудники перечисленных банков, это банки Санкт-Петербург, Открытие, ВТБ, МТС Банк и Альфа-банк, — все могут получить расширенную версию, потому что банк уже заплатил за всю подписку «Банковского UX», и за этот рейтинг в том числе.

Остальным можно, есть разные варианты получения расширенной версии.

Анна Минаева. Спасибо большое за внимание!

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

У нас дальше на повестке уважаемые гости. Михаил Кузьмин и Фамил Гаджиев. Михаил хотел рассказать про публичный гайдлайн Сбербанка. Мы все настоятельно рекомендуем его изучить и использовать в работе. Сбербанк подарил этот труд всей отрасли. Пожалуйста, Михаил.

Михаил Кузьмин. Добрый день, меня зовут Михаил. Да, я действительно хотел бы поделиться гайдлайном. Также вкратце расскажу о том, какие выводы мы сделали из прошлогоднего исследования.

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

Итак, гайдлайн. Он находится по простому адресу: specialbank.ru/guide. Пользователь, который заходит на этот гайдлайн, переходит на такую простую страницу. Она, кстати, сверстана так, чтобы она была доступна также для людей, работающих с экранными дикторами.

Для чего мы сделали этот гайдлайн? Когда мы подошли к вопросу доступности, мы поняли, что прочитать и проштудировать полностью Web Content Accessibility Guidelines, так называемый WCAG 2.1 и 2.0 — это довольно долго. И для погружения это, наверное, будет излишне. Поэтому мы начали с того, что разбили по ролям информацию. Это для дизайнера, это для разработчиков на всех платформах, на iOS, на Android и на web, а также для менеджеров. Потому что сами сталкивались зачастую с проблемами, когда мы приходили в команды и рассказывали про необходимость доступности, то включались обычные правила, продуктологи говорили: «А сколько у вас пользователей, кому это важно?» И приходилось объяснять такие, для нас уже, и для тех, кто участвует в этом вебинаре, я надеюсь, очевидные истины, что доступность — это не верстка, это не удобство, это доступ к услугам. Нельзя сказать про доступность, что это какая-то дополнительная фича, или дополнительное какое-то украшение. Это необходимость. То есть, если на сайте поехала верстка или куда-то уплыл заголовок, то зрячий пользователь сможет там разобраться, скорее всего. Или хотя бы он поймет, что сайт выглядит не так, как он этого ожидает. А если же сайт недоступен, то клиент с нарушением зрения в принципе не сможет им пользоваться и будет вынужден идти либо в банкомат, либо просить кого-то постороннего, чтобы ему помогли. Тем самым разгласит свою банковскую тайну. Либо пойдет в отделение,  что в нынешних реалиях подвергнет его здоровье дополнительному риску.

Давайте посмотрим раздел, посвященный iOS-разработке. Здесь как раз отмечены некоторые ошибки кода. В первую очередь здесь описаны возможные нарушения, которые образуют из себя специальные потребности, которые мы стараемся в своем приложении предусмотреть и сделать его доступным. Далее вкратце описано то, что демонстрировал Алексей Любимов. Это так называемые скринридеры, которые называются вспомогательными технологиями, которыми с нами щедро делятся корпорации Apple и Google.

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

Также очень важно соблюдать правила навигации. Например, визуально мы видим, что у нас сверху есть заголовок, далее есть текст. Особенности разработки некоторых приложений, мы тоже через это проходили, делали так, что для незрячего сначала был текст, который внизу страницы. Например, при открытии страницы фокус перемещался куда-то вниз. Когда он начинал по ним перемещаться, либо в случайном порядке прочитывались элементы, либо иногда сверху вниз, либо в каком-то хаотичном порядке. Для зрячего это все равно, как если бы вся страница у нас перемешалась, и заголовки поменялись местами с основным текстом. Поэтому важно соблюдать при разработке приложения порядок перемещения по элементам с помощью скринридера. Здесь также об этом написано, основные правила, к которым уже все привыкли, чтобы первым элементом страницы было имя-заголовок.

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

Также необходимо, чтобы у всех кнопок была подпись. Часто бывает такая проблема, что кнопка подписана каким-то системным именем и при этом пользователь не понимает, что она значит. Например, там кнопка подписана «Next page jpg». Можно предположить, что это переход на следующую страницу. Но лучше, когда есть так называемый лейбл, который говорит перейти на следующую страницу.

Далее хотелось бы сказать о том, как мы подходим к тестированию. Здесь тоже есть некоторое описание тестирования, но оно неполное. Потому что со времени написания этого гайда мы прошли уже несколько этапов. Первое — это очевидно, использовать встроенные утилиты среды разработки, Accessibility Inspector на iOS и Accessibility Scanner на Android. Однако зачастую их недостаточно, и ответственность в таком случае находится на стороне разработчика. Чтобы уменьшить количество ошибок и исключить пользовательское тестирование, можно настроить автоматические анализаторы кода. Мы так поступили с сайтом, нам помогли разработчики, и сейчас бóльшая часть тестирования происходит в автоматическом режиме.

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

Хотел бы рассказать про интересные фишки нашего приложения для незрячих, которые мы разработали, наши незрячие эксперты и разработчики нам помогли. Когда мы добавляли звуки в приложение, мы добавили специальные щелчки, которые позволяют незрячему пользователю знать, что приложение не зависло, а происходит загрузка страницы. И эти щелчки включаются только при включенном VoiceOver’е. Честно сказать, я такие штуки видел только во встроенных приложениях на iOS и некоторых современных приложениях типа Discord, которые спрашивают пользователя, нужны ли ему какие-то дополнительные функции, когда видят, что он зашел в приложение с включенным VoiceOver’ом.

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

Дмитрий Сатин. Да, спасибо большое. Ну, первый вопрос, он такой, очевидный: действительно ли доступен ваш гайдлайн для всех?

Михаил Кузьмин. Да, он находится в открытом доступе.

Дмитрий Сатин. Нет, нет, открыт. Мне кажется, спрашивают…

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

Дмитрий Сатин. Ну, и вопрос Ане и USABILITYLAB задали, Артём Тололуев спрашивает: «А почему в рейтинге нет Почта Банка?» Мы бы хотели, чтобы в рейтинге были все банки. Но это не совсем возможно, потому что это большие трудозатраты на исследование каждого из банков. Список первых 14-ти был составлен в рабочей группе. Но, тем не менее, если Вы — представитель Почта Банка, свяжитесь с нами, и мы обсудим, как мы можем в следующей волне вас происследовать.

Ну, что ж, мы тогда подходим к нашему завершающему выступлению. Это Фамил Гаджиев. Мы с ним познакомились совсем недавно, потому что увидели на Хабре публикацию, где он с коллегой рассказали о том, как они за последний год повысили доступность Alpha Mobile. Фамил, тебе слово.

Фамил Гаджиев. Про accessibility, как я к этому подошел, и с чего всё началось. Наверное, это с комментария, как ни странно, в Apple Store. Нам написал незрячий пользователь. Вы думаете, что разработчики ничего не читают, это неправда. Все комментарии регулярно, с постоянной частотой мы читаем с разработчиками. Мы даже написали скрипт, в который нам прилетают комментарии, мы их все командой разбираем дружно. И один из комментариев меня прямо кольнул за душу. Пользователь не мог элементарно выполнить вход в мобильное приложение через VoiceOver.

Я подумал: почему бы нет, надо поковырять. И обнаружил, что да, действительно есть проблемы. И пришел к лидам, говорю: «Саш, так и так, давай с этим что-то делать». Собрали консенсус небольшой, и меня направили ребята, которые этим как раз занимаются. И прилетела потом статья, как раз USABILITYLAB, которую дорогая коллега озвучила, показала все эти кейсы. И да, 4 базовых кейса мы прогнали: это вход, просмотр баланса, перевод между своими счетами и оплата мобильной связи.

Я их начал копать, смотреть, как в коде это всё выглядит. Да, всё это было печально. Начинали с ГОСТов и ориентировались на какой-то дизайн, на какой-то пользовательский фидбэк. Пока непонятно было, что это, что делать, сразу лезть в код было немножко страшновато, потому что не понимали, как двигаться. Но команда команда разработчиков в Альфа-Банке большая, у каждого свой какой-то кусок продукта. Я не мог подойти и сказать: «Слушай, парень, прими там мой кусок кода, нужно поправить». И не было даже ребят, которые могли бы это протестировать. То есть группа тестировщиков не понимала, как с этим работать.

Начали с обучения тестировщиков, как пользоваться этим. И выявили проблемы проектирования, проблемы качества кода и проблемы дизайна. Получается, взяли один какой-то элементарный пользовательский сценарий авторизации.

Проблема была в кнопке Touch ID, у которой не было accessibility label. Я попытался представить, как на самом деле пользователи, которые не видят интерфейса, представляют себе это визуально, и, в общем, выглядело это примерно так. Все кнопки подписаны, нет фона, ничего не видно, а вот конкретная кнопка — это сплошной текст, который занимает половину экрана, и непонятно, что он в себе несет.

В общем, перешли дальше к решительным действиям. Выявили огромное количество дефектов, провели регресс, вышло около 300 задач. Далее я написал гайдлайны, как править, они тоже по стандартам. Если зайти на Хабр, можно посмотреть. У Миши Рубанова очень много докладов на эту тему, очень крутой разработчик.

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

Начну, наверное, сначала, как мы это тестировали со стороны кода. Для тестировщиков есть VoiceOver’ы, это через устройство банально. На стороне X-кода, X-код предоставляет Accessibility Inspector. Это такой детектор, который выводит тебе иерархию вьюшек, именно в коде, каждая из которых показывает, на каком уровне она находится и есть ли на ней подписи. И если присмотреться, на панели, где написано «Введите код» —  у нее нет value, у нее есть статический какой-то текст. И accessibility VoiceOver будет пробегать по вот этим самым вьюшкам и читать нужный лейбл. Он там очень круто устроен, компания Apple делает очень много работы за разработчиков. То есть если ты просто статический какой-то текст писал, но у тебя не подписан accessibility label, Apple подстраховалась, он прочитает тот лейбл, который у тебя есть.

Нужно улучшать поддержку VoiceOver’а и всячески помогать ему, чтобы не возникало проблем. В первую очередь это подписывать кнопки. Мы замечали кнопки без текста, без без описания, а исключительно только иконка, визуальное оформление. И в этом случае желательно все-таки под капотом перестраховаться и написать какое-то описание кнопки, что она за собой несет. Добавлять значения этим кнопкам, оставлять подсказки, группировать контролы, если много кнопок. Я в дальнейшем вам это покажу. Править неправильные надписи. Указывать тип контролов и расширять минимальный, мы для себя выстроили какие-то минимальные границы, это 44 на 44 пойнта в iOS. И это допустимые нормы нажатия, это когда ты точно хочешь попасть в эту кнопку, ты в нее попадешь.

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

Что значит accessibility value? Это когда есть активное поле, с которым нужно взаимодействовать пользователю, разработчик должен подстраховаться и подсказать VoiceOver’у, как с ним взаимодействовать. То есть сколько перевести, нужно перевести столько-то столько-то, значения, там кнопка, текст или какой-то визуальный элемент.

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

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

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

В итоге, что мы сделали? Было привлечено 7 тестировщиков, мы собрали группу, наладили там целый процесс, раскидали огромное количество задач, появилась новая культура в компании, когда ты уже заботишься о пользователе, когда ты заранее продумываешь какие-то технические реализации, при этом не забываешь про accessibility. Было заведено около 300 задач, и банком стало пользоваться чуточку проще.

Далее я, хотел бы вам показать видеоролик.

Фамил Гаджиев. Это ролик про Voice Control — это когда пользователи уже могут пользоваться исключительно голосом на MacOs и iOS. Apple регулярно на каждой сессии выпускает новые фичи функциональности, с которыми очень круто и просто работать. Вот в данном случае это демонстрация фичи Voice Control исключительно на MacOS, и тут видно, что пользователь может переключаться между устройствами, спокойно конфигурировать все обычные взаимодействия. В общем, на самом деле я считаю, что это какая-то суперспособность на самом деле. Новые супергерои, новые суперспособности.

Видеоролик

Буквально 2-3 дня назад была новая сессия конференции Apple для разработчиков, я за ней очень активно наблюдаю и слежу. Появились новые фичи, которые уже непосредственно работают с пользовательским интерфейсом и взаимодействуют с визуальной составляющей. То есть теперь распознается всё тело, теперь пользователи, не прикасаясь к экрану, могут детектить все взаимодействия. Для разработчиков это новый виток, новые технологии. И появились даже возможности распознавания каждого пальца каждой руки, в общем, безумно крутая фича. Теперь, наверное, общаться с пользователями через визуальные какие-то, как сказать, через язык жестов, появятся, скорее всего, какие-то новые мессенджеры, новые взаимодействия.

В общем, Apple не стоит на месте. Круто развивается, и я бы, наверное, потом сбросил вам видеоролики, как это работает в реальности.

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

Алексей Любимов. А если еще и на английском языке, а если еще и снижение слуха, и ты находишься в зашумленном помещении, — это вешалка.

Дмитрий Сатин. Вот, еще Светлана Цветкова писала, что все подсказки, когда Фамил говорил, все подсказки надо делать опционно, так, чтобы пользователь мог бы это выключить. Я не совсем понимаю, как это выключать.

Алексей Любимов. Я понимаю, о чем говорит Светлана. Здесь речь идет вот о чем. Если мы берем скринридеры для десктопа, в частности для Windows, и, возможно, на Mac. Там можно включить подробности подсказок, есть уровни: начинающий, средний, опытный. В зависимости от выбранного уровня озвучиваются подсказки: «для перехода по ссылке нажмите Ctrl», «Option», «стрелка вниз» и так далее. Если я ставлю уровень конкретизации меньше, то мне это всё не произносится.

С другой стороны, если мы берем мобильные системы, Anroid и iOS, здесь честно не знаю. Для iOS, может быть, где-то VoiceOver можно сделать менее болтливым. Если я выполняю часто операции, например, перевод денег со счета на счет, я уже знаю, что первое поле, номер карты и есть конкретная сумма, мне достаточно. И я перескакиваю на следующее поле. Я уже не прослушиваю, что это поле для редактирования, чтобы его открыть: «тапните два раза и так далее». Я тапаю и начинаю из выпадающего списка выбирать нужную мне карту.

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

Дмитрий Сатин. Светлана продолжает писать на эту тему, говорит, что можно «выключить в настройках самого приложения». То есть потому что не столько скринридеры, сколько банковское приложение будет озвучивать или давать на подсказку. Тогда это, скорее, такой вопрос к разработчикам, чтобы была двухуровневая.

Алексей Любимов. Это тоже вариант, я такое решение видел на адаптации приложения «Московский транспорт». Там можно было включить подробный комментарий, а можно было выключить.

Юрий Божор. Это уже для продвинутого пользователя фактически, да?

Алексей Любимов. Фактически да. Решение нестандартное, решение интересное. И здесь вопрос у меня возникает такой. Извините, никого не хочу обидеть, я говорю про вообще. Если на сегодняшний день разработка, несмотря на критерии Apple и Google, умудряются делать приложения, где открываешь экран, а там вообще ничего нет, ни один контрол не прописан, но это приложение пропущено в App Store и Google Play. То просить «А давайте мы еще сделаем вот так и вот так» — вы сперва по минимуму сделайте, а дальше мы уже будем разговаривать, как лучше. Извините за резкость, никого не хочу обидеть.

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

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

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

Дмитрий Сатин. Мне нравятся комментарии Светланы, потому что они говорят про следующее, дать возможность, как Юрий сказал, для продвинутых и непродвинутых незрячих пользователей разный уровень озвучки.

Юрий Божор. Чем для незрячих можно заменить антибот типа капчи? Какие есть решения? Вот Алексей или Светлана, озвучьте, пожалуйста.

Дмитрий Сатин. Светлана ответила: «код по смс».

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

Юрий Божор. Тут вообще не нужно текст, в принципе.

Алексей Любимов. Как не нужно текст?

Юрий Божор. Алексей, вот Вы вошли в экран, вот у Вас есть капча. Есть экранное стандартное видео, а есть кнопочка «Отправить смс». Капча — это же ничего, это просто защита от бота. И там может быть трехзначный код.

Алексей Любимов. Смс-ка там приходит, от такого-то приложения или такого-то банка. А мало ли, вот в эту систему внедрится неизвестный товарищ, который подловит меня на этом и успеет… То есть смс-ка все-таки должна быть стандартная, от кого, кому, для чего и так далее.

Юрий Божор. Нет, просто это же не сутевая, не финансовая транзакция. Это просто антибот. Вот зачем капча, по большому счету.

Алексей Любимов. Да, я не переключился. Смс-ка, для смс-ки это, опять же, нужно вводить либо номер телефона, либо быть авторизованным и так далее…

Юрий Божор. Да, Вы вошли, нет, Вы вошли на сайт, Вам надо пройти капчу. Вы там можете либо, если зрячий, эти светофоры отметить, либо в поле ввести телефон и сказать «хочу смс». Вам прилетает тут же, это вопрос 2-3 секунд, 3 цифры или две, чтобы бот не мог подобрать, и всё.

Алексей Любимов. Мне понравилось, я не знаю, как на сегодняшний день обстоит дело, но в свое время на очень большом форуме, по-моему, woman.ru, там такой, семейный, там регистрация вообще была без капчи. И там весь принцип отсеивания человека от ботов, да, разделения человека от бота, он заключался во внутреннем механизме. То есть как заполнил, сколько времени потратил, и т.д. и т.п. И мне кажется, для меня как пользователя, это вообще самый шикарный вариант. Пусть болит голова на стороне разработчика, владельца, как меня отсеять. Но не ставить мне заборы.

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

Алексей Любимов. У меня не всегда срабатывает. Очень часто, к сожалению, бывает, что меня выкидывает, «ваш IP слишком часто обращался» и так далее.

Дмитрий Сатин. Еще один наш общий друг и эксперт по доступности Павел Попко из Сбербанка говорит, что капчу хорошо заменить логическим или математическим примером, например, 1+2.

Алексей Любимов. Да, а у кого акалькулия? Да, их будет 1.5 человека на страну, но тем не менее. Должна быть вариативность, тогда уж. Если мы говорим про капчу, давайте выбирать. А если придет слепоглухой? Значит, аудио- и видеокапча ему не подходят, даже если они будут шикарные. Но с математикой он справится, например.

Дмитрий Сатин. Я улыбаюсь, потому что Юрий нам сказал на прощание «я сейчас уйду, но вот вам вопрос «а что лучше капчи?» И мы такие 2 часа накидываем, целый мозговой штурм устроили.

Юрий Божор. Всем спасибо!

Дмитрий Сатин. Спасибо, Юрий! Наш вопрос на прощание. В вебинаре участвует много людей, которые не работают в банках. Банкам очень нужны UX-еры, как начинающие, так и опытные. Мы помогаем банкам их находить. Поэтому поставьте галочку, если вы хотели бы присоединиться к одной из UX-команд банков, у нас всегда есть свежая информация для вас.

Всем большое спасибо! Мне кажется, что сегодняшнее событие собрало очень много позитива. Очень много улыбок. Всегда очень здорово делать что-то на позитиве, надеюсь, этот позитив нас всех объединит.

Что будет дальше? Дальше мы разошлем сегодня материалы с Еленой Арсеньевой и напишем всем ответы на вопросы, которые вы нам задали. Спасибо вам большое! Хороших вам интерфейсов и accessibility тоже! Делать хорошие и доступные интерфейсы. Я благодарю всех наших спикеров. Фамил, огромное спасибо и приятно познакомиться.

Фамил Гаджиев. Вам спасибо, что позвали, пригласили.

Дмитрий Сатин. Спасибо! Пока!

Приобрести отчет "Исследование доступности топ-15 банковских приложений"