Contentdescription android studio что это

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

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

Используя пространство имен инструментов, android studio поддерживает множество атрибутов XML, которые будут удалены при сборке приложения без какого-либо влияния на размер APK и поведение во время выполнения. Посмотри пожалуйстаОфициальный сайт。

Атрибуты инструментов можно условно разделить на три категории: 1. Атрибуты обработки ошибок, которые будут влиять на запросы Lint, 2. Атрибуты сокращения ресурсов, которые влияют на сжатие ресурсов, 3. Просмотр атрибутов во время разработки редактора макета.

1 Свойства обработки ошибок

Любой элемент может использовать этот атрибут, например, строковый элемент в strings.xml, мы можем игнорировать неправильный атрибут MissingTranslation:

В другом примере для элемента ImageView в следующем коде, если мы не добавим атрибут tools: ignore, Lint предложит, чтобы в ImageView отсутствовал атрибут android: contentDescription, а tools: ignore = «contentDescription» может игнорировать это предупреждение:

Любой элемент может использовать этот атрибут, это и аннотации в коде Java@TargetApiЭто то же самое: оно определяет уровень API, поддерживаемый текущим элементом, а значение атрибута может быть числом или кодовым именем.
В этом случае, даже если указано minSdkVersion Если текущий элемент не поддерживается, Lint не будет предупреждать. Такие как набор minSdkVersion=12 , Но использовать GridLayout Если вам нужно добавить tools:targetApi=»14″ ：

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

Например, вы можете указать values/strings.xml Язык файла по умолчанию — испанский вместо английского:

2 Режим сжатия ресурсов

Когда используешьresource shrinkingПри следующих атрибутах указываются некоторые характеристики сжатия ресурсов.

Чтобы использовать сжатие ресурсов, пожалуйста, build.gradle файл shrinkResources Приписывать true ，( minifyEnabled Атрибут сокращает код):

Подходящее: , Укажите, использовать ли безопасный режим или строгий режим при сборке. В безопасном режиме резервируются все ресурсы, на которые имеются прямые ссылки, и ресурсы, которые могут использоваться динамически, такие какResources.getIdentifier()Ресурс, вызываемый методом. Строгий режим сохраняет только ресурсы с прямой ссылкой.

Режим безопасности по умолчанию shrinkMode=»safe» , Если вы хотите использовать строгий режим, вы можете использовать следующий код:

Если включен строгий режим, вы можете настроить ресурсы для сохранения. Если вы хотите сохранить или отменить определенные ресурсы, создайте файл XML, содержащий тег в вашем проекте, и укажите каждый из них в инструментах: атрибут keep Ресурсы, которые должны быть зарезервированы, укажите каждый ресурс, который нужно удалить, в атрибуте tools: discard. Оба эти атрибута принимают разделенный запятыми список имен ресурсов. Вы можете использовать символ звездочки в качестве подстановочного знака. Например:

Сохраните файл в ресурсах проекта, например, в res / raw / keep.xml. Сборка не упаковывает файл в APK.
Для получения дополнительной информации, пожалуйста, смотрите:Shrink your resources。

Подходящее: метка. Этот атрибут может резервировать определенные ресурсы, такие какResources.getIdentifier()) Динамически используемые ресурсы. Использование может быть создано res/raw/keep.xml Содержание файла выглядит следующим образом:

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

3 Просмотр свойств макета редактора времени разработки

• инструменты: заменить андроид:

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

Android studio2.2 добавил этот атрибут, чтобы указать тип макета тега слияния, например:

Только корневой вид может использовать этот атрибут. Он определяет, с каким действием текущий макет связан с текущим макетом по умолчанию, так что макет может получить некоторую информацию об этом действии, такую ​​как тема, используемая действием, и т. Д., А также при использовании быстрого исправления (сочетание клавиш на компьютере Mac + enter) При добавлении события onClick в дочерний View соответствующий код метода будет вставлен в Activity.

Только RecyclerView может использовать это свойство. Моя версия Android Studio 3.0.1, количество отображаемых RecyclerView по умолчанию в редакторе макетов равно 10. Этот атрибут может изменить количество отображений RecyclerView.

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

• tools:listitem / tools:listheader / tools:listfooter

Только AdapterView может использовать это свойство, которое определяет расположение элементов, верхний и нижний колонтитулы списка, но также можно использовать свойство tools: listitem RecyclerView:

Применимый объект: быть Любой корневой вид ссылается:

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

Окно предварительного просмотра очень умное. Если макет связан с действием (заданным с помощью tools: context), он автоматически запросит метод onCreateOptionsMenu этого действия, чтобы отобразить меню, и свойство tools: menu может переопределить это поведение по умолчанию.

Значением атрибута является идентификатор меню, и их может быть больше 1. Различные идентификаторы меню разделяются запятыми.

Следует отметить, что когда тема является Theme.AppCompat, это свойство не работает.

Укажите режим отображения панели действий, его значение может быть: 1. стандартное, 2. вкладки, 3. список

Точно так же, когда тема — Theme.AppCompat (r21 +, как минимум) или Theme.Material, или макет включает в себя панель инструментов. Этот атрибут тоже не работает, работает только голографическая тема.ссылка

• tools:minValue / tools:maxValue

Подходящее: NumberPicker , Предварительный просмотр максимальных и минимальных значений NumberPicker, но не вступать в силу. MaxValue и minValue NumberPicker могут быть установлены только по коду, если вы хотите установить его с помощью xml, вам нужно найти другой способ, здесьссылка, Почему xml из android studio не поддерживает установку этих двух атрибутов? Я не понимаю, пожалуйста, оставьте сообщение, чтобы сообщить мне.

Подходящее: , Позвольте DrawerLayout открыть направление.

Constant	Value	Description
end	800005	Push object to the end of its container, not changing its size.
left	3	Push object to the left of its container, not changing its size.
right	5	Push object to the right of its container, not changing its size.
start	800003	Push object to the beginning of its container, not changing its size.

• «@tools:sample/*» resources

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

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

Attribute value	Description of placeholder data
@tools:sample/full_names	Full names that are randomly generated from the combination of @tools:sample/first_names and @tools:sample/last_names.
@tools:sample/first_names	Common first names.
@tools:sample/last_names	Common last names.
@tools:sample/cities	Names of cities from across the world.
@tools:sample/us_zipcodes	Randomly generated US zipcodes.
@tools:sample/us_phones	Randomly generated phone numbers with the following format: (800) 555-xxxx.
@tools:sample/lorem/random	Placeholder text that is derived from Latin.
@tools:sample/date/day_of_week	Randomized dates and times for the specified format.
@tools:sample/date/ddmmyy	То же, что и выше
@tools:sample/date/mmddyy	То же, что и выше
@tools:sample/date/hhmm	То же, что и выше
@tools:sample/date/hhmmss	То же, что и выше
@tools:sample/avatars	Vector drawables that you can use as profile avatars.
@tools:sample/backgrounds/scenic	Images that you can use as backgrounds.

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

Вот два примера.

Например, следующий код определяет RecyclerView, его tools:listitem=»@layout/item_part1″ ：

Источник

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

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

Источник