Accessibility Events Status (re: privacy) #144

Activity

1. matt-curtis commented on Jun 5, 2019

   

   matt-curtis

   on Jun 5, 2019

   Last edited by matt-curtis

   More actions

   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.
2. alice commented on Jul 10, 2019

   

   alice

   on Jul 10, 2019

   Last edited by alice

   Member

   More actions

   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.