tl;dr TOC and more #2
Conversation
TOC, tl;dr and additional discussion
Co-authored-by: Thomas Steiner <[email protected]>
Co-authored-by: Thomas Steiner <[email protected]>
Co-authored-by: Thomas Steiner <[email protected]>
Co-authored-by: Thomas Steiner <[email protected]>
Co-authored-by: Thomas Steiner <[email protected]>
Co-authored-by: Thomas Steiner <[email protected]>
- Expand on developer trial goals - Expand on complexity
explainer.md
Outdated
| We propose a semantic permission element with styling constraints that ensures a | ||
| very high level of confidence concerning *user intent* to make a permission | ||
| decision. We believe this solves user problems related to accessibility, | ||
| context, regret and more. The permission element is more accessible and more |
There was a problem hiding this comment.
Maybe change "regret" to what it means in terms of a user more easily revising a choice, as it might not be clear what that's referring to.
| @@ -1,5 +1,66 @@ | |||
| # Page Embedded Permission Control (PEPC) | |||
|
|
|||
| ## tl;dr | |||
|
|
|||
| We propose a semantic permission element with styling constraints that ensures a | |||
There was a problem hiding this comment.
Might be good to be more explicit, like:
We propose a semantic
<permission>HTML element
explainer.md
Outdated
| very high level of confidence concerning *user intent* to make a permission | ||
| decision. We believe this solves user problems related to accessibility, | ||
| context, regret and more. The permission element is more accessible and more | ||
| secure than the current current permission journeys as the semantic element is |
There was a problem hiding this comment.
nit: current current
Also, you probably don't need "semantic"
explainer.md
Outdated
| decision. We believe this solves user problems related to accessibility, | ||
| context, regret and more. The permission element is more accessible and more | ||
| secure than the current current permission journeys as the semantic element is | ||
| by default more screen reader friendly than JavaScript and full page modal |
There was a problem hiding this comment.
This is accidentally somewhat not correct (but not for the reason stated):
"default more screen reader friendly than JavaScript"
Because the permission prompts must always be tied to some input element that triggered user activation (i.e., it's not JS that's the limiting factor here, it's HTML and Aria). It might be better to say that the accessibility semantics are more explicit, because user activation can be tied to just about any element.
In the best case, developers go from:
<button id="micBtn" aria-label="Request microphone access" aria-describedby="micDesc" onclick="requestMicAccess();">Enable Microphone</button>
<div id="micDesc" style="display:none;">Clicking this button will prompt you to allow microphone access.</div>To:
<permission onclick="requestMicAccess();" type="microphone">
explainer.md
Outdated
| secure than the current current permission journeys as the semantic element is | ||
| by default more screen reader friendly than JavaScript and full page modal | ||
| confirmation UI reduces risk of change blindness and makes it more difficult for | ||
| sites to manipulate the user's decision making by obscuring site content during |
There was a problem hiding this comment.
The use of the "manipulate the user's decision making" sounds a bit nefarious... 🙈 I guess maybe it's supposed to, but is that really the intent? Or is it just hard for sites to get right because of how browsers show permissions?
There was a problem hiding this comment.
I'll just add here that this is also why some browsers make the permission prompts modal, so users can't really be confused by sites doing the wrong thing (e.g., on mobile Safari).
explainer.md
Outdated
| improvements to existing capability based permission journeys can and should be | ||
| explored, we believe there to have limited headroom for optimization, and that | ||
| this proposal offers a significantly better user experience for users and | ||
| developers. |
There was a problem hiding this comment.
Not much to change here, but I would say that in the case of, for instance, mobile devices, I don't know if this really holds. The problem of where the permission prompt is show somewhat goes away when the dialog is modal.
| of the user's interaction in the content area, and the user's intent. At the | ||
| moment user agents are limited to trying to make use of potentially ambigous | ||
| signals such as the time elapsed between page load and the permission | ||
| request. |
There was a problem hiding this comment.
Maybe another thing to say here is that some APIs (e.g., geolocation and notifications API) predate requiring user activation, so for legacy reasons allow being called without user activation... leading to various browser mitigations you just mentioned.
| presenting an issue for both screen readers and magnification users. | ||
|
|
||
| Script attached to an existing DOM element is not interpreted by the screen | ||
| reader. If the DOM element was not accessibility tested and does not provide |
There was a problem hiding this comment.
I'm still not sure it's about "accessibility tested"... it's just that ARIA doesn't really cover permission requests at all, so it requires a fair bit of work for developers to express what's about to happen or what a input/button will do.
There was a problem hiding this comment.
So, yeah, I don't think it's fair to say that the there is "no way to know"... there clearly is, but it just requires a lot of additional markup and it could be improved.
Irrespective of what we do here, we should look at adding some kind of permission prompt role to Aria.
| user to know that the purpose of that element is to initiate access to a | ||
| capability. | ||
|
|
||
| Magnification users also struggle with the status quo. A page cannot detect |
There was a problem hiding this comment.
Maybe: "Users using magnification tools also..."
| Magnification users also struggle with the status quo. A page cannot detect | ||
| if a user is using OS level magnification tools (WAI for privacy reasons). A | ||
| user in a magnified state can easily miss the permission prompt if it falls | ||
| outside of their magnified viewport, and pages cannot assist these users. |
There was a problem hiding this comment.
This one is challenging because notifications and prompts can be multi-modal: for example, a permission prompt modal could vibrate and chime, more clearly signifying what is being asked. At the same time, that's those kinds of prompts are not convention on desktop environments - but that's not to say that overall tooling couldn't be enhanced, and it begs the question how this would integrate with OS tooling to support magnified displays.
| if a user is using OS level magnification tools (WAI for privacy reasons). A | ||
| user in a magnified state can easily miss the permission prompt if it falls | ||
| outside of their magnified viewport, and pages cannot assist these users. | ||
| With PEPC, the scrim and a contextually localized prompt greatly increase |
There was a problem hiding this comment.
greatly increase
The jury is still out as to whether this claim can be made.
| consistent across websites. The scrim and a contextually localized prompt | ||
| greatly increase the chance that a magnification user will observe the | ||
| permission request after interacting with the element. |
There was a problem hiding this comment.
contextually localized prompt
I still think this oversteps what would traditionally be in standard with respect to UI. Although PEPC affords the opportunity to "contextually localized prompt", that might not be convention for either the browser or for the OS. Thus, it can't be taken as a given that all browsers would display a "contextually localized prompt" as a pop-over where a click happens.
You can also see this with how Microsoft Edge chose to implement Web Share on Mac... in Safari we did a "contextually localized prompt" for Web Share, while Edge chose to do a drop down from the top of their browser UI. On Windows, Firefox shows a modal prompt, because that's Window's convention.
| [fallback](#fallbacks-when-constraints-are-not-met) if the language is not | ||
| one that the user speaks. | ||
| The global | ||
| <a href="https://html.spec.whatwg.org/multipage/dom.html#attr-lang">lang</a> |
There was a problem hiding this comment.
This conflicts with user preference. Although the page is, say, in French (and automatically translated), the user's UI preference for prompts might be in Spanish. The lang should only really be used to indicate that <span lang=es>esto está escrito en español.</span> but not to override that user's preference.
There was a problem hiding this comment.
Ah, never mind... you say the same thing below... I don't think it's worth mentioning this at all, to be honest, as it's confusing.
|
|
||
| 1. Accessibility. Native HTML elements (such as the proposed permission element | ||
| in this explainer) come with built-in roles, properties, and keyboard | ||
| interaction behaviors understood by assistive technologies. While JavaScript |
There was a problem hiding this comment.
While JavaScript
Maybe:
"While existing HTML elements could be made more accessible"
| in this explainer) come with built-in roles, properties, and keyboard | ||
| interaction behaviors understood by assistive technologies. While JavaScript | ||
| solutions can be *made* accessible, the PEPC can be accessible by default. | ||
| 1. User intent. JavaScript triggered UI journeys will never be able to capture |
There was a problem hiding this comment.
will never be able to capture
I still feel this hinges on a bunch of presuppositions that don't hold true for all browsers and other possible combined solutions (e.g., defining a "permission-prompt" aria role or something, which we would need to do regardless for <permission>)
| solutions can be *made* accessible, the PEPC can be accessible by default. | ||
| 1. User intent. JavaScript triggered UI journeys will never be able to capture | ||
| user intent the way we believe is possible with PEPC. User gestures are | ||
| easily gamed by manipulative or malicious websites. It's difficult to see |
There was a problem hiding this comment.
I just don't think this is a universally held view, but that's ok. However, these kinds of statements become problematic for the explainer because it will be representing a single browser engine's opinion, rather than community consensus.
| 1. Context. While sites *may* do a good job with providing context to the user | ||
| about why a permission journey is happening, the PEPC *ensures* the context | ||
| is present with consistent button UI and labels, and strong signal of user | ||
| intent. |
There was a problem hiding this comment.
at the same time, it does introduce a new UI language and affordances to the Web. It's not proven yet that these will be more effective than existing solutions - or that this new solution would be adopted over existing solutions, given the potential lack of flexibility with <permission> VS existing <button> + JS solutions.
| It's undesirable for browsers to allow users to reconsider past decisions | ||
| with the usage-driven UI model, as enabling reconsideration would present | ||
| spammy or abusive websites the ability to repeatedly prompt users who block | ||
| a permission request. Help text directing users to navigate browser UI to |
There was a problem hiding this comment.
I think this depends on how the UI model is handled. If it's made too easy change things, then sure... but if the UI introduces some road blocks, or changing permissions is only available in certain scenarios, then this is debatable.
My fear and sense is that this might be taking a very much single vendor/OS view of how permissions UIs are handled, and this proposal may be trying to overcome limitations of maybe a particular browser or OS. That's not to say that these issues are not universal, but that's my concern reading this proposal at the moment.
|
|
||
| We believe these aspects of the proposal offer the most user utility when | ||
| bundled. If we only improve the user intent signal with a permission element, we | ||
| fail to solve for change blindness and accessibility problems for magnification |
There was a problem hiding this comment.
Right, like "change blindness" is not necessarily and issue on browsers and platforms that present a modal dialogue, together with, other visual clues (e.g., darkening the page in the background, so to still give context for the permission prompt, but preventing interaction with the page).
Another example here is how Payment Request (or even file picker) works.
No description provided.