Meeting minutes
New Issue Triage
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
jamesn: issue 2886 is something to discuss at TPAC, issue 2883 is maybe a face to face candidate
jcraig: aria-actions had an underlined behavior when we were testing some code generation with Claude, and it would be good to align how it should work across browsers
jamesn: core-aam 268 was supposed to be on the agenda for today
jamesn: Issue 2880, ARIA annotations was never a spec
jcraig: The explainer that is linked to is Aaron's personal GitHub, they aren't working on it anymore.
spectranaut_: We can just remove the link to the explainer since it isn't being worked on anymore.
jamesn: Rest of issues have been discussed or are already on agendas
New PR Triage
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
<spectranaut_> r/link to the explainer since it isn't being worked on anymore/link to the explainer since everything in the explainer has landed/
jamesn: We can merge the scribe guide from Adam, the rest are editorial PRs. 2884 is a typo, but it is in a normative name.
(There was general agreement from the group that this can be fixed as editorial as long as implementations haven't implemented the spelling mistake.)
WPT Open PRs
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
jcraig: First one (61892) Valerie should review. The others are okay by 62251 needs a glance from Valerie.
spectranaut_: I can look at those.
TPAC planning
<github-bot> I can't comment on that because it doesn't look like a github issue to me.
jamesn: Please go through this list, in the future we will be asking people to lead these sessions as the chairs will be busy with other thing during TPAC. Prereading things, coming up with what we want to get out of the session so we don't rehash the same discussions with no actions taken.
jamesn: Add to existing issues or add new issues as needed!
Feedback on aria-relevant for Android Core AAM
spectranaut_: We may have to punt both of these because David isn't here, but he asked for a video link, let's talk about this item later in the meeting
Could a simple heading-sequence-to-tree algorithm be useful for generating document outlines?
jamesn: I did a quick summary of what this proposed algorithm does.
jamesn: This sounds very similar to the old HTML outline algorithm which was dropped.
spectranaut_: I'm not sure why there are asking us about this.
jamesn: I'm not sure either. While I see this as potentially being useful in part of a page, like inside a main element, but across the whole page I wouldn't want to do this because there are headings like in the footer that may not fit in the entire page. Correcting headings may be dangerous in some cases.
Matt_King: I want more background. Who are document outlines for? Who would use this and when? Would it be a thing you turn on and off? What does it have to with what the ARIA WG does unless it has something to do with what browsers do with content, which I agree with you about.
jamesn: Sometimes he comes to TPAC, so we could ask him there, or ask for more info in the issue. He is in Japan so the ARIA meeting isn't a good time for him.
keithamus: It isn't going to be implemented in browser because the previous version this algorithm was very slow.
<aardrian> agreed with Matt
jamesn: Can you summarize that in a comment so he can respond?
keithamus: Yes!
jamesn: This may be potentially useful for an author?
jamesn: If it's useful at author or dev time the performance issue wouldn't be a problem.
Giacomo: It would be important to understand what their intent is. if there is a study to understand the impact and other solutions that would help. Depending on intent another algorithm might be useful.
jamesn: We have an action for Keith to respond.
Feedback on aria-relevant for Android Core AAM
David: It was a year ago when we first talked about Android doing core AAM mappings. It got blocked but is starting up again. We have been discussing every mapping with the Android team so this is the first of potentially many mappings we want to discuss and ask questions about aria-relevant.
David: From the Chrome side of things we've done a lot to try to get it to work, supporting the whole vocabulary of what aria-relevant supports. The request for feedback is first, are there any concerns with us not mapping this to an OS API? We can discuss concerns with the Android team if a subset would be useful. Removals is not useful for us as far as we can tell.
jcraig: There is no problem with Android listing it as not mapped. Voiceover does speak deletion differently as a down pitch. I see it most frequently with rich text fields. We had two live regions in on app, one for additions, one for removals. Some apps did that for a while. In the context of aria-notify I think it's total reasonable to not map it if Android doesn't currently support that.
jcraig: Any implementation can choose to implement any portion of any spec. It isn't our job to tell an implementor what to implement, we can just advise. That is just my opinion, but others should give their opinions too.
Lucas: Is this just about relevant, or other attributes too?
jamesn: It is just about relevant, we have another agenda item for other attributes.
<spectranaut_> +1 to jcraig's advice
jcraig: Other aria attributes aren't mapped, that doesn't mean it doesn't work. It can also mean there isn't a relevant API to map it to. There is no harm in putting "Not Mapped". Sometimes we put in "TBD" but that is less relevant now as we move towards an evergreen spec.
David: We do use TBD on some things, some of which are actually mapped and we haven't gotten to them yet.
jcraig: We are putting a pause on inspectable because how things work and are mapped is changing over time. We made changes to the IDL because of that as well.
RESOLUTION: android can specify aria-relevant as not mapped
Feedback on aria-flowto mapping for Android in Core AAM
jamesn: This is similar to the last one?
David: this is trickier and more nuanced. This attribute isn't used currently it seems. Some ATs tried but it didn't work very well. it's a pretty dramatic feature that changes the reading order. The choices the Android team considered are to try to support the case where there is only one element (Android has a property to support that) or to make it unmapped. We could fully support it with a list of next nodes.
<spectranaut_> for context, here are the links jcraig is talking about: w3c/
jcraig: I opened an issue a while ago about aria-flowto which got a lot of comments. We decided to keep it for now, but then replace it once there is a suitable replacement. We are now 3 years from that decision. Voiceover or iOS did map this, but because of the problems (it's single direction, there is no return stack, multiple items can flow to the same element). What iOS Voiceover did was have a rotor to switch modes to escape
… loops. If you don't want to map it due to all those problems it would help us deprecate it, which is what this really needs.
David: Sometimes the team asks where is this used, where is it useful. I don't have an example but if someone has one I'd love to hear it.
jamesn: I echo a lot of what James Craig said. There are so many problems I'd rather you not map it than map it and have to engineer around a bunch of known problems. I can't think of a good use case.
Matt_King: I strongly endorse what both James' said. Mapping it would increase the technical debt of future changes. I am open to deprecating it more now than 3 years ago.
jamesn: I am also in favor of deprecation.
jcraig: I am in favor of deprecation and can open a ticket.
RESOLUTION: Android not to map aria-flowto
jcraig: Note that deprecation means it is still in the spec and marked as deprecated. It makes it clearer why some platforms don't map it.
RESOLUTION: re-open/open issue on deprecation of flowto
Allow aria-valuetext for use with combobox role
jamesn: Matt_King added a comment, can you summarize?
Matt_King: Scott had an excellent response in the issue. There are some edge cases where it could be valuable but I question those. I haven't put in the effort yet to research those questions. If you put this in the spec with no guardrails around it it will be a cascade of problems.
… I commented in the issue with some specific issues, but there a whole bunch more issues if you look more broadly at comboboxes built with ARIA. I was trying to directly address the rational for adding aria-valuetext here in the first place.
… I would like to propose the group abandons that PR unless there is a strong case and we can discuss the guardrails around the usage.
scott: I am okay with getting rid of the PR. It has been 2 years, it was meant to solve some issues, but I don't have the capacity to work on it. If my use cases aren't strong enough we have to tell peopel to fix their code they can't fix.
jamesn: I agree that this helps solve real issues that real people have.
scott: This was meant to be for select only use cases, not for guard boxes. I don't like the idea of abandoning it, but I don't have time for this.
<jcraig> discussing w3c/
Matt_King: I have empathy for the cases where it could be useful. I'm not sure what happens for customizable for select and how to put guardrails around that.
… I am also concerned about how to put guardrails around customizable select too. We don't have to abandon it if maybe over time I can find some time to add some more to the PR.
scott: I'm curious, outside of the editable instance, the use case for aria-valuetext is when there is a lot of data included in the options and you only need a portion returned for the collapsed state of the combobox. That can't be done natively now and to do it with existing ARIA would require a lot of effort.
… There are cases where teams have built it, are consuming other team's options, and they don't have the option to add ARIA labels. The combobox will just spit out what comes from the other team. aria-valuetext was the only solution we could come up with to solve that situation.
… Other things like aria-label have similar issues, so do we need guard rails for all those?
Matt_King: If what's shown isn't what you want the screen reader to announce, what's the use case.
scott: One example is a multiselect where the items are truncated and there is a visual marker to show other things are selected but that normally wouldn't be read to screen readers. I can visually see it, Screen readers would either get all the options that aren't shown, or only the ones shown and they won't get an indication that it is truncated.
<aardrian> +1 to Scott.
<jamesn> +1 to Scott and jane
<spectranaut_> I wonder if front-endian-jane can help scott get this PR updated? since scott is so busy
front-endian-jane: I agree with Scott. There are footguns all over ARIA. I'm happy to pickup updating the task.
Matt_King: Acc name would need to be updated too.