Как мы контролируем общедоступность BlaBlaCar

Специально для vc.ru BlaBlaCar перевёл колонку своего фронтенд-инженера, ответственного за общедоступность сайта и приложения. Внутри много полезных ссылок и советов, как привести интерфейс сервиса в соответствие международным стандартам качества.

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

Согласно Всемирному докладу об инвалидности, опубликованному Всемирной организаций здравоохранения, 15% населения Земли имеют ту или иную форму инвалидности, 253 млн из них имеют проблемы со зрением.

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

У людей разные способности, навыки, предпочтения и ожидания, влияющие на то, как они пользуются сервисами. В отчёте о разнообразии интернет-пользователей, который подготовил Консорциум всемирной паутины (World Wide Web Consortium, далее — W3C), можно подробнее почитать об этом.

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

Чаще всего главным врагом общедоступности (стандарт называется a11y) является недостаточная осведомлённость: мы просто не задумываемся об этом, а если и задумываемся, то не знаем, как правильно это реализовать, или намеренно опускаем этот пункт, думая: «Большинству людей это не нужно», «Это не для нашей бизнес-модели», «У нас нет на это времени», «Слепые люди в любом случае не будут пользоваться нашей платформой» и так далее.

Это неправильно. Соблюдение стандартов общедоступности a11y имеет ряд преимуществ для сервиса: легкая читаемость, повышение лояльности, увеличение аудитории.

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

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

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

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

Фронтенд-команда BlaBlaCar сейчас активно меняет вёрстку мобильного приложения и десктопной версии сервиса с учётом принципов одностраничного приложения (Single Page App).

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

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

Вот почему у нас два разных цветовых тона: один — для брендинга и для печати; второй — для использования в интернете.

Для интерфейса мы используем более тёмные варианты брендовых цветов:

Чтобы проверить читаемость текста и определить оптимальные комбинации между текстом и фоновыми цветами, мы используем специализированные онлайн-инструменты, такие как Tanaguru.

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

При выборе цвета мы стремимся соответствовать уровню А стандарта общедоступности WCAG-2.0, а при выборе контраста — уровню АА. Это соответствует критериям W3C. Нам всё больше удаётся соответствовать этим требованиям, поскольку мы постоянно совершенствуемся.

В дополнение к повышению читабельности, во время ребрендинга мы сильно упростили наши UX-шаблоны: уменьшили количество элементов на каждой странице, увеличили размеры шрифтов, размеры интерактивных кнопок («Вход», «Регистрация»).

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

А вот так ваш текст могут видеть люди с дислексией — избирательным нарушением способности к чтению (GitHum source):

Чтобы не допустить этого, мы стараемся избегать нечёткости, упрощаем и добавляем больше «воздуха» в тексты. Чисто чёрный текст на чисто белом фоне и длинные параграфы также могут вызывать сложности для людей с дислексией. О других примерах плохих UX-решений, от которых страдают дислексики, можно почитать в статье "6 Surprising Bad Practices".

Как я уже сказал, мы недавно стали начисто переверстывать веб-версию сервиса в формат одностраничного приложения. Для этого мы используем библиотеку системы проектирования под названием Kirk (обратите внимание на статью моего коллеги об этом), на которую мы опираемся при соблюдении всех параметров общедоступности стандарта а11y.

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

Создавая новые компоненты сервиса, мы внимательно изучаем рекомендации используемого стандарта: контролируем, чтобы использовалась правильная семантическая разметка содержания (пространство, блоки, альтернативное содержание), думаем, как адаптировать сложные компоненты на JavaScript (выпадающие меню и прочее).

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

Соблюдение правил W3C не гарантирует на 100%, что интерфейс будут удобен для пользователей. Поэтому, чтобы проверить эффективность встроенных компонентов, мы проводим ручные тесты по навигации с помощью клавиатуры и скринридеров (обычно используем VoiceOver).

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

После общения с Kaelig Deloumeau-Prigent (Shopify) мы решили обновить наши инструменты проверки общедоступности, используя Pa11y Webservice. Это позволит нам постоянно мониторить наше соответствие требованиям a11y и видеть эволюцию разработки.

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

#дизайн