Meeting minutes
New PR Triage
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
keithamus: I had an old PR, I updated it, also it's not on my fork, please review
jamesn: is it implemented yet?
keithamus: have implemented in firefox, not implemented in chrome
jamesn: needs reviews
keithamus: scott reviewed the prior PR
keithamus: updated in light of scotts commentary
scott: I assigned it myself covertly
Rahim: add me
clay: I'll review
pkra: me too
james: mappings for popover hint
keithamus: implemented and chrome, soon shipping in gecko, need a good review -- review is blocking!
scott: I'll review
keithamus: I need reviews from the non-engine side, I'm doing what chrome is doing, not sure its right. I want to know what people want from tooltips and these types of patterns
sarah: I will review
aardrian: I'll review too
jamesn: would be good to have someone from webkit
jcraig: fine you can put me
New Issue Triage
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
scott: rahim or I will take this
scott: going through PRs that haven't been merged, this is an outstanding request from rahim
scott: embed is similar to iframe
scott: use it to present graphics and an entire webpages other content. it works the same as iframe for naming
scott: doesn't need assing
pkra: I don't remember, assign it to me
jamesn: ok, so, would anyone like to investigate this? first stage is to work out whether this is supported across many platforms, accessibility APIs and maybe AT. Does this need expanding accessibility APIs?
jcraig: do we have anyone on the microsoft side that knows anything about excel?
jcraig: I can ask about numbers
spectranaut_: I'll look into the libreoffice side
jcraig: maybe reaching out to ben for the microsoft side....?
sarah: I can reach out to excel folks
sarah: my team works with office online... but maybe they know who works with native
jcraig: we want to know what is support on platforms specifically
jcraig: because we know it is not supported on the web
jamesn: I'll add agenda so we can bring it back
jamesn: there is a document, using ARIA, which is maintained by steve, its not within our working group. If you have ideas, share it in the issue, otherwise editors will make a decision
Daniel: we are trying to get steve's input too
jamesn: we talked about this in editors, the decision was to match reality of implementations
cyns: you can assign it to me
pkra: this a feature of svg 2
jamesn: did we already talk about this....
jamesn: keithamus found the tests
jamesn: are there results of the tests...? that would be handy for this
pkra: there is an accname side of this. it isn't really mentioned in accname. it just talks about css content. the implementations do take it into account.
jcraig: css defines what the css content is, so it might not need an edit. the accname spec should point to the css spec, and the is definitive enough to write tests for it
pkra: i didn't see a lot of css content alternative tests
pkra: if you read accname you might miss it, could use a note
jamesn: accname references lots of spec
(I missed something james said)
Rahim: can we add a label....
jamesn: the issue is in CSS AAM
jamesn: personally, I think things like htisi should be in CSS AAM
jamesn: implementation details like this that impact accessibility are noted
pkra: I filled this for three reasons, one is that it is talking about aam side of things, two mentions CSS-AAM specifically, third is the accname part mentions speech
pkra: we should do something from our end is import to clarify what is going on when you use these things
aardrian: one nugget, this issue appears to be looking at three different documents. developers try to read and follow the accname spec. last week I had a convo about css carousels -- sometimes in the accname it is implied not clear
aardrian: the expectation is that accname covers any input that feeds into accname
pkra: so it covers css content but not alternatives
aardrian: right
pkra: it references css-2 which doesn't have alternatives
spectranaut_: I think we should agenda this
WPT Open PRs
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
Deep Dive planning
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
jamesn: none here, anyone want to propose....?
Webkit landed ARIA notifty and Gecko is implementing! \o/
jamesn: an fyi! yay!
<smockle> w3c/
spectranaut_: there were questions from jamie teh and Jacques just answered, and Jacques will make one more update in response and we will land
smockle: but should we actually document that thing?
Matt_King: I think so
smockle: (explains why he thinks it should not be explicit)
keithamus: we have a warning in the dev console ....
jamesn: it should be valid for pages to fire it, it's jut not going to be delivered
keithamus: its an opp to educate users
jamesn: and you should be firing so many that that is a problem
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
jamesn: I think this belongs in the spec
Jacques: so is this a note in the spec?
jamesn: I think it should be normative, maybe a should or should not
Jacques: sounds good to me
jamesn: I think it's best practice
Jacques: if someone is doing this.. they should be aware it won't get to the user...
jamesn: if it is in the background, the visual user won't get it
jamesn: what do folks thinks?
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
scott: I was thinking about (??) messages....
scott: (scribe missing)
<aardrian> status messages
scott: In APG examples, we will need to call out something related to this
<aardrian> specifically SC 4.1.3
jamesn: we need to help with specific technique for WCAG
scott: I know they will appreciate it
mcking: if it is a MUST NOT, is that eliminating a use case we are not thinking of by being to restrictive
jcraig: yeah, good job matt, that is what I was going to say
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.
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
jcraig: voiceover has activities
jcraig: might be premature
<Matt_King> +1 for should not
jamesn: if we made it should not, allows browsers or AT or expose things in the future...?
jcraig: you are putting this change on the engine, I think the AT should make the decision
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
jcraig: I think this should be a note, basically
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
smockle: I was going to raise a similar clarification, inactive tabs vs inactive window, two browser windows tiled, wanting notifications from both
<smockle> WebKit/
smockle: secondly, everything said around allowing this to not be prescriptive, reminds me of webkit standard perspective
smockle: that different technologies can handle annoyance differently
<Zakim> Matt_King, you wanted to ask if talking about author req or UA req
smockle: and this is an opportunity for competitive innovation
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
jamesn: authors don't know whether tabs are in the background
jamesn: what should we do....?
<jcraig> The WebKit standards position reference that Clay mentioned: WebKit/
<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."
Matt_King: we need to be consistent, that effects the AT, if each user agent is doing something different
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.
scott: I think we don't need a user agent requirement
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.
Jacques: authors need to be aware this can happen, no restrictions
jcraig agrees
Matt_King: saying AT "might" do this is clear enough to me
Matt_King: but the UA need to be doing the same thing with the same web page.
jamesn: (scribe missed)
smockle: do we define what UA should do for live regions?
jamesn: no
spectranaut_: I suggest we merge and do this in a follow up
Jacques: I'll make a follow up note
RESOLUTION: 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: w3c/
Should :target-current pseudo class also imply aria-current=true on an active scroll marker?
Jacques: I added this for lucas
dgrogan: this came out of a blog post from sarah....
dgrogan: we implemented the suggestion, CSS wanted something firmer from the accessibility group
dgrogan: we think it is a good recommendation and it solves a real user problem
dgrogan: we'd like to hear agreement or just that no one objects
sarah: I was curious, there was discussion about different implicit roles, there has been talk about scroll markers having different mapped roles both on how they are used, or maybe adding something for authors to change what type of control the scroll marker would be, even those with role none, because aria-current is not valid on every possible role proposed for scroll markers.
Daniil: explains....... (scribe missed)
sarah: ok this doesn't exactly apply to what I'm talking about (????)
<Zakim> jcraig, you wanted to agree with using the same platform mapping, but to point out a potential problem with ARIA mapping conflicts re: 'strong native semantics'
jcraig: so what it currently says, the last paragraph, we should set aria-current=true, setting the dom or content attribute I don't really agree with, that would be a surprised to authors if those attributes change unexpectedly. the native implementation of target current should use the same platform mappings that aria-current uses. add an author note to not cross the streams, don't mix and match, aria has this concept called strong native semantics --
html wins over ARIA in some cases
jcraig: in this particular case, some is coming from pseudo class, dom, etc
jcraig: ultimately, there should be a mapping. maybe we will have a scenario where and author mixed the two... we probably want to do what the author wants
Daniil: just for styling....
jcraig: visiting links are just for styling, but those are communicated to AT
jcraig: this should NOT change any content attributes like aria-current
jamesn: no resolution yet, we need to discuss more next week
<jcraig> visiting links are just for styling, but those are communicated to AT/you said this is "just for styling" but many think :visited links are just for styling, but those are communicated to AT; so this can be the same in the native mapping/