W3C

– DRAFT –
ARIA Authoring Practices Task Force

10 June 2025

Attendees

Present
Adam_Page, CurtBellew, howard-e, jongund, Matt_King
Regrets
-
Chair
-
Scribe
howard-e

Meeting minutes

Reviewing agenda

Matt_King: [calls for change to agenda]

No changes

Matt_King: Meeting should be on for next week

Publication planning

Matt_King: We have 4 pull requests that are ready for publication

Matt_King: We have 2 on the agenda today that would be good to get in

Matt_King: we got jongund's disclosure work in, the search landmark and others

Matt_King: does next week still work howard-e?

howard-e: yes, that will works

Matt_King: Will check in with Daniel if that still works with the w3c team

PR 3251 - New example demonstrating expandable cards/regions

github: w3c/aria-practices#3251

Matt_King: Feeling like we're close to final review here. What do you think Adam_Page?

Adam_Page: I think so too. I made small quality of life changes to the code. I added preferred motion handling and mainly, I add a support draft of documentation for the pattern. So I think we're ready

Matt_King: Great. I haven't gotten to read through it all as yet

Matt_King: I was thinking we can expand the about just a bit .. to say "create an expandable card". So I'm wondering if we might provide a slightly more colorful description, mainly if people were searching for some word other than "card". I'm thinking of terms like "creating a card or region that can expanded or collapsed"

Matt_King: And maybe we highlight in the about section, that it can be expanded or collapsed by clicking anywhere within the card

Adam_Page: I think I did write a bit on that

Matt_King: I missed that, the "Authors sometimes ..."

Matt_King: This is pretty great

Matt_King: I'm thinking a bit that we haven't made such a statement in the APG or at least phrased in this way but I'm kinda liking it. Re: "To achieve this, authors may be tempted to nest the entirety of the rich summary within the disclosure button itself, but this can make the button’s accessible label cumbersome, inaccurate, or disorienting."

Matt_King: We might just want to break this into a couple of sentences

Adam_Page: I could turn it into a list "Authors may be tempted to do: bulleted list items"

Matt_King: I like that. What we're saying here is that people might want to do things here that are still html-legal. Does html permit headings inside buttons?

Adam_Page: I think it does

Matt_King: I just don't want us to note things authors may be tempted to do that aren't actually permitted

Adam_Page: In other words, we want to call out consequences that aren't valid in the first place?

Matt_King: Moreso, the pattern that breaks acecssibility. Guarding against that is a different kind of space for the APG to walk in

Adam_Page: also, checking the html spec, headings in buttons aren't permitted

Matt_King: However, it does mean that phrasing content is allowed to look like a heading

Matt_King: So what you could do here in your negatives is to say this doesn't permit things in your semantic headings markup

Matt_King: So things like not permitting links, making the label long and difficult to understand ... this is really good and I think we're getting somewhere here

Matt_King: So if you want to restructure that, I can come in and do more editorial changes

Adam_Page: Sounds good. And FWIW the about section is what I worked on the least. The bulk of what i did was in the accessibility section

Adam_Page: So definitely seeking some feedback as I have many details there so worried about overexplaining or leaving anything out

Matt_King: In the accessibility section, we typically cover the things that are non-obvious. For instance, I assume the reduced motion is in this list. The high contrast stuff is also non-obvious

Matt_King: Most of these explain the problems we're solving. The 3rd bullet talks about ... and brevity

Matt_King: So thinking we don't need the 1st bullet, the 2nd is a maybe. The 3rd we want to restructure to talk about the goal

Matt_King: This 4th I think is really important (the hover events)

Matt_King: Is there any accessibility thinking behind the choices you've made here that distinguishes your implementation from others that may be considered less accessible?

Adam_Page: Not really. The main motivation was to display a reaction and mostly on the side of UX

Matt_King: In some other examples like jongund's, we can borrow some of the wording like what was done in the radiobutton. This is similar to that work, right?

jongund: Yep, this is similar concept

