Guiding principles:
- We should aim to minimise as much as possible cases where privacy and accessible functionality may come into conflict - i.e. where a user may feel they are forced to choose one or the other.
- When a choice is inevitable, it should be possible for the user to provide informed consent.
Use cases
- Individual web components or widgets which wish to handle semantic events from assistive technology (i.e. the "slider" problem)
- Web pages which wish to behave differently for semantic events than for their equivalent user interaction events (i.e. separate event listeners for "accessibleclick" and "click")
- Web pages which consist mainly of a large virtualised accessibility tree, e.g.
<canvas>based applications which are difficult or impossible to map into a fallback DOM tree, or a virtual desktop application. - Individual web components or widgets which render their contents in
<canvas>or similar and wish to provide a good, equivalent accessible experience via a virtual accessibility tree.
All present agreed that (2) and (4) are less critical to solve immediately, and that (1) and (3) are worth focusing our efforts on sooner rather than later.
@alice: How would this have worked in IndieUI?
@jcsteh: e.g. move to a slider with VoiceOver; user flicks up. “increment” event gets sent.
@aboxhall: How does that not have the same problem as this proposal?
@jcsteh: It does, but at least it doesn’t have “accessible” in the name. My main concern is that tying it strongly to assistive technology by using the “accessible” prefix removes any ambiguity about who the user is, and thus it’s strongly a privacy issue. Just because AT is the only use today doesn’t mean it always will be.
Ed. note: @jyasskin earlier suggested WebXR as one potential future user which will be looking for alternative interaction modes]
@ljwatson: What are the actual events we’re talking about?
@alice: (Refers to list in deprecated spec)
@jcsteh: I feel that the original list is actually much too broad, if we’re talking about minimising the conflict between accessibility and privacy we should be trying to have as few events as possible at least to begin with - I actually feel that it’s probably only increment and decrement.
@alice: Do you think the other events have no use cases at all?
@jcsteh: Not saying that, but they are use cases which can be addressed in other ways, and where the importance of the gain is much less than the risk to the user by exposing them.
@alice: Ok, how about we go through the list and double check we’re not missing anything? (Omitting accessible from the event names per Jamie’s comments)
click,focus
@aboxhall: since we agreed to punt the use case of behaving differently for AT-specific versions of these events, we agree that there is no benefit above the existing click and focus events for now unless someone can provide a specific use case.
setvalue
@jcsteh: To be honest I’m not even sure what this is used for.
Ed. note: probably voice control, now that I think about it.
@marcosc: What is stopping us just using the change event?
@alice: Could we opt in to that?
@jcsteh: Needs to map to a value attribute.
select
@jcsteh: Well we already have user input events - click and arrow keys, and we can and do already fire those.
scrollintoview
@jcsteh: What’s the use case for this?
@IanPouncey: Isn’t it for things like headings lists etc?
@jcsteh: Is focus sufficient here?
Ed note: not sure I fully understand this actually. You wouldn’t focus on a heading typically?
dismiss
@jcsteh: Is that a scrub gesture? This seems good, but I think the back button should be enough.
@alice: Back button?
@jcsteh: As in, just use pushState() - a lot of PWAs are doing this already.
contextmenu
@jcsteh: How do you even trigger that on Android or iOS? This seems like a desktop only thing, and then it’s a browser shortcut, not a screen reader one.
Ed. note: https://html.spec.whatwg.org/multipage/indices.html#event-contextmenu already exists.
@jcsteh: In general, I like this direction of making keyboard events indistinguishable from AT events. I think there are use cases for the AT specific events, but they’re not important enough to me to be worth the privacy headache.
@alice: Ok, let’s talk a bit about the virtual accessibility tree case really quickly. I want to talk about trying to create a user flow for informed consent, even if that information relies on trusting the app which is providing it to be honest.
@alice: With the caveat that there are downsides to this including a potential for non-equal experiences, here is my proposal for a case where for technical reasons you need to have an entire virtual accessibility tree for most or all of the application.
@alice: Using Google Docs as an example, you probably know you already need to opt in to “Screen Reader support” for it to work with assistive technology. At that point the privacy concern is moot, right?
@alice: So my proposal is that you could create a user flow where the app sees that you’ve already opted in, and uses that opportunity to inform you as a user before triggering the browser permission prompt. It would be something like:
- User enables “Screen Reader support” (or “Assistive technology support”) option
- A prompt appears in the application UI (i.e. not browser UI) explaining that the browser will shortly prompt for permission to listen for events from assistive technology, and that this will allow the site to know that the user is using assistive technology.
- At this point, the user has explicitly opted into a special Assistive Technology mode, so this is not new information, so the user clicks through the application’s prompt (something like “Ok, got it”). (This is “priming”, considered good practice for permission prompts I believe.)
- The application requests the Assistive Technology event permission, which causes a browser prompt to appear, which grabs the user’s focus.
@alice: Given the discussion in bug #81, I’m reasonably confident we can come up with a permission prompt which is privacy preserving i.e. doesn’t require a user to leak information even if they respond “no”.
@ljwatson: What about bad actors like ads using this? Couldn’t they lie about their motivation?
@jcsteh: For ads, you can dismiss the browser prompt. I don’t think anyone is too concerned about missing out on an ad experience!
@ljwatson: Ah I hadn’t realised that the browser will be providing a permission prompt, I see.
@jcsteh: I want to anticipate Léonie’s objection, which is that this is still forcing users to choose between privacy and accessibility. And I agree, but nobody has come up with a solution to this problem yet. For example, mobile apps get this permission automatically, which I’m not saying we should copy, but it just shows that this is a problem nobody has solved. So I think this is ok.
@jcsteh: For case 4, I think this is not a good solution. I just want to make clear that I think having permission prompts everywhere for components is going to be a terrible user experience.
@alice: Totally agreed.
Some feedback:
setvalue:
We might want to clarify the concern here, which is that a change event is only supported by specific HTML "controls" (such as
<select>and<input>) and can't (currently) be supported by arbitrary elements; e.g. ARIA combo boxes or sliders.scrollintoview:
Typically, that's true; headings aren't focusable. However, making them focusable makes dealing with the scrolling problem really easy, assuming the AT focuses elements as the user moves to them. (Note that NVDA does this and I think VoiceOver/Narrator do too. However, JAWS does not currently.)
Might be worth clarifying what is meant here for future reference; e.g. incrementing a slider with VoiceOver would just send an up arrow key press to the web page, thus giving no indication at all that it came from accessibility.