16:55:35 <RRSAgent> RRSAgent has joined #aria
16:55:35 <RRSAgent> logging to https://www.w3.org/2021/09/30-aria-irc
16:55:37 <Zakim> RRSAgent, make logs Public
16:55:39 <Zakim> please title this meeting ("meeting: ..."), jamesn
16:55:39 <jamesn> meeting: ARIA WG
16:55:42 <jamesn> chair: JamesNurthen
16:56:51 <jamesn> agenda+ [New Issue Triage](https://bit.ly/3iilYxi)
16:56:51 <jamesn> agenda+ [New PR Triage](https://bit.ly/3mbRpdO)
16:56:51 <jamesn> agenda+ [Deep Dive planning](https://bit.ly/aria-meaty-topic-candidates)
16:56:51 <jamesn> agenda+ [TPAC 2021](https://github.com/w3c/aria/issues/1482)
16:56:51 <jamesn> agenda+ [Updating ARIA 1.2 due to IDL implementations (exit and re-enter CR?)](https://github.com/w3c/aria/issues/1598)
16:56:52 <jamesn> agenda+ [summary element role mapping](https://github.com/w3c/html-aam/issues/345)
16:56:52 <jamesn> agenda+ [When is hidden content taken into calculation of name and description?](https://github.com/w3c/accname/issues/57)
16:57:15 <jamesn> zakim, drop item 2
16:57:15 <Zakim> agendum 2, [New PR Triage](https://bit.ly/3mbRpdO), dropped
17:00:52 <WilliamTennisNFCU> WilliamTennisNFCU has joined #aria
17:01:45 <WilliamTennisNFCU> present+
17:02:01 <pkra> pkra has joined #aria
17:02:14 <pkra> present+
17:02:15 <jamesn> regrets+ CynthiaShelly
17:02:18 <MarkMcCarthy> MarkMcCarthy has joined #aria
17:02:20 <MarkMcCarthy> present+
17:02:38 <CurtBellew> CurtBellew has joined #aria
17:02:38 <joanie> present+ Joanmarie_Diggs
17:02:57 <CurtBellew> present+
17:03:03 <spectranaut> present+
17:03:20 <StefanS> StefanS has joined #aria
17:03:29 <WilliamTennisNFCU> It seems that I have lost the privileged ability of joining the video conference
17:03:41 <spectranaut> scribe: spectranaut
17:04:22 <pkra_> pkra_ has joined #aria
17:04:28 <WilliamTennisNFCU> I can log in, but it says I don't have privs to the zoom
17:04:40 <WilliamTennisNFCU> 403
17:05:02 <spectranaut> present+
17:05:38 <pkra_> https://www.w3.org/2017/08/telecon-info_aria
17:05:53 <WilliamTennisNFCU> I dialed in
17:06:10 <spectranaut> zakim, next item
17:06:10 <Zakim> agendum 1 -- [New Issue Triage](https://bit.ly/3iilYxi) -- taken up [from jamesn]
17:06:26 <Jory> Jory has joined #aria
17:06:32 <spectranaut> https://github.com/w3c/aria/issues/1622
17:06:41 <spectranaut> scott: I'm happy to do this for 1.3
17:06:54 <spectranaut> scott: I don't want to go through the issue but I see three different outocmes
17:07:06 <spectranaut> scott: we can talk about it at the end of the meeting or next meeting
17:07:14 <spectranaut> jamesn: lets put it in next week's meeting
17:07:32 <pkra__> pkra__ has joined #aria
17:08:40 <spectranaut> jamesn: the other two issues are related to aria solutions for ruby. the use requirements document in 16.20 covers all the use cases, but doesn't go through potentials to solve. we are scheduling something for TPAC week to discuss. Please look through this if you think it might have impact on implementations, or accessibility APIs, so we can get hte right people to attend.
17:10:08 <spectranaut> jamesn and jcraig seem to have ideas already. jcraig: you can check out most of the ruby test cases in japanese ebooks
17:10:20 <spectranaut> jamesn: I don't think these are milestonable
17:10:25 <spectranaut> zakim, next item
17:10:25 <Zakim> agendum 3 -- [Deep Dive planning](https://bit.ly/aria-meaty-topic-candidates) -- taken up [from jamesn]
17:11:17 <spectranaut> jamesn: should we skip and move to discuss TPAC?
17:11:28 <spectranaut> jamesn: no proposals
17:11:38 <spectranaut> jamesn: no deep dive next week
17:11:41 <spectranaut> zakim, next item
17:11:41 <Zakim> agendum 4 -- [TPAC 2021](https://github.com/w3c/aria/issues/1482) -- taken up [from jamesn]
17:11:58 <spectranaut> jamesn: cynthia proposed a lot of talks
17:12:08 <jcraig> s/test cases in japanese ebooks/test cases in the Apple Books app and maybe other readers. Ruby layout is commonly used in in Japanese ebooks./
17:12:49 <spectranaut> jamesn: any other ideas? otherwise we will schedule these meetings
17:13:21 <spectranaut> zakim, next item
17:13:21 <Zakim> agendum 5 -- [Updating ARIA 1.2 due to IDL implementations (exit and re-enter CR?)](https://github.com/w3c/aria/issues/1598) -- taken up [from jamesn]
17:13:37 <spectranaut> jamesn: this is blocking us from getting the new version of 1.2 out
17:13:42 <spectranaut> jamesn: I don't know what to do
17:14:28 <spectranaut> jamesn: it seems we hit a block where html is stating that what we have is not a thing, the thing they want us to do is not implemented
17:15:52 <spectranaut> jcraig: the question I think is that right now the implementations do it this way, if you remove the attribute and check the reflected dom property it returns null. dominic said this can result in a null pointer exception in the IDL. the IDL doesn't have a way to represent what is currently implemented in browser? Or, we are specifying it the wrong way. So what is the right way? I could use help from joanie and aaron
17:16:19 <spectranaut> jcraig: IDL doesn't allow you to do what you are doing. But we do have it implemented, because all browsers do the same thing here. Is IDL insufficient?
17:16:27 <spectranaut> jamesn: IDL allows null domstring
17:16:47 <spectranaut> jcraig: HTML's implementation of relfection doesn't allow it to be used with a nullable domstring
17:16:55 <spectranaut> jcraig: but the implementations are clearly doing that
17:17:16 <spectranaut> jamesn: should we not use the term "reflection"
17:17:25 <spectranaut> jamesn: joanie said we should call it mirroring
17:17:34 <spectranaut> jcraig: we could fire and issue against the HTML spec
17:17:43 <spectranaut> jamesn: but we probably won't get quick resolution
17:17:52 <spectranaut> jamesn: the only alternative is pulling the IDL section
17:17:58 <MarkMcCarthy> s/fire and/file an
17:18:12 <siri> siri has joined #aria
17:18:18 <spectranaut> joanie: the mirroring comment was snarky
17:18:28 <spectranaut> joanie: we have three implementations, and we shouldn't pull it
17:18:39 <spectranaut> jcraig: do you think they will file a formal rejection?
17:18:47 <spectranaut> jamesn: if they use the term reflect they will
17:19:02 <spectranaut> jcraig: if we use a different term we would have define the new terms
17:19:18 <spectranaut> joanie: aria reflection is based on IDL but here is one difference
17:19:33 <spectranaut> jamesn: aaron, james, joanie and cynthia -- can any of you sort this out?
17:19:48 <spectranaut> jcraig: I have to chat with other webkit people to see if there is a path to move forward on this
17:20:37 <spectranaut> jamesn: we are a year+ late, this is preventing publishing
17:20:53 <spectranaut> jamesn: this is the number 1 urgency from aria
17:21:26 <spectranaut> aaron: can we meet in person?
17:22:33 <spectranaut> jcraig: possible solutions: (1) remove IDL section, (2) ship it as is (and might get a formal rejection), (3) figure out out to change it, but we aren't sure how to change it to keep the section in and make them happy
17:22:55 <spectranaut> WilliamTennisNFCU: I think we should email them and explain
17:23:39 <spectranaut> jamesn: dominic is on vacation until oct 12
17:23:51 <spectranaut> aaron: can we move it to a note or something?
17:23:59 <spectranaut> aaron: its not like aria would break
17:24:11 <spectranaut> jamesn: it would be in 1.3 editors draft
17:24:25 <spectranaut> aaron: we might want to give is more time
17:24:56 <spectranaut> jcraig: we can ship this with a note that says "we have implementations, but it is the HTML reflect has a conflict with this"
17:25:14 <spectranaut> scott: I like that idea. Can we ship it is a "informative"
17:25:29 <spectranaut> jamesn: I think that doesn't sound great
17:25:49 <spectranaut> jcraig: we can't wrap a "infromative" about a "normative" section
17:27:02 <spectranaut> jamesn: I'm happy to help arrange things but I defer to people who actually know about IDL
17:27:15 <spectranaut> jcraig: I'll commit to chatting with people in webkit who are closer to the IDL implementation
17:27:24 <spectranaut> jamesn: can aaron do the same with google?
17:27:55 <spectranaut> jcraig: within apple, I'll chat with people to see if they agree with Dominic and sasha and the others in the issue
17:28:18 <spectranaut> jcraig: or if they feel this is an issue that needs to be resolved in html
17:29:23 <spectranaut> aaron: lets put a general message on the thread he responded to
17:29:38 <spectranaut> aaron: to dominic, because he is on vacation, so he doesn't have to reply
17:30:10 <spectranaut> zakim, next item
17:30:10 <Zakim> agendum 6 -- [summary element role mapping](https://github.com/w3c/html-aam/issues/345) -- taken up [from jamesn]
17:30:40 <spectranaut> jamesn: scott filed and issue, the fact that summary element doesn't have a role mapping.
17:31:12 <spectranaut> jamesn: the current mappings to html are kind of broken, summary is mapped to button, and summary allows child content within a summary element. button mapping does not allow that
17:32:06 <spectranaut> scott: this has been updated in the last year. it used to allow for fewer child elements, but now you can shove anything in a summary now. if you have an input inside of a summary, in chrome, if you try to put a space in the input it will open and close the summary because it is triggering the button response
17:32:37 <spectranaut> jamesn: this comes back to an aria issue where people need to put extra elements within various aria elements that don't allow
17:32:58 <spectranaut> jamesn: do we want to add another aria mapping in html aam
17:33:19 <spectranaut> jamesn: or do we not want to do that for now? or should with get the html spec changed and not allow this?
17:33:50 <spectranaut> scott: I'm open to suggestions. this has been brought up in html before, and there has been no change
17:34:15 <spectranaut> scott: maybe implementations need to change, there is two bits to a summary, there is a part where content can be added and there is a button
17:34:32 <spectranaut> jamesn: that seems like a reasonable implementation
17:35:11 <spectranaut> jamesn: chair hat off, I don't want to try to prohibit things that people need to do. The fact that people are doing this means people need a way to do it in an accessible manner
17:35:30 <spectranaut> WilliamTennisNFCU: can we compute the role dynamically based on what is inside of the element
17:35:46 <spectranaut> scott: you mean compute the role of the summary element based on it's children?
17:35:59 <spectranaut> scott: that could potentially solve one problem
17:36:15 <spectranaut> scott: but what is it when it has nested elements?
17:36:30 <spectranaut> WilliamTennisNFCU: if it is a button inside of a expand/collapsed thing....
17:36:51 <spectranaut> WilliamTennisNFCU: if you put a button inside of a summary element, it will remove the summary role from the summary element
17:37:45 <spectranaut> scott: because of the inconsistency with what is being done right now, this is mouse accessible, sometimes keyboard accessible, if we take away the button role, then how could someone using an assistive technology open and close the panel?
17:38:10 <spectranaut> scott: your suggestion makes it broken in a different way, but still broken, like it is now
17:38:28 <spectranaut> aaron: I think you made changes in chrome to make some of these situations not completely break, right?
17:38:47 <spectranaut> aaron: for buttons, we only truncate the descendants if it is a single text child
17:39:00 <spectranaut> aaron: not it is the case for all aria roles that have aria-presentational
17:39:11 <spectranaut> jamesn: how do the users interact with those?
17:39:28 <spectranaut> aaron: it is the same as if you put tabindex=0 to the containing div
17:39:38 <spectranaut> aaron: then you can tab inside
17:39:52 <spectranaut> scott: virtual cursor will move pass these things after one stop
17:40:00 <spectranaut> scott: but if you tab explictly you can frequently tab in
17:40:32 <spectranaut> scott: but if you press enter key inside of it, only one element will fire. a link inside the summary and send enter, you  might just toggle the summary instead of opening the link
17:40:58 <spectranaut> jamesn: we need to accept the reality that this exists, and we need to find a way to make it work better than it does today?
17:41:05 <spectranaut> scott: this might be a screen reader issue?
17:41:30 <spectranaut> jamesn: if browser says buttons don't have children presentational, then should we remove from the spec?
17:41:51 <spectranaut> jamesn: if we don't have implementations of children presentational any more, we should remove it
17:42:06 <spectranaut> aaron: there is no current widget that does this
17:42:41 <spectranaut> aaron: maybe this should be author advisory
17:43:08 <spectranaut> aaron: but we need to add this ability
17:44:24 <spectranaut> jamesn: can we leave this for now?
17:44:40 <spectranaut> scott: its been like this for years, and I have been personally asked about it many times recently
17:45:07 <spectranaut> scott: HTML says explicitly buttons can't contain interactive elements?
17:45:34 <spectranaut> jamesn: lets have a deep dive on this, with sarah and scott
17:45:44 <spectranaut> WilliamTennisNFCU: do we have an aria role "expandable"?
17:45:52 <spectranaut> WilliamTennisNFCU: we might need something other button or link
17:46:10 <spectranaut> WilliamTennisNFCU: we don't have a semantic for this scenario
17:47:10 <spectranaut> scott: tangental to this, I have had convos with people about how accordions are set up as heading with buttons, and maybe headings need to be focusable if they announce they can be expanded or collapse.
17:47:43 <spectranaut> scott: aria sort you need to put on column header, but changing value doesn't do anything, but you have to move away and back to hear the new state, could column headers be focusable elements
17:48:21 <spectranaut> scott: we need some way to make otherwise static elements interactive when they are interactive
17:48:30 <spectranaut> jamesn: we have has this discussion many times
17:48:43 <spectranaut> StefanS: I have brought this up a number of times
17:49:15 <spectranaut> jamesn: there is always a lot of pushback from various folks, but we should continue them. the more applications you encounter, the more you see the need for these things
17:49:35 <spectranaut> StefanS: when are we going to need to start talking about this redesign sooner than later
17:49:49 <spectranaut> StefanS: I would need help with other industry contacts, who shares the same pain
17:49:57 <jamesn> agenda?
17:49:58 <spectranaut> Zakim: next item
17:50:06 <spectranaut> zakim, next item
17:50:06 <Zakim> agendum 7 -- [When is hidden content taken into calculation of name and description?](https://github.com/w3c/accname/issues/57) -- taken up [from jamesn]
17:50:23 <spectranaut> jamesn: looping back on the hidden content conversation?
17:50:39 <spectranaut> jamesn: we were going to try to get some examples together?
17:51:09 <spectranaut> aaron: I had a call with ??, this doesn't solve firefox problems, firefox has a special implementation
17:51:54 <spectranaut> aaron: chrome, I came to the conclusion we don't need this, we can use the existing algorithm and simplify the code a low
17:52:02 <jcraig> Meet of the discussion is in the PR rather than the issue. https://github.com/w3c/accname/pull/137
17:52:08 <spectranaut> aaron: I don't know where wekbit is
17:52:23 <jcraig> s/wekbit/webkit/
17:53:12 <spectranaut> aaron -- i'm having trouble scribing your summary
17:54:23 <spectranaut> jcraig: if this is something like innertext exposed to web authors...
17:54:30 <spectranaut> aaron: no this is an implementation detail
17:54:41 <spectranaut> aaron: very slight modification to innertext code
17:54:47 <spectranaut> aaron: chrome doesn't need changes
17:55:09 <spectranaut> jamesn: what about if something is visibility hidden, we run through the innertext thing and we will get weird results?
17:55:20 <spectranaut> aaron: I'm just concerned that exisiting content is broken
17:55:26 <spectranaut> aaron: it's not broken for most cases
17:55:51 <spectranaut> aaron: if aria-labelledby, 99.9% you are trying to hide the text from sited users
17:55:59 <spectranaut> aaron: and that works
17:56:20 <spectranaut> jamesn: what about an intermediate solution, if you are pointing to node that only has text children, use text children, otherwise use innertext
17:56:44 <spectranaut> aaron: innertext does not get alt text
18:00:35 <spectranaut> RRSAgent: make minutes
18:00:35 <RRSAgent> I have made the request to generate https://www.w3.org/2021/09/30-aria-minutes.html spectranaut
19:00:15 <jongund> jongund has joined #aria