Авторы:
Дмитрий Сатин
USABILITYLAB, управляющий партнер
Михаил Кузьмин
ПАО Сбербанк, руководитель направления, CJE (customer journey expert)
Павел Попко
ПАО Сбербанк, аналитик, эксперт по цифровой доступности
Дмитрий САТИН: С 2017 г. USABILITYLAB проводит регулярные исследования доступности банковских приложений для частных клиентов.
Российские банки с этого времени сильно продвинулись в доступности для людей с ограниченными возможностями. Но общепризнанным лидером в вопросах доступности является Сбербанк. Признают это не только эксперты и исследователи, но и, что более важно, незрячие пользователи.
Каждое обновление приложения Сбербанк Онлайн проходит специальное тестирование, которое проводят в том числе незрячие сотрудники Сбербанка из дивизиона «Особенный банк».
Закономерно, что в исследовании 2019 г. приложение Сбербанк Онлайн заняло первое место в рейтинге банков-участников.
Чтобы рассказать другим банкам, как нужно заботиться о клиентах с особыми нуждами, мы поговорили с двумя сотрудниками «Особенного банка», которые непосредственно занимаются тестированием доступности в Сбербанке.
Сначала я попрошу коллег рассказать, кто они и почему занимаются доступностью.
Михаил КУЗЬМИН: Я закончил технический университет им. Баумана. Раньше работал в основном в сфере процессинга, пластиковых карт, в проект «Особенный банк» попал в 2017 г.
Сейчас занимаюсь адаптацией мобильных приложений, адаптацией сайта банка для экранных дикторов VoiceOver, TalkBack, NVDA, JAWS.
Павел ПОПКО: Я получил техническое образование, около 10 лет проработал системным администратором. Когда пропало зрение, я переключился на область цифровой доступности, занимаюсь этим года с 2016–2017-го. Участвовал в разных проектах, в том числе по адаптации приложения, разрабатываемого Департаментом информационных технологий г. Москвы. С 2018 г. работаю в Сбербанке: занимаюсь разработкой аудиоинтерфейса, адаптацией мобильного приложения, сайта и некоторых продуктов экосистемы.
Д.С.: В 2019 г. в ходе сравнительного анализа доступности мы анализировали в том числе мобильное приложение Сбербанк Онлайн. Ваша работа связана с ним?
М.К.: Павел Попко фактически проектировал аудиоинтерфейс, производимый экранным диктором, анализировал, как сделать его более правильным и удобным, чтобы он соответствовал стандартам: есть определенные правила, куда перемещать курсор при открытии новой страницы, какой должна быть логика прохождения по экрану.
Что собой представляет команда
Д.С.: Все наслышаны про проект «Особенный банк». Это структурное подразделение или некое движение внутри банка?
М.К.: Может быть, в определенном смысле уже и движение, но задумывался «Особенный банк» как команда, работающая с сегментом клиентов с особенными потребностями, для которых нужно адаптировать продукты и сервисы, причем в совершенно разных каналах: физическом, цифровом и т.д. Сейчас в команде несколько человек. Кто-то занимается методологическими вопросами, кто-то — адаптацией физической среды, отделений, кто-то — проектированием специальных сервисов и адаптацией продуктов.
Д.С.: Почему появилась такая команда?
М.К.: Людей с инвалидностью в РФ 11,9 миллиона. Большинство из них — клиенты Сбербанка. Они очень разные, и разные особенности здоровья по-разному влияют на способы коммуникации клиентов с банком — у каждой категории свои сложности. Особенности в коммуникации есть также у пожилых клиентов, у опекунов и сопровождающих, и никто из нас не застрахован от временных травм.
Поэтому три года назад особенные клиенты были выделены в отдельный сегмент и внутри банка была создана специальная команда «Особенный банк». Задача — сделать так, чтобы все продукты и сервисы банка были доступны любому клиенту независимо от особенностей.
Инклюзивный подход предполагает, что особенные продукты не отделены от общей линейки, а доступны всем клиентам, в том числе особенным.
Д.С.: Такая команда в банке — явление редкое, но еще более уникально то, что в ней работают особенные люди. То есть эксперты на своем пользовательском опыте проверяют доступность продуктов. Есть ли подобные команды где-то еще в России?
М.К.: Как правило, банки привлекают сторонних экспертов. Мы тоже проходили этот путь, привлекая экспертов к тестированию и адаптации приложения.
Это было эффективно, когда существовал классический «водопад» и разработка велась централизованно. Но сейчас мы перешли на agile. Сложно представить, как рассказать разработчикам и дизайнерам из ста других команд о том, какой должна быть доступность. Поэтому мы с Павлом практикуем формат воркшопа и совместного тестирования.
Как проходит тестирование
П.П.: Когда команда готовится к запуску продукта, первым этапом является согласование макетов. Потом начинается разработка в коде — это то, что доступно незрячему человеку. То есть на этапе макета коллеги описывают мне, как это выглядит.
Когда продукт есть в коде, я беру то, что называется тестовой сборкой, проверяю это на своем устройстве со своими настройками, оцениваю доступность. Затем мы с Михаилом встречаемся с командой, которая занимается продуктом, — с разработчиками аналитиками, дизайнерами — и вместе с ними анализируем функциональность.
Я включаю озвучку (VoiceOver на iOS или TalkBack на Android; для аппаратов Samsung есть также программа Voice Assistant, сделанная на базе TalkBack), и мы сопоставляем изображение на экране с аудиоинтерфейсом — с тем, что озвучивают программы-скринридеры. Вместе с командой мы думаем, достаточно ли аудиоинтерфейс соответствует визуальному интерфейсу, и сразу записываем те изменения, которые нужно внести в программную часть.
В абсолютном большинстве случаев такое тестирование не затрагивает дизайн продукта: все изменения в области адаптации, особенно для незрячих пользователей, ведутся на уровне кода. Распространено ошибочное мнение, что для адаптации продукта нужно переделывать дизайн. Однако это не так.
Д.С.: Хотел бы поправить: если речь идет не об отсутствии зрения, а о сниженном зрении, то вопросы дизайна очень важны. Например, у меня возрастная дальнозоркость. Иногда с моего счета списывали большую комиссию за перевод, но я не видел информацию о комиссии, поскольку шрифт был слишком мелким и не отличался по цвету от фона.
П.П.: Очень правильное замечание. Когда команда берется разрабатывать продукт, она, безусловно, учитывает гайдлайны. Если мы говорим о мобильной платформе, то это гайдлайны Google, Apple, их библиотеки SDK. И точно так же разработчики должны учитывать гайдлайны по доступности. В Сбербанке есть такие гайдлайны, созданные нашими коллегами, и они в том числе содержат рекомендации для дизайнеров.
М.К.: Хотел бы добавить, что это публичный гайдлайн, который можно найти по адресу specialbank.ru/guide. Он удобен тем, что разделен по ролям. Для менеджера (руководителя проекта), дизайнера, разработчиков iOS, Android и Web сделаны отдельные секции, где даны краткие наглядные рекомендации, как обеспечить необходимый уровень доступности. Это позволит избежать чтения многостраничных ГОСТов или WCAG. Подробности, например в отношении какого-то сложного элемента, придется искать в других справочниках, но основная информация есть в гайдлайне.
Много ли особенных клиентов?
Д.С.: Среди лиц, принимающих решения в банках, распространен миф, что особенных людей не так много. Он основан на том, что мы в России почти не видим таких людей. Но, я полагаю, мы их не видим потому, что городская среда не сильно адаптирована для них. Как вы мотивируете своих коллег?
П.П.: Банк провел масштабное исследование, целью которого было выявить людей с особенными потребностями и проанализировать характер этих потребностей. Исследование показало, что, например, незрячих в РФ порядка 450 тысяч человек, слабовидящих — 1,5 миллиона человек. Результаты этого исследования и легли в основу подхода Сбербанка к адаптации продуктов.
Надо понимать, что помимо лиц с нарушениями зрения, слуха, опорно-двигательного аппарата есть еще одна очень большая категория — люди пенсионного возраста. Это люди, у которых особые потребности могут возникнуть ввиду возраста.
Важно учитывать, что особенные потребности могут быть не только постоянными, но и временными, например после операции на глаза. А некоторые люди имеют такие потребности не из-за состояния здоровья, а в силу жизненных обстоятельств: например, молодым мамам, которые часто носят ребенка на руках, удобно пользоваться только одной рукой.
Если мы сложим все эти категории, то получим десятки миллионов человек.
Какие проблемы встречаются чаще всего
Д.С.: В статистике проблем, которые мы выявили в 12 банках — участниках нашего исследования мобильных приложений, основную долю занимают проблемы с кодом. Далее следуют проблемы с дизайном: с контрастностью, бизнес-логикой (например, неочевидный смысл текста), со свайпом. Однако единственный «небоскреб» на этом графике — проблемы с кодом. И если посмотреть на выявленные проблемы в разрезе особенностей клиентов, то больше всего затронуты незрячие люди.
М.К.: Такая же проблема заметна и при тестировании веб-интерфейсов, так как зрячий человек вряд ли будет задумываться, как размечены заголовок и текст. Когда мы работаем с аудиоинтерфейсом, например с NVDA или JAWS, то структура текста рассыпается, если нет заголовков, причем разных уровней. Более того, невозможно осуществлять навигацию по странице: если это html-разметка, то быстро перемещаться нельзя. В режиме экранного диктора идет перемещение по заголовкам различных уровней и областям, а если разметки нет, то приходится озвучивать весь текст, двигаясь по нему построчно.
Для аудиоинтерфейса требуется отдельное пользовательское тестирование, которое не всегда может быть проведено обычным тестировщиком. Имея перед собой визуальный интерфейс, он может пропустить ошибку, которая для незрячего человека станет критической.
Для обеспечения доступности мы также используем автоматизированное тестирование, которое подсвечивает проблемные элементы и участки кода, но его не всегда достаточно. Тем не менее, без автоматизированного тестирования невизуальный интерфейс зачастую находится в таком состоянии, что с ним невозможно работать в режиме экранного диктора.
Кстати, после того как Павел протестировал интерфейсы при помощи VoiceOver, многие дизайнеры и разработчики внезапно узнали, что ошибочное использование латинской C (си) вместо русской С (эс) делает текст, читаемый экранным диктором, недоступным для незрячих.
Д.С.: Человек не вовремя переключил клавиатуру, когда набирал текст.
П.П.: Такое часто встречается, когда русские и латинские буквы похожи, например буква О или С. Допустим, человек написал «С уважением», вовремя не переключившись, и программа произносит это как «Си уважением». В нашем здании есть деление по секторам: А, В, С, D. И когда я читал приглашение в переговорную в сектор С (эс), я думал: «Неужели здесь столько секторов, что есть все буквы до С?» И только потом понял, что С — это всего лишь «си».
Нужен ли QR-код?
М.К.: У нас был такой курьез: разработчики умышленно вырезали из аудиоинтерфейса кнопку «Оплатить по QR-коду», поскольку решили, что незрячий пользователь все равно не увидит QR-код. Тем не менее, тестирование различных сценариев показало, что для незрячих людей QR-код на квитанциях — это единственный способ оплаты.
Д.С.: Потому что реквизиты они не могут заполнить точно.
М.К.: Они, конечно, могут сохранить в адресной книге или в заметках код плательщика. Если же это неизвестная платежка, то остается просканировать ее камерой.
П.П.: У меня был реальный кейс, когда я не смог заплатить за ЖКУ по шаблону, потому что реквизиты изменились. Приходилось звонить и просить, чтобы мне продиктовали новые реквизиты, поскольку на тот момент QR-кода не было. Знай я, что есть QR-код и его можно распознать в мобильном приложении, оплата по изменившимся реквизитам не представляла бы никаких сложностей.
Как повысить доступность приложения
М.К.: Сейчас над приложениями работает около 100 команд, порядка 700 разработчиков и участников. Расположены все они в восьми городах. Релизы и изменения в коде стали чаще. Одного тестирования недостаточно, поэтому важное значение имеет культура разработки — когда разработчик ответственен не только за функциональность своего кода, но и за общую доступность.
Известная история: разработчик делал приложение Smart AudioBook Player по стандартам и не ставил перед собой задачу сделать его доступным. Он просто заполнял все необходимые поля, в которых содержались метки, лейблы для экранных дикторов. Результатом такой тщательной работы стал доступный интерфейс.
Мы проводим воркшопы с командами тестирования, рассказываем им, что такое доступность цифровых интерфейсов, экранные дикторы и т.д. Чтобы ускорить процесс, во время регрессионного тестирования нового релиза часть экранов проверяют зрячие тестировщики. Это механическая проверка наличия и последовательности нужных «кнопок». Более сложные процессы тестируются на этапах проектирования в прототипах и предрелизного тестирования.
П.П.: Если использовать инструментарий из SDK, следовать инструкциям, написанным разработчиками операционных систем, под которые мы программируем, то большая часть приложения будет доступной.
Банальный пример, связанный с культурой разработки, — разметка в web html.
Когда зрячий человек видит короткий фрагмент текста, выделенный жирным шрифтом, он думает, что это заголовок. Однако это не так. Жирный шрифт большего размера не значит, что перед вами заголовок. Заголовок — это конкретный термин, конкретное определение. И вот грамотный разработчик, который пишет html-сайт, должен разметить этот текст именно как заголовок, то есть поставить условный тег <h>. Достаточно указать его номер — h1–h6, и текст увеличится, станет жирным и будет по факту заголовком. Если этого не сделано, текст заголовком не является и скринридеры не смогут его распознать.
Д.С.: Я хотел бы усилить мысль о том, что нужно использовать стандарты платформы, в которых уже заложены вопросы доступности. Я как пользователь испытываю неудобства от того, что разработчики многих мобильных приложений, стремясь выделиться из общей массы, нарушают UI-стандарты. Не только технологические. Например, если увеличить размер шрифта в ОС, он изменится в нативных приложениях и в тех приложениях, которые не игнорируют требования ОС. В прочих приложениях он останется мелким, что является нарушением соглашений внутри ОС.
Моя мечта — чтобы все приложения были «на одно лицо» в том смысле, что все они должны использовать нативные паттерны. Если каждый дизайнер начнет изобретать свои принципы взаимодействия с интерфейсом, приложение будет задерживать решение задач пользователя.
Как работают программы озвучивания
Д.С.: Когда я сообщаю на конференциях, что незрячие люди пользуются айфоном, очень многие делают круглые глаза: «А как?» И я начинаю рассказывать: «Они не включают экран, а воспринимают все на слух. Они постоянно ходят в наушниках» и т.д. Возможно, мы сегодня раскроем глаза кому-то. Как незрячие люди пользуются мобильным телефоном?
П.П.: Надо сразу оговориться, что при использовании VoiceOver или TalkBack меняются все жесты. Обычному пользователю достаточно один раз коснуться кнопки (например, кнопки «ОК»). Незрячему пользователю нужно сначала установить фокус на тот элемент, куда он хочет нажать, путем однократного касания экрана (той же кнопки «ОК») и потом дважды быстро коснуться экрана одним пальцем. Это необходимо для того, чтобы после работы с VoiceOver он мог выключить программу.
Д.С.: Здесь нужна поправка, чтобы зрячие люди тебя поняли. Ты говоришь, что нужно установить фокус. Но ведь ты не видишь, куда его устанавливать. Имеется в виду, что фокус устанавливается благодаря озвучиванию?
П.П.: Да. Для навигации по экрану незрячий пользователь применяет жесты. Самый распространенный — смахивание, быстрое проведение одним пальцем слева направо или справа налево. Например, смахиванием слева направо осуществляется переход от одной иконки рабочего стола к другой. Программа последовательно произносит названия иконок, и чтобы активировать одну из них, нужно два раза быстро коснуться экрана одним пальцем. Допустим, программа говорит «Телефон», и если нам нужен телефон, мы дважды касаемся экрана. Дальше точно так же, путем смахивания слева направо, перемещаемся по элементам уже нового экрана, находим нужный номер и два раза касаемся экрана, чтобы позвонить.
Д.С.: То есть деятельность становится совсем сложной, если на экране много элементов, потому что их последовательный перебор получается очень длинным. Правильно ли я понимаю, что для облегчения такого взаимодействия нужно, чтобы экран не был перенасыщен интерактивными элементами?
П.П.: Это скорее вопрос UX (user experience). Дело в том, что незрячие люди в принципе вынуждены держать в голове образ того экрана, с которым работают, независимо от мобильной платформы или веб-сайта. Это одна из причин, по которым многие незрячие люди не любят обновлений мобильных приложений: придется забывать старую картинку и изучать новую.
Поэтому если экран содержит много элементов, с ним, возможно, будет чуть сложнее работать. Но об этом речи никогда не идет. То есть нет такого выбора: сделать на экране много элементов или мало, и уж тем более для незрячих людей. По большому счету незрячему человеку нужна доступность элементов.
Д.С.: Но все-таки я как проектировщик могу решить задачу по-разному. Предположим, могу разбить каталог на более-менее маленькие группы и предъявлять тебе их так, чтобы ты мог сфокусироваться в поиске: сперва категории верхнего уровня, потом категории нижнего уровня. И таким образом на каждом экране ты будешь тратить немного времени. А второй вариант — представить все элементы одним наружным списком. Если нужный элемент находится в конце этого списка, перебирать элементы придется очень долго.
П.П.: Совершенно верно. Это еще один плюс в пользу универсального дизайна: особенные потребности часто совпадают с обычными. Такой единый список неудобен и зрячему человеку.
М.К.: Должны быть статические элементы. В Сбербанк Онлайн это так называемый таббар внизу — элемент управления с картинками и названиями вкладок приложения. Ты можешь привязаться к нему и от него уже идти вверх по списку. И еще при обновлении возникает либо стрелочка, либо бегунок, которые мало где озвучены. Они озвучены, например, в встроенном браузере Safari. Мы сделали такую же функцию при загрузке новых экранов: она озвучена в Сбербанк Онлайн.
П.П.: Она щелчками озвучивает процесс загрузки. Пока идет загрузка, раздается звук щелчка.
Д.С.: Когда щелчки прервались, пользователь понимает, что загрузка закончилась, экран интерактивный?
М.К.: Как правило, озвучивается либо первый элемент экрана, либо заголовок. Это соответствует стандартам. А щелчки — я думаю, такого пока ни у кого нет.
Мы даже тестировали записи разных щелчков в разной тональности.
Помогают ли голосовые помощники
Д.С.: Мы много говорили про озвучивание, но есть исходно звуковые форматы взаимодействия. Насколько они важны для незрячих людей?
П.П.: Я тоже задавался этим вопросом, но дело в том, что все голосовые помощники делались не для незрячих людей. Это вопрос привычки: кому что нравится, кому что удобнее. Я сам пользуюсь голосовыми помощниками редко, при этом использую лишь несколько (около десятка) стандартных функций, например установку таймера.
Я сравнивал клиентский путь установки таймера без использования голосового ассистента Siri и с его помощью. Голосовой ассистент гораздо удобнее.
Интересно, что на Android есть голосовой ассистент «Дуся», сделанный российским разработчиком без учета потребностей незрячих людей, но настолько качественно, что многие незрячие пользователи просят о доработке приложения для них.
Например, приложение позволяет вам при звонке вашего друга, у которого сменился номер, сохранить новый номер в списке контактов, просто назвав имя.
Что дальше?
Д.С.: Что бы вы могли порекомендовать коллегам из других банков?
М.К.: Я бы хотел сказать, что коль скоро темп выхода релизов и появления новых функций растет, будет расти и потребность в адаптации. Важно, чтобы не получилось как с 8-й версией операционной системы iOS, на которую незрячие пользователи просто не переходили, потому что по доступности она сильно уступала более ранним версиям.
Подход к обеспечению доступности постоянно меняется. Сейчас у нас есть дизайн-система, в которую уже на уровне отдельных элементов, «кубиков» для строительства будущего интерфейса, закладываются требования к контрастности, поддержке экранных дикторов и др. Во многих аспектах у нас сейчас идет обсуждение не просто доступности, а удобной доступности. Доступна функция «Диалоги», доступны «Истории» — они зачитываются, а не пролистываются VoiceOver.
Понятно, что нерешенных задач еще много. Но при этом уже проведена колоссальная работа, которая отражается в постоянном росте количества пользователей с особенными потребностями.
