Accessibility Events Status (re: privacy)

[michaelcpuckett]

What is the current status of the AOM privacy model? (#81 was closed.)

Looks like there was concern when Apple displayed Accessibility Events option under accessibility settings.

Is that or any other part of the spec likely to get scrapped due to privacy concerns?

Is Accessibility Events part of spec now limited to semantic/ambiguous events (increment, decrement, dismiss, scrollPageUp, scrollPageDown) which could come from any source, rather than more specific accessible click, accessible focus, etc.? If so, why the need to opt in?

What about virtual accessible nodes? As previously mentioned, any events triggered on those nodes would also reveal the use of AT. (Again wondering about focus and .focus() method)

As a web developer, I'm excited to use these tools, but also expect an appropriate privacy model that doesn't make people choose between privacy and accessibility. For example, could the browser limit reading/writing the AOM to accessibility event callback functions inside some sort of worker or isolated process that cannot write to the DOM (or make AJAX requests, etc...)?

[matt-curtis]

For example, could the browser limit reading/writing the AOM to accessibility event callback functions inside some sort of worker or isolated process that cannot write to the DOM (or make AJAX requests, etc...)?

I like this suggestion, though the problem is that inevitably information would leak if there's any communication channels with the privileged main context(s). It would also beg the question of what could viably be accomplished that's of any use to a developer in such a sandbox.

The most viable option really seems just to give users the option to not have this information exposed. Opt-out by default, prompt user when an application requests the permission and inform them of the possible repercussions.

[alice]

Is Accessibility Events part of spec now limited to semantic/ambiguous events (increment, decrement, dismiss, scrollPageUp, scrollPageDown) which could come from any source, rather than more specific accessible click, accessible focus, etc.?

Yes, that's the plan (and should be reflected in the explainer).

What about virtual accessible nodes? As previously mentioned, any events triggered on those nodes would also reveal the use of AT. (Again wondering about focus and .focus() method)

Absolutely correct - we're working on figuring out the best way to address this issue.

Two options which have been mooted (may not be mutually exclusive):

• Make attaching a virtual accessibility tree a capability for installed PWAs only
• Show a permission prompt whenever an event listener is first added to a virtual accessibility node. This prompt would be shown for everyone, to avoid an issue where only AT users are seeing the prompt and so non-AT using developers would be unaware that it is showing (though if developers opt-in once they would not be shown the prompt again, possibly perpetuating the same issue).

For example, could the browser limit reading/writing the AOM to accessibility event callback functions inside some sort of worker or isolated process that cannot write to the DOM (or make AJAX requests, etc...)?

As @matt-curtis notes, it might be difficult to effectively react to an event in such a context.