Android contentdescription что такое

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

Подробное объяснение роли атрибута 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

Источник

«Отсутствует атрибут contentDescription на изображении» в XML

Я получаю предупреждение о [Доступность] Отсутствует атрибут contentDescription на изображении в eclipse. Это предупреждение отображается в строке 5 (объявить ImageView ) в XML-коде ниже.

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

Это мой XML-файл:

Пожалуйста, помогите мне в этом и спасибо за ваше чтение.

Следуйте этой ссылке для решения: Android Lint contentDescription warning

Устранено это предупреждение, установив атрибут android: contentDescription для моего ImageView

андроид: contentDescription = «@ строка / убывание»

Поддержка Android Lint в ADT 16 выдает это предупреждение, чтобы гарантировать, что виджеты изображений содержат контент.

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

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

Эта ссылка для объяснения: доступность, ресурсы и ресурсы для развития

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

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

Это руководство предназначено для доступа к вашему приложению: расширение доступа к приложениям

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

Обозначьте свой ImageButton , ImageView , EditText , CheckBox и другие элементы управления пользовательским интерфейсом, используя атрибут android: contentDescription .

Сделайте все элементы пользовательского интерфейса доступными с помощью контроллера направления, такого как трекбол или D-pad.

Протестируйте приложение, включив службы доступности, такие как TalkBack и Explore by Touch, и попробуйте использовать ваше приложение, используя только направленные средства управления.

Добавьте android:contentDescription=»@string/description» (статический или динамический) в ваш ImageView. Пожалуйста, не игнорируйте и не фильтруйте сообщение, потому что это полезно для людей, использующих альтернативные методы ввода из-за их инвалидности (например, TalkBack, Tecla Access Shield и т. Д.).

Обновлено:

Как отмечено в комментариях, установка описания на null указывает на то, что изображение является чисто декоративным и понимается как устройство чтения с экрана, такое как TalkBack.

Старый ответ, я больше не поддерживаю этот ответ:

Для всех людей, желающих избежать предупреждения:

Я не думаю, что android:contentDescription=»@null» – лучшее решение.

Я использую tools:ignore=»ContentDescription» , что и должно быть.

Убедитесь, что вы включили xmlns:tools=»http://schemas.android.com/tools» в корневой макет.

Предупреждение действительно раздражает, и во многих (большинстве!) Случаях нет описания контента для различных декоративных изображений. Самый радикальный способ решить проблему – это просто сказать Линт игнорировать эту проверку. В Eclipse перейдите к «Проверка ошибок Android / Lint» в настройках, найдите «contentDescription» (он находится в группе «Доступность») и измените «Severity:» на Ignore.

Если вам все равно, сделайте следующее:

Хотя я бы посоветовал принять принятые решения, это взломать: D

Источник

Технические аспекты обеспечения невизуальной доступности 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 в самой системе. Участие же сообщества в его развитии затруднено тем, что публикуемые исходники как правило неактуальны, а команда разработчиков попросту игнорирует обращения энтузиастов и конструктивные предложения.

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

Источник