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?)