Success Criterion 4.1.2 - Name, Role, Value - Level A

[JJdeGroot]

WCAG2ICT guidance: https://www.w3.org/TR/wcag2ict-22/#name-role-value

Share your thoughts for applying to mobile apps as a comment below.

[jamieherrera]

Conceptually, (as seen in the Notes for WCAG2ICT and Understanding in WCAG) 4.1.2 seems to primarily guide customizations and their interactions with (at least some) AT.
In thinking about a mobile context for 4.1.2, I have two questions I hope the group can decide on:

1. What is the intended coverage for 4.1.2 elements? Ie should it apply to all UI element types? Only input controls? Only interactive components?
   WCAG seems a bit circular in reasoning defining "control" and "UI component". there is a use of "including but not limited to..." which makes it hard to pin down whether non-interactive UI elements apply (such as when VoiceOver doesn't include the word, "image", for informational meaningful images that are not other traits, it's very likely custom, but are images even in scope for 4.1.2?)
2. I'm wondering your thoughts @ALL about explicitly calling out keyboard as an AT for 4.1,2? Full Keyboard access is explicitly an Accessibility feature on iOS though not on Android. One example that is sometimes a 2.1.1 keyboard best practice is when there is focus on a non-interactive item (without screen reader on). It could arguably be a 2.4.3 Focus Order issue, but if it's not "out of order", it seems like unnecessary tab stops are a code issue that likens keyboard to a sort of customization.

[JJdeGroot]

@jamieherrera
For you first point, I have always interpreted it as interactive elements. Meaning that a non-interactive image would not be required to have it's role set to image. But I agree that would be very helpful.

I think one of the major differences between Android/iOS and Web is that web uses alt to set a label for images, while Android/iOS use contentDescription / accessibilityLabel; which are the same properties used for setting a name in 4.1.2.

It might help to make the scope of elements broader, but we have to be careful about introducing any edge cases.

For your second point, I agree it would be good to include hardware keyboard in our updated definition of assistive technology. Double check when working on the definition of keyboard interface

[JJdeGroot]

Discussed in today’s meeting.

23 October 2024

Source

