Concerns re: focus action

[cookiecrook]

Fine to leave focus in for now (ref #80), but I have the following concerns about it:

• User privacy: This is an unambiguous indication of assistive technology where mere navigation of the content "outs" the user.
• Compatibility with non-linear navigation methods: Would it still be called "focus" if it's triggered by something that would fire many more events that linear keyboard focus? E.g. Pointer-based dwell AT may need to fire this on hover, more akin to mouseover/mouseout.
• Robustness: To make this complete, we'd need a pair of actions: focus/blur, or focusIn/focusOut.
• Ambiguity: As you're well aware (see :focus-ring) ambiguity between different types of focus can result in misuse or cumbersome workarounds by web developers.

Thoughts:

• Should actions allow an optional payload (e.g. "type of focus" or any other relevant data)
• Should a user privacy model be included at this point in the Incubation process? E.g. prompt the user (non-blocking) when the page first registers for actions. Consider aspects of the privacy model I sketched up for IndieUI User Context a few years back.

[minorninth]

User privacy: This is an unambiguous indication of assistive technology where mere navigation of the content "outs" the user.

True, but I'm not sure this is limited to focus. The accessible click event would do the same thing as soon as the user tries to activate anything on the page.

I like the idea of prompting the user the first time an accessible event would actually be captured by an event handler. More below.

Compatibility with non-linear navigation methods: Would it still be called "focus" if it's triggered by something that would fire many more events that linear keyboard focus? E.g. Pointer-based dwell AT may need to fire this on hover, more akin to mouseover/mouseout.

Can you give an example of how this is handled in any native accessibility API currently? I don't see anything along those lines in NSAccessibility or UIAccessibility, for example, but maybe I'm missing something.

Robustness: To make this complete, we'd need a pair of actions: focus/blur, or focusIn/focusOut. Ambiguity: As you're well aware (see :focus-ring) ambiguity between different types of focus can result in misuse or cumbersome workarounds by web developers.

What I want is an event that maps to the focus action from assistive technology. Perhaps a better name for it would be "accessiblerequestfocus".

Having events to track focus changes from all sources, including programmatic focus, would be different. Maybe like focusin, focusout, etc.

For example:

• User presses Tab -> DOM focus changes, but "accessiblerequestfocus" does not fire.
• JavaScript explicitly focuses a DOM element -> "accessiblerequestfocus" does not fire.
• Screen reader user navigates to the next form control and auto-focuses it. The "accessiblerequestfocus" DOES fire now and the author has a chance to override the behavior instead of triggering a focus of this DOM element.

Should actions allow an optional payload (e.g. "type of focus" or any other relevant data)

I think the key question is, can we get that information from a significant fraction of native APIs? I can't find any extra info, and plus this is the event that requests focus. I agree that when focus changes the after-the-fact notification could explain why focus changed and that'd be helpful.

Should a user privacy model be included at this point in the Incubation process? E.g. prompt the user (non-blocking) when the page first registers for actions. Consider aspects of the privacy model I sketched up for IndieUI User Context a few years back.

I'd do it the first time an event would be handled by their event handler, that way the user doesn't get the prompt until they actually interact with the part of the page that needs it.

"This site wants to offer a custom experience for assistive technology users. Allow?"

[benfredwells]

Bringing this to the attention of @raymeskhoury and @jyasskin. Some comments from a permissions perspective:

• we often worry about permissions just confusing users who may not understand what the risk is. I think the text of this permission is probably OK though, as only users who have a11y tech enabled would see it. Is that right?

• is there any chance the prompt would introduce a delay that could be detected by the page? If so the page might be able to determine that a11y assistance is being used regardless of the users' response.

• please co-ordinate with the permissions spec.

[cookiecrook]

@benfredwells wrote:

is there any chance the prompt would introduce a delay that could be detected by the page?

I anticipated this in the now-defunct IndieUI: User Context Privacy Model. I hope we would use something similar. Briefly, it was:

1. Any request is non-blocking and always returns "no" immediately regardless if the user is prompted.
2. The non-blocking dialog is presented and—if permission is granted—a subsequent change notification would fire.

To the permissions people reviewing, something I'd like to see added to browser permissions dialogs is the justification string proposed in the IndieUI draft.

[jyasskin]

+1 for considering privacy early, even if the decision is "do nothing".

I'm worried about showing a permission dialog right as the user is trying to accomplish something else. It seems like a risk that the user will blindly do something to get the dialog out of the way, instead of thinking about whether they want to give their information away. I'd defer to @raymeskhoury and the other experts on this though.

It may also be annoying to people using assistive technology: in the long run, will it fire on basically every site they visit?

That said, you can use the permission system to allow UAs to let users say "no" even if you think most UAs or assistive tools will set the default to "yes".

[alice]

I don't imagine it would fire on basically every site - for most things authors shouldn't need to use any kind of custom actions. I would imagine it would fire on frequently used, heavily interactive things like gmail, docs, slack etc - unless sites start trying to use it as a means of trying to track AT users.

[minorninth]

My idea is that the permission dialog should only show the first time an event listener would actually fire. Initially the event listener would not fire (and the fallback behavior would be triggered), and the dialog would show.

I don't think there are any timing attacks, because as James said, we reject immediately; the site only gets notified if the user grants permission, and doesn't even know that the dialog was triggered.

Just visiting a site shouldn't trigger it. A malicious or buggy site could try to register all event listeners on the body, and it's true that'd be pretty annoying. But if used as intended, the event listeners would be on a particular control on the page, so the permission dialog wouldn't show until the user lands on that control.

[alice]

Showing the dialog on interaction might be annoying as @jyasskin describes, though: right as you're trying to, say, change a slider value, or click a button, you have to deal with this dialog because... why exactly? (From the user's point of view.)

