Clarifying "Accessibility Supported" requirement when Mobile OS AT support is sub-optimal for native non-custom widgets

[jha11y]

Is it the responsibility of a native mobile app developer (iOS or Android) to address any potential shortcomings in the way the built-in Screen reader announces roles, states, names, values, etc. for "standard" components/widgets (standard = pre-built elements provided by Apple or Google that can be implemented with little to no extra coding outside of the required coding for these elements to work properly) to fulfill the "Accessibility Supported" requirement of WCAG 2.1?

An example of a standard widget would be an Android DatePicker (spinner Style with no calendar) (https://developer.android.com/reference/android/widget/DatePicker). it can be implemented with 5 lines of code as show on this web page: https://www.tutlane.com/tutorial/android/android-datepicker-with-examples under the heading "Android DatePicker with Spinner Mode" (spinner mode only example).

As an example of a potential shortcoming, the TalkBack announcement of the standard Android DatePicker "widget" for each day of the week button does not indicate to the user what will happen when this button is pressed, it is simply announced as "[number], Button". Video of this widget with TalkBack and no customization at http://a11yeval.com/videos/Android_standard_spinner_style_date_picker.mp4. This potential shortcoming could be addressed using a widely available and supported accessibility attribute (android:contentDescription) but doing so would require a developer to create a completely custom implementation of the DatePicker widget because the individual buttons are not directly exposed in the code with the "standard" implementation.

While it can be disputed as to whether the above described "issue" is an actual shortcoming and how WCAG 2.1 applies to Mobile, I'm posing this as a more general higher level question about the requirements for native mobile app developers to meet the definition of "Accessibility Supported" if the information provided by the built-in AT fails to meet WCAG requirements on non-customized "standard" widgets. A potential sticking point is the difference between native mobile app and "desktop" AT availability.

On desktops, multiple assistive technologies may be available and if support with one is sub-optimal, users could choose to use a different assistive technology. Whereas on Mobile, there is often only one AT available (e.g., screen readers).

This is my first time asking a question like this in this forum, so I am happy to try and clarify anything. (edited multiple time for grammar and clarity).

[mraccess77]

Just some additional thoughts... In general I find that Talkback will not announce roles except for certain specific classes. Trying to add roles is not easy and requires a hack unless you use a standard class like button. TalkBack will announce something like "double tap to activate" which does let the user know something is interactive. A solution that add the word "button" to the contentDescription is not a preferred solution -- so folks are left with limited options to meet the requirements.

[patrickhlauke]

dumping in here the general off-the-cuff musings i had on the topic...

ok. i think that standard datepicker has quite some issues (beyond the buttons that don't give arguably enough context, so candidate for 3.2.2 Labels or Instructions failure - as they have an accessible name, not a 4.1.2 fail as that doesn't mandate any kind of 'understandable/appropriate' name, just that the controls need to HAVE a name - the actual fields in the middle seem to completely lack an accessible name, since they just announce the current value + "edit box".
now, my gut interpretation here would be: yes, the fault is ultimately with Google here for not making their standard component accessible enough. but as a dev, you're reliant on this. you're using something that isn't "accessibility supported"
so from the actual point of view of the user trying to use the app, you might not be able to understand what those controls are/what they do. the fact that the blame is with Google is possibly irrelevant.
so a fail, i'd say. and sure, in the writeup, and can be explained to the devs that yes, the fault is ultimately with google here, but right here right now, the use of this widget as is makes the app fail under these aspects

so the devs either have to live with the fails, and if pulled up about it they can then explain (to the lawyers) that it's not actually their fault but google's
or they can build a custom set of controls, which of course is a pain, but gives them control
now, IF this were web content, and the problem only manifested in a particular browser or AT combo, yes there'd be more grounds to say this is actually a pass, and noting as best practice that "but watch out this fails in that particular browser/AT combo, but because it works in all others that are readily available, it's a bug in that browser/AT, so it's 'accessibility supported'"
but as here for native, there is no "user agent" as such, and there's only one single AT that is available to users, it's arguably NOT accessibility supported

and adapting https://www.w3.org/TR/WCAG21/#dfn-accessibility-supported a bit
"The way that the [native] technology is used must be supported by users' [one and only] assistive technology (AT) [available on that native platform]"
again, this is coloured in my mind more by the fact that on mobile native, users don't have much choice
when it comes to AT. so the slightly more vague "The technology is supported natively in widely-distributed user agents that are also accessibility supported" (that lets you defend if something borks in one particular browser/AT for web content on desktop by saying "well it works everywhere else, that's clearly a bug with Chrome" or something) doesn't really stick for native

of course, this is a two-pronged approach type problem. right here and now, users need to be given things that actually work for them/are "accessibility supported". at same time, browser (for web stuff) and AT companies need to be told to fix their stuff

[guyhickling]

As Patrick says, it is not "accessibility supported" (as required by the WCAG), so fails. If I'm auditing an iOS or Android app, I fail components that fail the WCAG's SCs without concerning myself how or why they fail. The only difference, for me, from a website is that when a website fails the audit I then give the developers detailed solutions on how to fix it, but I can't do that on mobile apps as I am not an iOS or Android developer. But if it fails the WCAG there's no argument about it, it's failed, and the developers must fix it in whatever way they can if they want to achieve compliance. Compliance can't be achieved by blaming it on Google!

[jha11y]

So, for example on iOS, if a developer has added custom actions following the accessibility documentation (e.g., Delete) and the actions can be used by VoiceOver users, but VoiceOver doesn't announce each interactive element (in a "list") that has these custom actions, instead when a VoiceOver user reaches the beginning or end of the "list" of interactive elements VoiceOver simply announces "Actions available", it is the developers' responsibility to fix the poor VoiceOver announcement? The above description is how VO announces custom actions based on how Apple coded VO to announce them.

Another Android example is the "Bottom Navigation". This is native component (https://developer.android.com/reference/com/google/android/material/bottomnavigation/BottomNavigationView). It is similar to the "bottom of screen navigation tabs" on iOS. However, TalkBack simply announces each "Tab" as the visible text present underneath its icon (e.g., Home) with no indication no how it may relate to the other "Tabs". Is it the developers' responsibility to either add a custom accessible or implement a custom version of this standard component to pass the 1.3.1 A and/or 4.1.2 A SC?

I guess I'm just trying to understand a developers responsibility if the short coming is with the OS AT and not their coded in regard to "Accessibility Supported".

[jha11y]

IMO, if meeting WCAG is going to force developers to fix AT shortcomings, Mobile AT users are most likely going to get a huge variety in the way they receive information and interact with common components and widgets that should work the same way and announce the same information. This will be extremely confusing when content does not work the same way across diverse applications.

[alastc]

Hi @jha11y,

I guess I'm just trying to understand a developers responsibility if the short coming is with the OS AT and not their coded in regard to "Accessibility Supported".

Technically WCAG is not aimed at native apps at all, but some areas / jurisdictions try to apply it to native platforms, so we won't close this as "not-applicable".

We have various stakeholders for WCAG, including:

• End-users (beneficiaries);
• "Authors", the web site 'owners' / designers / developers (the target audiences).
• Other standards/frameworks (like HTML, ARIA, iOS/Android accessibility SDKs etc).
• User-agent providers (Firefox + NVDA, Safari + VoiceOver, Browsers with pluggins etc.).

The requirements in WCAG are aimed at the authors, but obviously there is a reliance on platforms, user-agents and other specs to make that possible.

Where there is little support outside the web platform for certain features (e.g. text-spacing) they are scoped to things like "Markup languages".

Criteria like Info & Relationships and Name/role/value are more dependent on what is available on the platform, which brings me to:

if the information provided by the built-in AT fails to meet WCAG requirements on non-customized "standard" widgets.

I can see a couple of levels to this:

1. The core platform: does it provide the appropriate accessibility attributes for a particular component? E.g. Can make something a button (role) and give it a name?
2. The default components: Do the default components work effectively? They help to set the expectations of users.

If the core system doesn't provide the appropriate attributes for something (e.g. no concept of slider when you want to use a slider), then that is an overall limit of the accessibility of the platform. You either have to take a step back and choose another direction (e.g. use a text input), or point users towards another version of the service (e.g. the website).

If the default components are not really good enough then implementing an accessible version is probably a task you need to take on (or avoid by doing something else).

Personally, I'd probably look at passing the strict requirements of 1.3.1/4.1.2 and the most effective way to label it. The labeling is more subjective, and if the default components don't help then you are on your own for that, go with the simplest thing you can.

The other aspect is to make noise, e.g. creating bugs for the platform providers on their default components and/or accessibility guidance materials. If lots of developers get annoyed at plastering over basic accessibility issues they might work on it...

[jha11y]

@alastc Those are very good points. As I said in my initial post. I don't want to turn this into a discussion of IF or HOW WCAG 2.1 applies to native mobile. I'm approaching this with the view that WCAG 2.1 does apply to the extent possible. I want to answer some of the level questions you posed:

1. The core platform: does it provide the appropriate accessibility attributes for a particular component? E.g. Can make something a button (role) and give it a name?

   Answer: Technically, on both Android and iOS many components can use OS-level accessibility attributes/properties to provide an accessible name and (on iOS at least) role information. For some components, an accessible role (particularly on Android) could be provided if a developer were to create a custom instance of the component and change the sub components used to create the larger component.

2. The default components: Do the default components work effectively? They help to set the expectations of users.

   Answer: Some do, but many with no customization do not adequately convey the appropriate roles and states.

with those answers, if a non-customized component does not work effectively and/or cannot provide the appropriate role/state/name without customization and one-off tweaks, would those components still fail the appropriate WCAG SC (e.g., 1.3.1, 4.1.2, etc.)?

If I am beating a dead horse, just let me know.

[patrickhlauke]

i sense that there's still a perception here of "it's not the author/developer's fault, so why should I fail it and penalize them". the SCs assess whether or not a particular outcome is met. if it can't be met because of limitations of the platform, it still fails. that's not a bad mark against an author/developer, and certainly the "but the platform itself doesn't let you do it properly" argument can be added/documented (e.g. in a VPAT based ACR). but if something fundamentally fails the intention/ask of the SC, it needs to be failed i'd say.

again, this is often less of an issue on platforms where there's a choice of different ATs and user agents, where an argument can be made that it's a bug/shortcoming in one of these, and that users can still switch to another UA or AT (though in an audit report it would ideally be noted that a particular approach is currently not working in a particular UA/AT and that ideally, if the site deems that particular UA/AT combo as common among their audience, they should really use a different approach). there, it would then be a pass rather than a fail.

[jha11y]

i sense that there's still a perception here of "it's not the author/developer's fault, so why should I fail it and penalize them"

It is not a perception, but the core of my question. I'm not trying to make the assumption either way, but rather asking which way is correct.

I accept that a WCAG failure is a failure regardless of who is to blame, if that is the consensus.

From a legal risk perspective, a failure (due to "platform/AT inadequacy") could cause lots of headaches for developers/companies with limited resources. It could also hurt efforts to fix other accessibility failures.

[alastc]

if a non-customized component does not work effectively and/or cannot provide the appropriate role/state/name without customization and one-off tweaks, would those components still fail the appropriate WCAG SC (e.g., 1.3.1, 4.1.2, etc.)

I think that answers itself: yes.

That isn't to say that a widget on native must provide the same thing as a widget on web (or vice versa), and there is some grey area around what is "appropriate" for any particular component. But in principle the answer should be yes.

It may cause headaches, it may also drive some change if enough devs complain to the platforms or have to use alternatives.

Whether it hurts efforts to fix other accessibility issues will be down to the priorities and experience of the people making decisions, it shouldn't.

Both Patrick and I are speaking as group members, I suspect the whole group would agree but can't guarantee that. I can put this to the group if you like? I.e. I would ask if our discussion represents the group's view.
I'm afraid it might be a while, we've a lot of 2.2 (and 2.1/2.0) issues to resolve!

[mraccess77]

One specific question I'd like to know is for Android controls that are actionable since there is no way to add a role without hacking classes or stuffing the role in the contentDescription is the phrase "double tap to activate" enough information to communicate the role is actionable. I'd say that the phrase is there because the AT knows in a way that is programmatically available that the element is actionable and thus that phrase would indicate it passes.

[jha11y]

is the phrase "double tap to activate" enough information to communicate the role is actionable

On Android, this is an accessibility "usage hint" that can be turned off in user settings.

IMO, I would not equate this to a programmatic "role". It only indicates something is interactive, not how to interact with this based on its role

[jha11y]

@alastc, @patrickhlauke et al,

I think you have answered my question. I appreciate the discourse and I will take it as is without requiring feedback from the entire group :-)

[mraccess77]

I believe the "double tap" message is tied to the property of "isClickable" which does indicate that it's actionable and tends to communicate how to interactive with it "by double tapping" with Talkback or by being "clicked". Switch control would also move to these elements which indicates they are actionable. For buttons what other information is needed to communicate how to interact with a button?

[jha11y]

@mraccess77 that it why I specifically said (IMO) :-) I agree that the usage hint, does communicate the action needed for a button and potentially other similar elements. I do not think that particular usage hint works for other components (e.g. a slider) or interactive elements that require more than just a "double tap"

[guyhickling]

do not think that particular usage hint works for other components (e.g. a slider)

Presumably most shortcomings in announcing components and how they work can be covered on Android by adding hidden text for TalkBack to announce? Of course that doesn't help if the component itself is unusable in the screen reader!

[mraccess77]

I hesitate recommending adding in words like "button" to the contentDescription (accessible name) as these will need to be translated with possible wrong equivalents and also will show up in braille but likely not reduced to shorter notation. Setting a standard to do such a thing only justifies it's misuse other places as well such as on the web.

[jha11y]

I agree with @mraccess77 about adding "role" information using the accessible name being a inadvisable practice.

I also agree that Google and Apple need to improve the accessibility of standard components as well as provide (as a last resort) attributes or properties to programmatically convey the appropriate accessibility information. I will work to provide bugs reports to both about the current deficiencies.

[peterkorn]

A couple of Android versions ago, AccessibilityNodeInfoCompat added a new call: getRoleDescription(). This is where custom components can add role information. Unfortunately this is a localized string, so it can only be presented to the user and not used in a switch() statement to have differential logic depending upon the role. But this is by far better than appending it to the contentDescription. Also note that coming in Android R is getStateDescription(), so you can again have a user-presentable, localized string of all of the node’s states (and again, you cannot have differential logic based on those states). Sigh. Peter -- Peter Korn | Director, Accessibility | Amazon Lab126 pkorn@amazon.com From: jha11y <notifications@github.com> Reply-To: w3c/wcag <reply@reply.github.com> Date: Monday, March 16, 2020 at 2:22 PM To: w3c/wcag <wcag@noreply.github.com> Cc: Subscribed <subscribed@noreply.github.com> Subject: Re: [w3c/wcag] Clarifying "Accessibility Supported" requirement when Mobile OS AT support is sub-optimal for native non-custom widgets (#1070) I agree with @mraccess77<https://github.com/mraccess77> about adding "role" information using the accessible name being a inadvisable practice. I also agree that Google and Apple need to improve the accessibility of standard components as well as provide (as a last resort) attributes or properties to programmatically convey the appropriate accessibility information. I will work to provide bugs reports to both about the current deficiencies. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#1070 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AA4HEQIM3HXLFDYLCMFKL5TRH2J6JANCNFSM4LBKEY3A>.