Content description android что это

Русские Блоги

Подробное объяснение роли атрибута contentDescription в Android ImageView и ImageButton

При использовании ImageView и ImageButton, AS напомнит нам добавить атрибут contentDescription, в противном случае появится предупреждение желтого цвета. Для человека с обсессивно-компульсивным расстройством это то, что я не могу допустить, поэтому я хочу понять использование и значение contentDescription. ContentDescription в основном для повышения интерпретации контроля для людей с нарушениями зрения. tools:ignore=»ContentDescription» Просто отлично

В элементе управления Android есть атрибут android:contentDescription 。

Вообще говоря, пользователи редко используют этот атрибут.

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

Этот атрибут может использоваться только после того, как соответствующий атрибут в Accessible пользователя включен.

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

Добавьте этот атрибут в приложение.

1. Поскольку этот элемент управления не имеет свойства текста, для некоторых пользователей невозможно понять, что делает этот элемент управления.

В это время пользователь нажимает на этот элемент управления. Система Android будет автоматически использовать содержимое, на которое указывает атрибут android: contentDescription в элементе управления чтением.

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

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

Если вы не хотите использовать это свойство и не хотите видеть предупреждение, добавьте android:contentDescription

Источник

Автоматизированное тестирование базовой доступности интерфейсов 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

Источник

Знакомство со свойствами доступности Android

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

Android предлагает много возможностей, но ими часто пренебрегают во время разработки и реализации проектов. Доступность API была впервые представлена в Android 1.6 (API уровень 4), но многие разработчики не знакомы или не заинтересованы в этом.

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

Добавление текстового описания к элементам пользовательского интерфейса

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

Content Descriptions – простейшая функция реализации доступности и одна из наиболее полезных. Это похоже на комментарии в коде. Google советует использовать описания в основном для элементов ImageView, ImageButton и CheckBox, так как здесь они наиболее необходимы.

Описания добавляются двумя способами, с помощью макета XML или традиционных методов Java.

Используя XML вы добавляете описание к изображению, как это (обратите внимание на последнюю строку):

@string выражен в файле strings.xml вроде этого:

Для поля EditText используйте следующую строку, чтобы объяснить пользователю, что они должны ввести:

Если элементы вашего интерфейса меняют состояние, как кнопка переключения или флажок, вы должны убедиться, что contentDescription меняется динамически в зависимости от состояния. В этом случае используйте метод setContentDescription ():

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

Навигация без использования сенсорного экрана

Она позволяет использовать ваше приложение без сенсорного экрана, но с использованием контроллеров. Они включают в себя D-pad, trackball, жесты и клавиши со стрелками. Важно, чтобы ваше приложение поддерживало эти различные механизмы для навигации.

Убедитесь, что каждый элемент ввода фокусируем и налажен, используя указательные кнопки. Не забудьте указать визуально элемент, на котором пользователь фокусируется, выделив его. Каждый элемент управления в Android имеет эту функцию по умолчанию, но если вы создали свои собственные элементы, сделайте их фокусируемыми с помощью метода setFocusable(true) или атрибута android:focusable:

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

Они говорят сами за себя, но следующий пример кода демонстрирует их использование:

Создание собственных услуг доступности

Услуги доступности общаются с пользователем от имени приложения и обеспечивают навигационную обратную связь, такую как тактильную обратную связь, преобразование текста в речь и визуальные сигналы. Android по умолчанию предоставляет такие услуги как TalkBack и Explore by touch. Они помогают пользователям, которые не в состоянии нормально взаимодействовать с устройством из-за физических недостатков или в особых ситуациях, таких как вождение автомобиля, тренировка и т.д.

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

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

Тестирование очень важно, поэтому убедитесь, что тщательно протестировали приложения после осуществления каких-либо функций доступности. Это может быть достигнуто путем включения TalkBack и Explore by touch и управлением вашего приложения, используя только аудио обратную связь. Убедитесь, что каждый элемент управления обеспечивает необходимую обратную связь, и что аудио подсказки не повторяются больше, чем нужно. Кроме того, директивы Android Design предполагает, что каждый фокусируемый элемент должен быть, по крайней мере, 48dp в длину и ширину.

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

Вывод

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

Источник

Технические аспекты обеспечения невизуальной доступности Android-приложений