So maybe showing the dialog on page load would make more sense? Not sure how to walk the line here.

[cookiecrook]

I don't think it has to be a blocking dialog. It could come up like the non-blocking search banner in Safari when you press Cmd+F.

[alice]

Hm, yeah, if it was shown on page load we'd show it to users who have no interest in it, so it definitely needs to wait until an action is sent from AT.

So the flow would be something like:

• try to [e.g.] click something via AT for the first time
• a non-blocking dialog is shown to the user, but no accessibleClick event is fired? Just a click event?
• the user completes their action and then, if they choose, navigates to the dialog (how?), grants or denies permission, then returns to what they were doing (how?)

I don't think we even need to get as far as pretending the user denied permission, because the page never explicitly requests it - it just registers an event hander for the accessible event, then either that event handler gets triggered (if the user grants permission and then performs the action again..?) or it doesn't.

[minorninth]

In Chrome, the permission dialog steals focus but it isn't modal, so if you want to, you can click or tab back into the page and keep going, and the dialog will stay up. It's not currently easy to get keyboard focus back to the dialog, but there's a bug open to make it just part of the tab order where it appears to be anchored to - in this case, immediately before the location bar.

Actually that suggest a potential privacy hole, though, if we're not careful - the navigator.permissions https://w3c.github.io/permissions/ api would allow the web page to determine if the permission status is "granted", "prompt", or "denied". Initially it'd be "prompt", but if the user pressed "Deny", it'd change to "denied", but that would reveal to the site that the user saw the prompt! We actually need to only return "granted" or "prompt" here.

On Wed, Aug 9, 2017 at 11:58 PM Alice notifications@github.com wrote:

Hm, yeah, if it was shown on page load we'd show it to users who have no interest in it, so it definitely needs to wait until an action is sent from AT.

So the flow would be something like:

• try to [e.g.] click something via AT for the first time
• a non-blocking dialog is shown to the user, but no accessibleClick event is fired? Just a click event?
• the user completes their action and then, if they choose, navigates to the dialog (how?), grants or denies permission, then returns to what they were doing (how?)

I don't think we even need to get as far as pretending the user denied permission, because the page never explicitly requests it - it just registers an event hander for the accessible event, then either that event handler gets triggered (if the user grants permission and then performs the action again..?) or it doesn't.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/WICG/aom/issues/81#issuecomment-321468094, or mute the thread https://github.com/notifications/unsubscribe-auth/AFqKhpIcWu7dqsETOinpTr34JdRXSIOVks5sWqoYgaJpZM4OfEyi .

