Success Criterion 4.1.3 - Status Messages - Level AA

[JJdeGroot]

WCAG2ICT guidance: https://www.w3.org/TR/wcag2ict-22/#status-messages

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

[carolinacrespo]

I think this one need a note about timing adjustable 2.2.1 for toast messages as well. Here a bit old post but I think has good points: https://adrianroselli.com/2020/01/defining-toast-messages.html

[JJdeGroot]

Discussed in today’s meeting.

30 October 2024

Source

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](https://github.com/w3c/matf/issues/61)

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

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

[JJdeGroot]

Discussed in today’s meeting.

6 November 2024

Source

JJ mentioning that use of the term "markup" is problematic for mobile

JJ reading through comments

Joe_Humbert for the note about toast/snackbar - this seems very specific and terms might change, subject to Google or other platforms

<quintinb> +1 - probably should call them "UI-based notifications"

<Joe_Humbert> good suggestion quintinb

<dotjay> Joe has a good point. It’s probably better to use WAI Aria APG design pattern terminology – although totally acknowledge that these don’t all map neatly to native mobile

julianmka I think that we need to talk about iOS - we should describe the general behaviour, the problem is that they're always at the bottom, self-dismissing, etc

<quintinb> +1 julianmka - magnifier magnifier magnifier

Yeah we should mention or link to "time to take action" - although that is Android only

<dotjay> I use “snackbars” and “in-app notifications” interchangably

JJ I noticed that when going through WCAG3 I found it interesting that when things are too generic, it's difficult to follow

<Joe_Humbert> +1 to generic term , but give current examples somewhere

normative vs informative?

JJ we are trying to focus on normative for now

JJ we don't want to end up with too many notes distracting and balance is key

dotjayit's a good idea to be generic in terms of UI patterns. Glossaries can be helpful in this context. Probably smart idea to specify a group of standard phrases to describe things in a cross platform manner.

JJ can we delete the first sentence of NOTE 1, since mobile is not markup

Jamie can we use "since it's not implemented using m/u..."

<Joe_Humbert> the shorter, the better

<quintinb> +1 Joe_Humbert - probably should remove references to markup - regardless of presentation + structure, it should work as such...

or we could just publish a new book on 4.1.3 Note 1...

Joe_Humbert should we consider other elements such as PDF's in this context?

JJ we should focus on native right now

JJ PDF would use WCAG2PDF and web WCAG2Web etc

<JJ> ack \

Could we not just remove the reference to markup languages for mobile?

<dotjay> quintinb: +1

<dotjay> I do feel it’s important to be clear around use of web terminology. Indeed, I know accessibillity consultants that use references to web technology like markup languages to be the reason that an SC should not be applied.

<dotjay> While this guidance likely needs to reflect WCAG, there are SCs that need to be specifically interpreted for mobile.

JJ the mobile guidance would be more compact, so maybe we can remove the reference, but we need to be careful as to why WCAG2ICT didn't remove the guidance

<julianmka> +1 dotjay

<dotjay> We should be able to deviate from guidance that’s been designed to apply to “software” in general

<Jamie> A glossary term or something somewhere about "markup languages" could be helpful for non-technical readers

Joe_Humbert maybe there needs to be a higher level statement about removing markup languages with a set of reasons why - there may be a greater pattern here

<Joe_Humbert> quintinb has valid points about consumers of this Group Note

Comment: It would be nice to reach devs, but they are not the primary audience for this type of documentation

ACTION: Propose text for 4.1.3 and shortened note on Github

ACTION: Propose text for 4.1.3 and shortened note on Github

[JJdeGroot]

This SC is ready for drafting, but was not labeled as such, therefore it was not considered in today's meeting.