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)
<https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Accessibility/AriaNotify/explainer.md>.
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 <sara...@microsoft.com> wrote:
>
>> + Cynthia Shelly
>> ------------------------------
>> *From:* Sara Tang <sara...@microsoft.com>
>> *Sent:* Wednesday, March 9, 2022 3:32 PM
>> *To:* David Tseng <dts...@google.com>; blink-dev <blin...@chromium.org>
>> *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 <dts...@google.com>
>> *Sent:* Monday, March 7, 2022 4:44 PM
>> *To:* blink-dev <blin...@chromium.org>
>> *Cc:* Sara Tang <sara...@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/c70ef472-474a-4566-841d-4db1642ee429n%40chromium.org.
