Alert Dialog Example: Is disappearing toaster alert WCAG compliant?

[brooksienoodlesoup]

I just checked out the Alert Dialog example that is up for review by the working group. I love it! Glad to have clarity in the implementation details via the working demo. However, I'm disappointed that this demo has a built-in alert example that operates as a toast message that shows the word "Saved" in the upper-right portion of the screen, which disappears a few seconds after it first appears. In my understanding of WCAG 2.0/2.1, allowing an alert message to disappear without the user affirmatively dismissing the message violates SC 2.2.1 Timing Adjustable - Level A.

Would it be possible to use an example where the alert is persistent? Many thanks for the work on this!

Brooks Newton

[mcking65]

@brooksienoodlesoup, thank you for this feedback. We do have a persistent alert example.

However, I think your concern with the disappearing alert on the alert dialog example page should be discussed by the task force.

[geraldfullam]

I noticed this discrepancy also. It seems that WCAG 2.2.1 is applicable to toast messages, though it is not explicitly indicated; only strongly implied. Does this mean that ephemeral messages are exempt from 2.2.1 under the "Real-time Exception" clause?

The time limit is a required part of a real-time event (for example, an auction), and no alternative to the time limit is possible

Considering that a website or application may not offer user settings that allow one to "turn off" or "adjust" toast message timing before encountering it, 2.2.1 would have these messages displayed for a minimum of 20 seconds by default with the opportunity to "extend" unless one of the exceptions applies.

What is the guidance or exception for these kinds of messages?

[a11ydoer]

This will be discussed at ARIA-APG meeting on 5/21/2019 Reference: https://www.w3.org/WAI/WCAG21/quickref/?versions=2.0&showtechniques=221#timing-adjustable

[mbgower]

My two bits on this. First, the Saved confirmation does not apply to 2.2.1. Why? Because there is no user action required. The key point of 2.2.1 is to allow users sufficient time to perform actions and input material. As the material below the SC bullets (which I think is normative) says:

This success criterion helps ensure that users can complete tasks without unexpected changes in content or context that are a result of a time limit.

In this situation, the Saved toaster is merely a confirmation. No action is required (or even possible). Compare this to the Discard button which triggers a persistent dialog. If this dialog suddenly disappeared after 30 seconds, that would be a violation because the user has a decision point.

Note that the Saved toaster does need to be considered for the new 4.1.3 Status Messages requirement (and with that alert role, it would).

---

Having answered what I think is a pretty clear case of not applying, I will note that there is a real lack of clarity in 2.2.1, and I'd be happy to take this back to the WG for consideration for a future release, if that is desirable.

There are two key points for me. First, if there was any user decision point in the toaster, say an ability to 'remind me later' or 'don't display these in the future', then I think the user should not face a timeout. But there are varying degrees of 'prevention'. If the user never was able to answer those prompts, circumstances would likely need to determine whether that prevented a user from completing a task.

Second, I certainly think that giving users control over all kinds of timed events is an optimal goal, and that includes any timed messages. But that seems to me to be beyond the existing SC.

Looking at this SC again, I think that while the intent of the broad area of coverage is relatively clear from the understanding document, the language in the SC itself is not.

The Understanding document states:

Any process that happens without user initiation after a set time or on a periodic basis is a time limit.

The "after a set time" is of particular note here. But of course the Understanding document is not normative. It is unfortunate that "time limit" is not a defined term. However, I think it is clear from the above quote and from the actual bullets of the success criteria that this is aimed at implementations that restrict users from completing input or a task due to an imposed developer time limit.

So if folks believe any form of timed interaction or messaging needs to allow the user to turn off or adapt the timing, I think that would be a future SC.

[carmacleod]

Thank-you so much, @mbgower !

I'd be happy to take this back to the WG for consideration for a future release, if that is desirable.

Yes, please, that would be great. Thanks again.

@brooksienoodlesoup, @geraldfullam Does @mbgower's reply answer your question? WCAG SC 2.2.1 Timing Adjustable does not apply because there's no interaction, and SC 4.1.3 Status Messages is satisfied because the status message has role="alert". Can we close this issue?

[brooksienoodlesoup]

I think that is a very narrow interpretation of SC 2.2.1. The user task doesn’t require input for SC 2.2.1 to apply. The user task for a toast is getting the message. If you aren’t browsing with AT, role=“alert” does nothing to allow you to get the message. Users with memory impairments may need substantial time to keep the toast onscreen beyond what the page author has arbitrarily determined to get the message. Mike’s response doesn’t satisfy my sense of what SC 2.2.1 requires of non-interactive content.

Brooks

Sent from my iPhone

On May 21, 2019, at 5:45 PM, Carolyn MacLeod notifications@github.com wrote:

Thank-you so much, @mbgower !

I'd be happy to take this back to the WG for consideration for a future release, if that is desirable.

Yes, please, that would be great. Thanks again.

@brooksienoodlesoup, @geraldfullam Does @mbgower's reply answer your question? WCAG SC 2.2.1 Timing Adjustable does not apply because there's no interaction, and SC 4.1.3 Status Messages is satisfied because the status message has role="alert". Can we close this issue?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[a11ydoer]

Alert Dialog Example

To see the discussion point, Choose option to "save" and there is "saved" alert toast on the right top corner.

• HTML line <div role="alert" id="alert_toast" class="toast hidden">Saved</div>
• CSS : .toast {transform: translateY(-150%); transition: transform **225ms** cubic-bezier(0.4, 0, 0.2, 1);}
• Under "To use this example" section, there "A successful save triggers a short alert to notify the user that the notes have been saved."
• WCAG 4.1.3 Status Messages requirement

[a11ydoer]

APG decided to change the design itself. Some of design poitns are

• use aria described to point hidden element off screen.
• add check mark visible to save button
• not use live region for tab/focus issue

[smhigley]

Made an example codepen that shows the loading/saved approach we discussed today: https://codepen.io/smhigley/pen/GRvOevx (also, here's a link to the demo without the codepen UI: https://codepen.io/smhigley/debug/GRvOevx)

[a11ydoer]

@smhigley Sarah, thanks for quick implementation of design change. I am wondering where the role= "alert" is in the example. btw, I love your accessibilty documentation for the example.

[zcorpan]

I did not get to this today unfortunately. cc @richnoah

[smhigley]

@a11ydoer the role="alert" would still be on the error dialog in the APG example, though I didn't put it on the loading/success messages. That generally follows the patterns I've followed -- that status and success messages don't need alert semantics, but errors do. I'd be curious what others think on that, though.

[a11ydoer]

@smhigley I did not mean to adding role="alert" to save button. I was checking for existence of alert role so that APG make sure to demonstrate how to use alert role. In the original alert example, there is role alert so your codepen example is fine. <div role="alert" id="alert_toast" class="toast hidden">Nothing to discard.</div>

Regarding "status" message, here is the definition from WCAG.

A status message is a defined term in WCAG. There are two main criteria that determine whether something meets the definition of a status message:

• the message provides information to the user on the success or results of an action, on the waiting state of an application, on the progress of a process, or on the existence of errors;
• the message is not delivered via a change in context.

Here are other WCAG status examples.

[a11ydoer]

From the revised example by @howard-e, I see

<div class="visually-hidden" id="notes_save_status" role="alert"></div>

PR 2112

[mcking65]

Fixed with 0c74238 via PR #2112.

Thank you @howard-e and @smhigley for your work on this!!