W3C

– DRAFT –
ARIA Authoring Practices Task Force

29 April 2026

Attendees

Present
CurtBellew
Regrets
-
Chair
-
Scribe
Daniel

Meeting minutes

<Jem_> Hi everyone. Our team has an important product release today so I have to be there.

<Jem_> I will miss today's APG meeting.

Setup and Review Agenda

<Jem_> Hi everyone. Our team has an important product release today so I have to be there.

<Jem_> 11:03 AM

<Jem_> I will miss today's APG meeting.

Daniel: Good progress on the current milestone. No PRs on the agenda outside of those

jongund: I created a couple of PRs. One to fix the landmark link and the other the aside element update

Matt_King: No need to discuss the link updates. We have a PR related to aside already
… Joe has provided comments, and I have provided comments, let's discuss when we get to that agenda item

Matt_King: Nex meeting is May 13

Publication planning

Matt_King: 4 closed PRs and 3 in the queue

Add Practice Page for Supporting Color Contrast

Matt_King: For PR 2991 Jon you said you'd send an email when it's ready for review

jongund: I sent an email to the list

Matt_King: I missed that. Is this ready for people to take another look?

jongund: Yes

Matt_King: Joe, Jemma, Curt and Adam are listed as reviewers

Daniel: Topic Revise Content for New Experimental Example of Scrollable Listbox

CurtBellew: I just incorporated the changes. Wondering if I should send an email or update you all here
… I think I got the changes incorporated

Matt_King: This is now ready for people to look at. I'll need to add a comment into the related ARIA issue before I merge it into 3372

Daniel: This is a bit stuck at the moment in ARIA

Matt_King: I think we do need the examples for people to understand the challenges
… I almost want to at least merge this into 3372 as soon as we think we are close enough and then update the ARIA issue
… I want it to be relatively stable though. Part of this is the visual design, Adam's feedback could be particularly helpful
… Jon, Ari, have you been following this?

jongund: Just a bit, but I could take a look

Matt_King: What's the resolution as per selected versus focused?

CurtBellew: Added a details panel so that when you make the selection the details panel reflects that. Scrolling doesn't change what's on the details until you select it. Visual indication on the check box. Star close to the check box. As you move through with the keyboard you still can look at the other options

Matt_King: We don't have selection in here, right? Just focus.

CurtBellew: As you use your arrow keys you are changing focus, but in order to select it you have to press Enter or space

Matt_King: Still single select?

CurtBellew: Yes
… 3400 URL preview is correct

jongund: I think this oe has a keyboard trap
… Get stuck when tabbing to the box, tried with Safari, Chrome, and Firefox

CurtBellew: Let me figure out what's happening there

Matt_King: The visual design piece has been updated. Selection not following focus is one decision we made.

CurtBellew: With the mouse you hover, you can move it without selecting. With the keyboard, you first focus and you can move or delete without selecting

Matt_King: Selection is supposed to display the item

CurtBellew: It shows the detail panel

Matt_King: Thank you

jongund: Just put a check mark instead of a check box, and nothing on the unselected ones

Matt_King: Is that what we do in other places?

CurtBellew: Yes
… That jumped out at me too. Thought about making it a radio, but others are just like you describe jongund

Matt_King: How would this look visually if we make it like a radio?

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

jongund: I don't think we need to make it like a radio, it's just getting rid of the boxes what I think would be clearer for me

Matt_King: This check is similar to aria-current

jongund: I think that's what you see in many radio-type selects

Siri: That's how we have it in buttons and list box

CurtBellew: There's no clear indication whether you can check them but I think this is implied. In the end it's just the visual representation

Matt_King: Let's fix it. There's the keyboard trap and the removal of the check box

Siri: Also addition of some tooltips would be beneficial

Matt_King: Are you saying icons that don't have text labels?

Siri: Yes

Matt_King: Those only appear on-hover, so you have to account for two hover scenarios

Siri: Yes, make sense

Matt_King: Do you agree CurtBellew?

CurtBellew: I think it depends on how we do that. If I add a title attribute it's a whole less intrusive
… The problem is that the title attribute doesn't work well for the keyboard user
… I'd look for a more descriptive icon

