Skip to content
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

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

andypaicu
Copy link
Collaborator

Updated explainer with better wording around permission reconsideration and accessibility

b1tr0t added 2 commits May 9, 2024 11:40
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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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

Comment on lines +192 to +193
be accessible if properly implemented and tested, however, PEPC has explicit
accessibility semantics by default.
Copy link
Contributor

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 :
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
"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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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
Copy link
Contributor

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"...):

Suggested change
Developers will need to handle the `onvalidationstatuschange` event, which helps
Developers will need to handle the `"validationstatuschange"` event, which helps

Copy link
Contributor

@marcoscaceres marcoscaceres left a 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...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants