W3C

– DRAFT –
ARIA Authoring Practices Task Force

30 September 2025

Attendees

Present
Adam_Page, arigilmore, CurtBellew, Hadi, howard-e, Jem, Jemma, jongund, jugglinmike, Matt_King, Siri, Siri1
Regrets
-
Chair
-
Scribe
jugglinmike

Meeting minutes

<Jem> https://github.com/w3c/aria-practices/wiki/September-30%2C-2025-Agenda

Setup and Review Agenda

Jem: Next meeting: October 7

Jem: Any requests for change to agenda?

Jem: Hearing none, we'll use the agenda as planned

Publication planning

Jem: I know Daniel and howard-e worked hard on this

Matt_King: The latest news I have regarding the publication is a question on the pull request which howard-e answered

Matt_King: I reviewed an editorial correction last night

howard-e: It's on the "main" branch, and once something reaches the "main" branch, then it will be included in the open publication pull request

Matt_King: Ah, so the pull request is to merge "main" into "publication"

howard-e: That's right. We're just waiting on the merge, now

howard-e: There shouldn't be anything else. I'll be monitoring for further questions, just in case

Matt_King: Once it's merged, we'll need some folks to go out and take a look and verify that everything went through properly

Matt_King: I should be able to help with that

Jem: Me, too

Matt_King: We don't know when it's going to get merged. It seems like it's ready to go, so we're just waiting for Remi to merge. It could get merged as early as today or tomorrow morning

Matt_King: I made another milestone for the next publication, perhaps at the end of October

Matt_King: I wonder if there are any items that we want to land before TPAC and that we can land before TPAC

<Jem> https://github.com/w3c/aria-practices/milestone/40

Matt_King: I'm also wondering about a couple patches from jongund. One regards skipTo.js

jongund: I'm working on that one, now

Jem: So we'll add more items for the next publication as we finish them

Issue 3193: Next aria-actions example

github: w3c/aria-practices#3193

Jem: This sounds exciting!

Matt_King: This was an issue that Aaron raised last year after TPAC

Matt_King: At that time, we had the example which Adam_Page worked on--I think it was "tabs with manual activation"

Matt_King: In the ARIA-AT group, we're beginning the work of a JAWS test plan for that pattern. I would like to share it at TPAC, but I think Aaron was requesting a different specific example because it includes some features that we can't really model in the "tabs" example

Matt_King: He's talking about adding tabs in something like a listbox or a tree--where you have buttons that appear as you navigate through the list

Matt_King: ...unlike tabs where the visibility of the buttons is commonly persistent. In this case, though, the visibility wouldn't be persistent. It could be based on hover (but gosh, how do you make that work with touch...? It's not really described here)

Matt_King: So I guess there are some things to work out in terms of how this would behave, but is there anyone who is excited to work on it?

<Adam_Page> https://a11y-screenreader-demos.netlify.app/studies/secondary-actions/

Adam_Page: Sarah put together a page of examples when she initially proposed aria-actions. None of them use aria-actions; they are just patterns that she thought aria-actions could solve

Adam_Page: I just reviewed them, though, and I don't think they relate exactly to what Aaron is describing?

Matt_King: The question is: what aspects of actions are we NOT demonstrating with the "tabs" example?

Matt_King: One, I think, is visibility, since all tabs are visible at all times

Adam_Page: If not for Aaron mentioning the listbox role specifically, I would have suggested forking the "tabs" example and add that reveal

Matt_King: Is that an authentic use, though?

Adam_Page: I'm not sure

Adam_Page: Also, Gmail came to mind--that UI pattern where you bring focus to a list of things, and you want to perform some action on that list

Adam_Page: I just looked at production GMail. They do reveal actions on hover, but they do not reveal them on focus

CurtBellew: I find this interesting, but I do have some questions. I can't think of a use-case involving options in a list with actions on them

Matt_King: I've experienced this in a lot of cases

Matt_King: Mobile versions of mail are all like that--they're all some kind of list with actions that don't show when you're just looking at the list

Adam_Page: Another (maybe contrived) example that came to mind is an ordered list that allows for resorting

Matt_King: We have an example like that: the listbox with rearrange-able options. We could make an aria-actions version of that

