Введение

Многие разработчики программных продуктов заинтересованы в расширении аудитории приложения, которое они разрабатывают. Если вы только начинаете задумываться о том, насколько удобно будет пользоваться вашим приложением людям с ограниченными возможностями, и вам трудно понять, каковы требования к
accessibility и как начать работу, то эта статья для вас. Она позволит вам начать изучение распространенных проблем с accessibility в приложениях Android. А их устранение поможет многим пользователям вашего приложения.

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

Инструменты

Основные инструменты, используемые для тестирования Android Accessibility, с которых вам можно начать, являются:

TalkBack (документация, исходный код)
Accessibility Scanner
Различные онлайн ресурсы для вычисления contrast ratio:
Color tool, Contrast Checker, Color Palette Contrast Checker
Инструменты для автоматизации тестирования: Espresso, Robolectric

TalkBack

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

Включение TalkBack может отличаться в зависимости от производителя устройства и версии Android, например, так:
Settings -> Accessibility -> Vision -> Talkback -> Включить switch

При разработке необходимо привыкнуть к особенностям взаимодействия с устройством, когда TalkBack включен. Например, чтобы произвести нажатие на элемент на экране, необходимо выбрать элемент касанием и выполнить двойное нажатие на экран, а чтобы прокрутить экран (swipe) необходимо использовать два пальца вместо одного.

TalkBack поддерживает два основных вида навигации по устройству:
Линейный обход. Для перемещения между элементами экрана необходимо проводить по экрану вправо или влево. При этом TalkBack будет озвучивать каждый объект, которого вы выбираете.
Изучение касанием. Для этого нужно коснуться экрана пальцем и водить по экрану, пока не найдете нужный элемент.

Accessibility Scanner

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

Области для улучшения

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

Описание содержимого элементов
Навигация
Размеры шрифтов
Контраст цветов
Области элементов для нажатия

Описание содержимого элементов

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

Есть ли у элементов описания содержимого?
Соответствует ли озвучивание тому, что на самом деле показано на экране?
Совпадает ли озвучивание действий, которые выполняют элементы экрана?
При изменении состояния элемента обновляется ли описание содержимого?
Есть ли какие-то элементы, которые являются только декоративными и могут быть исключены из озвучивания?

Вышеупомянутый Accessibility Scanner выявит многие из этих проблем и даже подскажет возможные их решения. В основном потребуется добавить атрибуты конкретным элементам, такие как contentDescription, importantForAccessibility, labelFor и др. Android Lint указывает на отсутствие атрибута contentDescription у ImageView:
screenshot_from_2021-11-22_17-59-55
Описание элемента экрана может быть добавлено и обновлено. Декоративные элементы могут быть помечены как не важные для accessibility и будут пропущены (android:importantForAccessibility = "no").

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

Если на экране есть элемент Button с текстом "Log In", TalkBack сам добавляет тип элемента "Button" после текста: "Log In, button". Если же разработчик решит включить тип элемента в contentDescription, то тип элемента озвучится дважды: "Log In, button button").
Если на экране есть элемент CheckBox с текстом, TalkBack озвучивает его состояние "checked" или "not checked" вместе с текстом. Если, например, разработчик попробует добавить к CheckBox'у информацию о состоянии, то пользователь может услышать эту информацию дважды.

Бывает и так, что тип элемента не соответствует его предназначению. Например, на Camfrog Android 7.13 кнопка открытия экрана логина была не Button, а TextView, стилизованный под кнопку:
screenshot_2021-11-22-08-31-49
В результате того, что для кнопки использовался элемент TextView, TalkBack озвучивал только его текст ("Log In"), не озвучивая, что это кнопка. Соответственно пользователь также этого не знал, и это вводило его в заблуждение. Решение было простое: заменить TextView на MaterialButton.

Для упрощения разработки можно показывать текст озвучки на экране: Settings -> Accessibility -> Vision -> Talkback -> Settings -> Advance settings -> Developer settings -> Display speech output set to ON. Эту настройку можно также использовать, если есть необходимость продемонстрировать коллеге текст озвучки, отправив ему скриншот экрана.

Когда вы перемещаетесь по приложению, логичен ли порядок изменения фокуса элементов?
Можно ли сгруппировать некоторые элементы для упрощения линейного обхода Talkback?

Исправление навигации может быть трудной задачей. Некоторые проблемы можно решить добавлением атрибутов accessibilityTraversalBefore, accessibilityTraversalAfter, nextFocusForward и др. Здесь стоит задуматься о порядке линейного обхода Talkback, например, элементы display name могут быть сгруппированы в один и пройдены, и озвучены единожды, не делая это четыре раза для каждого элемента:
screenshot_2021-11-23-09-12-55

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

Размеры шрифта

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

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

Чтобы устранить проблемы в этой области, замените все dp на sp для определения размера текста. Убедитесь, что элементы масштабируются в соответствии с размерами текста: атрибуты minWidth, minHeight и ellipsize, а также использование wrap_content для высоты и ширины помогут с этим.

Контраст

Некоторые вопросы, которые требуют внимания:

Какие цвета фона и текста/изображения на нем можно использовать в приложении, чтобы упростить их просмотр?
Можно ли легко различить элементы, которые можно нажать?

Общее требование - минимальное соотношение контрастности текста к фону 4,5:1 и 3:1 для элементов управления. В некоторых случаях добавление контуров поможет различить элементы на экране. Проверить контрастность текста и изображений на определенном фоне можно с помощью Accessibility Scanner'a:

Область элемента для нажатия

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

Достаточных ли размеров область вокруг элемента, которая реагирует на нажатие?
Можно ли ее расширить?
Можно ли коснуться всего элемента или область касания ограничена небольшой его частью?
Есть ли много мелких элементов рядом друг с другом, так что можно легко нажать на соседний элемент вместо желаемого?

Рекомендация Android - минимум 48x48dp для доступных областей. Выставление margin'ов и padding'ов между элементами, где это возможно, может облегчить нажатие на нужный элемент. Accessibility Scanner умеет определять области, которые слишком малы для точного нажатия и дает рекомендации по их увеличению:

Custom views

Особое внимание следует обратить на custom views. Если вы создаете их на основе классов Material Components, то возможно их встроенной поддержки accessibility будет достаточно. Но бывает так, что custom views наследует и использует Android framework/appcompat widget'ы, в которых поддержки accessibility может не хватать. Это можно исправить путем добавления AccessibilityDelegateCompat с указанием нужных текстов для озвучивания:

open class AuthInputView @JvmOverloads constructor(context: Context, attrs: AttributeSet? = null, defStyleAttr: Int = 0) :
	FrameLayout(context, attrs, defStyleAttr) {
	...

	init {
  	...
		ViewCompat.setAccessibilityDelegate(viewHolder.input, AccessibilityDelegate(viewHolder))
	}
  
	class AccessibilityDelegate(val viewHolder: ViewHolder) : AccessibilityDelegateCompat() {
		override fun onInitializeAccessibilityNodeInfo(host: View, info: AccessibilityNodeInfoCompat) {
			super.onInitializeAccessibilityNodeInfo(host, info)
			val inputText = viewHolder.input.text
			val helperText = viewHolder.helperText.text
			info.text = "$inputText, $helperText"

			if (viewHolder.error.isVisible) {
				info.error = viewHolder.error.text
			}
		}
	}
}

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

В некоторых случаях, функционала AccessibilityDelegateCompat может не хватать, и придется писать свой Accessibility service для логики вашего приложения.

Есть еще несколько ресурсов по дизайну, разработке и тестированию accessibility приложений, которые не были упомянуты в этой статье.

Заключение

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

Android accessibility