Confirmation of Action: (ariaNotify) general feedback for consideration

@aleventhal

The following is re-posted with permission from @aleventhal:

I had some thoughts about ariaNotify based on my previous experience in helping to create the properties used by ARIA live regions.

Importance: first, the ARIA WG did not want to use an "important" indicator, because it was felt that developers would not know when to use it (or importantly not use it), e.g. developers would always feel that their content was important. We wanted to have something that was more descriptive of what would happen, and ended up on polite/assertive. I'm not saying that we got consistent implementation of polite/assertive in ATs, however.
I think that what we actually wanted was to:
- indicate whether the message should interrupt other messages and be fired immediately, or whether it should wait until other messages have completed. A third type, which I think may actually be most common, would be to fold the message into the stream at the point right after an action occurred, not interrupting anything.
  - Another thing about the "fold into speech stream" that may be interesting food for thought. At one point (may still be true), Firefox computed an attribute that it exposed when an a11y tree changed, and the change was from a user input event. The idea was that if something could be spoken as part of the stream that occurs when you perform an input, that it's much less jarring (as opposed to random stuff changing based on a timer). Example: the user navigates in a tree view, and another pane updates a help topic. The screen reader could have a heuristic that decides whether to read part of the new help topic after it reads the new tree view item. Because it's part of what you did, I thought it would be helpful to hear it. The user can always interrupt it with the next input event. The opposite might be changes that occur randomly, e.g. from a timer, or say in a collaborative interface where another user changed something.
- indicate whether the message itself can be interrupted. Some messages are so critical, that if the user does not hear the message, they might miss something absolutely vital. This could obviously be abused, so some thought needs to go into it.
  I had some more thoughts here, but it didn't have the idea of "fold into the speech stream" order.
Earcons. I wonder if it makes sense to try to come up with a semantic list of earcons and let the AT interpret them, and optionally present them with the message, e.g. "bad-entry" might sounds like a bzzt.
The name of the API. I wonder if it makes sense to use "aria" in the name. I kind of like it, but I wonder if others will feel that it's a naming collision.

(Thanks for the feedback @aleventhal!)

I love the idea of being more explicit about the intentions for when and how to interrupt, combine together, etc. rather than relying on a general sense of assertiveness or politeness and leaving the defintion largely up to implementers.

I also love the 'earcons' idea that could help make a set of common notifications consistent across the user's experience from site to site.

On the name: glad you like it. I appreciate the clear associate with aria, a.k.a., the API is intended for assistive technology use cases. If we change the name, I would still like to preserve some connection to accessibility so that authors don't confuse this for some other kind of general purpose notification API.

We should also describe how we imagine the Braille interface to work. One of the big problems with live regions is that Braille is not always supported, and when it is, it's not necessarily helpful. For example, I believe in VoiceOver, the live region message shows on the Braille display temporarily and then disappears. There's no way to get it back after it's gone.

Another useful thing might be to explain good/bad uses of this. E.g. should it be used for error messages during form input?

Just a few bullets from me.

This is a very important and valuable initiative. Power to all elbows.
The semantics of earcons are the most important aspect of the (excellent) earcon suggestion. The specific expressions (beeps, oversized glyphs, braille patterns, whatever) should be regarded as something we expect end users to tweak. The term 'Earcon' is already somewhat 'wrong' because it suggests audio-only.
API hints for interruptability, including the 'third type' are needed
If document 'owns' these notifications, might we not need multiple queues? (e.g. different contexts, different RIAs?).
A mechanism for actively 'clearing the queue' is needed, since out-dated announcements can sometimes be more misleading or confusing than no announcement at all. How might we control what gets cleared?
Some explicit consideration of <iframe> and nested content using <object> or <SVG> (possibly from third parties) needed.
Some explicit consideration of (ARIA) application/document roles needed.
Might it be useful to piggyback on existing events such as loaded?
Single page app rerouting requires a limited set of notifications which currently don't work reliably. This use case is part of the same problem and might be part of the same solution. "The new rendering is done, and we've just focused its H1" is common enough to be a standard, I think.
Browsing a collection of data looking for spikes, peaks, outliers or anomalies is an unsolved problem (although Apple are bringing some audio-based solutions to market already). This might be another kind of notification.

@aleventhal

From the proposal's "Considerations & Open Issues" section:

What about supporting non-textual cues? We think other platform capabilities (like <audio>.play()) can be used to handle non-textual output, and that non-textual based messages don't need to be handled by this API.

This doesn't seem like a viable option given the concerns about fingerprinting. If authors are intentionally prevented from learning if/how this information is being consumed, then they can't be expected to integrate it with other platform features.

The considerations behind media playback (e.g. resource loading and decoding capabilities) would tend to complicate this proposal in a way that doesn't seem justified, yet. @brennanyoung's thoughts on semantic icons, above, make so-called "earcons" seem like a more tractable answer. (Thanks also for the reminder about the inaccuracy of that term.)

the ARIA WG did not want to use an "important" indicator, because it was felt that developers would not know when to use it (or importantly not use it), e.g. developers would always feel that their content was important. We wanted to have something that was more descriptive of what would happen, and ended up on polite/assertive.

@aleventhal Do you think this could be mitigated through word choice? To me, the term "priority" seems substantially more likely to communicate the presence of trade-offs.

Reusing the values of the aria-live content attribute value may be an opportunity to improve coherence with the existing platform, both in terms of API and expected behavior:

-document.ariaNotify( "Text bolded", { priority: "important" } );
+document.ariaNotify( "Text bolded", { priority: "assertive" } );
+document.ariaNotify( "Text bolded", { priority: "polite" } );

If a richer priority gradient is warranted, then we could still tie in to that convention with enum values:

document.ariaNotify( "Text bolded", { priority: 8 } );
document.ariaNotify( "Text bolded", { priority: document.ariaNotify.ASSERTIVE } ); // initialized to `1`
document.ariaNotify( "Text bolded", { priority: document.ariaNotify.POLITE } ); // initialized to `2`

@zcorpan

Elsewhere, @zcorpan pointed out how enums are generally discouraged in web API design these days. If the priority and the existing content attribute really are correlated, and if there really is a need for a large gradient of priorities, then another way to "bridge the gap" would be to accept a mixed type: either a number OR "assertive" OR "polite". The downside is that authors couldn't intuit how the string values related to numeric ones.

@jugglinmike

@jugglinmike I think we should mitigate the problems with importance, and lack of functionality with polite/assertive, by having some of the options described at the top of this issue:

These are just ideas of what the author could provide:

Can the message interrupt other messages?
Can the message be easily interrupted (perhaps if an AT user specifically hits the stop speech it obeys, but merely typing or navigating won't stop it).
Is the message "in the flow" and slipped in as if part of the previous action.

Maybe we could talk about it on a call sometime.

This came up in the following code-review (https://chromium-review.googlesource.com/c/chromium/src/+/3453306):

What should we do for nodes that are not connected to the main document (generally these won't have a representation in the accessibility tree). Simplest example is document.createElement('div').ariaNotify()

Navigation Menu

Repository navigation

Confirmation of Action: (ariaNotify) general feedback for consideration #187

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

📋 Server Request & Proxy Logs

⚙️ Pengaturan Proxy Target

Confirmation of Action: (ariaNotify) general feedback for consideration #187

Description

Activity

travisleithead commented on Feb 11, 2022

aleventhal commented on Feb 11, 2022

medeaoblongata commented on Feb 18, 2022

jugglinmike commented on Feb 22, 2022

jugglinmike commented on Feb 22, 2022

aleventhal commented on Feb 24, 2022

sartang commented on Sep 16, 2022

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions