Цифры и масштабы использования
Согласно Всемирному докладу об инвалидности, опубликованному Всемирной организаций здравоохранения, 15% населения Земли имеют ту или иную форму инвалидности, а 253 миллиона человек имеют проблемы со зрением. Существует несколько видов инвалидности, которые существенно оказывают влияние на использование интерфейса. Среди них: глухота, когнитивные, физические и речевые нарушения, дислексия, проблемы со зрением.
Разные способности людей, а также их предпочтения и ожидания влияют на то, как они пользуются сервисами. В отчете о Разнообразии интернет пользователей, который подготовил Консорциум Всемирной Паутины (World Wide Web Consortium, далее – W3C), можно узнать об этом подробнее.
Иногда пользователям, чтобы воспользоваться сервисом, необходимо изменить цвет интерфейса, масштаб, иметь возможность навигации с помощью клавиатуры или включить функцию скринридера.
Роль frontend-инженера в создании сервиса, доступного всем
Чаще всего главным врагом общедоступности по международному стандарту a11y является недостаточная осведомленность: мы просто не задумываемся об этом, а если и задумываемся, то не знаем, как правильно это реализовать, или намеренно опускаем этот пункт, думая: «Большинству людей это не нужно», «Это не для нашей бизнес-модели», «У нас нет на это времени», «Слепые люди в любом случае не будут пользоваться нашей платформой»…
Это неправильно. Соблюдение стандартов общедоступности a11y имеет ряд преимуществ для сервиса: легкая читаемость, повышение лояльности, увеличение аудитории и так далее. Много маленьких шагов могут быть сделаны ценой минимальных усилий. Например, выбрать правильный цветовой тон, добавить альтернативное наполнение, соответствующее стандартам общедоступности a11y. Такие инновации проще внедрять на начальном этапе развития проекта.
Роль frontend-инженеров – убедить каждого, что дизайн «для всех» – это преимущество, а не ограничение. В BlaBlaCar мы рассматриваем стандарт общедоступности a11y не как отдельный проект, а как часть глобального стандарта качества нашего сервиса. Мы стараемся его приоритизировать, перенимаем передовой опыт в процессе разработки и используем различные ручные и автоматизированные инструменты на этапах разработки. В ином случае мы будем всегда на шаг позади и будем тратить время на залатывание дыр, поскольку обогнать локомотив разработки при таком подходе невозможно.
Подход и инструменты
Немного контекста
Frondend-команда BlaBlaCar сейчас активно меняет верстку нашего мобильного приложения и десктопной версии сервиса с учетом принципов одностраничного приложения (Single Page App). Это включает в себя техническую миграцию в React и улучшение пользовательского опыта.
UX-аспекты
В процессе ребрендинга, который мы недавно провели, приходится идти на ряд компромиссов между читабельностью и тем чувством, которое вы хотите вызвать в пользователе новым дизайном. Вот почему у нас два разных цветовых тона: один – для брендинга и для печати; второй – для использования в интернете.
Для интерфейса мы используем более темные варианты брендинговых цветов:
Чтобы проверить читаемость текста и определить оптимальные комбинации между текстом и фоновыми цветами, мы используем специализированные онлайн-инструменты, такие как Tanaguru. Это очень помогает найти подходящие цветовые комбинации и гайдлайны. Например, если контраст недостаточен, применяем другие визуальные инструменты, такие как минимальный размер шрифта или «полужирный» текст.
При выборе цвета, мы стремимся соответствовать уровню А стандарта общедоступности WCAG-2.0, а при выборе контраста – уровню АА. Это соответствует критериям W3C.
В дополнение к повышению читабельности, во время ребрендинга мы сильно упростили наши UX-шаблоны: уменьшили количество элементов на каждой странице, увеличили размеры шрифтов, размеры интерактивных кнопок (Вход/Регистрация).
В помощь дальтоникам
Чтобы увидеть наш дизайн глазами дальтоников, мы использовали Skala Preview, которая поддерживает основные типы дальтонизма, включая протанопию, дейтеранопию, тританопию и монохромазию.
Пляшущие тексты
А вот так ваш текст могут видеть люди с дислексией – избирательным нарушением способности к чтению (GitHum source):
Чтобы не допустить это, мы стараемся избегать нечеткости, упрощаем или добавляем больше «воздуха» в тексты. Чисто черный текст на чисто белом фоне и длинные параграфы также могут вызывать сложности для людей с дислексией. О других примерах плохих UX-решений, от которых страдают дислексики, можно почитать в статье 6 Surprising Bad Practices.
Технический аспект
Как было сказано выше, мы недавно стали начисто переверстывать веб-версию сервиса в формат одностраничного приложения. Для этого мы используем собственную библиотеку Системы проектирования под названием Kirk (обратите внимание на эту статью моего коллеги), на которую мы опираемся при соблюдении всех параметров общедоступности стандарта а11y. Наличие составных элементов, соответствующих этому стандарту, является первым шагом для эффективного внедрения передовых методов доступности в остальной части приложения.
Инструменты разработки и построение процессов
Создавая новые компоненты сервиса, мы внимательно изучаем рекомендации используемого стандарта: контролируем, чтобы использовалась правильная семантическая разметка содержания (пространство, блоки, альтернативное содержание…), думаем, как адаптировать сложные компоненты на JavaScript (выпадающие меню и проч.).
Чтобы избежать типичных ошибок при внедрении критериев a11y, мы применяем правила ESLint, которые использует Airbnb. Проводим модульные тесты по контролю за содержанием страницы и состояниям атрибутов. Благодаря этому, front-end инженер не сможет случайно забыть или пропустить требуемый элемент.
Соблюдение правил W3C не гарантирует на 100%, что интерфейс будут удобен для пользователей. Поэтому, чтобы проверить эффективность встроенных компонентов, мы проводим ручные тесты по навигации с помощью клавиатуры и скринридеров (обычно используем VoiceOver).
При сквозных тестах мы отрабатываем общие сценарии использования сервиса, чтобы также быть уверенными, что у нас нет проблем с общедоступностью.
Контроль соблюдения требований a11y (еще не введен)
После общения с Kaelig Deloumeau-Prigent (Shopify), мы решили обновить наши инструменты проверки общедоступности, используя Pa11y Webservice. Это позволит нам постоянно мониторить наше соответствие требованиям a11y и видеть эволюцию разработки.
Данной колонкой мы хотели показать, как и с помощью каких инструментов мы повышаем общедоступность нашего сервиса.
Автор: Николя Эну, front-end разработчик в BlaBlaCar