[jyasskin]

From the above discussion, it sounds like the permission prompt is going to be something of a mess, so I wonder if y'all can avoid it somehow. My thought was to have non-AT input also go through the AT path, to obscure whether AT was being used. I asked @alice about this, and she pointed out that AT may already be detectable by looking for whether change events are accompanied by the keydown events that cause them. If AT is already detectable, then you probably don't need to prompt before letting sites detect it in a second way.

[minorninth]

From the above discussion, it sounds like the permission prompt is going to be something of a mess, so I wonder if y'all can avoid it somehow. My thought was to have non-AT input also go through the AT path, to obscure whether AT was being used.

Interesting idea. A couple of reasons I don't think that will work:

• In Phase 3 we'll introduce virtual accessibility nodes. They'll only be exposed to AT, so if you get an event on one of those you know it came from AT.
• Even aside from that, not all of the AT input events correspond to DOM events. For example there's no DOM event for "scroll into view", "scroll down by one page", "increment", or "decrement". Even for "click", it'd happen in a weird order - like you'd have a mouse down event, then a mouse up event, then before the click event there'd be an accessible click event?

I asked @alice about this, and she pointed out that AT may already be detectable by looking for whether change events are accompanied by the keydown events that cause them. If AT is already detectable, then you probably don't need to prompt before letting sites detect it in a second way.

First, I'm skeptical that there's any technique that reliably detects AT. I've seen sites that claim to do this and they're usually easy to fool. If we saw any good ones being widely used I'd prefer to try to mitigate those rather than just give up.

More importantly, though, a segment of the accessibility community feels very strongly about this. They've strongly opposed previous web standards proposals that would have exposed this information.

Privacy is never 100% perfect, there are always ways to try to fingerprint users. That doesn't mean we shouldn't try to do as much as possible to protect users, especially when users have expressed concerns about certain data - and this is one of those cases.

[jyasskin]

In phase 3, do you want to let websites avoid the time used building virtual accessibility nodes when there's no AT around to consume them? If so, we'll probably want the prompt for this phase to also include permission for that phase.

Could Chrome and the AT collaborate to show the prompt when the handler's installed iff AT is also enabled?

Then maybe we can think of it not as a permission (for which "denied" leaks information) and more as an "AT was revealed" event, which could be communicated by a Promise resolving if you need to tell websites at all.

There are some similarities between this and https://github.com/w3c/webauthn/pull/379 (@kpaulh). We could try to do something generic in the Permissions spec for this kind of bit, but I'd rather wait until we see a couple more use cases.

[minorninth]

In phase 3, do you want to let websites avoid the time used building virtual accessibility nodes when there's no AT around to consume them? If so, we'll probably want the prompt for this phase to also include permission for that phase.

Yes, but sites could just create a button with an accessibility label "Click here to enable full accessibility support for this site (requires granting a permission)" - then when the user clicks the button, they'll know the permission was granted and they could go ahead with building a virtual accessibility tree.

Could Chrome and the AT collaborate to show the prompt when the handler's installed iff AT is also enabled?

Then maybe we can think of it not as a permission (for which "denied" leaks information) and more as an "AT was revealed" event, which could be communicated by a Promise resolving if you need to tell websites at all.

The downside I see here is that the permission shows upon simply visiting a site, rather than upon interacting with a component that needs nontrivial accessibility support.

While a site might prefer to know whether someone's using AT immediately, I think users might prefer not just granting a site access until they've explored a bit and decided they may actually want to use it.

Google Maps might be a great example. You should be able to get directions somewhere without accepting any permissions, but to explore the interactive map you'd need to.

[jyasskin]

This is sounding more like https://w3c.github.io/webauthn/#isPlatformAuthenticatorAvailable, where a minority of users care about the feature, but those users might care a lot, and the site needs to know whether to build UI to support those users. I believe @kpaulh is implementing isPlatformAuthenticatorAvailable to let the user interact with the site for a while before answering the prompt, although I could be wrong about that, and, of course, the right UI for this might be different between the non-AT common case for webauthn and the AT common case for this permission.

[raymeskhoury]

Sorry just catching up on emails now. Adding a permission prompt here does seem like quite a big hammer. Will it be cumbersome/confusing for users to have to opt-in to this permission whenever they want to use AT with a site that supports it? How often would users not grant the permission? Would it be sufficient to have a global option instead?

Initially it'd be "prompt", but if the user pressed "Deny", it'd change to "denied", but that would reveal to the site that the user saw the prompt! We actually need to only return "granted" or "prompt" here.

That sounds potentially problematic. Websites are meant to use the outcome of navigator.permissions.query to determine whether to show UI to give users context for a prompt. If we always say "prompt" even when we don't prompt, then websites may do the wrong thing. It sounds like the website should never actually know if a prompt will be shown?

[minorninth]

Sorry just catching up on emails now. Adding a permission prompt here does seem like quite a big hammer. Will it be cumbersome/confusing for users to have to opt-in to this permission whenever they want to use AT with a site that supports it?

This permission is not required to use AT, only for the site to listen to some AT-specific events, which reveals that the user is using AT. Most sites shouldn't need this, but some highly interactive web apps like GSuite-type apps could deliver an improved experience.

How often would users not grant the permission? Would it be sufficient to have a global option instead?

This would be just like any other content setting, so a user could definitely opt-in or opt-out globally.

I don't think a global option would suffice for all users, though. Here are a couple of cases where users may specifically want to opt out, there may be more:

1. The site is collecting sensitive personal information (like a job application), and the user doesn't want to reveal that they may have a disability
2. The site's accessibility support is broken, and they want to disable the detection and get the same experience as every other user

Initially it'd be "prompt", but if the user pressed "Deny", it'd change to "denied", but that would reveal to the site that the user saw the prompt! We actually need to only return "granted" or "prompt" here.

That sounds potentially problematic. Websites are meant to use the outcome of navigator.permissions.query to determine whether to show UI to give users context for a prompt. If we always say "prompt" even when we don't prompt, then websites may do the wrong thing. It sounds like the website should never actually know if a prompt will be shown?

OK, alternative idea: if the user does not appear to have AT running, then we return "deny" after some random delay. I think I saw a random delay added for other permission prompts, right?

[alice]

Most sites shouldn't need this, but some highly interactive web apps like GSuite-type apps could deliver an improved experience.

I know I originally said this as well, but I think this may potentially not always be true - imagine a future where custom elements became ubiquitous, and many pages were using <acme-custom-slider>, which requires listening for the accessibleincrement event etc. So I think it actually does make sense to plan for the case where this includes most pages.

[minorninth]

True, although if the sites are designed well, you won't hit that permission prompt until if and when you actually navigate to that slider and perform an increment gesture.

Even for sites that incorporate lots of custom elements that use AOM, I'd expect really basic usage of the site still shouldn't require this sort of thing at all.

I'd almost rather have it annoy users and discourage sites from abusing these event listeners without a good reason.

[raymeskhoury]

Thanks @alice and @minorninth for meeting the other day to explain more. It does sound like a prompt is the best we can do here.

I just want to make sure I understand the current proposal correctly. My understanding of the prompting behavior: 1) A user visits a website. 2) The website registers an AOM event handler 3) The user interacts with the website via AT. An event is fired from the AT into the page 4) Before the website's event handler is fired, we trigger a permission prompt asynchronously. The event is ignored. 5) If the user allows the prompt, subsequent events will be allowed to be handled by the website. If the prompt is denied, the website won't receive any events.

Is that right? Would the site need to depend on waiting for an event to be received in order to know that it has been granted access? Will that be sufficient?

I'm not sure though whether we should actually expose this through the permissions.query API as sites will never be able to tell when the prompt will actually be shown. The alternative would be to expose some other property with the value (I think this is what @jyasskin is getting at?) but I don't see a huge advantage to that to be honest.

I'm also curious if you have thought through the iframes story? It looks like you've already added a feature policy feature. I would recommend going with a delegation model. What that would mean in practice is that the user can only be prompted by the top level origin. iframes will get access as long as the feature policy allowing the feature is specified. I think it makes a lot of sense here and it's the direction we're moving towards for other permissions. The content setting registration should probably change in that case from REQUESTING_ORIGIN_AND_TOP_LEVEL_ORIGIN_SCOPE to TOP_LEVEL_ORIGIN_ONLY_SCOPE.

[alice]

Raw, very rough notes from meeting with @estark37 (Chrome Usable Security expert):

---

What about physically showing a prompt only if AT is in use, but auto-declining if AT is not being used?

• No priming possible
• May not need priming? Could maybe just show on page load

"Skip link" style user opt in Other cases where prompt is "auto denied"? e.g. Android webview maybe?

What about at the browser level?

What's the threat model

• discrimination?
• "not equal" experience

Dominic learning towards conservatism Maybe slightly more annoying and privacy conscious option first What can give us flexibility?

Issues

• Timing attack (detecting via slow denial that the user is using AT)
• Contextualisation (priming)

Auto denial

• Would have to auto-deny no matter what

Maybe only allow "allow" and "ask", to avoid knowing about explicit denial?

What about insecure http? *** We're ok with limiting AOM events to https.

Some sites do "fake" permission prompts to know whether a user is going to deny and then show the actual permission prompt later

Users may not be able to distinguish a fake prompt and a real prompt if they can't see the screen.

[estark37]

Thanks @alice. After reading through the notes and the thread, here's my current understanding of the issues:

Some websites might want to give the user context for why the prompt is going to be shown. There doesn't seem to be a great way to enable this:

• Allow the website to query the permission via permissions.query, but only return 'allow' or 'prompt'. This doesn't really solve the problem because it doesn't allow the website to distinguish when the prompt will be shown, as @raymeskhoury pointed out.
• The alternative is allowing the website to provide a justification string in the prompt, but this is a recipe for abuse and we've historically never wanted to allow this. OTOH, I'm still not convinced that the context/priming is so important for this prompt. My instinct, admittedly based on a very fuzzy understanding of the API, is that website-provided context won't necessarily give the user a lot of insight into whether the website is using it for legitimate or nefarious purposes. (Maybe someone can give me a counterexample?)

I could see a website wanting to prompt on page load rather than in the middle of some interaction, and for that there would need to be some kind of time-fuzzed autodeny to obscure a lack of prompt from a deny. This is pretty messy, though, and as @minorninth suggested, maybe it's better to wait on this until seeing if websites really want it.

[alice]

Copying some comments from the other issue:

@LJWatson: https://github.com/WICG/aom/issues/51#comment-377384788

Enabling authors to determine that someone is using an AT is an invasion of privacy. It effectively exposes the fact that the person has a disability, and that is information we should protect to the same extent we protect other pieces of personal information like gender, race, orientation, or faith.

Opt-in is not a solution. It asks AT users to choose between privacy and accessibility. Opt-in may be viable for geo-location, but sharing your location and sharing your disability are two distinctly different things.

@jcsteh: https://github.com/WICG/aom/issues/51#comment-377395811

I'd like to echo @LJWatson's concerns regarding privacy. It's not reasonable that my experience should be degraded unless I choose to expose the fact that I have a disability.

I realise that native applications do have access to this information. However, just because native apps do something doesn't necessarily mean it's always a good idea.

As some food for thought regarding an alternative, I question why these events need to be "accessibility specific". Why "accessibleclick" and "accessibleincrement" instead of just "click" and "increment"? In order to fill the gap in current experiences, what we really need here is input agnostic events, not accessibility specific events. "Increment" could be just as useful for cases where a user isn't using a traditional 'assistive technology". That allows for new input methods that might be used by anyone and abstracted by the operating system. Essentially, I'm suggesting something more like IndieUI Events.

[alice]

@LJWatson also went into more detail on concerns here: https://tink.uk/thoughts-on-screen-reader-detection/

[alice]

Some thoughts bubbling around my head here...

I feel like there are two main use cases for an AT event permission:

1. a Web Component which may be included on many different sites, which can "act like a built in element" by listening for AT events.
   • It would be a very bad experience if every site which included one or more such components requested a user permission just so that the component could do the "right" thing in response to AT interactions
   • The developers may not even know that the permission is being requested, and would have no way to warn or prime users as to the meaning of the request.
   • We do have suggestions for fallback events for most of these cases (much like a touch event triggers a mouse event)
2. listening for events on virtual AccessibleNode trees, which can only come from AT.
   • This is a much easier case to explain and prime users for.
   • It's not clear to me what a fallback solution would look like here - mouse events could be targeted at the host node at the appropriate location if the location is set correctly, but that's about all I can come up with.

@jcsteh noted that more generic events would avoid this issue entirely, but as discussed elsewhere I don't think that will ever be an option, although perhaps @cookiecrook could give more background as to what happened with IndieUI here.

[raymeskhoury]

Sorry that I haven't read through the above carefully so I may be blatantly missing all the nuance. But it occurred to me that perhaps we could have an experience that is similar to page Translation. What I mean is that the website could say (using an API) "I can offer a better experience for the user if they use AT". This could cause Chrome to then expose some kind of passive UI to the user - similar to what Translate provides, that says "This site may provide a better experience for users of screen readers. Do you want to enable this?". Accepting would then either reload the page and send an extra header, or fire an event. Obviously this would only show up if you are using AT.

[LJWatson]

The difficulty with an "opt in" approach, is that it requires the user to choose between privacy and accessibility.

[cookiecrook]

accessibleclick came from IndieUI as a Mozilla proposal. @eeejay wanted to use it for the "slide to unlock" feature on FirefoxOS. This mirrors the support of native activation events, where the mainstream user has to perform a gesture, but a screen reader or switch interface can trigger an accessibility-specific activation.

[cookiecrook]

@raymeskhoury wrote:

…expose some kind of passive UI to the user - similar to what Translate provides, that says "This site may provide a better experience for users of screen readers. Do you want to enable this?". Accepting would then either reload the page and send an extra header, or fire an event. Obviously this would only show up if you are using AT.

+1 to passive UI, but not to the HTTP header. Check out the matchMedia-based event model sketched for IndieUI (@michael-n-cooper, is there an updated link for the old W3C Mercurial pages?).

Summary:

1. Passive UI appears for AT users on first matchMedia request, but always returns "no" to the page.
2. If user accepts, fire a match media changed event.

These new events would not follow the matchMedia patten, but UI could behave similarly... Passive UI until user accepts. For example, on first capture of accessible click, a standard click would go through (web page cannot easily distinguish between this and a mouse click) then passive UI is shown. Any subsequent captures after user accepts could send the new events.

[eeejay]

Here is the thread on that "activate" event in IndieUI. I think I still agree with myself now. I proposed an "activate" request that would perform the element's "default" action, and hoped that the web can move on from the "click" misnomer because a default action is not always a mouse click (like a lockscreen slider).

I also agree with @jcsteh in issue #51:

In order to fill the gap in current experiences, what we really need here is input agnostic events, not accessibility specific events.

I would like to see a separate spec tackle multi-modal input that separates intent from action like indieui events did, and not include it in a spec that is explicitly meant for assistive technologies. The scope goes well beyond AT clients: integrating with special platform input methods, form factors, etc.

AOM can then determine what actions an object supports by its listeners, and won't compromise a user's privacy.

Of course, I just popped in to this convo because I was tagged. I'll leave the rest to folks who are working hard on this :)

[cookiecrook]

My response from the same thread:

[click is] only mouse-centric in its onomatopoetic name. Click has been the de facto input-agnostic activation event for more than a decade, and user inputs from all modalities have the ability to trigger a click.

In an ideal world, or with a new API, I'd agree with you, but practically speaking, click is not likely to be replaced with DOMActivate (tried and failed) or any other modality-agnostic name.

That said, I'd be happy to change "AccessibleClick" to "AccessibleActivate" if we don't pull it entirely.

[alice]

@cookiecrook

That said, I'd be happy to change "AccessibleClick" to "AccessibleActivate" if we don't pull it entirely.

Obviously that doesn't get us away from accessibility-specific events. I would very much like to address @LJWatson and @jcsteh's concerns there.

If we consider the two use cases I outlined above, can we begin by discussing whether or not we need each of them, or what the privacy trade-offs are?

1. Listening to accessibility-specific events such as "increment" in order to provide a native-like experience for a custom widget (including the "lock screen slider" type case).
2. Listening to events targeted at virtual accessibility trees.

[patrickhlauke]

coming in late with a naive thought: what if the events were not explicitly "accessibility" events that are only fired when AT is present, but rather high-level intent events that are fired for any kind of input, in whatever way is appropriate for that kind of input? I know we keep coming back to the (defunct and never implemented) Indie UI Events idea somehow, but there's a lot of merit to it ... (and to be clear, having these events fire in addition to whatever current events are fired, e.g. key events, click, mouse* ones, etc ... though then authors will need to de-dupe events to avoid triggering things twice)

[jcsteh]

That's the solution I (and others at Mozilla) have been advocating, but it seems to be suggested that this won't fly because it didn't with IndieUI. I still haven't seen an actual solid justification as to why, though.

[alice]

Right, that suggestion was actually made up-thread in this issue.

Rather than jump immediately to solutions, I would really like to talk about the use cases I asked about earlier:

If we consider the two use cases I outlined above, can we begin by discussing whether or not we need each of them, or what the privacy trade-offs are?

• Listening to accessibility-specific events such as "increment" in order to provide a native-like experience for a custom widget (including the "lock screen slider" type case).
• Listening to events targeted at virtual accessibility trees.

[cookiecrook]

@jcsteh wrote:

That's ["high-level intent events"] the solution I and others at Mozilla have been advocating, but it seems to be suggested that this won't fly because it didn't with IndieUI. I still haven't seen an actual solid justification as to why, though.

Not just IndieUI (~2012) or Intentional Events aka Semantic Events (2008?), but several other attempts that didn't make it as far.

The short version is that it turns out to be really hard to make a single event that works for mouse pointers, touch, eye gaze, screen readers, dwell controls, switch software, keyboards, etc. Even the discrete events (e.g. escape) were controversial. When you get into continuous events (mousemove, touchmove, "eye gaze move", "screenreader adjust value via a touch screen gesture", etc), it gets much, much more difficult. I certainly see the value in it, but I no longer think that delaying an accessibility-specific approach is the right path forward, which is why I and other suggested mainstream events should be out-of-scope for AOM.

With the best of intentions (pun intended) we inadvertently delayed basic web accessibility functionality (accessibility events) that exists on all native platforms as accessibility-specific API. We really needed these 10 or 15 years ago. If they are later replaced by a better API, well, that's the Web.

As Voltaire put it: “[Perfect] is the enemy of the good.” Let's ship something functional.

[cookiecrook]

@Alice wrote

• Listening to accessibility-specific events such as "increment" in order to provide a native-like experience for a custom widget (including the "lock screen slider" type case).

Necessary for ARIA sliders, among other things.

• Listening to events targeted at virtual accessibility trees.

Also necessary. If virtual AX trees are to exist at all, they need an event model.

[alice]

Necessary for ARIA sliders, among other things.

How far could we get with a richer keyboard event model which is "faked" the same way a click event results from a touch event?

This is the case which gives me the most pause, because of the "accessible web component included across hundreds of websites" case. Users have no way to know what they are opting into and why, and the site likely doesn't even realise that users will be prompted.

Also necessary. If virtual AX trees are to exist at all, they need an event model.

I agree, but I feel like this case is easier to solve, because it is possible to "prime" the user before asking permission.

For example, imagine if you have a canvas app which requires an extensive virtual accessibility tree. You may not want to compute the virtual tree for all users, so you could have an (accessible, HTML based) explicit opt-in which explains to the user that they will be prompted for permission so that they can interact with an interface which is only exposed to assistive technology.

This is not a perfect solution, but for things which literally have no other way to be made accessible, virtual trees are a necessity, and as you say they require an event model, so at least we can create a user experience which includes informed consent.

[cookiecrook]

Closing since "focus" has since been removed.