Add ariaNotify#2577
Conversation
✅ Deploy Preview for wai-aria ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
@cookiecrook, @jcsteh, @front-endian, thanks in advance for reviewing this change! While I'll be out of the office from tonight (July 29th) until next Tuesday (Aug 5th), I'll be able to answer questions or make clarifications, just with a delay. Once I am back on July 11th, I can apply any feedback to this PR. Looking forward to hearing your thoughts! @scottaohara, while I'll be out, would it make sense for this to be added to the agenda for this or next week's meeting, or would that only make sense if reviewers had something they would like to discuss specifically? I just want to ensure this keeps momentum. Adding a few relevant links in case they are helpful:
|
|
@keithamus why is there also another PR with the same name, should we close it as a duplicate? #2211 |
|
@cookiecrook, @front-endian, friendly ping to PTAL at this when you get the chance! |
front-endian
left a comment
There was a problem hiding this comment.
Left some minor suggestions and questions around two bits that might be able to be written a bit clearer, but everything else looked good to me.
| <section id="arianotify-permissions-policy"> | ||
| <h3>Permissions Policy Integration</h3> | ||
| <p>This specification defines a [=policy-controlled feature=] identified by the string <code><dfn class="permission">"aria-notify"</dfn></code>. | ||
| It has a [=policy-controlled feature/default allowlist=] of <code class=permissionspolicy>"*"</code>. |
There was a problem hiding this comment.
I'm working on implementing this in Gecko and I was asked about why this is * and not self:
Usually new APIs should be using 'self'.
I replied:
I'm not sure of the background behind this decision. This is about messages that are reported to users, so I guess a site would normally not want to interfere with that for iframes it chooses to load, since that effectively breaks some of the functionality of the iframe. The only time you'd want to disable it is if an iframe you're loading behaves very badly and spams users with annoying messages.
Replies:
But why would a site then load such iframe at all? Would they even notice that a bad site is spamming users.
IMO, this is a fair argument and I don't have a good response for it. @janewman, could you give me some background on why the decision was made to default this to * rather than self?
There was a problem hiding this comment.
While I can contrive a situation where the badly behaving iframe is still needed for xyz reason, this isn't a strong opinion at all.
I think this came from wanting to be as permissive as possible, tracked down to this thread: whatwg/html#11004 (comment)
|
Another question that came up as I'm implementing this: should we restrict this so it only fires when the document has focus/is in the foreground? I think we should. I don't think background tabs should be able to fire announcements at the user. There may be reasons this happens implicitly - e.g. a browser might not fire events for background tabs, the tab might be a background OS widget and so screen readers ignore it because of that, etc. - but I think it's worth calling this out explicitly so there's no room for interpretation. |
Agree this would be worth being explicit about. I just did a sanity check and verified that this is the current chromium behavior, I'll update this PR with language that restricts this shortly. |
|
The ARIA Working Group just discussed
The full IRC log of that discussion<Zakim> agendum 5 -- Webkit landed ARIA notifty and Gecko is implementing! \o/ -- taken up [from agendabot]<spectranaut_> jamesn: an fyi! yay! <spectranaut_> q+ <jamesn> Ack spectranaut_ <smockle> https://github.com//pull/2577 <spectranaut_> spectranaut_: there were questions from jamie teh and Jacques just answered, and Jacques will make one more update in response and we will land <spectranaut_> smockle: but should we actually document that thing? <spectranaut_> Matt_King: I think so <spectranaut_> smockle: (explains why he thinks it should not be explicit) <spectranaut_> keithamus: we have a warning in the dev console .... <spectranaut_> jamesn: it should be valid for pages to fire it, it's jut not going to be delivered <spectranaut_> keithamus: its an opp to educate users <spectranaut_> jamesn: and you should be firing so many that that is a problem <spectranaut_> Matt_King: we have a lot of useful notes in teh ARIA spec for authors, so whether or not it belongs in the spec is an editorial call. it is nice to have those, though <Jacques> q+ <spectranaut_> jamesn: I think this belongs in the spec <spectranaut_> Jacques: so is this a note in the spec? <spectranaut_> jamesn: I think it should be normative, maybe a should or should not <spectranaut_> Jacques: sounds good to me <scott> q+ <spectranaut_> jamesn: I think it's best practice <spectranaut_> Jacques: if someone is doing this.. they should be aware it won't get to the user... <spectranaut_> jamesn: if it is in the background, the visual user won't get it <scott> q- <scott> q+ <spectranaut_> jamesn: what do folks thinks? <spectranaut_> ack Jacques <jamesn> Ack scott <spectranaut_> ack scott <spectranaut_> scott: I would agree it should be in the spec and a MUST, it would lead to problems with users if other pages are screaming at you <spectranaut_> scott: I was thinking about (??) messages.... <spectranaut_> scott: (scribe missing) <aardrian> status messages <spectranaut_> scott: In APG examples, we will need to call out something related to this <aardrian> specifically SC 4.1.3 <spectranaut_> jamesn: we need to help with specific technique for WCAG <jcraig> q+ <spectranaut_> scott: I know they will appreciate it <jcraig> ack me <spectranaut_> mcking: if it is a MUST NOT, is that eliminating a use case we are not thinking of by being to restrictive <jamesn> Ack jcraig <jamesn> q+ <spectranaut_> jcraig: yeah, good job matt, that is what I was going to say <spectranaut_> jcraig: there is some level of support for AriaNotify that can use existing notification mechanism, other things that might be adopted by screen readers and platforms, AT portions of AriaNotify. one of the things we discussed internally was exactly this, what are the usecase for whether you want to monitor, not a background tab, but background windw -- the window is rendered, a sighted user can see it, maybe someone wants to monitor it. <spectranaut_> Front most tab or window. it would be premature to lock a limitation to the spec for the exact reasons -- leave flexible for implementers to handle annoyance factors <smockle> q+ <spectranaut_> jcraig: voiceover has activities <spectranaut_> jcraig: might be premature <Matt_King> +1 for should not <spectranaut_> jamesn: if we made it should not, allows browsers or AT or expose things in the future...? <spectranaut_> jcraig: you are putting this change on the engine, I think the AT should make the decision <spectranaut_> jcraig: putting the should not requirement on the engine, is more rigid and less flexible then allowing the AT to ignore things in certain contents. The engine can throw out notifications, the AT should decide what to communicate or pass or put in background log <spectranaut_> jcraig: I think this should be a note, basically <jamesn> Ack jamesn <spectranaut_> jamesn: I want to confirm, the implementations today work the same as a live region implementation today, which doesn't fire notification on background tabs... so we are following the same, would that be a reasonable way of doing this <jamesn> Ack smockle <jamesn> q+ Matt_King <spectranaut_> smockle: I was going to raise a similar clarification, inactive tabs vs inactive window, two browser windows tiled, wanting notifications from both <jamesn> Agenda? <smockle> https://github.com/WebKit/standards-positions/issues/370#issuecomment-3229961127 <Matt_King> q+ to ask if talking about author req or UA req <spectranaut_> smockle: secondly, everything said around allowing this to not be prescriptive, reminds me of webkit standard perspective <spectranaut_> smockle: that different technologies can handle annoyance differently <jamesn> Ack Matt_King <Zakim> Matt_King, you wanted to ask if talking about author req or UA req <spectranaut_> smockle: and this is an opportunity for competitive innovation <jamesn> q+ <jamesn> Ack me <spectranaut_> Matt_King: I was confused by the beginning of the conversation... I haven't see the language ... are we talking about author or user agent requirement. If it is an authoring requirement, it should be a should not, if it is a UA requirement, that is different <spectranaut_> jamesn: authors don't know whether tabs are in the background <spectranaut_> jamesn: what should we do....? <scott> q+ <jcraig> The WebKit standards position reference that Clay mentioned: https://github.com/WebKit/standards-positions/issues/370#issuecomment-3229961127 <Jacques> q+ <jcraig> "concern-annoyance: misuse of this API may annoy or pester the user (a larger version of the same problem exists with Live Regions); browsers and/or assistive technologies should allow users to disallow usage by domain, but the spec should not be prescriptive about how this annoyance remediation is achieved. This is an opportunity for innovation and competitive differentiation." <spectranaut_> Matt_King: we need to be consistent, that effects the AT, if each user agent is doing something different <jamesn> Ack scott <Jacques> q- <Jacques> q+ <spectranaut_> scott: I actually changed my mind, I think really my concern about author guidance, should that be added here -- that people should know that it will be easier to use to communicate to users, it is easier to not know how info is being communicated by users. make sure people are careful where they can find such messages are coming from. <jamesn> Ack Jacques <spectranaut_> scott: I think we don't need a user agent requirement <spectranaut_> Jacques: I'm not clear... I'm not sure I'm clear on what I think. I agree UA and ATs, they should have the ability to do the filtering they want to do. Authors should be aware filtering can happen. would a note saying useragents and AT can do this filtering for inactive or background tabes. <spectranaut_> Jacques: authors need to be aware this can happen, no restrictions <spectranaut_> jcraig agrees <spectranaut_> Matt_King: saying AT "might" do this is clear enough to me <spectranaut_> Matt_King: but the UA need to be doing the same thing with the same web page. <smockle> q+ <jamesn> ack smockle <spectranaut_> jamesn: (scribe missed) <spectranaut_> smockle: do we define what UA should do for live regions? <spectranaut_> jamesn: no <spectranaut_> q+ <jamesn> Ack spectranaut_ <spectranaut_> spectranaut_: I suggest we merge and do this in a follow up <spectranaut_> Jacques: I'll make a follow up note <spectranaut_> RESOLVED: We will land AriaNotify and deal with the issue about what user agents should do with notifications from background tabs in a follow up, or what note to add to help authors understand filtering, in a follow up PR. <jamesn> GitHub: https://github.com//pull/2577 <spectranaut_> zakim, next item |
|
Here is the issue tracking the issue about what user agents should do with notifications from background tabs in a follow up, or what note to add to help authors understand filtering, in a follow up. |
|
@spectranaut, @jcsteh, I believe I've addressed any remaining questions/concerns, as discussed today we will do a follow up PR to document how user agents and ATs can choose to filter notifications, #2721 Let me know if there is anything left to do here, and if not, I'd love to see this merged 🍾 |
|
My security peers still have some concerns about the permissions policy being It's also been argued that live regions can already be abused by iframes, but I don't think this should be a significant factor: we should be trying to make new APIs better, not saddle them with the same problems the old APIs had. So I'd suggest that we dismiss that particular argument unless there are strong reasons it should matter. I'm trying to work out the best way to get this resolved. Personally, I could go either way, but it feels like we have a bit of an impasse here. If there's some appetite to discuss this further, perhaps we can merge this and agree that it needs to be discussed further in a timely fashion. That said, the decision we make here does have an impact on how authors use this, so I think it is substantive from a web compat perspective. |
This is my main concern. The author of the top level frame may not even be aware that ariaNotify exists, is being used, or is important for the accessibility of the hosted content. I think of the permission policy being more as a failsafe - hopefully it will never need to be used, but at least it is there if we need it. That said, if there is consensus in the other direction, this isn't something I'll hold out on. |
|
I re-read whatwg/html#11004 and w3ctag/design-reviews#1075, and I agree there are valid arguments on both sides. Two things stand out to me:
Footnotes |
|
My concern isn't just about authors, but users of that site. Here's an example: This could be argued that this is just a problem of site A's authors, but this scenario is why I have preference for opt-out rather than opt-in. (Notifications allowed unless author chooses to block a child frame).
In either case, authors have the option to block notifications from child frames via permission policy, this is just a question of what the default should be: should notifications be blocked by default, with authors able to add a policy to allow, or should they be allowed by default, with authors able to add a policy to block. |
|
The ARIA Working Group just discussed
The full IRC log of that discussion<Zakim> agendum 5 -- -> AriaNotify Permissions Policy -- needs resolution https://github.com//pull/2577#issuecomment-3787651067 -- taken up [from agendabot]<smockle> q+ <Daniel> scribe+ <jamesn> Ack smockle <jamesn> q+ <Daniel> Jacques: What concerns me is sites embeding content from other sites <Daniel> ... this is going to make adoption hard <jamesn> Q? <jamesn> Ack me <Daniel> Clay: I think there could be a list of allowed domains that we can reuse in the future <Daniel> Jacques: Don't think this would be even exposed to ATs <Daniel> JamesN: Is there anything we could ask browsers to do? For example, if something is allowed by defult or blocked by default that could ranslate to ARIANotify <Daniel> Jacques: That's where I'm not sure. The equestion is it should be allowed or blocked by default <Daniel> ... Authors may not know that they need to opt-in <giacomo-petri> +1 allow by default <Daniel> JamesN: I lean towards allowing by default, you can block bad actors when they start to misbehave <Daniel> ... If you don't trust the site you'll block JavaScript anyways and that's not going to work <Daniel> Jacques: Agree. <jamesn> Q? <Jacques> proposed resolution: we should allow arianotify to be allowed by default as written in the current version. <Daniel> Jamesn: Objections? <Jacques> �Resolved: we should allow arianotify to be allowed by default as written in the current version. <Jacques> RESOLVED: we should allow arianotify to be allowed by default as written in the current version. <smockle> q+ <jamesn> Ack smockle <Daniel> Clay: If we decide to change this, what would this look like? <Daniel> Jacques: It'd require implementation changes. I think allowing by default and then changing to denying by default would be an option <Daniel> JamesN: What we are resolving on today is not to give somebody something new that hey couldn't do with live-regions <Daniel> Clay: Yes, this is not going to work worse than live regions <Daniel> zakim, take up next |
|
Sounds like we have consensus to go with "*" for the policy, so I think that addresses the main substantive outstanding question on this initial version of the feature. While I accept the consensus decision, for the record, there are two points I think worth highlighting:
As per #2577 (comment), this is possible, but it creates a web compat problem, since something that was previously working in some cases would now stop working. In contrast, going the other way (more restrictive to less restrictive) is far less of a concern.
I don't think "this isn't worse than live regions" is necessarily a good reason to do something with ariaNotify. The whole point of ariaNotify is to improve on live regions, not to inherit its problems. |
|
@spectranaut at this point all issues have been addressed, should we merge? (I don't have the permission to do so myself) |
Recently added to the ARIA specification: w3c/aria@5c7229a w3c/aria#2577
Recently added to the ARIA specification: w3c/aria@5c7229a w3c/aria#2577
This adds the mechanics for introducing the ariaNotify API on Elements, which is a function that will map to various AT APIs, as defined in core-aam.
Aria Notify Explainer
Original PR: #2211
Test, Documentation and Implementation tracking
Once this PR has been reviewed and has consensus from the working group, tests should be written and issues should be opened on browsers. Add N/A and check when not applicable.
Preview | Diff