Editorial: ARIA Notify security prose, intro, and i18n example - #2869
Editorial: ARIA Notify security prose, intro, and i18n example#2869daniel-montalvo wants to merge 7 commits into
Conversation
✅ Deploy Preview for wai-aria ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
daniel-montalvo
changed the title
|
🚀 Deployed on https://deploy-preview-2869--wai-aria.netlify.app |
Co-authored-by: Giacomo Petri <giacomo.petri@usablenet.com>
Co-authored-by: Giacomo Petri <giacomo.petri@usablenet.com>
Co-authored-by: Giacomo Petri <giacomo.petri@usablenet.com>
daniel-montalvo
moved this to Needs Review
in ARIA Editorial (Spec Prose Updates) PR Tracking
Co-authored-by: Jacques Newman <44789917+janewman@users.noreply.github.com>
There was a problem hiding this comment.
Perhaps the i18n example should have been a different PR than the Sec/Privacy changes... I would have approved this example diff either way, but am marking the PR Review as a "Comment" (not "Approved") because of the questions in the lower Security section.
| <h2>Security Considerations</h2> | ||
| <p>This specification introduces no new security considerations.</p> | ||
| <p> | ||
| The <a>"aria-notify"</a> permissions policy has a default allowlist of "*". This relaxes the Permission Policy default because requiring embedders to opt in for each frame would leave announcements coming |
There was a problem hiding this comment.
I'm don't recall why this decision was made... Is it worth an editorial note pointing to prior discussions, or explaining why? I've never seen Live Regions abused in an ad frame, so maybe that's the reason? If theres a direct link to tjhis detail in the explainer or discussion, should it be listed or linked here?
| <p>This specification introduces no new security considerations.</p> | ||
| <p> | ||
| The <a>"aria-notify"</a> permissions policy has a default allowlist of "*". This relaxes the Permission Policy default because requiring embedders to opt in for each frame would leave announcements coming | ||
| from third-party content inaccessible by default. Cross-origin embedded content can invoke this user-facing channel without explicit delegation, which can cause uncontrolled disruption for uses of assistive technologies. Authors who want tighter control can still restrict the "aria-notify" policy explicitly, for example with |
There was a problem hiding this comment.
And there is is nothing stopping implementations from restricting this for untrusted sources, right? If not, we could mention that as a "UAs SHOULD/MAY" in the spec.
| <p> | ||
| The <a>"aria-notify"</a> permissions policy has a default allowlist of "*". This relaxes the Permission Policy default because requiring embedders to opt in for each frame would leave announcements coming | ||
| from third-party content inaccessible by default. Cross-origin embedded content can invoke this user-facing channel without explicit delegation, which can cause uncontrolled disruption for uses of assistive technologies. Authors who want tighter control can still restrict the "aria-notify" policy explicitly, for example with | ||
| <code><iframe allow="aria-notify 'none'"></code> or <code>Permissions-Policy: aria-notify=(self)</code>. |
There was a problem hiding this comment.
This might be seen as prioritizing author ease over AT users re: Priorities of Constituencies?
There was a problem hiding this comment.
Though that's not really a Security risk... It's more just a "user annoyance" pester risk.
There was a problem hiding this comment.
But if ariaNotify is mentioned in this context, should Live Regions be mentioned, too?
| <p> | ||
| The original page language is English, but there is a notification in Spanish. | ||
| </p> | ||
| <!-- ReSpec needs these examples to be unindented. --> |
There was a problem hiding this comment.
But they are indented.
| The original page language is English, but there is a notification in Spanish. | ||
| </p> | ||
| <!-- ReSpec needs these examples to be unindented. --> | ||
| <pre class="example highlight html"> |
There was a problem hiding this comment.
This example could be more terse, and might be easier to read if there is a generated element.
Something like:
// To create a one-off notification that doesn't match the
// language of the page or any other existing element, authors
// could append a dynamically created courier element.
var courier = document.createElement('div')
courier.setAttribute('lang', 'es');
document.body.appendElement(courier);
courier.ariaNotify('Este texto debería leerse con la voz en español'); Note: I did not test the syntax above. Please verify if you decide to use this.
There was a problem hiding this comment.
For clarity, this is a suggestion, but the longer existing example is fine if the WG prefers. (I have no objection to disregarding my suggestion here.)
4 participants
🚀 Netlify Preview:
🔄 this PR updates the following sspecs:
Addresses:
AriaNotificationOptions#2828