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 ***@***.***> 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 <#81 (comment)>, 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 w3c/webauthn#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.