<Joe_Humbert> [w3c/matf#48](https://github.com/w3c/matf/issues/48)

<JJ> Fixed link in agenda

Jamie on 4.1.2 - 2 questions: intended coverage - to all UI element types, and how to call out keyboard as an AT for 4.1.2

Jamie How do we interpret the control aspect?

I would say that all UI components regardless of interaction should be identifiable by AT

JJ I've interpreted this in the context of interactive components - the issues are mostly about custom components

julianmka I think there is a world where this primarily applies to custom components, native components usually work but devs do lack a lot of knowledge in this area (e.g. separation of name and state).

GleidsonRamos I agree about custom components, but not always - in X platform there are additional issues because a lot of the time the components that are "standard" are actually already "custom"

<Jamie> +1 to julianmka that even standard user interface components in mobile do include a higher layer of accessibility knowledge than in web so should be mentioned in this SC

ACTION: Continue discussion next week

[detlevhfischer]

For your second point, I agree it would be good to include hardware keyboard in our updated definition of assistive technology

I think the general assumption both in WCAG2ICT and standards like EN 301 549 is that keyboard (without running any AT) is just another input mode that 2.1.1 requires to be supported by software, incl. mobile apps. That Apple added keyboard support belatedly to be activated as an accessibility setting does not seem to force us to classify it as AT? At least on an iPad with Magic Keyboard, shouldn‘t the assumption be that all UIE are keyboard accessible (tab or arrow keys) and would fail 2.1.1. if they aren‘t? I would not mix this up with 4.1.2.

But maybe I‘m all wrong and we need to align more closely with current mobile development constraints…

[jamieherrera]

@detlevhfischer that's essentially what I'm trying to capture is whether as a group we feel that the use case for a physical keyboard in the native mobile space (especially in the Apple context of FKA as an Accessibility feature) merits a deviation from WCAG, as the physical keyboard (and onscreen keyboard in tablets/ touchscreen laptops) is an extension of the interface itself, whereas a physical keyboard for a mobile phone (and tablets, to some extent) is an accessory tool.

[detlevhfischer]

as the physical keyboard (and onscreen keyboard in tablets/ touchscreen laptops) is an extension of the interface itself, whereas a physical keyboard for a mobile phone (and tablets, to some extent) is an accessory tool.

As far as the AGWG is concerned, the consensus so far (if I read it correctly) has been to de-emphasize the desktop/mobile distinction, in part because of the growing confluence of both.

If we, as a group, choose a deviation, the question remains whether keyboard accessibility would still be a requirement - so that after activating the Keyboard setting on iOS (I think it is reasonable to expect kb users to know and activate that setting), everything is indeed keyboard-accessible (in some way). If that would be the line we take, it seems there wouldn‘t be a big difference to applying WCAG undeviated?

How would we treat keyboard SCs like 2.1.1 and 2.4.3 in a context where we do embark on a deviation? This is not a rhetorical question. In practical terms it could mean that a less stringent implementation of keyboard focus order would be acceptable (some deviations of order? - A wild mix of tab and arrow keys? Or accepting that for reaching some UIE, kb users would need visual feedback to move arrow keys — provided that in a screenreader + touch mode of use, SR focus does reach everything sequentially)?

[JJdeGroot]

Discussed in today’s meeting.

30 October 2024

Source

JJ: Recapped discussion to date in the issue for 4.1.2: [w3c/matf#48](https://github.com/w3c/matf/issues/48)

<JJ> Keyboard interface definition: [w3c/matf#66](https://github.com/w3c/matf/issues/66)

julianmka: Can we split the keyboard question from this SC?

Jamie: We can return to keyboard as an AT after settling this and other SCs

JJ: I see failures of this SC come up frequently in audits. List items not marked as buttons, buttons without names, etc.

Jamie: WCAG2ICT note 2 acknowledges that there are differences between ATs and accessibility support of different platforms. Do we need to clarify that this SC applies only to custom components, or to standard components as well? (Since many standard components require additional modifiers to be accessible.)

JJ: And what about platform quirks like lists in Android where interactive items are often not marked as buttons and only have the "double-tap to activate" hint

Carolina: Since users often turn off hints, I recommend using the explicit role.

Karla: Want to return to Jamie's question on Github -- this SC is only about interactive elements?

JJ: Definition of UI element in WCAG lists interactive elements but there's also "not limited to" language.

Jamie: Would an image with alt text but not marked up as an image fail this SC?

JJ: It would be better for users if elements have roles that are supported by the OS.

JJ: There are platform limitations, but maybe we're making it too complex if we require certain roles.

Jamie: At work, I've run into questions about whether something would fail if it didn't have a programmatically determinable role, even for non-interactive components.

Jamie: We often conflate `interactive` and `UI` components, but there is a distinction.

Jamie: We need to deviate from the idea that standard UI components meet accessibility criteria.

<julianmka> +1 Jamie

<Karla> + Jamie

<JJ> Julian: Developers should correctly use the available accessibility API's such as setting name, role, value in the right places

JJ: Back to the image with alt text but no role: Maybe that would fail under 1.3.1 because there's presentation information that isn't given to a non-sighted user.

JJ: Based on the +1s, it sounds like we should require developers to enhance standard components with the accessibility API if necessary.

Jamie: Perhaps we add a note to 1.3.1 about including images' role in info

Jamie: Maybe a larger convo with the AGWG since it could affect web

JJ: How would we approach this in our documentation? Would we edit Note 1?

<JJ> julianmka: Notes the importance of keeping name and value separate, especially for TalkBack users on Android because they can choose the order that accessibility properties are announced

<JJ> julianmka: Important to honor user preferences, this can be achieved by using correct semantcs

<JJ> Available accessibility API's related to 4.1.2: https://appt.org/en/guidelines/wcag/success-criterion-4-1-2#solution

Jamie: Are there other programmatic things to consider in native apps that go beyond what's described in WCAG?

<JJ> iOS accessibility traits: https://developer.apple.com/documentation/uikit/uiaccessibilitytraits

<JJ> Jetpack Compose (Android) roles: https://developer.android.com/reference/kotlin/androidx/compose/ui/semantics/Role

<JJ> julianmka: Mentions the behavior of accessibility traits on iOS, and where they can go beyond the web

JJ: We can add a note or understanding page about traits/roles in native apps.

<Karla> +1 JJ

<julianmka> +1 JJ

Jamie: In looking at the normative text of 4.1.2, it doesn't seem like there's much difference for native mobile, but more in the Notes.

<julianmka> +1 Jamie

<JJ> +1

<Karla> +1

JJ: Don't need a note about name, but we should add a note about roles and states.

JJ: But what would go in a note vs an Understanding doc?

julianmka: General language clarifying that "role" includes traits in iOS and roles in Android; further info in the Understanding doc

<Carolina> +1

<Jamie> +1

<Karla> +1

<JJ> +1

ACTION: Draft proposed language for a note about roles and states for 4.1.2

Jamie: Note 2 final sentence in WCAG2ICT mentions "list of available actions" which we might need to modify since custom actions are important in native apps.

Jamie: Custom actions are unique to native mobile.

<julianmka> +1

<Karla> +1

<JJ> +1

<Jamie> +1 to possibly adding custom actions

JJ: Our note about roles and states could also call out custom actions

<JJ> julianmka

Julian: Would custom actions fall under 4.1.2 or 1.3.1? I tend to think of it under Info & relationships.

JJ: Both could make sense, but it's important for 4.1.2, thinking of how switch control displays actions differently than screen readers for example.

ACTION: Add note about custom actions to 4.1.2 (and/or 1.3.1?)

• ACTION: Draft proposed language for a note about roles and states for 4.1.2
• ACTION: Add note about custom actions to 4.1.2 (and/or 1.3.1?)

[detlevhfischer]

Having read the article on Android accessibility: Roles and TalkBack by Greame Coleman and raising the issue of conformance assessment in the a11y slack channel > mobile testing, I wonder if our advice can pin down what native elements in iOS / Android come with their baked-in role, whixch ones don't and which ones may be OK without any extra role assigned. The example in Graeme's article is item inside menu and @JJdeGroot commented that it is indeed difficutl to add role information here. Are we going to propose such elements can then be treated as exceptions? Would usage info scuh as "double-tap to activate", present when TalkBack is set to high verbositiy, be sufficient? Are there common custom elements for which no suitable role information can be given? I think it would be good to draw up a list of the most common UIE for both platforms and work out what kind of (missing, incorrect) role information would actually constitute a FAIL and what is acceptable (even if not ideal). Testers in my context currently come up with different conformance results, and better guidance is urgently needed.

This also relates to @jamieherrera's issue above regarding roles of non-interactive elements (such as lists, images). I think this is somewhat easier: I would generally argue that there is a trade-off between suppying role information on these: for example, it may be useful to know that a menu implemented as list has 14 entries, but it also increases the verbosity and may be distracting. So I tend to pass cases where from a usage perspective, I am led to believe that there is no real issue when role info is missing.

[JJdeGroot]

Hi @detlevhfischer I agree such information would be very helpful, and fitting for our group to determine. But, that would probably be an Understanding document, which is not planned in this phase.

For the SC text, I think that we need to consider adding an exception that covers situations such as Android's menu item that does not have a role by default AND can (easily) be set by the author either.

4.1.2 does not have an exception for controls provided by the user agent or platform software.

Note
This success criterion is primarily for web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification.

On Android and iOS, the standard controls do not always meet this success criterion.

WCAG2ICT modifies the Note above:

This success criterion is primarily for software developers who develop or use custom user interface components. Standard user interface components on most accessibility-supported platforms already meet this success criterion when used according to specification.

where "already meet" has been toned down to "most already meet". But what happens to those components that are not part of "most"?

WCAG2ICT adds two more notes:

For conforming to this success criterion, it is usually best practice for software user interfaces to use the accessibility services provided by platform software. These accessibility services enable interoperability between software user interfaces and both assistive technologies and accessibility features of software in standardized ways. Most platform accessibility services go beyond programmatic exposure of name and role, and programmatic setting of states, properties and values (and notification of same), and specify additional information that could be exposed and / or set (for instance, a list of the available actions for a given user interface component, and a means to programmatically execute one of the listed actions).

once again, using "most"

and

For document formats that support interoperability with assistive technology, standard user interface components often meet this success criterion when used according to the general design and accessibility guidance for the document format.

using "often"

I think we should add the exception in the SC text itself. Something like:

4.1.2 Name, Role, Value: For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies; except if the user interface component is provided by the user agent or platform software and the aforementioned properties are not modified by the author.

And then we could add a note with some common cases where default user interface components fail 4.1.2? Later we can build that out in an Understanding doc.

[detlevhfischer]

Role information on product tiles, naming of buttons

I would like to discuss a very common scenario and raise questions regarding necessary role information and necessary labels.
An e-commerce product tile contains various bits of information on one screen reader focus point (In this order, essentially following visual order): (optionally) bonus amounts available when purchasing it; a thumbnail image (not rendered programmatically because it is redundant to the product description below); the price; the product name; a qualifying product description specifying the amount or other attributes like "frozen"; the equivalent price per kilogram. The next focus point is a button placed on top of the tile: "add product to shopping list".

The tile is interactive and goes to a view showing the individual product enlarged and with scant additional information. The tile has no role info like button, despite being interactive. However, when "speak usage hints" under Accessbility > TalkBack > Verbosity is set, the system generates "doubletap to activate".

From a screen reader usability perspective, grouping the product price name and info in one focus point has the advantage that navigating from product to product is speedier than going through the individual elements individually. Information can be accessed individually when navigating by paragraphs.

The question arises whether the lack of role information on the product tile (e.g. role "button") is a problem here that would be a FAIL of 4.1.2 Name, Role, Value (applied to mobile). The next focusable element after the tile is a button with a clear name ("add to shopping list") and the appropriate role, even though the context (what is the product to be added to the shopping list) is only available on the preceding focus point. Disregarding the navigational context, the button may be considered to fail 2.4.6 Headings and labels (applied to mobile). Adding the product name to the button text, however, would make the output a lot more verbose, so there is a trade-off between sufficient label text disregarding navigational context, and usability considering the common navigational context, where each product description is followed by the same generic button.

My personal view is that in this conventional and repetitive context, the lack of role information on the interactive product tile and the lack of specific name on the following action button are not practical problems. If so, it is unclear how to define any exceptions for 4.1.2 and 2.4.6. The normative text does not seem to afford such exceptions.

@JJdeGroot I realize this is unlikely to go into notes at this point and more likely to inform a future understanding text - but I guess it is a pressing question for many people conducting audits of mobile apps.