-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updated explainer with better wording around permission reconsideration and accessibility #17
base: main
Are you sure you want to change the base?
Conversation
Additional clarification & simplification of text
Added caveat that PEPC will require prototyping and real world testing to validate assumptions.
@@ -2,79 +2,83 @@ | |||
|
|||
## tl;dr | |||
|
|||
We propose a semantic permission element with styling constraints that ensures a | |||
We propose a <permission> HTML element with styling constraints that ensures a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We propose a <permission> HTML element with styling constraints that ensures a | |
We propose a `<permission>` HTML element with styling constraints that ensures a |
Some APIs, including geolocation & notifications, predate requiring user | ||
activation and support use without user activation for backwards | ||
compatibility. For this reason user agents may use unintrusive UI for these | ||
requests, which can easily be missed by users. User agents must navigate the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
requests, which can easily be missed by users. User agents must navigate the | |
requests, which, in some browsers, can easily be missed by users (e.g., browsers that don't present permission requests as modal dialogs). User agents must navigate the |
be accessible if properly implemented and tested, however, PEPC has explicit | ||
accessibility semantics by default. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is sorta true... but to have "explicit accessibility semantics", wouldn't it need an explicit ARIA role (which then maps to the OS's a11y model)?
PEPC does not to replace existing permission journeys to benefit a large | ||
fraction of the users who interact with permission gated capabilities. A | ||
relatively small number of sites account for a large fraction of permission | ||
requests with real world benefit, for example : |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
requests with real world benefit, for example : | |
requests with real world benefit, for example: |
|
||
Most of the implementation complexity of the PEPC lies in the annoyance | ||
reduction mechanisms. As previously mentioned, the main security surface is the | ||
"Confirmation UI" which is straightforward to implement. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Confirmation UI" which is straightforward to implement. | |
"Confirmation UI", which we believe is straightforward to implement. |
reduction mechanisms. As previously mentioned, the main security surface is the | ||
"Confirmation UI" which is straightforward to implement. | ||
|
||
This proposal describes a deliberately conservative set of annoyance reduction |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This proposal describes a deliberately conservative set of annoyance reduction | |
This proposal describes a deliberately restricted set of annoyance reduction |
|
||
This proposal describes a deliberately conservative set of annoyance reduction | ||
mechanisms with the aim to discovering in [developer trials](#developer-trials) | ||
which restrictions will be infeasible for users, developers or implementors. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
which restrictions will be infeasible for users, developers or implementors. | |
which restrictions will be infeasible for users, developers, or implementors. |
such Camera/Microphone or Location and the PEPC can share strings used in the | ||
existing permission journey. | ||
|
||
Developers will need to handle the `onvalidationstatuschange` event, which helps |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Covers both "onvalidationstatuschange" and .addEventListener("validationstatuschange"...)
:
Developers will need to handle the `onvalidationstatuschange` event, which helps | |
Developers will need to handle the `"validationstatuschange"` event, which helps |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couple of nits and comments...
Updated explainer with better wording around permission reconsideration and accessibility