Feature request: Add accessibility labels to views.

Please, provide the details below:

The App we're developing must be made accessible for our visually impaired users.
For that we'd like to have support for the relevant properties on Views on both iOS and Android.

For starters we need to be able to define the accessibilityLabel on a View, for iOS' VoiceOver and Android's TalkBack to read.

Tell us about the problem

{N}'s ui/core/view have the property automationText, which maps to:

on iOS: UIAccessibilityIdentification.accessibilityIdentifier
on Android: android:contentDescription

As I see it the properties used on the two platforms doesn't provide the same functionality:

UIAccessibilityIdentification on iOS is as I understand it used for UI Automation script, not for VoiceOver
contentDescription on Android is used primarily for accessibility for views that doesn't have a textual representation, so TalkBack can tell the user what view is.

automationText is just mentioned with explanation in the API docs, so we wrongly guessed this was the property we could use, since it does what we need on Android. It doesn't on iOS.

So we suggest adding a property accessibilityLabel for the View-class, which would map:

on iOS: accessibilityLabel
on Android: android:contentDescription

We'd like to help implement support for accessibility in {N}, if you're interested in adding it upstream.

I know the labels are only part of what will be needed, but it'll be good place to start.
Things are like accessibility-events/notifications can come later.

Are you interested in us contributing this and do you have any suggestions?

@m-abs

HI @m-abs ,

Thank you for your feature request,

We would be glad if you could contribute this functionality for NativeScript. In regard to that, our team has one suggestion about this feature. You could change the existing property for iOS to be able to set asccessiblityIdentifier and accessibilityLabel instead to have two manual properties that set one native property.

Regards

@tsonevn

Hi @tsonevn,

Thank you for the quick response.

As I understand it asccessiblityIdentifier and accessibilityLabel serves different purposes on iOS.

From their documentation:
asccessiblityIdentifier:

An identifier can be used to uniquely identify an element in the scripts you write using the UI Automation interfaces. Using an identifier allows you to avoid inappropriately setting or accessing an element’s accessibility label.

accessibilityLabel:

If you implement a custom control or view or if you display a custom icon on a UIKit control, set this property to make sure your accessibility elements have appropriate labels. If an accessibility element does not display a descriptive label, set this property to supply a short, localized label that succinctly identifies the element. For example, a “Play music” button might display an icon that shows sighted users what it does. To be accessible, however, the button should have the accessibility label “Play” or “Play music” so that an assistive application can provide this information to users with disabilities. Note, however, that the label should never include the control type (such as “button”) because this information is contained in the traits associated with the accessibility element.

I might be missing something here :)
Could you elaborate on why setting the same value to both properties on iOS is the way to go?

@tsonevn

Hi @tsonevn,

I've been thinking about this.

There's far more to accessibility than just setting some labels and there are some pretty big differences between how Android and iOS does it.

iOS have several accessibility properties on their views.

accessibilityLabel -- For short names of the element
accessibilityHint -- For longer descriptions than the label.
accessibilityValue -- For the value an input element, like a slider.
accessibilityTraits -- For the characteristics of the element, if it's a button, image etc.

Android

android:contentDescription - For label on ImageButton, ImageView, CheckBox and other user interface controls
android:hint-- For input elements like TextEdit and should

(And this is just about labeling the elements for the screen reader)

android:contentDescription is more like accessibilityHint than it's like accessibilityLabel, so should which should I use on iOS?
So how do I best generalize this?

@m-abs

Hi @m-abs,

We are aware of these differences that is why we did only automationText. There is no way to change the android implementation that is why @tsonevn suggested to change the current implementation to set both properties on ios. Adding new property will probably confuse people - they might think that setting both is good practise but in the end on android we will set only contentDescriptor and this will generate more support.

Do you think setting both properties for ios will be a problem?

@hshristov

Hi @hshristov,

Do you think setting both properties for ios will be a problem?

The only problem I see it that the two properties on iOS serves different purposes, but I don't see another way around it.

I'll try it later to see how the our app behaves when both properties are set as suggested and make a PR afterwards.

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

Navigation Menu

Repository navigation

Feature request: Add accessibility labels to views. #2621

Please, provide the details below:

Tell us about the problem

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Feature request: Add accessibility labels to views. #2621

Description

Please, provide the details below:

Tell us about the problem

Activity

tsonevn commented on Aug 24, 2016

m-abs commented on Aug 25, 2016

m-abs commented on Aug 31, 2016

hshristov commented on Sep 1, 2016

m-abs commented on Sep 1, 2016

lock commented on Aug 29, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions