Meeting minutes
New Issue Triage
spectranaut_: w3c/
jcraig: these are read by screen readers, so I think it does not have "little benefit". I am not opposed to removing redundancy but some of the lesser known acronyms feel useful to keep.
Francis_Storr: there are an awful lot of them, I don't think we need all of them. There is some benefit, not a huge amount. Best practice is to expand on plain text on first use, e.g. wai-aria (yadda yadda). That's what I put in the PR. Everything I could find on first use I expanded in plain text... seemed to the best way to do it? Otherwise there
is an _awful_ lot.
<Rahim> +present
jcraig: HTML, CSS, aria, it's fine, but UIA for example is not commonly familiar.
jcraig: WCAG... DOM... All common knowledge in this context. Some feel like we should keep
spectranaut_: Please weigh in on the issue if you have more thoughts. Next is https://
Francis_Storr: Updated references from WCAG 2.1 to 2.2
spectranaut_: next https://
Francis_Storr: I looked in a few dictionaries the consensus seems to be two "M"s. It seemed inconsistent.
<melsumner> I'd keep the PRs separate TBH
Francis_Storr: I closed it, I'm not precious, it seemed like it got merged accidentally in another PR.
spectranaut_: Yes it seems it was closed by another. Onto next. https://
Francis_Storr: Happy there is a style guide!
spectranaut_: only new issue is https://
scotto: I haven't.
scotto: I will get on it!
spectranaut_: assigned to you then. It looks like it was changed in Chromium? Do we need to discuss? Or just make the change? Looks like a leaf node not being a leaf node. If it's the way UI should be then it seems like it should change.
New PR Triage
<TheoHale> +present
spectranaut_: next w3c/
jcraig: This is around live regions; there is some ambiguity in the spec around expectations for non alert live regions inserted into the page. For the most part this change codifies the agreed upon behavior, where webkit differs from gecko/chrome. It's not testable yet - we didn't want to change too much, we'd have multiple layers of
inconsistency. I'd love to get melsumner's review on this too. Domenic also gave thoughts which have been incorporated
jcraig: the API for testing is not there yet though
spectranaut_: Some more reviewers for this please?
sarah_h: I can
spectranaut_: one more?
scotto: I'd be happy but given sarah_h is I thought there'd be little reason for me as well.
<TheoHale> I was going to offer, but I agree with Scott, Sarah, Scott and I likely have similar opinions.
jcraig: It might help if I explain the difference. When a live region becomes rendered, e.g inserted and rendered or visibility/display css change. On the API this accounts as a new element, in the a11y API the rendering engines need to have a new live region notification sent to the platform.
jcraig: The only one consistently announces on insert is alert - per core-aam requirements. Even live regions that aren't alerts dont trigger speech if they're added to page.
jcraig: live regions aren't created so platform downstream waits for it... the thing that shouldnt be current behavior until testable is alerts only get spoken when dropped into page. All other live regions are only spoken on subsequent modification, this one exception was firefox & chrome we weren't hearing the extra. WebKit was doing something
different so we'll align to the others to minimise the breakage
sarah_h: there are no UA MUST statements, is that becuase it's not testable?
jcraig: yes, there are existing UA must which were not changed.
jcraig: please suggest MUSTs but I'd like to make sure they are testable
siri: trying to understand, even if aria-live is not alert it is still reading?
jcraig: this is a point of author confusion. We wanted to clarify so people are on the same page. If you do for e.g. appendChild(createElement()) with a live region that is status or something, it won't (or shouldn't) speak contents. Role=alert specifically (not aria-live value but role) it will speak that at the time it is created. Other live
regions must be in the page and rendered. Does that answer the question?
siri: if it is aria-live=polite/assertive it is still reading it?
jcraig: I think so. This shouldn't cause any change to behaviour in chrome or firefox in windows screen readers. We were fixing a bug so WebKit aligns with others. Codifying in spec what that is.
jcraig: e.g. role=status on verified badges in youtube. That was a live region, and when it got inserted browsers were speaking it. I believe now it's more clear.
siri: thank you for explaining
spectranaut_: next is https://
Francis_Storr: I don't think so.
spectranaut_: I'll review and land.
spectranaut_: next would be w3c/
spectranaut_: next https://
pkra: you can add me
spectranaut_: last one. https://
WPT Open PRs
spectranaut_: we can move from this unless anyone has a deep dive
keithamus: invokers and interesttarget, could I do a deep dive on that?
scotto: that would be good
spectranaut_: can you raise an issue?
keithamus: will do
Deep Dive planning
Consider allowing CSS inline display to modify the whitespace character joins in accessible name computation
spectranaut_: this issue from jcraig on accname. You weren't here in triage last week.
spectranaut_: is there something for us in the WG to discuss?
jcraig: I think this was a follow on to the first issue, https://
jcraig: we landed on and merged a note, in accname computation, that says the WG is considering allowing css inline display to modify how whitespace is joined. It doesnt go into detail
jcraig: this PR is the follow on for that.
jcraig: so I hope to ping some CSS people. The agreement we got to - interrupt if wrong - we'd like to, if possible, any time there is a block or block level rendering, including inline-block, joining the text equivalents to each of those is a line feed.
jcraig: inline only though, or both things are at the boundary were inline they'd join with no space.
jcraig: if its possible do we need a table of all display values that contribute to this? If we need a table do we need a css-aam table again?
jcraig: however since the time fantasai, one of the css editors, mentioned the current definition of how to correctly convert nodes into plain text. It might be as simple as referencing the accname computation into the plain text algorithm that css-text-4 has defined.
jcraig: that includes things like before, after, marker pseudos.
Bryan: Not sure the best way to do that but sounds great
jcraig: I'll assign myself and you.
jcraig: I dont foresee having time this month but if I do I'll dig in
<spectranaut_> keithamus: I want to pointed out that the way the display works, there is the outer and inner value, there is a complex set of legacy values, but the new "precomposed" values. I think only the outer value would change this, there are 4 keywords. The outvalues are block, inline. The inside is flow.. etc... Inline block resolves to the outer of inline, and the inner to something else, but ultimately we only need to be concerned with two
<spectranaut_> values
<melsumner> Like Severance (not an ad)
jcraig: i would expect since inline-block has inline outer, that wouldn't work, because in every instance I could think of we would _not_ want to join with a space.
jcraig: that's not where I'd expect accname computation to join with a space, but I haven't looked at the plain text flattening algorithm either.
jcraig: if you'd like to make an attempt or be an assignee, please do
keithamus: I can try
jcraig: thank you
AccName Role Traversal Proposal and ARIA Spec could be more flexible when elements with "nameFrom:author" are left unlabeled by the author
spectranaut_: this is from last week, another issue related to accname role traversal recursion getting to an element that requires name from author but doesn't have one
Bryan: basically a link but for some reason they put a header in it. According to accname header maps to header if its not in... as a result it wasn't returning content for link name. It seems to be implementations are unsure how to handle that.
Bryan: if you nest in different landmark types it's supposed to return to generic to return the name but this doesn't work across the browsers. It's not clear what should happen in this case, so it should tie into recursion. What is that recursion supposed to look like?
<spectranaut_> w3c/
spectranaut_: looks like also movement on original issue. James took an action.
Bryan: He had reservations about which roles were allowable.
spectranaut_: he just commented 10 hours ago. (reads issue). Always traverse vs never traverse roles, gecko chromium disagree.
scotto: quickly looking at this, some rules under never traverse would mean this problem wont be solved.
scotto: in HTML hyperlinks can wrap any content. I can wrap an entire article or main or search or whatever, in a hyperlink. Some of these elements where it maps to a role which requires name from author, we'll have instances where hyperlinks have no name.
scotto: this would call out that you're not allowed to do that
spectranaut_: link is in always traverse
scotto: I read this in never traverse as if an element was wrapped in the link
jcraig: i think you're right, you'd traverse into the link and hit the table boundary.
scotto: maybe that's a problem too! if we have different interpretations no one will be right
spectranaut_: no I think your interpretation is right
jcraig: i want to link in the comment, the coming change, PR is a few years old, issue is 5 years old, this is one of the complications of the new authoring expectations for PRs. Long running PR will solve some of this, part of the reason we have this issue is the other PR is taking so long to merge - 1018 I mean
jcraig: w3c/
Bryan: PR referenced in labelling?
jcraig: yeah, also related to issue w3c/
Bryan: in this case? We're talking about header.
jcraig: the particular part of the algorithm could be changed to have header/heading...
Bryan: if we allow this, without role=region, what about banner? What about all these different things, it'll have the same blocking point
jcraig: IMO where it's ambiguous we'll align on what best is. Initial issue on how aria could be more flexible. w3c/
jcraig: we've explicitly disallowed some of the impls shine with heuristic detection. If we can relax those restrictions it might end up better.
Bryan: can you think of modifying that, that deals with... I guess a way it would more correctly handle it in a way that makes sense? Discrepency between accname and aria specs based on name from author and recursion algorithms
Bryan: Seems like this should be included there some way
jcraig: I haven't wrapped my head around all the cross references to be able to answer that.
Bryan: I understand... would this be a good deep dive topic then?
spectranaut_: I wonder what next steps are? Informed deep dive? It's clear its a problem we need to resolve... 5 years or more of requests.
scotto: Bryan you had said you had some work to identify... name from author with no name to pull text from that. I don't remember, is that somewhere?
Bryan: in the issue we're talking about
scotto: maybe we can discuss that a bit more during a deep dive? I think that has some weight to it. Get to a situation where element has a name from content, an unnamed element, arguably if it doesn't have a name the algo should update to look inside, if it does it can grab the name and stop right there.
Bryan: Simplifying this a lot could be possible, it revolves primarily around links. In the case of link (or possibly button) if you have all this weird stuff in it we can possibly make a basic rule, if you have a link with no conceptual name it can hold content regardless of what role is in it. A viable option?
scotto: 99% sure you're correct that this comes up with the context of links. Again, links can wrap anything but other elements don't allow that in the content model. At least in HTML where this is possible, they're author errors. Whereas this is something authors can absolutely do.
spectranaut_: that proposal is at odds with James' proposals? It's only talking about link? Even in a link we shouldn't traverse in other roles?
scotto: from my reading yes, this wouldn't resolve
Bryan: Scott can you summarize the problem for James?
scotto: Yeah I'll do that.
spectranaut_: we've discussed a related issue to this many times. Has anyone kept track of all the issues related to this? Traversing in elements that require name from author?
spectranaut_: would be good before we have a deep dive
Bryan: let's see what James says and we can figure that out
Bryan: Related there was one other issue...
Bryan: To do with heading inside of an article?
<spectranaut_> w3c/
spectranaut_: that PR only has one approving review, so blocking on reviews. Next step to review.
jcraig: I think his comment is addressed. Its not just blocked on reviews, also impls.
jcraig: if Bryan reviews it will unblock the WPT issue
<spectranaut_> s/zakim choose a victim//