Методология подготовки рейтинга доступности банковских приложений. Методология составлена при поддержке ЦБ РФ. Рейтинг будет составлен и опубликован в 2019 году.
для людей с различными нарушениями • Пример расчета доступности мобильного банка • Рейтинг доступности мобильных банков для людей с различными нарушениями • Общий рейтинг доступности мобильных банков
ЮзабилитиЛаб проводит разработку и согласование единой методологии оценки доступности мобильных приложений банков. В рамках текущего рейтинга предлагается провести оценки доступности Android- и iOS-приложений. За основу методологии должны быть взяты требования доступности для инвалидов по зрению ГОСТ Р 52872-2012, а также лучшие практики и дополнения: • Информационные письма от ЦБ РФ (от 12.05.2017 и от 23.10.2017) • WCAG 2.1 Руководство по обеспечению доступности веб-контента 2. Банк России организует проведение встречи для согласования методологии рейтингования с представителями рабочей группы ЦБ РФ, а также 14 крупнейших банков, оказывающих услуги населению с использованием дистанционных каналов коммуникации с клиентами. 3. ЮзабилитиЛаб оценивает каждый сервис по набору базовых сценариев, создает профили доступности и рассчитывает рейтинг доступности iOS- и Android-приложений. 4. ЮзабилитиЛаб представляет результаты рейтинга доступности на совещании Рабочей группы, после чего данные будут доступны на сайте UsabilityLab.ru. Результаты будут использоваться для публикаций в СМИ.
финансовой доступности для инвалидов и маломобильных групп населения, а также учитывает участников исследования доступности НАФИ. Список банков для оценки доступности
использованы уровни из ГОСТ Р 52872-2012. Рекомендации ГОСТ в данном случае воспринимаются как обязательные требования, а несоответствие требованиям снижает уровень доступности. Также проведена работа по соотнесению требований ГОСТ и WCAG и формированию дополнений. Примеры далее.
во многом цитирует WCAG 2.0, но при этом описывает доступность интерфейсов только для пользователей с нарушениями зрения. Стандарт выделяет 3 уровня доступности интерфейсов: Уровень минимальной доступности. Позволяет инвалиду по зрению обеспечить доступность к интернет-ресурсу без потерь информации. Уровень полной доступности. Позволяет инвалиду по зрению обеспечить доступность ко всем структурным элементам интернет-ресурса. Уровень доступности специализированных интернет-ресурсов для инвалидов по зрению. Позволяет инвалиду по зрению обеспечить доступность к интернет-ресурсу с использованием специальных технологий этого ресурса, разработанных для людей с ограничениями по зрению. А АА ААА
от ГОСТ Р 52872-2012, описывает рекомендации, направленные на обеспечение доступности интерфейсов для людей со всеми видами нарушений. Рекомендации также имеют 3 уровня важности: Сайт обязан следовать этим положениям, иначе некоторые пользователи не смогут получить доступ к содержимому сайта. Сайт должен следовать этим положениям, иначе некоторые пользователи испытают существенные затруднения при доступе к содержимому сайта. Желательно, чтобы сайт следовал этим положениям, иначе некоторые пользователи испытают некоторые затруднения при доступе к содержимому сайта. А АА ААА
планируют проводить тестирование мобильных приложений на платформах IOS и Android, с использованием набора базовых пользовательских сценариев: 1. Вход в мобильный банк; 2. Просмотр баланса; 3. Перевод между своими счетами; 4. Оплата мобильной связи; 5. Оплата коммунального платежа по ЕПД. Если один сценарий можно выполнить разными путями, оценка будет производиться по каждому из них. Список таких путей будет согласован перед началом исследования. Базовый критерий, который эксперты будут использовать для составления рейтинга — «уровень проходимости сценария» (см. следующий слайд).
сценарий, в котором обнаружена критичная проблема доступности, которая не позволяет выполнить задачу людям с определенным типом ограничений; 0.2 балла получает приложение за сценарий, в котором обнаружены проблемы доступности средней критичности ─ пользователи испытают существенные затруднения; 0.5 балла получает приложение за сценарий, в котором обнаружены проблемы доступности низкой критичности ─ пользователи испытают некоторые затруднения, что приводит к ощутимому увеличению времени выполнения задачи; 1 балл получает приложение, в котором не обнаружено проблем доступности. Если при выполнении сценария не обнаружено критичных проблем, то сценарию присваивается минимальный балл по самой критичной выявленной проблеме. 0.2 0.5 1 0
мобильного приложения для использования людьми с инвалидностью; 2. Оценка происходит путем тестирования прохождения всех базовых пользовательских сценариев взаимодействия клиента с приложением; 3. Чем больше базовых пользовательских сценариев доступны клиенту, и чем меньше барьеров и сложностей выявлено при прохождении сценария, тем выше рейтинг; 4. Уровень доступности сценария определяется по наиболее критичной* выявленной проблеме. *Примеры частотных категорий проблем доступности приведены в данной презентации. Каждой проблеме была присвоена степень критичности в соответствие с нормативными документами – ссылка. Данная оценка критичности будет использоваться в случае, если выявленная проблема влияет на прохождение сценария.
пользователей с нарушениями*: Незрячие Слабовидящие Моторика Слух и речь 1. Вход в мобильный банк 0,5 1 1 1 2. Просмотр баланса 0 1 0,5 1 3. Перевод между своими счетами 0,2 0,5 0,2 1 4. Оплата мобильной связи 0,2 0,5 0,5 1 5. Оплата коммунального платежа по ЕПД 0,2 0,2 0,5 1 Итого: 1,1 3,2 2,7 5 *Доступность интерфейсов для пользователей с ментальными нарушениями не входит в критерии оценки, поскольку это очень широкая группа нарушений с трудно формализуемыми критериями, что может привести к неточностям при составлении рейтинга.
Рейтинг доступности для пользователей с нарушениями Зрение Слабо- видящие Моторика Слух и речь 1. Банк А (5 баллов) 1. Банк А (4,7 баллов) 1-3. Банк А, Г, Д, (5 баллов) 1-4. Банк А, Б, В, Д (5 баллов) 2. Банк Б (4,2) 2. Банк Б (4,2) 3. Банк В (4,2) 3. Банк В (4,0) 4. Банк Г (3,2) 4. Банк Г (3,7) 4. Банк В (4,2) 5. Банк Д (2,7) 5. Банк Д (3,0) 5. Банк Б (4,5) 5. Банк Г (4,5) ... ... ... Несоответствие рекомендациям понижает оценку доступности анализируемого приложения. Для каждого выявленного несоответствия будет указан уровень доступности в соответствии с ГОСТ и WCAG, до которого оно понижает доступность страницы.
Б 13,25 3. Банк В 10,5 4. Банк Д 9,75 5. Банк Г 9 ... Общий рейтинг доступности мобильных банков Все оценки доступности для людей с различными категориями нарушений будут просуммированы для каждого участвующего в исследовании мобильного приложения. Полученная оценка будет использована для создания итогового общего рейтинга доступности мобильных банковских приложений.
933 01 37 www.usabilitylab.ru facebook.com/usabilitylab Дмитрий Силаев +7 (926) 492 05 50 [email protected] Презентация подготовлена с целью утверждения методологии оценки доступности и рейтингования Android- и iOS- приложений банков 2019 Приложение ниже содержит детальные примеры проблем доступности Ожидаемый срок представления рейтинга: конец 1 квартала 2019 года.
интерфейсами. Часть проблем, которая будет касаться и людей без нарушений, будут маркироваться соответствующим значком. В исследовании не затрагивались пользователи с ментальными нарушениями, поскольку это очень широкая группа нарушений с трудно формализуемыми критериями оценки интерфейсов, что могло привести к неточностям при описании проблем.
практически полной потерей зрения. Для работы с мобильными приложениями используют экранные дикторы. Для пользователей важна правильная работа экранного диктора, поскольку ошибки в его поведении могут привести к невыполнению основных задач мобильных банков. Ошибки в работе экранного диктора возникают в основном из-за некорректного кода, гораздо реже проблемы возникают из-за проектирования или дизайна. При проектировании приложений для слепых или слабовидящих людей, которые использую диктор, обязательно учитывать, что управление жестами недопустимо, поскольку их выполнение совместно с экранным диктором вызывает большие затруднения или в принципе невозможно. Слабовидящие пользователи, не использующие экранный диктор – люди с сильной потерей зрения, испытывают затруднения с чтением с экрана, но в интерфейсе могут ориентироваться на контрастные элементы управления, а для чтения с экрана использовать экранные дикторы.
позиционированием пальцев на элементах управления и с взаимодействием с интерфейсом жестами. Часто люди с моторными нарушениями используют стилусы для работы с приложениями. Сложности взаимодействия для пользователей с этой категорией нарушений стоит учитывать при проектировании интерфейса и стараться по возможности избегать появления элементов, для которых требуются такие жесты, как перетаскивания, свайпы, двойные нажатия и т.д.
речи не могут полноценно воспринимать аудиоинформацию и общаться голосом. При проектировании приложений для учета нужд этой категории пользователей рекомендуется создавать чаты и выстраивать бизнес-процессы таким образом, чтобы не возникало вопросов, решаемых исключительно обращениями в колл-центр банка.
и WCAG для digital-команд, т.е. для тех, кто занимается развитием продуктов, но не занимается подробным погружением в них, мы проанализировали частотные проблемы доступности приложений для разных категорий пользователей. Проблемы мы поделили на 26 категорий и привели примеры. Каждый пример содержит описание проблемы, скриншот, уровни доступности по ГОСТ и WCAG, тип нарушения, для которого актуальна указанная проблема, а также рекомендации по их устранению. Уровень критичности обнаруженного несоответствия не указан, поскольку это будет сделано только в контексте исследуемого интерфейса, решаемой задачи и особенности пользователей.
поэтому пользователь не может понять, что происходит на экране. Такой текст тяжело воспринимается людьми с разными ментальными расстройствами и проблемами с концентрацией. Пожилые люди и люди, не знающие латинский алфавит, также испытывают затруднения с чтением подобных текстов. 20 Проблемы бизнес-логики Тинькофф. SMS-сообщение с кодом подтверждения набрано транслитом Рекомендация: Не использовать в интерфейсе текст, набранный транслитом, а также по возможности избегать канцеляризмов, длинных предложений и больших объёмов текста. Подробнее: п. 3.1 WCAG 2.0 Использование сложного для восприятия текста
аббревиатуры и сокращения. Поэтому пользователь будет испытывать затруднения с выполнением операций или вовсе не сможет понять, что происходит на экране. Например, сокращенное наименование дней недели (пт, вт, ср и т.д.) озвучивается так же, как и пишется: «Ср» вместо «Среда» и т.д. 21 Наличие сложных для восприятия на слух терминов Проблемы бизнес-логики Альфабанк, экран с историей операций. Дни недели сокращены до двух букв Рекомендации: по возможности избегать сокращений и аббревиатур, или предоставлять пользователям их пояснения и расшифровки Подробнее: п. 3.1 WCAG 2.0
более 30 000 рублей требуется подтверждение операции через колл-центр банка. Пользователи с нарушениями слуха или речи, в том числе люди с расстройствами речи после инсульта, испытывают затруднения или не имеют физической возможности общения по телефону. 22 Отсутствие альтернативных способов подтверждения Проблемы бизнес-логики Экран подтверждения перевода: сообщение о том, что переводы суммой свыше 30 000 рублей должны подтверждаться в контактном центре банка Рекомендация: Убрать ограничение на сумму перевода без подтверждения или предоставить альтернативный колл-центру способ подтверждения, доступный для людей с нарушением слуха и речи.
потребоваться связь с банком. В случае, если не предусмотрен чат или иной способ оперативно разрешить проблему в письменном виде, пользователь не сможет решить свою задачу. Данная проблема актуальна как для людей с постоянными нарушениями слуха и речи, так и для, например, восстанавливающихся после ЧМТ — их речь может показаться оператору нетрезвой. 23 Отсутствие чата или иного незвукового способа связи Проблемы проектирования ОТПбанк, основное меню. В приложении есть возможность прочитать нотификации от банка, но нельзя отправить сообщение. Рекомендация: добавить в приложение чат для связи с оператором. Дополнительно рекомендуется добавить возможность для связи с использованием русского жестового языка, например, видеовызов в самом приложении или в любом другом.
виде списка. Поскольку экранный диктор некорректно озвучивает содержимое карты, незрячий или слабовидящий пользователь не сможет найти ближайший банкомат или отделение. Также для управления картой требуются жесты, что затруднительно для пользователей с нарушениями моторики. 24 Отсутствует альтернативный, доступный пользователю, способ восприятия контента Проблемы проектирования Промсвязьбанк. В приложении нет возможности просмотреть список отделений или банкоматов Рекомендация: для контента, который представлен в визуальном формате должен быть предусмотрен альтернативный способ представления.
приложении не используется текст, то пользователь экранного диктора не сможет узнать, прошла ли операция. В таком случае пользователь может попробовать выполнить ее повторно. 25 Отсутствует обратная связь Проблемы проектирования Росбанк. Экран обработки операции оплаты услуг: при обработке платежа пользователю не дается обратной связи Рекомендация: Озвучивать информацию о загрузке, проведении транзакций, переходе между экранами и т.д. Подробнее: п.2.4.8 WCAG 2.0
использование приложений людьми с моторными нарушениями. К таким проблемам в первую очередь относится выполнение действий жестами — «потрясти», «наклонить», «жестикуляция перед камерой телефона». 26 Наличие единственного способ управления — жестами Проблемы проектирования ВТБ. Для смены карты требуется свайп влево. Рекомендация: предусмотреть альтернативный способ управления для всех элементов, с которыми возможно взаимодействовать жестами — использование компонентов интерфейсного управления. Подробнее: п. 2.5.4 WCAG 2.1
3:1, пользователи с нарушениями зрения испытывают большие затруднения при взаимодействии с ними. 27 Низкий контраст функциональных элементов Проблемы дизайна Тинькофф, экран ввода периода оплаты. Иконка очищения поля имеет коэффициент контрастности относительно фона 1.59 Рекомендация: В дизайне приложения изменить цвета функциональных элементов на более контрастные, с коэффициентом контрастности более 3. Подробнее: п.1.4.11 WCAG 2.1. Для оценки контраста использовался сервис contrastchecker.com
пользователи с нарушениями зрения будут испытывать большие затруднения при чтении текста, а какую-то часть информации на экране могут не заметить. 2 8 Низкий контраст текста Проблемы дизайна Промсвязьбанк, экран входа в приложение. Название поля «Номер клиента или псевдоним» имеет контрастность 1,67. Рекомендация: В дизайне приложения изменить цвета текста на более контрастные, с коэффициентом контрастности более 3:1. Подробнее: п.1.4.3 WCAG 2.0. Для оценки контраста использовался сервис contrastchecker.com
не задано альтернативное описание в коде, пользователь экранного диктора не сможет узнать содержимое картинки. 29 Использование изображения текста Русский стандарт, главный экран неавторизованной зоны. Баннер «Управляйте своим бонусным счетом…» не имеет тифлокомментариев Рекомендация: по возможности избегать изображений текста. В случаях, когда это необходимо, следует дополнять код изображения описанием содержимого изображения. Подробнее: п. 1.4.5 и 1.4.9 WCAG 2.0 Проблемы дизайна
будут испытывать затруднения с идентификацией этого элемента. Пользователям с моторными нарушениями (например, отсутствием пальцев или тремором рук), будет тяжело прицелиться и попасть в такие элементы, что значительно увеличит время на выполнение их задач. 30 Малый размер элементов управления Проблемы дизайна Открытие, страница оплаты телефона. Иконка редактирования оператора маленькая. Рекомендация: сделать иконки и прочие элементы, задачу которых нельзя решить аналогичным способом, размером не менее 44×44 пикселей без учёта кликабельной области. Подробнее: п. 2.5.5 WCAG 2.1
управления никаким способом. Это приведёт к тому, что пользователь экранного диктора не сможет взаимодействовать с данным элементом и, соответственно, выполнить свою задачу в мобильном приложении. 31 Не устанавливается фокус на элемент Проблемы качества кода Росбанк, экран перевода между собственными счетами. Не устанавливается фокус на кнопку смены счета списания. Рекомендация: Позволить устанавливать фокус экранного диктора на все функциональные элементы Подробнее: п.2.1 WCAG 2.0
если оно не указано, пользователь не сможет идентифицировать элемент управления и воспользоваться им. 32 Не озвучивается название элемента ЮниКредит Банк, экран входа в приложение. Не озвучивается название кнопки «Войти». Рекомендация: Указать корректные русскоязычные наименования и типы элементов управления в коде. Подробнее: п. 1.1.1 и п.4.1.2 WCAG 2.0 Проблемы качества кода
если это наименование указано некорректно, слепой или слабовидящий пользователь будет испытывать затруднения с идентификацией и использованием этого элемента. 33 Элемент озвучивается некорректно Проблемы качества кода Открытие, экран перевода с карты на карту. Вместо названия поля ввода озвучивается маска ввода: «ноль ноль ноль ноль…» Рекомендация: Указать корректные русскоязычные наименования элементов управления. Подробнее: п. 1.1.1 и п.4.1.2 WCAG 2.0.
странице приложения, он начинает озвучку на указанном в коде языке, и, встретившись с элементами, названными на другом языке, озвучивает их некорректно (чаще всего коверкая слова или произнося их с акцентом, из-за которого их трудно различить даже человеку, знающему иностранный язык). 34 Озвучивается англоязычное название элемента Проблемы качества кода Тинькофф, экран перевода с карты на карту. Кнопки очистки поля и возврата на предыдущий шаг озвучиваются бессмысленным набором букв. Рекомендация: Указать корректные русскоязычные наименования элементов управления. Подробнее: п. 1.1.1 и п.4.1.2 WCAG 2.0 Эсэфклиарайкон Эйэфэрроуап
вкладки, фокус экранного диктора должен автоматически переключаться на их содержимое. В противном случае экранный диктор продолжит озвучивать содержимое предыдущего экрана и получить информацию будет невозможно. 35 Отсутствует автоматическое переключение фокуса Проблемы качества кода Газпромбанк, экран с историей операций: фокус не устанавливается автоматически на окно с подробностями операции Рекомендация: автоматически устанавливать фокус на контент вкладок, модальных окон, панелей или клавиатуру при их появлении на экране. Подробнее: п.2.4.3 WCAG 2.0
случае, если тип не указан, пользователь экранного диктора не сможет воспользоваться им, так как не будет знать как с ним взаимодействовать. • Экранные дикторы имеют режим озвучивания, в котором они переключаются не между всеми элементами, а только элементами одного типа — например, заголовками. В случае, если тип не указан, использование данной функции станет невозможным, что увеличит время на поиск нужной информации на странице. 36 Не озвучивается тип элемента Проблемы качества кода Райффайзен, экран входа в приложение. Не указано, что «По логину / По карте» – это переключатель и с ним можно взаимодействовать. Рекомендация: Указывать типы для всех элементов. Подробнее: п.4.1.2 WCAG 2.0
пользователь не может правильно его идентифицировать, и, соответственно, использовать. Экранные дикторы имеют функцию переключения между элементами определённых типов, например, между заголовками и ссылками, которая также не будет работать в случае наличия данной проблемы. 37 Озвучивается некорректный тип элемента Проблемы качества кода Сбербанк, экран подтверждения перевода. Сумма зачисления и комиссия озвучиваются как текстовые поля, хотя на самом деле это нередактируемый текст Рекомендация: Указывать корректные типы для всех элементов. Подробнее: п.4.1.2 WCAG 2.0
перевода), то при повторной установке фокуса экранного диктора в это же поле они должны озвучиваться. В противном случае пользователь может внести данные повторно, что приведет к ошибке. Кроме того, он не сможет проверить правильность заполнения полей. 38 Не озвучиваются введенные в поле данные Проблемы качества кода Русский стандарт, экран оплаты ЖКХ по ЕПД. Не озвучиваются данные в полях «Код плательщика» и «Месяц и год оплаты», из-за чего после ввода нельзя проверить корректность данных. Рекомендация: Озвучивать введённые в поля данные. Подробнее: п. 3.3 WCAG 2.0
левого верхнего угла. Если фокус экранного диктора устанавливается на нефункциональные элементы (декоративные блоки или элементы, не отображаемые на экране), пользователю сложнее понять, что происходит на экране, а путь к целевому действию существенно удлиняется. 39 Озвучиваются декоративные или скрытые элементы Проблемы качества кода Альфа-Банк, экран перевода между собственными счетами. Озвучиваются декоративные элементы, с которыми нельзя взаимодействовать. Рекомендация: Скрывать от экранного диктора декоративные элементы. Подробнее: п.4.1.1 WCAG 2.0
в логически неверном порядке. Например, сначала могут озвучиваться все названия элементов, а потом все типы. Данная проблема приводит к тому, что пользователь не сможет понять структуру страницы и воспользоваться её элементами, а значит, не завершит её выполнение без посторонней помощи. 40 Некорректная верстка составного эл-та управления Проблемы качества кода ВТБ, просмотр подробностей о банкомате. Информация о валютах озвучивается как «Выдаёт принимает российский рубль российский рубль» Рекомендация: Объекты, являющиеся одним элементом управления, должны быть сверстаны таким образом, чтобы фокус устанавливался не на отдельные их части, а на весь элемент управления целиком. Подробнее: п.2.4.10 WCAG 2.0.
если это состояние влияет на функции приложения (например, кнопка выполнения перевода недоступна), а пользователь экранного диктора не сможет об этом узнать, то такой пользователь не сможет выполнить свою задачу в приложении. 41 Не озвучивается состояние элемента Проблемы качества кода Райффайзен Банк, главный экран. Нет возможности узнать в какой вкладке (История, Шаблоны или входящие) находится пользователь. Рекомендация: озвучивать состояния всех элементов, если таких состояний больше одного. Подробнее: п. 4.1.2 WCAG 2.0
ошибки, с которыми не встречаются пользователи, не использующие его. Например, с экранным диктором фокус устанавливается в конец поля «Код плательщика», и пользователь не может ввести данные, предварительно не очистив поле от маски ввода. В обычном режиме фокус устанавливается в начало поля и позволяет заполнить его без дополнительных действий. 42 Некорректное озвучивание масок ввода Проблемы качества кода Росбанк, экран оплаты ЖКУ по ЕПД. При включённом экранном дикторе поле ввода кода плательщика нельзя заполнить, пока не будет удалена маска ввода (нижние подчёркивания) Рекомендация: проверять функциональные элементы на корректность взаимодействия с экранным диктором
933 01 37 www.usabilitylab.ru facebook.com/usabilitylab Дмитрий Силаев +7 (926) 492 05 50 [email protected] ПОВЫШАЯ УРОВЕНЬ ДОСТУПНОСТИ ПРИЛОЖЕНИЙ БАНКОВ, ВЫ УЛУЧШАЕТЕ КАЧЕСТВО ЖИЗНИ МНОГИМ И СЕБЕ В ЧАСТНОСТИ
usabilitylab
beglobal_document
alpinc
livesense
coacha
beerandtech_recruiter
jtes
kubell_storage
tokyo_metropolitan_gov_digital_hr
cinchr
palettecloud
00marvel
loglass2019
cassininazir
thoeni
chrislema
tammyeverts
brianwarren
trishagee
sferik
michaelherold
tanoku
paulrobertlloyd
eileencodes
zakiyama
