Автор:	© Никита Цейковец
Дата публикации:	23.11.2011

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

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

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

Основные концепции

Соблюдение следующих двух правил поможет решить ряд основных проблем в отношении доступности приложения.

1. Обеспечить доступность взаимодействия со всеми элементами управления посредством trackball'а или джойстика.
2. Реализовать ImageButton, EditTexts и другие элементы ввода с использованием атрибута contentDescription.

Реализация навигации посредством управляющего контроллера

Многие Android-устройства имеют управляющий контроллер, такой как:

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

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

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

Возможности навигации, в частности обзора посредством управляющего контроллера, определяются через метод isFocusable(). Для задания возможности пользователя по фокусированию элементов, следует вызвать setFocusable(boolean) или установить атрибут android:focusable в файле XML-макета.

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

• Вниз - nextFocusDown;
• Влево - nextFocusLeft;
• Вправо - nextFocusRight;
• Вверх - nextFocusUp.

Нажатие управляющего контроллера

На большинстве устройств, нажатие контроллера, то есть выполнение команды ввод, посылает KeyEvent с KEYCODE_DPAD_CENTER. Следует убедиться, что это событие даёт тот же результат, что и нажатие управляющего элемента на сенсорном экране. Все стандартные приложения Android уже обрабатывают KEYCODE_DPAD_CENTER соответствующим образом.

У KEYCODE_DPAD_CENTER также есть эквивалент - KEYCODE_ENTER, который более удобен для устройств с QWERTY-клавиатурой.

Маркировка элементов ввода

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

Для задания текстового описания таких элементов предназначен атрибут contentDescription. В нём следует поместить текст, ясно описывающий назначение элемента ввода, при этом желательно его логическое соответствие графической пиктограмме. Данный атрибут следует указывать для всех элементов ImageButton, EditText и всех остальных виджетов ввода, для которых это возможно.

Следование Android UI Best Practices

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

Следует использовать представление элементов, которое описано в Android SDK, когда это возможно, так как эти элементы имеют встроенную поддержку доступности.

Отправка AccessibilityEvents из кастомных видимых элементов

Если приложение требует создание кастомных видимых элементов, то оно может быть сделано доступным посредством реализации интерфейса AccessibilityEventSource (android.view.accessibility.AccessibilityEventSource) и отправки в надлежащее время AccessibilityEvent (android.view.accessibility.AccessibilityEvent).

Видимые классы уже применяют интерфейс AccessibilityEventSource. Данный интерфейс обеспечивает механизм для отправки событий зарегистрированным службам доступности AccessibilityService (android.accessibilityservice).

Существует несколько типов событий доступности, которые должны быть отправлены:

1. Нажатие видимого элемента - TYPE_VIEW_CLICKED;
2. Нажатие видимого элемента с долгим удержанием - TYPE_VIEW_LONG_CLICKED;
3. Выделение элемента, как правило, в контексте "AdapterView." - TYPE_VIEW_SELECTED;
4. Установка фокуса на элемент - TYPE_VIEW_FOCUSED;
5. Изменение текстового содержимого элемента в фокусе - TYPE_VIEW_TEXT_CHANGED.

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

Тестирование доступности приложения

Для тестирования доступности приложения можно либо обратиться к сообществу пользователей с ограниченными возможностями, либо попытаться самостоятельно имитировать работу пользователей, используя функции специальных возможностей и появившейся в API level 18 специализированной службы UI-Automation. Одним из таких инструментов является TalkBack — программа экранного доступа, предустановленная на многих устройствах. Кроме того, она бесплатно доступна в Android Market.

Для работы TalkBack требует наличие в системе синтезатора речи. На некоторых устройствах может потребоваться предварительная установка в том числе и голосового движка, например, бесплатного eSpeak for Android.

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

Справочник для разработчиков

• AccessibilityEvent
• AccessibilityEventSource
• AdapterView
• android:focusable
• contentDescription
• EditTexts
• ImageButton
• isFocusable()
• KEYCODE_DPAD_CENTER
• KEYCODE_ENTER
• KeyEvent
• setFocusable(boolean)

Ссылки на специализированное ПО

• Программа голосового экранного доступа TalkBack
• Синтезатор речи eSpeak for Android
• Системная библиотека Text-To-Speech Extended, необходимая для работы синтеза речи (на некоторых версиях Android OS требует отдельной установки)