– DRAFT –
MATF 30 October 2024

4.1.2 Name, Role, Value

JJ: Recapped discussion to date in the issue for 4.1.2: w3c/matf#48

<JJ> Keyboard interface definition: w3c/matf#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?)

4.1.3 Status Messages

Jamie: Content of the custom action needs to make sense, what SC does that fall into?

JJ: Reviews SC original language and WCAG2ICT additions.

JJ: Same issue as for other SCs, apps are not written in markup languages.

Jamie: Android can include a spinner inside of a button. When someone activates the button, a spinner displays and then the label might change -- e.g. "Download" becomes "Downloading." That change (and loading indicator) is important to let AT users know. Does this fall into this SC?

JJ: For interactive elements that can change state, developers can change the name, or even transform the button into something else.

julianmka: This could be a time to fall back on semantics and use `value` since SRs automatically announce changes to it unlike `label`

<Karla> I think is better to add a status message in that case, to announce "Downloading" for example

<JJ> close the queue

julianmka: We have to handle toast components, in this SC or another.

JJ: Also need to mention users' expectations for toast/snackbar components.

<JJ> JJ: Continue discussion on Github: w3c/matf#61

ACTION: Add note about Toast/Snackbar/etc in 4.1.3