[blink-dev] Re: [EXTERNAL] Re: Intent to Prototype: Confirmation of Action API

['Sara Tang' via blink-dev]

Hi all!

Letting everyone know that we are picking up this initiative again :) 
Please find an updated explainer here:  
MSEdgeExplainers/Accessibility/AriaNotify/explainer.md 
at main · MicrosoftEdge/MSEdgeExplainers (github.com) 
.
 
I've already updated the ChromeStatus.

There is also an updated design doc in the works, but still waiting on 
reviews from third parties.

Thanks!
Sara

On Wednesday, June 1, 2022 at 9:23:04 PM UTC-7 David Tseng wrote:

> Thanks for the responses here and sorry for the late reply.
>
> IIUC, this looks mostly like syntactic sugar. The imperitiveness of the 
> api is somewhat of an illusion since this takes the same code path as 
> ordinary live regions and for most platforms and even most clients on 
> Windows, it re-uses the same mechanics of delivering the announcement as a 
> live region.
>
> So, we are basically reduced to the two lines:
> someElement.textContent = 'foo';
>
> vs
>
> document.ariaNotify('foo');
>
> (assuming someElement is a live region).
>
> The key diff is some number of queueing modes to reorder the announcements 
> for the current callstack and the aforementioned syntax cleanup. The other 
> diff is not having to add a DOM element which is somewhat negligible if it 
> is positioned offscreen.
>
> Is that a fair assessment of the difference? If so, could we consider 
> introducing additions to live regions to get the queueing behaviors 
> introduced?
>
> On Fri, Mar 18, 2022 at 1:05 PM Sara Tang  wrote:
>
>> + Cynthia Shelly
>> --
>> *From:* Sara Tang 
>> *Sent:* Wednesday, March 9, 2022 3:32 PM
>> *To:* David Tseng ; blink-dev 
>> *Subject:* Re: [EXTERNAL] Re: Intent to Prototype: Confirmation of 
>> Action API 
>>  
>> Hi David,
>>
>> Responses inline 🙂. I've also linked the design doc if you'd like to 
>> take a further look: 
>> https://docs.google.com/document/d/1pz7KQUgd3zjjH7aTWFTFBEps_GrxXF3pZjaV8H76WjA/edit?usp=sharing
>>
>> Cheers,
>> Sara
>>
>> --
>> *From:* David Tseng 
>> *Sent:* Monday, March 7, 2022 4:44 PM
>> *To:* blink-dev 
>> *Cc:* Sara Tang 
>> *Subject:* [EXTERNAL] Re: Intent to Prototype: Confirmation of Action API 
>>  
>> Hi there,
>>
>> A few additional questions/comments:
>> - this api will be a separate channel from ordinary live regions. If we 
>> mix the two techniques, wouldn't the output be interleave? For example, an 
>> iframe with a live region, and another iframe wherein we call 
>> document.ariaNotify?
>>
>> In the Windows implementation, we are indeed using a different channel 
>> than live regions. However, the final invocation out of Chromium for both 
>> this API and live regions is into UIA, which has its own queuing mechanism. 
>> While it is possible for notifications to interleave, they will never 
>> interrupt each other (unless specifically intended)
>>
>> The plan for other systems is to hook our API into the existing ARIA live 
>> region machinery. It will have a similar outcome as above, where ariaNotify 
>> notifications may interleave with live ARIA region ones, but they won't 
>> interrupt or interfere with each other.
>>
>> - the way Chrome (at least) works is based on the serialization of a tree 
>> structure. This api appears to be a imperitive call, making it seem like 
>> the call gets honored immediately. However, the a11y tree gets pushed only 
>> on layout clean.
>> - what happens if I repeatedly call document.ariaNotify? Would these 
>> announcements queue up? Would they flush tts? Would it trigger a refresh of 
>> the accessibility tree?
>>
>> This is a good point! We mark the a11y tree as dirty whenever 
>> document.ariaNotify is called and store unqueued notifications on 
>> AXTreeData.
>>
>> - live regions have the aria-live polite|assertive properties which 
>> roughly (though not really for all screen readers) map to queue vs flushing 
>> tts. Is there something equivalent for this api?
>>
>> Yes! One of the goals for this API was to have more indicative properties 
>> to describe how notification behave. Currently, we have any combination of 
>> the following two properties (naming tbd):
>>
>>- PlaceInQueue: (front | back | newest-only)
>>   - front: place the notification in the front of the queue
>>   - back: place the notification in the back of the queue
>>   - newest-only: place the notification in the back of the queue, 
>>   but also drop all existing notifications from the same element (good 
>> for 
>>   progress bars, latest status, etc.)
>>- Interrupt: (true | false)
>>   - true: if a notification is currently speaking and shares the 
>>   same source as the one being queued, interrupt it and move to the next 
>>   notification in the queue
>>   - false: let the current notification speak to completion
>>
>> - many screen readers actually suppress live regions (e.g. NVDA) or

