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

['David Tseng' via blink-dev]

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?
- 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?
- 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?
- 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.
- 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?

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 
> 
>
> Motivation 
>
> Currently the only mechanism available today that communicates content 
> changes in a web app down to the accessibility layer is via ARIA live 
> regions. One major limitation to ARIA live regions is that they assume the 
> change to a webpage is tied to a DOM element. This leads to content authors 
> employing various inefficient or inconsistent tricks and hacks to notify of 
> changes that are not associated with the DOM. We propose a separate 
> notification API to address these scenarios, called Confirmation of Action.
>
>
> Initial public proposal 
> https://github.com/WICG/aom/blob/gh-pages/notification-api.md
>
> TAG review 
>
> TAG review status Pending
>
> Risks 
>
>
> Interoperability and Compatibility 
>
>
>
> *Gecko*: No signal
>
> *WebKit*: No signal
>
> *Web developers*: Positive (https://github.com/w3c/aria/issues/832)
>
> *Other signals*:
>
>
> Debuggability 
>
> TBD
>
>
> Is this feature fully tested by web-platform-tests 
> 
> ? No
>
> Flag name --enable-blink-features=ConfirmationOfAction
>
> Requires code in //chrome? False
>
> Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=1291098
>
> Estimated milestones 
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status 
> https://chromestatus.com/feature/5745430754230272
>
> This intent message was generated by Chrome Platform Status 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/371c88d9-1ab5-47c5-be1f-8007a16febf2n%40chromium.org.

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

['Roberto Clapis' via blink-dev]

> - readback: Do not readback AT configuration settings.

This would be ideal. What would the major downsides of this be?

> - authoritative-sounding notifications

Do we currently (before this proposal) inform the user on which page/origin 
is causing a certain ARIA node to be read?

> We should suppress notifications when focus moves outside of the web 
content.

+1 on that

> Maybe only offer this feature to Secure Contexts (instead of 3rd party 
browsing contexts)

+1 on this too

Thanks for the clarification on the APIs. If I understand correctly this 
proposal won't change the API we use or the way we communicate with it, but 
it might end up opening a more direct channel to use it.
My proposal would be to then validate messages encoding (UTF-wise) and 
limit them in length and character set. Alphanumeric and punctuation should 
be sufficient for the use case we're trying to address, right?
I don't think running the message through parsers would be beneficial, so 
we can skip that part.
On Friday, February 18, 2022 at 11:24:38 PM UTC+1 Sara Tang wrote:

> Hi Roberto, thanks for your feedback  Responses inline:
>
> --
> *From:* Roberto Clapis 
> *Sent:* Tuesday, February 8, 2022 9:05 AM
> *To:* blink-dev 
> *Cc:* Roberto Clapis ; Sara Tang ; 
> blin...@chromium.org ; Daniel Libby <
> dli...@microsoft.com>; yoav...@chromium.org 
> *Subject:* Re: [EXTERNAL] Re: [blink-dev] Re: Intent to Prototype: 
> Confirmation of Action API 
>  
> There is one additional question that was brought forward during the 
> discussion:
>
>- What information can be read by the users of this API? This is 
>mentioned in the security concerns but it doesn't seem to be specified 
>elsewhere. Is this just about learning of an existence of a AT or is this 
>some additional info?
>
>
>- Here are some security concerns and possible mitigations. These are 
>also re-iterated in the "Privacy and Security Considerations" section of 
>the proposal:
>- - readback: Do not readback AT configuration settings. Doing so 
>makes the user an easier target for fingerprinting.
>- - authoritative-sounding notifications: announcements can be crafted 
>to deceive the user. We should suppress notifications when focus moves 
>outside of the web content.
>- - Maybe only offer this feature to Secure Contexts (instead of 3rd party 
>browsing contexts)
>
>
> On Tuesday, February 8, 2022 at 11:06:43 AM UTC+1 Roberto Clapis wrote:
>
> Hi All, 
>
> During a discussion about this proposal a few concerns were raised:
>
>
>- What pipeline of data would be used to pass the new messages to a 
>potential screen-reader? Would screen-readers need to implement a new API 
>or would this use pre-existing ones?
>
>
>- A small nuance: screen-readers do not implement APIs, they consume 
>ones that are exported by the Web Platform.
>- - In the case of Windows systems, we use the UIA notifications API 
>to pass information along to screen-readers.
>- - In the case for other systems, we can hijack the existing ARIA 
>live regions implemenation. In the case where the confirmation of action 
>API is called without a DOM element/ARIA node, we can attach the 
>announcement to an internal "root" node instead.
>
>
>- Does this new API allow pages to have a more direct or a less 
>restricted way to pass data to a screen reader?
>
>
>- Less restrictive; possible restrictions we'll need to employ are 
>listed in the next response.
>
>
>- Would this API allow potential attackers to use different character 
>sets or might this allow them to pass potentially malformed data to screen 
>readers that was not possible to pass before?
>
>
>- Here are some possible mitigations we have for this scenario:
>- - Truncating strings, employing a max queue length
>- - Restricting to alphanumeric input.
>- - Running the announcement-text through a 
>HTML-parser/DOM-parser/setInnerHtml or similar JS API
>
>
>
>
>- If a pre-existing channel is used to communicate with the screen 
>reader (e.g. already existing APIs) how would a user distinguish this new 
>mechanism from content on the page?
>
>
>- I don't think it's necessary for the user to distinguish between 
>different screen-announcing APIs. Is there a particular scenario you are 
>thinking of where a distinction would be needed? 
>
> Thanks in advance,
> Rob
>
>
>
> On Wednesday, February 2, 2022 at 1:05:58 AM UTC+1 Sara Tang wrote:
>
> Good suggestion Yaov! I've opened one here: Review request for 
> Confirmation of Acti

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

['Sara Tang' via blink-dev]

Hi Roberto, thanks for your feedback  Responses inline:


From: Roberto Clapis 
Sent: Tuesday, February 8, 2022 9:05 AM
To: blink-dev 
Cc: Roberto Clapis ; Sara Tang ; 
blin...@chromium.org ; Daniel Libby 
; yoav...@chromium.org 
Subject: Re: [EXTERNAL] Re: [blink-dev] Re: Intent to Prototype: Confirmation 
of Action API

There is one additional question that was brought forward during the discussion:

  *   What information can be read by the users of this API? This is mentioned 
in the security concerns but it doesn't seem to be specified elsewhere. Is this 
just about learning of an existence of a AT or is this some additional info?
  *   Here are some security concerns and possible mitigations. These are also 
re-iterated in the "Privacy and Security Considerations" section of the 
proposal:
  *   - readback: Do not readback AT configuration settings. Doing so makes the 
user an easier target for fingerprinting.
  *   - authoritative-sounding notifications: announcements can be crafted to 
deceive the user. We should suppress notifications when focus moves outside of 
the web content.
  *   - Maybe only offer this feature to Secure Contexts (instead of 3rd party 
browsing contexts)

On Tuesday, February 8, 2022 at 11:06:43 AM UTC+1 Roberto Clapis wrote:
Hi All,

During a discussion about this proposal a few concerns were raised:

  *   What pipeline of data would be used to pass the new messages to a 
potential screen-reader? Would screen-readers need to implement a new API or 
would this use pre-existing ones?
  *   A small nuance: screen-readers do not implement APIs, they consume ones 
that are exported by the Web Platform.
  *   - In the case of Windows systems, we use the UIA notifications API to 
pass information along to screen-readers.
  *   - In the case for other systems, we can hijack the existing ARIA live 
regions implemenation. In the case where the confirmation of action API is 
called without a DOM element/ARIA node, we can attach the announcement to an 
internal "root" node instead.
  *   Does this new API allow pages to have a more direct or a less restricted 
way to pass data to a screen reader?
  *   Less restrictive; possible restrictions we'll need to employ are listed 
in the next response.
  *   Would this API allow potential attackers to use different character sets 
or might this allow them to pass potentially malformed data to screen readers 
that was not possible to pass before?
  *   Here are some possible mitigations we have for this scenario:
  *   - Truncating strings, employing a max queue length
  *   - Restricting to alphanumeric input.
  *   - Running the announcement-text through a 
HTML-parser/DOM-parser/setInnerHtml or similar JS API

  *   If a pre-existing channel is used to communicate with the screen reader 
(e.g. already existing APIs) how would a user distinguish this new mechanism 
from content on the page?
  *   I don't think it's necessary for the user to distinguish between 
different screen-announcing APIs. Is there a particular scenario you are 
thinking of where a distinction would be needed?

Thanks in advance,
Rob



On Wednesday, February 2, 2022 at 1:05:58 AM UTC+1 Sara Tang wrote:
Good suggestion Yaov! I've opened one here: Review request for Confirmation of 
Action API · Issue #713 · w3ctag/design-reviews 
(github.com)<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3ctag%2Fdesign-reviews%2Fissues%2F713=04%7C01%7CSara.Tang%40microsoft.com%7Cf431134001a745dcb4c208d9eb2540f4%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637799369399593658%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=lsVh4SiL6qRcNXChcBKu%2FSd570FF65I6J%2BvkAWpWhA4%3D=0>

From: Yoav Weiss 
Sent: Monday, January 31, 2022 6:33 AM
To: Sara Tang 
Cc: blin...@chromium.org ; Daniel Libby 

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



On Sat, Jan 29, 2022 at 1:27 AM 'Sara Tang' via blink-dev 
 wrote:
+Daniel Libby

From: Sara Tang
Sent: Friday, January 28, 2022 4:26 PM
To: blin...@chromium.org 
Subject: Intent to Prototype: Confirmation of Action API

Contact emails
sar...@microsoft.com

Explainer
https://github.com/WICG/aom/blob/gh-pages/notification-api.md<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FWICG%2Faom%2Fblob%2Fgh-pages%2Fnotification-api.md=04%7C01%7CSara.Tang%40microsoft.com%7Cf431134001a745dcb4c208d9eb2540f4%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637799369399593658%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=lnxqPAw92p%2FOzBzVbk5qpZPUVQ%2FLxLSu8bbq1ZQHLY8%3D=0>

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 necessari

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

['Roberto Clapis' via blink-dev]

There is one additional question that was brought forward during the 
discussion:

   - What information can be read by the users of this API? This is 
   mentioned in the security concerns but it doesn't seem to be specified 
   elsewhere. Is this just about learning of an existence of a AT or is this 
   some additional info?


On Tuesday, February 8, 2022 at 11:06:43 AM UTC+1 Roberto Clapis wrote:

> Hi All,
>
> During a discussion about this proposal a few concerns were raised:
>
>- What pipeline of data would be used to pass the new messages to a 
>potential screen-reader? Would screen-readers need to implement a new API 
>or would this use pre-existing ones?
>- Does this new API allow pages to have a more direct or a less 
>restricted way to pass data to a screen reader?
>- Would this API allow potential attackers to use different character 
>sets or might this allow them to pass potentially malformed data to screen 
>readers that was not possible to pass before?
>- If a pre-existing channel is used to communicate with the screen 
>reader (e.g. already existing APIs) how would a user distinguish this new 
>mechanism from content on the page?
>
> Thanks in advance,
> Rob
>
>
>
> On Wednesday, February 2, 2022 at 1:05:58 AM UTC+1 Sara Tang wrote:
>
>> Good suggestion Yaov! I've opened one here: Review request for 
>> Confirmation of Action API · Issue #713 · w3ctag/design-reviews (github.com) 
>> <https://github.com/w3ctag/design-reviews/issues/713>
>> --
>> *From:* Yoav Weiss 
>> *Sent:* Monday, January 31, 2022 6:33 AM
>> *To:* Sara Tang 
>> *Cc:* blin...@chromium.org ; Daniel Libby <
>> dli...@microsoft.com>
>> *Subject:* [EXTERNAL] Re: [blink-dev] Re: Intent to Prototype: 
>> Confirmation of Action API 
>>  
>>
>>
>> On Sat, Jan 29, 2022 at 1:27 AM 'Sara Tang' via blink-dev <
>> blin...@chromium.org> wrote:
>>
>> +Daniel Libby
>> --
>> *From:* Sara Tang
>> *Sent:* Friday, January 28, 2022 4:26 PM
>> *To:* blin...@chromium.org 
>> *Subject:* Intent to Prototype: Confirmation of Action API 
>>  
>> Contact emails sar...@microsoft.com
>>
>> Explainer https://github.com/WICG/aom/blob/gh-pages/notification-api.md 
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FWICG%2Faom%2Fblob%2Fgh-pages%2Fnotification-api.md=04%7C01%7CSara.Tang%40microsoft.com%7C6382a5898c4249ab4dd508d9e4c6aed4%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637792365781317718%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=0hbc9Z0A2Pc6gPcQ5YCJgLbCplL4zVzbGieXwHQI%2BIU%3D=0>
>>
>> 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 
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.chromium.org%2Fp%2Fchromium%2Fissues%2Flist%3Fq%3Dcomponent%3ABlink%253EAccessibility=04%7C01%7CSara.Tang%40microsoft.com%7C6382a5898c4249ab4dd508d9e4c6aed4%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637792365781317718%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=LUDpXQ3U9jlBNAiZr9Wgvdj8%2FbkaO%2FqYAxea%2FRxaEuQ%3D=0>
>>
>> Motivation 
>>
>> Currently the only mechanism available today that communicates content 
>> changes in a web app down to the accessibility layer is via ARIA live 
>> regions. One major limitation to ARIA live regions is that they assume the 
>> change to a webpage is tied to a DOM element. This leads to content authors 
>> employing various inefficient or inconsistent tricks and hacks to notify of 
>> changes that are not associated with the DOM. We propose a separate 
>> notification API to address these scenarios, called Confirmation of Action.
>>
>>
>> Initial public proposal 
>> https://github.com/WICG/aom/blob/gh-pages/notification-api.md 
>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FWICG%2Faom%2Fblob%2Fgh-pages%2Fnotification-api.md=04%7C01%7CSara.Tang%40microsoft.com%7C6382a5898c4249ab4dd508d9e4c6aed4%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637792365781317718%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=0hbc9Z0A2Pc6gPcQ5YCJgLbCplL4zVzbGieXwHQI%2BIU%3D=0>
>>
>> TAG review 
>>
>>  
>> Just wanted to not

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

['Roberto Clapis' via blink-dev]

Hi All,

During a discussion about this proposal a few concerns were raised:

   - What pipeline of data would be used to pass the new messages to a 
   potential screen-reader? Would screen-readers need to implement a new API 
   or would this use pre-existing ones?
   - Does this new API allow pages to have a more direct or a less 
   restricted way to pass data to a screen reader?
   - Would this API allow potential attackers to use different character 
   sets or might this allow them to pass potentially malformed data to screen 
   readers that was not possible to pass before?
   - If a pre-existing channel is used to communicate with the screen 
   reader (e.g. already existing APIs) how would a user distinguish this new 
   mechanism from content on the page?

Thanks in advance,
Rob



On Wednesday, February 2, 2022 at 1:05:58 AM UTC+1 Sara Tang wrote:

> Good suggestion Yaov! I've opened one here: Review request for 
> Confirmation of Action API · Issue #713 · w3ctag/design-reviews (github.com) 
> <https://github.com/w3ctag/design-reviews/issues/713>
> --
> *From:* Yoav Weiss 
> *Sent:* Monday, January 31, 2022 6:33 AM
> *To:* Sara Tang 
> *Cc:* blin...@chromium.org ; Daniel Libby <
> dli...@microsoft.com>
> *Subject:* [EXTERNAL] Re: [blink-dev] Re: Intent to Prototype: 
> Confirmation of Action API 
>  
>
>
> On Sat, Jan 29, 2022 at 1:27 AM 'Sara Tang' via blink-dev <
> blin...@chromium.org> wrote:
>
> +Daniel Libby
> --
> *From:* Sara Tang
> *Sent:* Friday, January 28, 2022 4:26 PM
> *To:* blin...@chromium.org 
> *Subject:* Intent to Prototype: Confirmation of Action API 
>  
> Contact emails sar...@microsoft.com
>
> Explainer https://github.com/WICG/aom/blob/gh-pages/notification-api.md 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FWICG%2Faom%2Fblob%2Fgh-pages%2Fnotification-api.md=04%7C01%7CSara.Tang%40microsoft.com%7C6382a5898c4249ab4dd508d9e4c6aed4%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637792365781317718%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=0hbc9Z0A2Pc6gPcQ5YCJgLbCplL4zVzbGieXwHQI%2BIU%3D=0>
>
> 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 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.chromium.org%2Fp%2Fchromium%2Fissues%2Flist%3Fq%3Dcomponent%3ABlink%253EAccessibility=04%7C01%7CSara.Tang%40microsoft.com%7C6382a5898c4249ab4dd508d9e4c6aed4%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637792365781317718%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=LUDpXQ3U9jlBNAiZr9Wgvdj8%2FbkaO%2FqYAxea%2FRxaEuQ%3D=0>
>
> Motivation 
>
> Currently the only mechanism available today that communicates content 
> changes in a web app down to the accessibility layer is via ARIA live 
> regions. One major limitation to ARIA live regions is that they assume the 
> change to a webpage is tied to a DOM element. This leads to content authors 
> employing various inefficient or inconsistent tricks and hacks to notify of 
> changes that are not associated with the DOM. We propose a separate 
> notification API to address these scenarios, called Confirmation of Action.
>
>
> Initial public proposal 
> https://github.com/WICG/aom/blob/gh-pages/notification-api.md 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FWICG%2Faom%2Fblob%2Fgh-pages%2Fnotification-api.md=04%7C01%7CSara.Tang%40microsoft.com%7C6382a5898c4249ab4dd508d9e4c6aed4%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637792365781317718%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=0hbc9Z0A2Pc6gPcQ5YCJgLbCplL4zVzbGieXwHQI%2BIU%3D=0>
>
> TAG review 
>
>  
> Just wanted to note that it seems worthwhile to file for an early TAG 
> review. 
>
>
> TAG review status Pending
>
> Risks 
>
>
> Interoperability and Compatibility 
>
>
>
> *Gecko*: No signal
>
> *WebKit*: No signal
>
> *Web developers*: Positive (https://github.com/w3c/aria/issues/832 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Faria%2Fissues%2F832=04%7C01%7CSara.Tang%40microsoft.com%7C6382a5898c4249ab4dd508d9e4c6aed4%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637792365781317718%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=T4UsOOd8wCYCMZRGB8PtvhjwGbQYZXytYTBP6Q0LAaw%3D=0>
> )
>
> *Other signals*:
&g

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

['Sara Tang' via blink-dev]

Good suggestion Yaov! I've opened one here: Review request for Confirmation of 
Action API * Issue #713 * w3ctag/design-reviews 
(github.com)<https://github.com/w3ctag/design-reviews/issues/713>

From: Yoav Weiss 
Sent: Monday, January 31, 2022 6:33 AM
To: Sara Tang 
Cc: blink-dev@chromium.org ; Daniel Libby 

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



On Sat, Jan 29, 2022 at 1:27 AM 'Sara Tang' via blink-dev 
mailto:blink-dev@chromium.org>> wrote:
+Daniel Libby

From: Sara Tang
Sent: Friday, January 28, 2022 4:26 PM
To: blink-dev@chromium.org<mailto:blink-dev@chromium.org> 
mailto:blink-dev@chromium.org>>
Subject: Intent to Prototype: Confirmation of Action API

Contact emails
sart...@microsoft.com<mailto:sart...@microsoft.com>

Explainer
https://github.com/WICG/aom/blob/gh-pages/notification-api.md<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FWICG%2Faom%2Fblob%2Fgh-pages%2Fnotification-api.md=04%7C01%7CSara.Tang%40microsoft.com%7C6382a5898c4249ab4dd508d9e4c6aed4%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637792365781317718%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=0hbc9Z0A2Pc6gPcQ5YCJgLbCplL4zVzbGieXwHQI%2BIU%3D=0>

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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.chromium.org%2Fp%2Fchromium%2Fissues%2Flist%3Fq%3Dcomponent%3ABlink%253EAccessibility=04%7C01%7CSara.Tang%40microsoft.com%7C6382a5898c4249ab4dd508d9e4c6aed4%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637792365781317718%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=LUDpXQ3U9jlBNAiZr9Wgvdj8%2FbkaO%2FqYAxea%2FRxaEuQ%3D=0>

Motivation

Currently the only mechanism available today that communicates content changes 
in a web app down to the accessibility layer is via ARIA live regions. One 
major limitation to ARIA live regions is that they assume the change to a 
webpage is tied to a DOM element. This leads to content authors employing 
various inefficient or inconsistent tricks and hacks to notify of changes that 
are not associated with the DOM. We propose a separate notification API to 
address these scenarios, called Confirmation of Action.


Initial public proposal
https://github.com/WICG/aom/blob/gh-pages/notification-api.md<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FWICG%2Faom%2Fblob%2Fgh-pages%2Fnotification-api.md=04%7C01%7CSara.Tang%40microsoft.com%7C6382a5898c4249ab4dd508d9e4c6aed4%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637792365781317718%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=0hbc9Z0A2Pc6gPcQ5YCJgLbCplL4zVzbGieXwHQI%2BIU%3D=0>

TAG review


Just wanted to note that it seems worthwhile to file for an early TAG review.


TAG review status
Pending

Risks


Interoperability and Compatibility


Gecko: No signal

WebKit: No signal

Web developers: Positive 
(https://github.com/w3c/aria/issues/832<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Faria%2Fissues%2F832=04%7C01%7CSara.Tang%40microsoft.com%7C6382a5898c4249ab4dd508d9e4c6aed4%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637792365781317718%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=T4UsOOd8wCYCMZRGB8PtvhjwGbQYZXytYTBP6Q0LAaw%3D=0>)

Other signals:


Debuggability

TBD


Is this feature fully tested by 
web-platform-tests<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchromium.googlesource.com%2Fchromium%2Fsrc%2F%2B%2Fmaster%2Fdocs%2Ftesting%2Fweb_platform_tests.md=04%7C01%7CSara.Tang%40microsoft.com%7C6382a5898c4249ab4dd508d9e4c6aed4%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637792365781367695%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=%2BlpfYYe4ynJlQt4H5gxCYp%2FtW4Z%2FRW9hpWVHFaOzd%2BI%3D=0>?
No

Flag name
--enable-blink-features=ConfirmationOfAction

Requires code in //chrome?
False

Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1291098<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.chromium.org%2Fp%2Fchromium%2Fissues%2Fdetail%3Fid%3D1291098=04%7C01%7CSara.Tang%40microsoft.com%7C6382a5898c4249ab4dd508d9e4c6aed4%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637792365781367695%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000=GrDlD2ouj7qXwiUHetoQU5N2Ksd7LlcZLr2ygxG%2B8iY%3D=0>

Estimated milestones

No milestones specified


Link to entry on the Chrome Platform S

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

[Yoav Weiss]

On Sat, Jan 29, 2022 at 1:27 AM 'Sara Tang' via blink-dev <
blink-dev@chromium.org> wrote:

> +Daniel Libby
> --
> *From:* Sara Tang
> *Sent:* Friday, January 28, 2022 4:26 PM
> *To:* blink-dev@chromium.org 
> *Subject:* Intent to Prototype: Confirmation of Action API
>
> Contact emails sart...@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
> 
>
> Motivation
>
> Currently the only mechanism available today that communicates content
> changes in a web app down to the accessibility layer is via ARIA live
> regions. One major limitation to ARIA live regions is that they assume the
> change to a webpage is tied to a DOM element. This leads to content authors
> employing various inefficient or inconsistent tricks and hacks to notify of
> changes that are not associated with the DOM. We propose a separate
> notification API to address these scenarios, called Confirmation of Action.
>
>
> Initial public proposal
> https://github.com/WICG/aom/blob/gh-pages/notification-api.md
>
> TAG review
>

Just wanted to note that it seems worthwhile to file for an early TAG
review.


> TAG review status Pending
>
> Risks
>
>
> Interoperability and Compatibility
>
>
>
> *Gecko*: No signal
>
> *WebKit*: No signal
>
> *Web developers*: Positive (https://github.com/w3c/aria/issues/832)
>
> *Other signals*:
>
>
> Debuggability
>
> TBD
>
>
> Is this feature fully tested by web-platform-tests
> 
> ? No
>
> Flag name --enable-blink-features=ConfirmationOfAction
>
> Requires code in //chrome? False
>
> Tracking bug https://bugs.chromium.org/p/chromium/issues/detail?id=1291098
>
> Estimated milestones
>
> No milestones specified
>
>
> Link to entry on the Chrome Platform Status
> https://chromestatus.com/feature/5745430754230272
>
> This intent message was generated by Chrome Platform Status
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "blink-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+unsubscr...@chromium.org.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CH2PR00MB06809C5589E8FD6848CF5E09F2239%40CH2PR00MB0680.namprd00.prod.outlook.com
> 
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfV68gZzQ70-Ff_Cj6HYfThdPAe3ywT8bYWAdO-c5fKoLw%40mail.gmail.com.

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

['Sara Tang' via blink-dev]

+Daniel Libby

From: Sara Tang
Sent: Friday, January 28, 2022 4:26 PM
To: blink-dev@chromium.org 
Subject: Intent to Prototype: Confirmation of Action API

Contact emails
sart...@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

Motivation

Currently the only mechanism available today that communicates content changes 
in a web app down to the accessibility layer is via ARIA live regions. One 
major limitation to ARIA live regions is that they assume the change to a 
webpage is tied to a DOM element. This leads to content authors employing 
various inefficient or inconsistent tricks and hacks to notify of changes that 
are not associated with the DOM. We propose a separate notification API to 
address these scenarios, called Confirmation of Action.


Initial public proposal
https://github.com/WICG/aom/blob/gh-pages/notification-api.md

TAG review


TAG review status
Pending

Risks


Interoperability and Compatibility


Gecko: No signal

WebKit: No signal

Web developers: Positive (https://github.com/w3c/aria/issues/832)

Other signals:


Debuggability

TBD


Is this feature fully tested by 
web-platform-tests?
No

Flag name
--enable-blink-features=ConfirmationOfAction

Requires code in //chrome?
False

Tracking bug
https://bugs.chromium.org/p/chromium/issues/detail?id=1291098

Estimated milestones

No milestones specified


Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5745430754230272

This intent message was generated by Chrome Platform 
Status.

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CH2PR00MB06809C5589E8FD6848CF5E09F2239%40CH2PR00MB0680.namprd00.prod.outlook.com.