Matt_King: So Adam_Page, you may just want to look there to borrow some of the wording for how this matters to accessibility

Matt_King: So pointing these things out is important to designers. What's missing is the reason why we did these things, to support accessibility. That's to help people understand why these are important elements of the design

Adam_Page: It's becoming clear as we go through this, that some of these decisions were done out of instinct, rather than the accessible reasoning

Matt_King: Well that's the difference with you who is honed in this work and the folks that come here without that seeking the guidance and why that's the guidance

Matt_King: So I think you have the breadth of feedback request here. I can plug some commits here and there to assist

Matt_King: Now also thinking we could push back the publication to the 19th so we could land this. It feels very close. This is ready for code and design review. But do we have regression tests?

Adam_Page: We have no regression tests

Matt_King: do you have any experience there?

Adam_Page: No but I would love some assistance there. I haven't had any experience writing from scratch

Matt_King: We have ids associated with each row in the role, property, state and index attributes

jongund: if you also look at the setup of the other disclosure examples, you could probably copy a lot of what's there because these are similar

jongund: I'd offer to help but I won't be available over the next week

Adam_Page: I can try to get that done. A little worried I won't be able to wrap it by publishing but will try

Matt_King: Another thing we can do after learning the aria-at examples aren't dependent on the publication is to even push out the date of the publication

Matt_King: We're potentially flexible on that

Matt_King: I think some folks would out there would be happy to see this get in. So maybe we should wait til next week to assign those reviewers

Adam_Page: Well the design and code is ready for folks to review

Matt_King: CurtBellew, would you be available to check out the code and design after the call?

Matt_King: So I'll assign jongund and CurtBellew as reviewers right now

jongund: just note as well if your css adds light-dark, it might mess with your page

Adam_Page: got it, is dark theme on the APG roadmap?

jongund: one way to do is to create your own web component. But just an idea

Matt_King: I think if we support light-dark, it would be APG wide and that would be dependent on the WAI resources templates

jongund: Makes sense. The main thing may be to try and show how one would support it in APG examples. So that may be a separate question on if we want to support it

PR 3291 - Remove role of row from TR elements in treegrid example

github: w3c/aria-practices#3291

Matt_King: This is ready for review too but I'm a little confused by what's going on with the validator here

Matt_King: Adam_Page, do you understand why it's still failing here after updating the vnurc even though it's updated

Adam_Page: [describes the failure as "Element “tr” is missing one or more of the following attributes: “role”."]

Matt_King: I wonder why the validator thinks it needs to have it

Matt_King: I thought the validator was throwing an error if it was present before but we had a line in vnurc that said don't throw this error

Adam_Page: is there a verbose option for the log?

howard-e: Unsure but I can check

Matt_King: It's so ironic, right?

Matt_King: at least an older version of the validator said the opposite

Matt_King: So which one is needed?

Adam_Page: just found a note in the vnurc which describes this exact scenario so this really is some weird paradox

Matt_King: Wondering if you took out all the rows in vnurc on row, posinset, tr, how it reacts

Matt_King: And also setsize but less sure about that

Matt_King: if there's still validator bug fixing needed, we should just make sure the right issues are raised

Adam_Page: I will comment out those lines in vnurc for now

Matt_King: I'm checking to see if the prior validator bugs we filed are still open

Matt_King: Ultimately, we want to figure out that if we remove the row=role, what validator needs from us

Adam_Page: Yep. I just pushed a commit so I can check what happens there

Issue 3277 - Treegrid focus order question

github: w3c/aria-practices#3277

Matt_King: They are asking about the focus order for the parent cell that expands/collapses

Matt_King: It could be that we need more clarity from the author. Does anybody else here read this and it's clear?

Matt_King: I can ask a clarifying question on the issue

zakim: end meeting

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

Diagnostics

Maybe present: zakim

All speakers: Adam_Page, howard-e, jongund, Matt_King, zakim

Active on IRC: Adam_Page, CurtBellew, howard-e, Matt_King