<Jem> https://www.w3.org/WAI/ARIA/apg/patterns/listbox/examples/listbox-rearrangeable/

Matt_King: I think the simpler, the better

Matt_King: In my experience, this happens a lot

Matt_King: In 1password, you have a long list of different entries, and you can perform actions like "edit" and "delete"

Matt_King: It's like a contextual toolbar

CurtBellew: Ah, so as opposed to making a list of selections, these are actions with a list of sub-actions

Matt_King: Gmail is a grid, but we could make a much simpler list

Matt_King: The select-only combobox is "select your favorite fruit." That's a very simple list with some ready-to-go content.

Matt_King: We have a bunch of examples that provide content so we don't have to start from zero

Matt_King: What else did Sarah suggest as examples?

Adam_Page: She had trees where each tree could contain items like "files" which you could delete

Adam_Page: She had tabs, she also had listboxes

Matt_King: We have examples of both listbox and tree that are fairly straight-foward and either of which would satisfy Aaron's requirements

Matt_King: If you want to use aria-actions and just learn about the different ways of coding it, it seems to me that if you had an example of it applied to a listbox, that's sufficient. That you could use that example to figure out how to apply it to a terr

Matt_King: I think we would copy it an make a whole new example (to avoid complexity)

<Jem> https://www.w3.org/WAI/ARIA/apg/patterns/listbox/examples/listbox-grouped/

Matt_King: The "re-arrangeable options listbox" is pretty complicated in the sense that it currently has two listboxes

Adam_Page: I don't know if it's necessary for this example to have a notion of one being selected

Matt_King: We just have selection following focus because they're all single-selects

Matt_King: If it was multiple select, that feels like it could make it a lot more complicated

Matt_King: I think "scrollable listbox" is the simplest example of them all

Jem: So we would add aria-action to each option?

Adam_Page: Yes

Jem: Because it's simpler than any other pattern?

Matt_King: Yeah. I don't know we need to bring in the complexity of the other examples in order to demonstrate the essential features of aria-actions

Matt_King: The other thing that would differentiate this from "tabs" is that we would reveal each of these individually. In tabs, it would be rare to see three buttons displayed when you hover on the tab. In a listbox, on the other hand, that would almost be the norm. You would never put another click in front of the actions

Adam_Page: Agreed

Matt_King: And three actions is probably sufficient. I kind of like "remove" for one because it shows how you have to respond to destructive options in terms of focus management

Adam_Page: Right, yes

Matt_King: All of those end up don't something that is focus-management-ish

Adam_Page: Maybe we have an action like "Favorite"

Matt_King: Yeah. That could add a little "favorite" star next to it. You could favorite as many as you like

Adam_Page: At first, I was tempted to overload aria-selected, but that doesn't make sense. But when you get to a listbox, how do you want it announced? I imagine you want it worked into the name

Matt_King: Yeah, it should be part of the name

Jem: "add" button and "trash" button are typical

Matt_King: Yeah.. "move up/down", "delete/trash", and "trash"

Matt_King: One changes the content of the current item without moving focus

Matt_King: If you move up, I think you would maintain focus (just like we do in the other ones) so that way when you move up, you're able to continuing moving up

Jem: Can you just go with "edit", "trash", and "favorite"?

Jem: But maybe we're ready to decide if we want to do this

Matt_King: I'm wondering if implementing this might help move some of the aria-actions discussions forward at TPAC

CurtBellew: That makes sense.

CurtBellew: I won't be at TPAC

CurtBellew: But I can devote some resources to it before TPAC. I have some time right now (though those things can change quickly)

Jem: What other discussion is needed to make this happen? Do we want to add this for the next agenda?

Matt_King: Adam_Page's recent experience demonstrated how so much nuance is unearthed as a result of implementation

Adam_Page: Right. Touch, for instance

Matt_King: We don't have to worry about touch in the first iteration

CurtBellew: Yeah, I'd worry about that last

Matt_King: We can release without touch support and then add touch support later

Matt_King: I can cut a branch and set up the files for you, CurtBellew

CurtBellew: That would help me get started

Matt_King: I'll make a branch for you to work on

