Делаем Android-приложение Airbnb более доступным

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

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

Часть I. Создание для всех: лучшие практики, которые мы применяем

В Airbnb мы следуем лучшим отраслевым практикам, чтобы сделать приложение для Android доступным. Если вы заинтересованы, вы можете найти все рекомендации, которым мы следуем, в официальной документации Android для конкретных платформ и в Руководстве по доступности веб-контента в качестве отраслевого стандарта. Здесь мы хотим выделить несколько примеров, где мы применяем лучшие практики:

Лучшая практика: описания контента

Все должно иметь точное описание содержания, если оно не должно игнорироваться технологиями реабилитации. В этих примерах кнопка «Поделиться» имеет описание содержимого, которое TalkBack читает вслух. Однако TalkBack пропускает иконку дома.

Лучшая практика: группировка

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

Лучшая практика: масштаб шрифта

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

Стандартный и увеличенный масштаб шрифта:

Лучшие практики масштабирования

Приложение Airbnb для Android — это большое приложение с множеством экранов. Было бы утомительно и не масштабируемо, если бы нам нужно было везде добавлять код для реализации специальных возможностей. К счастью, наша Система языков дизайна позволяет нам широко применять эти передовые методы на различных продуктовых поверхностях очень эффективным способом. Каждый экран состоит из набора многократно используемых компонентов пользовательского интерфейса. Когда мы улучшаем доступность для одного компонента, это изменение распространяется на все страницы с этим компонентом как часть представления. Это оказывает долгосрочное положительное влияние на улучшение доступности нашего приложения. Вот пример:

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

Часть II. Расширьте возможности инженеров с помощью автоматизированных проверок

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

Автоматизированное тестирование

Мы настроили автоматическое тестирование на основе Espresso, чтобы проверить наличие проблем с доступностью. Espresso — популярная библиотека для тестирования пользовательского интерфейса Android со встроенными проверками доступности. Она поддерживает полный набор правил доступности и проста в настройке:

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

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

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

Линтинг

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

Вот пример правила lint для доступности для Android:

Помимо встроенного Android Lint, мы также используем Ktlint для создания собственных правил lint. Например, когда пользователь переходит на новый экран, мы предоставляем имя страницы, которое программа чтения с экрана объявляет. Мы используем следующее правило, чтобы убедиться, что имя страницы локализовано.

Правила lint просты в настройке и обеспечивают своевременную обратную связь, но у linting есть ограничения — он может выполнять только статический анализ кода.

Сегодня эти автоматические проверки выполняются как часть проверок CI (Continuous Integration) для каждого коммита кода. Если пул-реквест не проходит проверки, он будет заблокирован от слияния с основной веткой кода. Мы по-прежнему используем ручное тестирование, чтобы охватить области, которые не охватывают автоматические проверки, например, порядок обхода элементов пользовательского интерфейса на странице. Автоматизированные и ручные проверки хорошо дополняют друг друга.

Часть III. Взгляд в будущее: специальные возможности с помощью Compose

В течение последнего года мы интегрировали Jetpack Compose в наше приложение. Документация Google «Доступность в Compose» была отличным ресурсом для обеспечения доступности наших компонентов и экранов Compose. Несмотря на то, что в представлениях отсутствуют некоторые заметные вещи (например, изменение порядка фокусировки), Compose — все еще молодая библиотека, и мы с нетерпением ждем будущих улучшений. Вот несколько вещей, которые стоит упомянуть о наших инструментах доступности для Compose.

Активно поощряйте описания контента в API

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

Объявления названия страницы

При использовании фрагментов и представлений мы используем API-интерфейсы View.setAccessibilityPaneTitle() и View.announceForAccessibility() при переходе на новый экран, чтобы объявить пользователю описательное имя страницы. Этих API нет в Compose, но мы хотели сохранить эту функциональность, поскольку она помогает предоставить больше контекста в отношении того, что отображается на новом экране. Наш текущий обходной путь задает определенную семантику для внешнего компонента экрана:

Мы используем свойство liveRegion, поэтому изменения могут быть объявлены при изменении описания контента. Это полезно для страниц, все содержимое которых определяется ответом сервера. В этом случае TalkBack будет объявлять «Загрузка контента», пока сетевой запрос находится в ожидании, затем «Контент загружен», когда он завершен, и, наконец, описание страницы, указанное в ответе сервера. Недостатком этого подхода является то, что он требует, чтобы внешний контейнер был фокусируемым, что требует дополнительного действия навигации для доступа к содержимому.

Заключительные мысли

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

Благодарности

Сделать такое сложное приложение, как приложение Airbnb для Android, более доступным — огромная задача. Эта работа была бы невозможна без огромных усилий команды цифровой доступности и сплоченного сообщества Android в Airbnb. Каждый инженер внес свой вклад в то, чтобы сделать свои функции доступными. Сделать приложение для Android более доступным — это постоянная работа, и без всех этих усилий мы не смогли бы добиться успеха.

Источник