[blink-dev] Re: [EXTERNAL] Re: Intent to Prototype: Confirmation of Action API

['David Tseng' via blink-dev]

Thanks for the responses here and sorry for the late reply.

IIUC, this looks mostly like syntactic sugar. The imperitiveness of the api
is somewhat of an illusion since this takes the same code path as ordinary
live regions and for most platforms and even most clients on Windows, it
re-uses the same mechanics of delivering the announcement as a live region.

So, we are basically reduced to the two lines:
someElement.textContent = 'foo';

vs

document.ariaNotify('foo');

(assuming someElement is a live region).

The key diff is some number of queueing modes to reorder the announcements
for the current callstack and the aforementioned syntax cleanup. The other
diff is not having to add a DOM element which is somewhat negligible if it
is positioned offscreen.

Is that a fair assessment of the difference? If so, could we consider
introducing additions to live regions to get the queueing behaviors
introduced?

On Fri, Mar 18, 2022 at 1:05 PM Sara Tang  wrote:

> + Cynthia Shelly
> --
> *From:* Sara Tang 
> *Sent:* Wednesday, March 9, 2022 3:32 PM
> *To:* David Tseng ; blink-dev 
> *Subject:* Re: [EXTERNAL] Re: Intent to Prototype: Confirmation of Action
> API
>
> Hi David,
>
> Responses inline 🙂. I've also linked the design doc if you'd like to
> take a further look:
> https://docs.google.com/document/d/1pz7KQUgd3zjjH7aTWFTFBEps_GrxXF3pZjaV8H76WjA/edit?usp=sharing
>
> Cheers,
> Sara
>
> --
> *From:* David Tseng 
> *Sent:* Monday, March 7, 2022 4:44 PM
> *To:* blink-dev 
> *Cc:* Sara Tang 
> *Subject:* [EXTERNAL] Re: Intent to Prototype: Confirmation of Action API
>
> Hi there,
>
> A few additional questions/comments:
> - this api will be a separate channel from ordinary live regions. If we
> mix the two techniques, wouldn't the output be interleave? For example, an
> iframe with a live region, and another iframe wherein we call
> document.ariaNotify?
>
> In the Windows implementation, we are indeed using a different channel
> than live regions. However, the final invocation out of Chromium for both
> this API and live regions is into UIA, which has its own queuing mechanism.
> While it is possible for notifications to interleave, they will never
> interrupt each other (unless specifically intended)
>
> The plan for other systems is to hook our API into the existing ARIA live
> region machinery. It will have a similar outcome as above, where ariaNotify
> notifications may interleave with live ARIA region ones, but they won't
> interrupt or interfere with each other.
>
> - the way Chrome (at least) works is based on the serialization of a tree
> structure. This api appears to be a imperitive call, making it seem like
> the call gets honored immediately. However, the a11y tree gets pushed only
> on layout clean.
> - what happens if I repeatedly call document.ariaNotify? Would these
> announcements queue up? Would they flush tts? Would it trigger a refresh of
> the accessibility tree?
>
> This is a good point! We mark the a11y tree as dirty whenever
> document.ariaNotify is called and store unqueued notifications on
> AXTreeData.
>
> - live regions have the aria-live polite|assertive properties which
> roughly (though not really for all screen readers) map to queue vs flushing
> tts. Is there something equivalent for this api?
>
> Yes! One of the goals for this API was to have more indicative properties
> to describe how notification behave. Currently, we have any combination of
> the following two properties (naming tbd):
>
>- PlaceInQueue: (front | back | newest-only)
>   - front: place the notification in the front of the queue
>   - back: place the notification in the back of the queue
>   - newest-only: place the notification in the back of the queue, but
>   also drop all existing notifications from the same element (good for
>   progress bars, latest status, etc.)
>- Interrupt: (true | false)
>   - true: if a notification is currently speaking and shares the same
>   source as the one being queued, interrupt it and move to the next
>   notification in the queue
>   - false: let the current notification speak to completion
>
> - many screen readers actually suppress live regions (e.g. NVDA) or give
> users a way to turn them off. This api might reduce the ability for screen
> readers to do this depending on how it gets implemented.
>
> Another good point! I think it makes sense that if live regions are
> suppressed, we would want this API to also be suppressed.
>
> On non-Windows systems, since we will be hooking directly into the
> existing ARIA live regions implementation, we will share the same behavior
> as ARIA live regions (aka. suppress live regions => suppress JS API).
>
> I'm not so sure in the Windows implementation, I'll do more research on
> how live regions are suppressed in screen readers.
>
> - at least via the current proposed change, it looks like notify is trying
> hard to be a direct tts cha