Возможно, читателю, далекому от рассматриваемой проблематики, название покажется абсурдным, ведь дизайн интерфейса как самой системы Android, так и разрабатываемых для нее приложений, ориентирован прежде всего именно на визуальную наглядность и привлекательность, что усугубляется использованием сенсорного экрана в качестве главного органа взаимодействия пользователя с устройством. Однако существует категория пользователей, волею природы или случая лишенных возможности в полной мере насладиться всеми этими прелестями. Благодаря тому, что в Android предусмотрены альтернативные, — или, лучше сказать, дополнительные, — способы взаимодействия, интерфейс и основной функционал системы отнюдь не являются принципиально недоступными для данной категории пользователей. Именно обеспечению такой доступности посвящены пункт «Специальные возможности» в меню настроек системы и входящее в ее состав приложение TalkBack. Что же касается невизуальной доступности сторонних приложений, то она варьируется от случая к случаю и порой требует от разработчика не то чтобы каких-то специальных сверхусилий, но хотя бы минимального внимания к проблеме.

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

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

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

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

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

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

Концепция универсального дизайна и принцип здорового минимализма

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

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

То есть, когда возникает соблазн воспользоваться при разработке интерфейса какой-либо сторонней библиотекой или же создать свой собственный совершенно оригинальный элемент управления, недурно бы для начала задуматься: а так ли оно необходимо на самом деле? Android SDK предоставляет в распоряжение программиста весьма богатый набор средств такого рода, и без достаточно серьезных оснований за его пределы выходить не следует. Это, кстати, положительно отразится не только на доступности приложения, но и на его совместимости.

Об атрибуте contentDescription

Самое простое и очевидное, что разработчик приложения может (и должен, на мой взгляд) сделать для пользователей с визуальными ограничениями, не перетрудившись при этом и ничем не пожертвовав, — это аккуратно подписать все чисто графические элементы интерфейса через атрибут contentDescription . Однако, к сожалению, очень мало кто это делает. И должное уважение к данному атрибуту представляется скорее счастливым исключением, нежели общепринятой практикой.

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

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

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

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

Как видим, чисто графический элемент ImageView в этой схеме не имеет атрибута contentDescription . И это совершенно осознанно. Элемент списка здесь рассматривается как единое целое, то есть, его части ( ImageView и TextView ) не имеют самостоятельной роли: у них не установлен атрибут clickable . Текстовая информация, необходимая службе специального доступа, целиком содержится в TextView , а ImageView в данном случае играет по большей части декоративную роль и с точки зрения невизуального доступа полезной информации не несет.

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

Теперь предположим, что пользователи в нашем списке могут находиться в различном состоянии, скажем, «online» и «offline», и для их индикации мы будем пользоваться разными цветами. Сделать эту дополнительную информацию также невизуально доступной нам опять-таки поможет атрибут contentDescription , который на сей раз мы будем задавать динамически вместе с цветом элемента в адаптере списка.

Вот как это может быть реализовано:

Предполагается, что в строковом ресурсе имеется определение:

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

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

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

Списки с «живыми» элементами

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

Для определенности предположим следующую реализацию:

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

С этой целью введем в рассмотрение вспомогательный класс:

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

В принципе, задачу можно было бы решить и переопределением метода notifyDataSetChanged() в адаптере списка:

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

Сложные элементы списка и динамическая информация

Теперь рассмотрим ситуацию, когда каждый элемент списка имеет сопряженную с ним кнопку, то есть описывается, например, следующей схемой:

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

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

И, по установившейся уже традиции, будем производить ежесекундные обновления:

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

Для борьбы с этой неприятностью несколько расширим функциональность нашего вспомогательного класса:

И будем избегать обновления информации на экране при попадании фокуса доступности на встроенные в список кнопки, но, разумеется, лишь тогда, когда используется режим невизуального доступа:

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

События на невидимых страницах

Рассмотрим еще один интересный случай, а именно, использование переключаемых вкладок (или страниц):

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

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

Теперь остается только вовремя сообщать о смене страниц:

А каждый фрагмент, отвечающий за страницу, должен ее зарегистрировать:

Параметр PAGE_NUMBER здесь на самом деле означает позиционный номер страницы. То же самое, что и параметр метода FragmentPagerAdapter.getItem().

Заключение

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

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

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

Источник