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 <dts...@google.com>
Sent: Monday, March 7, 2022 4:44 PM
To: blink-dev <blink-dev@chromium.org>
Cc: Sara Tang <sara.t...@microsoft.com>
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<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FWICG%2Faom%2Fblob%2Fgh-pages%2Fnotification-api.md&data=04%7C01%7CSara.Tang%40microsoft.com%7C773383cd75244918a82508da009cc969%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637822970663462541%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=bmDurw1dfMcZzwWxl0WSOyQl8ox6TdHm77wlXE%2FWXGY%3D&reserved=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&data=04%7C01%7CSara.Tang%40microsoft.com%7C773383cd75244918a82508da009cc969%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637822970663462541%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=%2B7teELybGISEmodZGVNnWE4zMLn5aVigsfcoO5%2Fco8Y%3D&reserved=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&data=04%7C01%7CSara.Tang%40microsoft.com%7C773383cd75244918a82508da009cc969%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637822970663462541%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=bmDurw1dfMcZzwWxl0WSOyQl8ox6TdHm77wlXE%2FWXGY%3D&reserved=0>
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&data=04%7C01%7CSara.Tang%40microsoft.com%7C773383cd75244918a82508da009cc969%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637822970663462541%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=W0%2FAsv6K%2F5CeT6GxPW6HHqCziXXWGMK9Nll%2BVHggQAU%3D&reserved=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&data=04%7C01%7CSara.Tang%40microsoft.com%7C773383cd75244918a82508da009cc969%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637822970663462541%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=akUlWNqeA4RHrn6mQZIiW1LoAr1pkKJFdVhrvWNWSaQ%3D&reserved=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&data=04%7C01%7CSara.Tang%40microsoft.com%7C773383cd75244918a82508da009cc969%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637822970663462541%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=BQUfSHBw3XVqZs6wSTImhJQd25aU%2Bc%2F5Y89lElQ6yAE%3D&reserved=0>
Estimated milestones
No milestones specified
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5745430754230272<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchromestatus.com%2Ffeature%2F5745430754230272&data=04%7C01%7CSara.Tang%40microsoft.com%7C773383cd75244918a82508da009cc969%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637822970663462541%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=7nj2NaJ%2FGA9kC8wyOm0R4%2F5Qaoo6eE0nNupUWdErYvQ%3D&reserved=0>
This intent message was generated by Chrome Platform
Status<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchromestatus.com%2F&data=04%7C01%7CSara.Tang%40microsoft.com%7C773383cd75244918a82508da009cc969%7C72f988bf86f141af91ab2d7cd011db47%7C0%7C0%7C637822970663513114%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=LHugQqUWNGi2bSoWLBEnNpFbx4oF2SMSTJ2MvvlgFTI%3D&reserved=0>.
--
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/MN2PR00MB0685556DC6613E8B3FB43269F20A9%40MN2PR00MB0685.namprd00.prod.outlook.com.
