Concerns re: focus action #81
Comments
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.
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.
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:
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.
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?" |
|
Bringing this to the attention of @raymeskhoury and @jyasskin. Some comments from a permissions perspective:
|
|
@benfredwells wrote:
I anticipated this in the now-defunct IndieUI: User Context Privacy Model. I hope we would use something similar. Briefly, it was:
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. |
|
+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". |
|
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. |
|
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. |
|
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. |
|
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. |
|
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:
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. |
|
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>
.
|
|
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 |
Interesting idea. A couple of reasons I don't think that will work:
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. |
|
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 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. |
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.
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. |
|
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 |
|
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?
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? |
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.
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:
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? |
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 |
|
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. |
|
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:
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. |
|
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?
"Skip link" style user opt in What about at the browser level? What's the threat model
Dominic learning towards conservatism Issues
Auto denial
Maybe only allow "allow" and "ask", to avoid knowing about explicit denial? What about insecure http? 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. |
|
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:
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. |
|
Copying some comments from the other issue: 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. 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. |
|
@LJWatson also went into more detail on concerns here: |
|
Some thoughts bubbling around my head here... I feel like there are two main use cases for an AT event permission:
@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. |
|
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. |
|
The difficulty with an "opt in" approach, is that it requires the user
to choose between privacy and accessibility.
|
|
|
|
@raymeskhoury wrote:
+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:
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. |
|
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:
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 :) |
|
My response from the same thread:
In an ideal world, or with a new API, I'd agree with you, but practically speaking, 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?
|
|
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) |
|
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.
|
|
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:
|
|
@jcsteh wrote:
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. |
|
@alice wrote
Necessary for ARIA sliders, among other things.
Also necessary. If virtual AX trees are to exist at all, they need an event model. |
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.
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. |
|
Closing since "focus" has since been removed. |
Fine to leave
focusin for now (ref #80), but I have the following concerns about it:Thoughts:
The text was updated successfully, but these errors were encountered: