Автоматизированное тестирование базовой доступности интерфейсов Android-приложений

в 17:58, , рубрики: accessibility, Accessibility Scanner, android, Google, дизайн мобильных приложений, доступность, интерфейсы, разработка мобильных приложений, Разработка под android, тестирование, Тестирование мобильных приложений

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

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

С технической точки зрения Accessibility Scanner представляет собой так называемую службу доступности, то есть приложение, работающее в фоне и взаимодействующее с accessibility API OS Android с целью реализации дополнительной функциональности для пользователей с ограниченными возможностями. После установки Accessibility Scanner, необходимо открыть раздел «Спец. возможности» (Accessibility) в настройках устройства, найти в них Accessibility Scanner и активировать службу, дав ей необходимые разрешения. После этого, на экране появится кнопка Accessibility Scanner, отображаемая поверх всего интерфейса.

Открыв интерфейс, который необходимо протестировать, следует нажать на эту кнопку, после чего служба последовательно опишет все найденные проблемы и предложит варианты их исправления. Также можно будет вывести все найденные проблемы единым списком и отправить полученный отчёт по E-mail.

Отчёт может содержать примерно такие рекомендации:

Text contrast
com.habrahabr.example:id/label
The item's text contrast ratio is 2,46. This ratio is based on an estimated foreground color of #999999 and an estimated background color of #EEEEEE. Consider increasing this item's text contrast ratio to 3,00 or greater.

Здесь всё довольно очевидно: разработчику необходимо повысить контрастность цветов текста и фона. Accessibility Scanner рекомендует обеспечивать коэффициент контрастности для крупного текста не менее 3, а для мелкого — не менее 4,5. Это является ничем иным, как нормативами стандарта WCAG 2.0 от W3C с средним уровнем соответствия AA.

Впрочем, если разработчик желает повысить степень доступности, то может использовать более жёсткие требования по высшему уровню соответствия AAA. В этом случае коэффициент контрастности для крупного текста должен быть не менее 4,5, а для мелкого — не менее 7.

Желающие вникнуть в методику расчёта коэффициента контрастности могут кликнуть по данному тексту и прочитать под спойлером соответствующую портянку.

Коэффициент контрастности (CR) рассчитывается по следующей формуле:

CR = (L1 + 0,05)/(L2 + 0,05)
где
L1 — относительная яркость наиболее светлого из цветов;
L2 — относительная яркость наиболее тёмного из цветов.

В цветовом пространстве sRGB относительная яркость цвета (L) рассчитывается по формуле:

L = 0,2126*R + 0,7152*G + 0,0722*B
где
если RsRGB <= 0,03928, то R = RsRGB/12,92, иначе R = ((RsRGB+0,055)/1,055)^2,4;
если GsRGB <= 0,03928, то G = GsRGB/12,92, иначе G = ((GsRGB+0,055)/1,055)^2,4;
если BsRGB <= 0,03928, то B = BsRGB/12,92, иначе B = ((BsRGB+0,055)/1,055)^2,4.

RsRGB, GsRGB, BsRGB определяются как:

RsRGB = R8bit/255;
GsRGB = G8bit/255;
BsRGB = B8bit/255.

В результате значение коэффициента контрастности располагается в интервале [1; 21], где 1 — минимальная контрастность, например, белый на белом, а 21 — максимальная, например, чёрный на белом.

Item label
com.habrahabr.example:id/button
This item may not have a label readable by screen readers.

Тут разработчики Google несколько поленились, так как вряд ли подобный комментарий окажется достаточно информативным для неподготовленного разработчика. Однако всё довольно просто. Это означает, что элемент управления имеет лишь графическое представление, а текстовая метка у него отсутствует. Таким образом, пользователи, работающие с интерфейсом не при помощи зрения, а посредством программ чтения экрана, будут слышать на нём что-то типа «Кнопка 25 без ярлыка».

Для исправления этой проблемы необходимо подписать каждый элемент управления текстовой меткой посредством атрибута android:contentDescription:

<Button
	android:id="@+id/button"
	android:src="@drawable/button"
	android:contentDescription="@string/button"/>

Стоит отметить, что значение атрибута android:contentDescription не будет отображаться визуально. Оно предназначено для программ чтения экрана и произносится ими при фокусировании данного элемента управления. То есть как-либо оптимизировать длину данного текста под размер экрана не требуется. Однако android:contentDescription — это полноценный строковой ресурс, поэтому точно также нуждается в локализации. Именно поэтому его следует выносить в strings.xml и переводить на ряду со всеми остальными.

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

Если Android-разработчики потратят немного времени на тестирование интерфейса своих приложений посредством Accessibility Scanner и потом ещё чуть больше времени на исправление найденных базовых проблем доступности, то их продукты станут более дружественны к пользователям, имеющим некоторые ограничения зрения. В ряде случаев подобный автоматический аудит и соответствующие ему исправления вообще могут обеспечить полную доступность приложения. Однако в более сложных случаях всё же не стоит полагаться исключительно на Accessibility Scanner и по возможности тестировать доступность интерфейса вручную, в том числе и с привлечением реальных пользователей. Об этом предупреждают и сами разработчики Accessibility Scanner в описании службы: «Accessibility Scanner isn't a replacement for manual testing, and doesn't guarantee an app's accessibility».

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

Под конец ещё раз ссылка на Play Маркет для тех, кто не кликнул по ней в начале статьи.

Автор: Tseikovets

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js