Meeting minutes
[New Issue Triage](https://bit.ly/3CH8cfG)
https://
jamesn: let's leave this to simmer for a bit and discuss next week
jamesn: https://
jamesn: https://
https://
jamesn: why not support on role="group"?
aaron: seems like it get revoked, maybe not intentionally?
aaron: fieldset is a group, and fieldset you can still disable
stefan: original idea declare an entire group, all children get disabled. old discussion
jamesn: milestone 1.3? anyone want to be assigned to determine a proposal?
sarah_higley: scott already has a PR for it
jamesn: is this a deuplicate?
sarah_higley: related to aria-disable 1130 issue...
jamesn: milestone 1.3, lets revist after the other issue is resolved.
https://
jamesn: spec or practices?
sarah_higley: we just moved an issue over to APG related to overflow tabs, seems related to this and secondary tabs.
sarah_higley: you can assign to me
jamesn: milestone 1.3 not to lose
https://
scott: you can assign this issue to me, but not a 1.3 issue....
jamesn: does this need normative changes?
scott: no
jamesn: maybe brennan can do it?
jamesn: let's ask him
jamesn: I won't assign it to you yet, but we can come back and assign you later on if need be
[New PR Triage](https://bit.ly/3wcnVRy)
jamesn: https://
https://
https://
scott: will need implementation when lands. no aria-spec impact, just html
jamesn: we should have implementation review
jcraig: I'll review
aaron: I'll review
joanie: I'll review
[Deep Dive planning](https://bit.ly/aria-meaty-topic-candidates)
jamesn: next week I can't do the deep dive
jamesn: anyone else on holiday?
jamesn: I guess we should meet next week!
jamesn: because we have so much to do, but no deep dive. if you have a topic for the following week, please send
[Updating ARIA 1.2 due to IDL implementations (exit and re-enter CR?)](https://github.com/w3c/aria/issues/1598)
<jamesn> https://
jamesn: I created a pr based on our discussions during the meeting last week
jamesn: I would like more reviews
jamesn: we have no implementation in a shipping spec of IDL
jcraig: only in the browsers
jamesn: can aaron ping dominic?
aaronlev: yes
jamesn: I'll try pining dominic and anna in the thread?
jamesn: this is the most urgent thing we are doing, it is the blocker for 1.2, I would appreciate as much review as possible on this!!!!
[A role for indicating whether a given ruby represents phonetics ](https://github.com/w3c/aria/issues/1620)
jamesn: is there still work to do on this?
jcraig: seems like he is open to us closing it
jamesn: can I leave it to you and aaronlev to finalize these issues and close it out?
jcraig: I'm going to close issues 1619 and 1620, and if we need to reopen we can
[Updated spec text to reflect the processing of hidden elements when c…](https://github.com/w3c/accname/pull/137)
aaronlev: I feel like the innertext was a nice simplification until we realized there were too many details
aaronlev: firefox doesn't implement it quite correctly
jamesn: having inconsistent implementations.... is a problem
jamesn: is your solution for chrome a solution other people could use?
aaronlev: I think so, you can make an accessible object for a dom node even it is not in the final platform tree
aaronlev: it might be harder in other browsers
aaronlev: because of the number of accesisbility APIs we support, with only one tree in blink, and we have to send from render to browser process... we have ways of skipping nodes in output
aaronlev: when we are computing name we can use fuller tree
aaronlev: I think firefox will have to move to that model as well
jamesn: does the fact that we don't have consistent implementations mean we can get to CR, or it's ok because it has always been broken?
aaronlev: chrome, we can do it based on the spec now or based on some different innertext thing
aaronlev: probably firefox and webkit can support current spec, but its probably harder
aaronlev: we are flexible if you want to do something else
<Zakim> joanie, you wanted to ask what exactly what the spec says now means
jamesn: currently everything is broken in a different way
joanie: what do you mean when you say what you implemented what the spec says... I think the spec says don't go down the tree!
joanie: apple does what the spec currently confusingly says
joanie: the spec is in accname, if the div is hidden, it's innertext, but any children that are not directly references by the idea of aria-labelled by, they are not included
jcraig: brian wrote the first version of the spec change, I clarified, pull 137 -- if chrome is doing that specifically, but this PR mentions innerText, chrome is not using innerText?
jcraig: aaronlev can you reply with PR changes to match your implementation...?
<pkra> sorry, have to drop off.
matt_king: joanie, your summary... I thought the whole purpose was for this to be understandable by users, web authors who are trying to make accessible labels. my interpretation of what aaronlev was saying is that chrome is doing what people thought the spec is meant to say. What the spec actually says is bizarre and unexpected.
matt_king: I thought the point was to clear up and include the tree
aaronlev: you might want to have a hidden label or description..
bryan: .... a real world example I couldn't catch!
matt_king: good example
matt_king: is there a concern with the new proposal?
jcraig: if part of the label is displayed, and part not displayed, how do we computer? Once the ancestor is not displayed, we don't care why the sub level elements are not displayed.
jcraig: I don't think we should exposed those substrings willy nilly
jcraig: what is the PR change we can review, the devil is in the details, I can't tell you what I think until we see the PR
aaronlev: I don't think the double hidden is a real case. if people used aria-label... probably because it's in the dom already. if you have double hidden, you can expect predictable behavoir
sarah_higley: we reference tool tips via labelled-by or described by, it's hidden until you have focus, but we want the labelledby or describedby to be consistent. tooltips contain whatever text you want, some of it is display none, the displaynone in the displaynone tool tip I would expect as an author for it to NOT be used
matt_king: I can't imagine a display-none in a display-none
sarah_higley: it might be aria-hidden....
matt_king: I can understand that
jcraig: sometimes password fields have a bunch of rules, but only the unfullfilled criteria will be visible
stefan: is there a general idea of how to handle these nested situations generally???
bryan: in the case where it is area hidden... it doesn't matter what is on the inside
aaronlev: the problem with display none is that there is implementation problems. the browser will do many optimizations.
aaronlev: a lot of styling is not applied, its hard to have a special rule about display-none subtrees
aaronlev: if people want hidden sub trees in display-none... they would have to use aria-hidden, every other way of hiding something would not have an impact
jamesn: sounds feasible
jamesn: while we may have one user agent that works, we don't have consistency, so authors who are using this stuff are already broken. I don't care about breaking authors who are already broken in a slightly different way.
jcraig: aaronlev mentioned the only thing that can hid substrings in hidden elements is "aria-hidden=false", I don't think this is a fair expectation for web authors
jcraig: if you landed on the tool tip, and it is displayed, then you follow the expectations of hidden vs not hidden. if you land on the tool tip and it is NOT displayed for some reason, the aria-describedby is going to follow different rules
jamesn: displayed vs not displayed should not change the value
matt_king: I was going to say that might not be the best example.
jamesn: there might not be much to gain with this discussion. someone needs to come up with another example/fix for us to change our mind on the current change proposed
jcraig: if we make this change, we have three working implementations. aaronlev did point out some edge cases, I would propose that if that is the case, then we should point out that case in the implementation of innerText itself. it if it is the wrong value for accessibility, then maybe it's wrong for the web generally
jamesn: I doubt innertext will change for this
<aaronlev> maybe a deep dive topic?
<jcraig> +1
bryan: I will put example in this PR
<jamesn> https://
<Zakim> jcraig, you wanted to defend innertext
[Clarify how "otherwise interactive" relates to overriding the none/presentation role](https://github.com/w3c/aria/issues/1628)
jcraig: one of the webkit implementers raised this
jcraig: I think this means the spec is right but could use some clarification, and all the implementations are wrong in this case,
jcraig: if this element is interactive (including if its focusable), then the presentation role should be ignored.
jcraig: onClick should make something interactive and none role should be ignored?
jcraig: what about drag events?
jcraig: should we take delegation into consideration? like click event on body? everything can't be excluded from presentation
jamesn: lets discuss in the issue!
RRSAgent: make minutes