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 [email protected] > > 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 > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EAccessibility> > > 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 > <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md> > ? 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 > <https://chromestatus.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 [email protected]. 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.
