Как сделать цифровой сервис для человека, а не для сферического клиента в вакууме

О проблемах доступности государственных сервисов мы поговорили с Татьяной Мироновой — руководителем направления проектирования мобильных интерфейсов Департамента проектирования пользовательских интерфейсов АО «РТ Лабс». Татьяна — одна из авторов исследования о доступности, которое выйдет в Центре подготовки руководителей и команд цифровой трансформации в 2022 году.


— Можно ли с первого взгляда понять, как обстоят дела с доступностью на сайте?

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

— А почему тогда появились эти версии для слабовидящих, если они не нужны?

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

ГОСТ Р 52872–2019 «Требования доступности для людей с инвалидностью и других лиц с ограничениями жизнедеятельности» был разработан на основе международного стандарта «Руководство по обеспечению доступности веб-контента» (Web Content Accessibility Guidelines, WCAG 2.2).

— Какие шаги нужны, чтобы сделать госуслуги доступными?

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


— Неужели один человек в команде, озабоченный проблемой доступности, реально что-то может сделать, чтобы с доступностью на сервисе стало лучше?

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

— А что еще можно сделать?

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

Важная часть — работа с голосовым помощником (VoiceOver). Это требует дополнительных ресурсов,  — как времени, так и денег.

VoiceOver — технология, с помощью которой можно управлять компьютером, используя речь и клавиатуру; встроенная программа чтения экрана озвучивает информацию, выведенную на экране. Мобильные приложения, созданные для iOS и Android, как правило, способны корректно работать с VoiceОver, сторонние приложения часто требуют дополнительной адаптации.

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

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

— Если на сайте шрифты недостаточно контрастны для людей с плохим зрением, можно ли это подкорректировать, не переделывая весь сайт?

— Если сайт сделан правильно, с использованием CSS-стилей, подкорректировать можно быстро, но если сайт сделан «на коленке», то его придется переделывать весь. Много проблем возникает из-за кривого кода. VoiceOver только обнажает проблемы.

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

Сайты и приложения государственных учреждений должны быть доступны всем, в том числе и людям с ограниченными возможностями здоровья (ОВЗ). По данным Федерального реестра инвалидов, в России 11,96 млн людей с инвалидностью, при этом людей с особыми потребностями гораздо больше. Один пользователь может входить в несколько категорий.

— В чем функция тестировщиков с ОВЗ?

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

— Нужны ли тестировщики ПО с моторными нарушениями, глухотой и другими видами нарушений?

— Для тестирования достаточно привлечь незрячего человека и человека с ДЦП (это заболевание влияет на моторику и иногда на речь). Большинство глухих людей умеют читать, поэтому каких-то особенных проблем с доступностью для глухих не возникает. Очень много людей имеет различные нарушения зрения: выпадение полей зрения, полная потеря, частичная потеря. У каждого своя специфика. По-хорошему, нужно дополнительно взять человека с частичной потерей зрения, который использует увеличенные шрифты или экранную лупу, можно также привлечь человека с нормальным зрением, который плохо видит под вечер или в сумерках.

— Есть ли какая-то специфика при общении с тестировщиками с ОВЗ?

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

— Работа с жалобами и обратной связью увеличивает доступность сервиса?

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

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

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

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

Автоматический альтернативный текст на основе распознавания объектов - функция для сторис Instagram, повышающая доступность приложения для слабовидящих и незрячих пользователей

— Допустим, у меня есть десять минут, чтобы донести идею доступности до начальства. Что сказать, чтобы начальство прониклось этой темой? 

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

Беседовала Алиса Орлова