CurtBellew: Great!

Issue 3315: Table naming guidance

github: w3c/aria-practices#3315

Matt_King: ARIA 1.2 had specified that naming a table is required. In ARIA 1.3, the group has wisely removed the requirement to name the table

Matt_King: Our table-naming guidance still reflects the ARIA 1.2 requirement

<jongund> I need to go a little early today

Matt_King: We can change this to match ARIA 1.3

Matt_King: The ARIA spec text, currently reads that "authors SHOULD"

CurtBellew: I couldn't find this when I went looking

Matt_King: If you go to the "table" role in the ARIA 1.3 draft (and there is a link to that in this issue)

CurtBellew: This is a huge change for us! I can't believe I missed it

Adam_Page: We found instances in the real world where the name wasn't helpful

Matt_King: I thought we previously had a pull request that made all the necessary changes in APG. Maybe we should check the others, too

<Adam_Page> w3c/aria#2297

Matt_King: What this does is, it makes your job a little bit harder. You don't have strict guidance, anymore. The APG will say that something is "recommended"

<Adam_Page> w3c/aria-practices#3244

Adam_Page: I just shared two URLs. The first is the ARIA spec pull request that made the spec change. And the second is the aria-practices counterpart. It's just an issue that I created, and it's still open

Siri: Where is the guidance on aria-label?

Matt_King: It's in the table on the editor's draft of the ARIA spec

Siri: I don't see anything about aria-label there

Matt_King: The "characteristics" table only includes normative-MUST requirements

Siri: How can we understand this change by looking at the spec itself when it is not written anywhere?

Matt_King: I thought that we were supposed to go to "evergreen" at the beginning of the year. Maybe that's not actually happening until after 1.3 is done

Matt_King: That may be affecting the AXE core decision

Matt_King: Okay, so the question is, I think, what the APG guidance should be

Matt_King: We have two options

Matt_King: We can list it as "recommended" or "discretionary"

Matt_King: I think that because there is an "authors SHOULD" in the spec, the most appropriate guidance for APG is "recommended"

Matt_King: Since "discretionary" is "optional or in some cases discouraged"

Matt_King: If we look at the next row down after table (which has a "recommended" for tab list), the very first bullet of the "recommended" ones for the third column explains why we recommended

Matt_King: We don't do that for the required ones

Matt_King: We could almost copy the first bullet of the "tablist" one word-for-word

Adam_Page: I think that would work

Adam_Page: Do we want to update the others while we're at it?

Matt_King: Yeah, I think so

Adam_Page: The issue I raised is issue #3244 in aria-practices

<Jem> w3c/aria-practices#3244

Matt_King: I'm hesitant to put my name on it because I think it will be a long time before I can get to it. Probably that's the same reason everyone else is hesitating

Matt_King: We're definitely going to change what's in the APG from "required" to "recommended". And we'll make a similar change for the other roles, as well

Jem: I can do this. Adam_Page can you review my work?

Adam_Page: Sure

Matt_King: Awesome, thank you Jem!

Issue 3314: Potential infra bug?

github: w3c/aria-practices#3314

Matt_King: Someone has reported a method somewhere in our code that isn't working the way it ought to

Matt_King: It sounds like it might be in the link-checker code, but they didn't provide a code pointer. I didn't go searching for the function

Matt_King: a function called "indexLineNumbers"

Matt_King: I don't know if this is causing any problems, so I don't know how this person discovered it

howard-e: Yes, it is in the link checker

howard-e: What they're reported could happen, but I'd be very surprised if it did

Matt_King: Can you write a comment and close the issue, howard-e?

howard-e: Sure

Jem: I assigned it to howard-e

Matt_King: Thanks!

Minutes manually created (not a transcript), formatted by scribe.perl version 244 (Thu Feb 27 01:23:09 2025 UTC).

Diagnostics

Succeeded: s/though/though?/

Succeeded: s/counterpoint/counterpart/

Succeeded 4 times: s/Hadi/Siri/g

All speakers: Adam_Page, CurtBellew, howard-e, Jem, jongund, Matt_King, Siri

Active on IRC: Adam_Page, CurtBellew, Jem, jongund, jugglinmike, Siri1