[blink-dev] Re: [EXTERNAL] Re: Intent to Prototype: Confirmation of Action API

['Sara Tang' via blink-dev]

+ Cynthia Shelly

From: Sara Tang 
Sent: Wednesday, March 9, 2022 3:32 PM
To: David Tseng ; blink-dev 
Subject: Re: [EXTERNAL] Re: Intent to Prototype: Confirmation of Action API

Hi David,

Responses inline 🙂. I've also linked the design doc if you'd like to take a 
further look: 
https://docs.google.com/document/d/1pz7KQUgd3zjjH7aTWFTFBEps_GrxXF3pZjaV8H76WjA/edit?usp=sharing

Cheers,
Sara


From: David Tseng 
Sent: Monday, March 7, 2022 4:44 PM
To: blink-dev 
Cc: Sara Tang 
Subject: [EXTERNAL] Re: Intent to Prototype: Confirmation of Action API

Hi there,

A few additional questions/comments:
- this api will be a separate channel from ordinary live regions. If we mix the 
two techniques, wouldn't the output be interleave? For example, an iframe with 
a live region, and another iframe wherein we call document.ariaNotify?

In the Windows implementation, we are indeed using a different channel than 
live regions. However, the final invocation out of Chromium for both this API 
and live regions is into UIA, which has its own queuing mechanism. While it is 
possible for notifications to interleave, they will never interrupt each other 
(unless specifically intended)

The plan for other systems is to hook our API into the existing ARIA live 
region machinery. It will have a similar outcome as above, where ariaNotify 
notifications may interleave with live ARIA region ones, but they won't 
interrupt or interfere with each other.

- the way Chrome (at least) works is based on the serialization of a tree 
structure. This api appears to be a imperitive call, making it seem like the 
call gets honored immediately. However, the a11y tree gets pushed only on 
layout clean.
- what happens if I repeatedly call document.ariaNotify? Would these 
announcements queue up? Would they flush tts? Would it trigger a refresh of the 
accessibility tree?

This is a good point! We mark the a11y tree as dirty whenever 
document.ariaNotify is called and store unqueued notifications on AXTreeData.

- live regions have the aria-live polite|assertive properties which roughly 
(though not really for all screen readers) map to queue vs flushing tts. Is 
there something equivalent for this api?

Yes! One of the goals for this API was to have more indicative properties to 
describe how notification behave. Currently, we have any combination of the 
following two properties (naming tbd):

  *   PlaceInQueue: (front | back | newest-only)
 *   front: place the notification in the front of the queue
 *   back: place the notification in the back of the queue
 *   newest-only: place the notification in the back of the queue, but also 
drop all existing notifications from the same element (good for progress bars, 
latest status, etc.)
  *   Interrupt: (true | false)
 *   true: if a notification is currently speaking and shares the same 
source as the one being queued, interrupt it and move to the next notification 
in the queue
 *   false: let the current notification speak to completion

- many screen readers actually suppress live regions (e.g. NVDA) or give users 
a way to turn them off. This api might reduce the ability for screen readers to 
do this depending on how it gets implemented.

Another good point! I think it makes sense that if live regions are suppressed, 
we would want this API to also be suppressed.

On non-Windows systems, since we will be hooking directly into the existing 
ARIA live regions implementation, we will share the same behavior as ARIA live 
regions (aka. suppress live regions => suppress JS API).

I'm not so sure in the Windows implementation, I'll do more research on how 
live regions are suppressed in screen readers.

- at least via the current proposed change, it looks like notify is trying hard 
to be a direct tts channel to the screen reader. It has very little to do with 
ARIA?

That is correct, but we decided to keep the ARIA-naming because many web 
authors associate accessibility with ARIA. Thus, this naming most succinctly 
expresses the intention of the API.