Siri: The icon looks different than a usual trashcan
… If you can change the icon that'd be fine

CurtBellew: There is an icon repository that I could take a look at

CurtBellew: I'll look to address these two things, then the icon and changing the boxes to check marks

Matt_King: Thanks

Landmark Practice: Update alignment between HTML aside element and ARIA complementary role

Matt_King: Let's talk about 3418
… This PR was from an outside contributor that was intended to update the landmark guidance to accommodate the new mappings on HTML-AAM
… Joe did a review and I've commented on some of that feedback, this was the one we were looking for you to review

jongund: It's incomplete, it doesn't address the example pages.

Matt_King: That's intentional. There's an open PR talking about getting rid of them

jongund: We'd be having conflicting information between the examples and this one if we don't get rid of them

Matt_King: Since we're not deleting the example pages with this PR, we should at least make them consistent
… We could also have two pRs: this one where we agree on the guidance and how things should be wording, we could get this approved and ready to merge, and then have a separate PR aligned with this to update the example pages
… Would you be willing to edo that mimics this one and also updates the example pages?

jongund: There are other problems with this page

Matt_King: Sure, but I'd like to get this landed, then merge this and then fast follow

Matt_King: Can you then add your review comments to this one Jon?

jongund: Sure

Matt_King: And then we could discuss in the next meeting

Siri: What's this trying to say?

Matt_King: That aside only becomes complementary only in two conditions: 1 within the context of the body or main, 2 if it has a label

Daniel: I think there needs to be split. It's complicated to parse for an outreach resource

Matt_King: The only time it should be complementary within main is if it's within body. In other cases, why doesn't matter where it is? ?What's the point of all of this complexity?

jongund: I think it should be if it's in the context of body or if named

Daniel: Valerie put some WPT tests, I think that's the only way for this to first be tracked and get alignment between browsers, not sure if this is the right time to update this guidance.

Matt_King: I think it needs to be much simpler. Either in the context of body or if it named

Matt_King: Maybe the thing to do here is opening an issue with HTML-AAM to be discussed in the ARIA meeting at some point

Daniel: I could do it

jongund: That makes it even simpler to implement

Matt_King: This would avoid people putting aside elements in many places

Siri: Should we make a point that it shouldn't be used within main?

Matt_King: No, we cannot chase every author error

Daniel: I think there's a valid reason to add complementary sometimes for examples for notes within the specs or other related content

Matt_King: You are right that we should give authors flexibility

Matt_King: I'll take it out of the milestone

Determine how tabs examples should support reflow for any number of tabs

Matt_King: They made four changes to the accordion and put it into codepen
… There's two changes related to CSS. I'd like to make sure we are aligned with this
… The goal is for us to give feedback on whether these changes we'd like to make or not
… First is the use of hidden until found

jongund: That's probably a browser switch. If you do a search it will disable the hidden

Matt_King: Does it have to do with HTML hidden element?

jongund: I think it's a pseudo element

Matt_King: That seems appropriate for accordion. It only changes what happens when doing a browser search. I guess it would automatically expand the accordion, but there wold be some tricks because you'd have to look for the event

jongund: This is a value for the hidden attribute in HTML. You can make it hidden=until-found

Matt_King: You JavaScript would have to look for a change in your hidden property and then change aria-expanded appropriately

<Siri> w3c/aria-practices#3428

jongund: It's more like visibility hidden where you'd still have a box

Matt_King: I don't know if our accordion was using none or hidden

jongund: We were using the HTML hidden element, which is display:none effectively

Matt_King: It may have some consequences to how the code is written

Matt_King: Change number 2 talks to browsers that doesn't support the content visibility, and then they go on with IE hacks
… We officially said we wouldn't be supporting IE anymore

jongund: If I search for "City" it'll expand these three tabs

Matt_King: Does it set aria-expanded correctly?

jongund: No.

Matt_King: jongund, If you look at issue 3428 and look at the second change in the list, can you explain what this refers to?

Minutes manually created (not a transcript), formatted by scribe.perl version 248 (Mon Oct 27 20:04:16 2025 UTC).