On Friday, January 28, 2022 at 4:26:36 PM UTC-8 Sara Tang wrote:
Contact emails
sar...@microsoft.com

Explainer
https://github.com/WICG/aom/blob/gh-pages/notification-api.md

Specification


Summary

This effort aims to create a JavaScript API so that developers can better 
notify AT users of actions/changes to a webpage not necessarily tied to UI 
elements.


Blink component
Blink>Accessibility

[blink-dev] Re: [EXTERNAL] Re: Intent to Prototype: Confirmation of Action API

['Sara Tang' via blink-dev]

Hi David,

Responses inline 🙂. I've also linked the design doc if you'd like to take a 
further look: 
https://docs.google.com/document/d/1pz7KQUgd3zjjH7aTWFTFBEps_GrxXF3pZjaV8H76WjA/edit?usp=sharing

Cheers,
Sara


From: David Tseng 
Sent: Monday, March 7, 2022 4:44 PM
To: blink-dev 
Cc: Sara Tang 
Subject: [EXTERNAL] Re: Intent to Prototype: Confirmation of Action API

Hi there,

A few additional questions/comments:
- this api will be a separate channel from ordinary live regions. If we mix the 
two techniques, wouldn't the output be interleave? For example, an iframe with 
a live region, and another iframe wherein we call document.ariaNotify?

In the Windows implementation, we are indeed using a different channel than 
live regions. However, the final invocation out of Chromium for both this API 
and live regions is into UIA, which has its own queuing mechanism. While it is 
possible for notifications to interleave, they will never interrupt each other 
(unless specifically intended)

The plan for other systems is to hook our API into the existing ARIA live 
region machinery. It will have a similar outcome as above, where ariaNotify 
notifications may interleave with live ARIA region ones, but they won't 
interrupt or interfere with each other.

- the way Chrome (at least) works is based on the serialization of a tree 
structure. This api appears to be a imperitive call, making it seem like the 
call gets honored immediately. However, the a11y tree gets pushed only on 
layout clean.
- what happens if I repeatedly call document.ariaNotify? Would these 
announcements queue up? Would they flush tts? Would it trigger a refresh of the 
accessibility tree?

This is a good point! We mark the a11y tree as dirty whenever 
document.ariaNotify is called and store unqueued notifications on AXTreeData.

- live regions have the aria-live polite|assertive properties which roughly 
(though not really for all screen readers) map to queue vs flushing tts. Is 
there something equivalent for this api?

Yes! One of the goals for this API was to have more indicative properties to 
describe how notification behave. Currently, we have any combination of the 
following two properties (naming tbd):

  *   PlaceInQueue: (front | back | newest-only)
 *   front: place the notification in the front of the queue
 *   back: place the notification in the back of the queue
 *   newest-only: place the notification in the back of the queue, but also 
drop all existing notifications from the same element (good for progress bars, 
latest status, etc.)
  *   Interrupt: (true | false)
 *   true: if a notification is currently speaking and shares the same 
source as the one being queued, interrupt it and move to the next notification 
in the queue
 *   false: let the current notification speak to completion

- many screen readers actually suppress live regions (e.g. NVDA) or give users 
a way to turn them off. This api might reduce the ability for screen readers to 
do this depending on how it gets implemented.

Another good point! I think it makes sense that if live regions are suppressed, 
we would want this API to also be suppressed.

On non-Windows systems, since we will be hooking directly into the existing 
ARIA live regions implementation, we will share the same behavior as ARIA live 
regions (aka. suppress live regions => suppress JS API).

I'm not so sure in the Windows implementation, I'll do more research on how 
live regions are suppressed in screen readers.

- at least via the current proposed change, it looks like notify is trying hard 
to be a direct tts channel to the screen reader. It has very little to do with 
ARIA?

That is correct, but we decided to keep the ARIA-naming because many web 
authors associate accessibility with ARIA. Thus, this naming most succinctly 
expresses the intention of the API.

On Friday, January 28, 2022 at 4:26:36 PM UTC-8 Sara Tang wrote:
Contact emails
sar...@microsoft.com

Explainer
https://github.com/WICG/aom/blob/gh-pages/notification-api.md

Specification


Summary

This effort aims to create a JavaScript API so that developers can better 
notify AT users of actions/changes to a webpage not necessarily tied to UI 
elements.


Blink component
Blink>Accessibility