W3C

– DRAFT –
ARIA Authoring Practices Task Force

07 October 2025

Attendees

Present
Adam_Page, arigilmore, cbellew, Daniel, howard-e, jem, jugglinmike, Matt_King, Siri
Regrets
-
Chair
-
Scribe
jugglinmike

Meeting minutes

Setup and Review Agenda

https://github.com/w3c/aria-practices/wiki/October-7%2C-2025-Agenda

jem: Next meeting: October 14

jem: Any requests for change to agenda?

Daniel: Can we discuss issue 3373, as well?

Jem: Yes, I saw that. We can add it to the agenda, directly after the discussion of publication planning

Publication planning

Matt_King: As Daniel mentioned, the September publication went out

<Daniel> September milestone publisshed

Matt_King: We have seven things to check following that publication

Matt_King: Adam_Page could you go to the production site and make sure the spin button is all good?

Adam_Page: Sure

Matt_King: I'll take a look at the editorial changes for keyboard in grid

Matt_King: We have one related to the editor menubar example. This is a tab index management issue.

Matt_King: Fix so that only the most recent item is in the tab sequence

Matt_King: arigilmore I believe you worked on this; would you mind verifying it on the production website?

arigilmore: Sure

Matt_King: I can take the "read this first" item, and I'm not worried about the JavaScript item

Matt_King: If you folks find any problems, please raise a new issue. I don't expect any problems, but we always want to double-check

Matt_King: So that covers the past publication milesone

Matt_King: For the next publication milestone, we have three items so far

Matt_King: That includes the experimental example which we talked about last week

Matt_King: The date on this milestone is flexible

Matt_King: The one place we are seeking additional review is jongund's pull request, number 3213

Matt_King: This is the skipTo link and menu

Matt_King: jongund pushed a commit and asked if someone could test it on iOS

Matt_King: Adam_Page and arigilmore were reproducing this problem earlier. Would either of you be willing to take a look at jongund's pull request?

Adam_Page: Yes, we both did this already, just today. Unfortunately, we can both still reproduce the problem

Matt_King: Okay, that's it for the publication status update!

"Read this first" code upate

github: w3c/aria-practices#3373

Daniel: I think it would be more elegant if we could use static HTML for this

Daniel: We're more open to Jekyll "include" directives than we used to be

howard-e: I think the Jekyll "include" (or any frontmatter approach) would be going back to what wasn't wanted. There was an ask that the content in "read this first" could be controlled from this repository. We use a JavaScript approach to simplify maintenance for contributors

howard-e: if it was done in pure HTML, that would involve duplicating the template content across over 30 patterns

Matt_King: So we have client-side JavaScript not just for "read this first" but also for the disclosure on the example pages.

Matt_King: We have it in a couple places

Matt_King: What is the problem with the client-side JavaScript, Daniel?

Daniel: If you've disabled JavaScript, then the content is not available to you

Matt_King: But if you've disabled JavaScript, then most of the APG is not useful to you

Matt_King: Is there a way for the build process to perform the injection into every page as it's built? Is that somehow preferable?

Matt_King: I don't think that we want content repeated across many pages in the source repository. If we want to change content in that scenario, we have to update multiple pages. That makes the content-management more difficult, from an editorial perspective

Jem: What is the downside of using "include"?

Jem: What I'm hearing from Daniel is, "why don't we just use a simpler approach?"

howard-e: All that content was controlled in that repository. There are some assumptions which could be broken

howard-e: If we go back to the approach where the "builder" repository injects it, perhaps with a configuration file, then there may be a happy medium, here

Matt_King: The builder is just supposed to be an automated thing that transforms the content

Matt_King: The build should not be making editorial decisions

Matt_King: Is "include" a Jekyll feature?

Daniel: Yes

Matt_King: Then we'll end up mixing Jekyll directive into our HTML

Matt_King: Our content repository doesn't have any Jekyll in it. That was part of the beauty of the separation--that we don't require anybody to know anything about Jekyll in order to contribute to APG

Matt_King: Is there a "pure HTML" way of including content?

Daniel: I'll have to look into that

Daniel: you could argue that this is not exactly content per se...

Daniel: I'll reflect on this further and share my thoughts as a comment on the issue

Matt_King: In today's world, I wonder if we should be at all concerned about users who disable JavaScript

Daniel: They can read about the examples, they just can't interact with them

Matt_King: I wonder what that kind of person is even doing. And whether they're even part of the target audience

Daniel: This is motivated by discussions around the WAI website

Jem: Is this a build process issue?

Matt_King: Yes

Jem: I used to know people who disable JavaScript, they were mainly security experts

Issue 3193: listbox example with aria-actions

github: w3c/aria-practices#3193

Matt_King: I created a draft pull request

Matt_King: w3c/aria-practices#3372

Matt_King: The HTML page is basically complete, including proposed keyboard documentation and roles, states, and properties

Matt_King: I don't know if we can have a useful discussion of the keyboard proposal. We could wait for code from cbellew. I do have a proposal here, though.

Matt_King: This came out of TPAC discussions last year, where we're talking about "aria-actions" being set to null (or '") in certain circumstances

Matt_King: The screen reader would know that it has actions but wouldn't be able to figure out what the actions are until the element receives focus

Matt_King: This is specifically what Aaron was hoping to do

Matt_King: In the aria-actions specification, the empty string is supposed to have meaning

Matt_King: That allows you to use "display: none" for the buttons

cbellew: Ah, so you aren't referencing IDs which don't exist

Matt_King: Exactly. Or so we don't have to use some weird mechanism of making them not visible

cbellew: are there standard icons or icon libraries? Or should I just choose my own?

Matt_King: We don't have a standard set. We have some other examples which have icons which might be similar

Matt_King: Here we want move up, move down, favorite, and delete...

Matt_King: We probably have SVGs already in the repository that might represent most of those things...

cbellew: I've been looking but haven't seen anything. I'll keep searching

siri: Can you add a pattern that has disabled actions?

Matt_King: Well, in this case, you would not show disabled actions

Matt_King: But if the item is the first in the list, you can't move it up. Likewise, if it's the last item in the list, you can't move it down. But I'm assuming we wouldn't display those actions as disabled--that we would simply not display them at all

Issue 3371: Potential bug or editorial issue in navigation tree example related to aria-selected

github: w3c/aria-practices#3371

Matt_King: In the navigation tree view, we aren't using "Selected" at all. We're using aria-current = page

Matt_King: I re-read the spec, and aria-selected is supported for tree items. It's not required. There is spec language around whether or not the browser should do automatic selection, and I think in this case, some browsers might choose to do automatic selection

Matt_King: ...because that meets the requirements for single-select which are in the spec

Matt_King: And then I read our language in the pattern. There, when we talk about "aria-selected" and "checked", we say how to mark it up if it is selected. But there isn't any language in the pattern that says whether there needs to be a selection

Matt_King: But then when you look at this navigation tree view example, we don't say very much about this choice

Matt_King: There is some language--under "Accessibility Features" we have a section named "Focus Movement after content load" and that's where we talk about the use of "aria-current"

Matt_King: But we don't talk about "aria-selected" anywhere. I don't know if that's a miss, here, but it clearly tripped up this person

Matt_King: So we could add some language.

Matt_King: I don't think it's a bug--I don't think we need to specify aria-selected, but I wonder whether we should say why we are not doing so

<Siri> https://w3c.github.io/aria/#aria-selected

Jem: So would you like to update the pattern regarding aria-selected?

Matt_King: We could just explain how aria-selected is not required, just as a comment on this issue, and then close this issue

Matt_King: We could say something about not using aria-selected here on this example page. I'm not sure about that.

Matt_King: I don't think we want to update the pattern, though. We use this in aria-breadcrumb, but everywhere else, it's not part of the pattern--its just something you can

Jem: I think this person is just looking for guidance on aria-selected. I think there will be others who will ask the same question

Jem: So I vote for adding some language about aria-selected here in the example

Matt_King: Maybe what we're really doing is using aria-current in lieu of aria-selected

Jem: Maybe we add it to the table. We could add a note to the row for aria-current

Matt_King: We could add a note in the "Accessibility features", too, where we talk about aria-current. Maybe the same note could go in both places

Jem: I remember when I first started learning about ARIA, I was always looking for all the "aria-selected" attributes

Matt_King: I guess a note would say something like, "aria-current is used in lieu of aria-selected because it more clearly conveys the state of the tree, and the pattern and specification do not require that there be a selected element"

Jem: Great!

<Adam_Page> https://w3c.github.io/aria/#aria-current:~:text=In%20some%20use,delete%22%20and%20%22move.%22

Adam_Page: For what it's worth, I just reviewed the spec for aria-current and found some prose to this effect

Matt_King: I didn't think to check that!

Matt_King: I may have written that

Adam_Page: I think maybe you did. It sounds a lot like the text you just proposed

Matt_King: Maybe we can re-use that language

Matt_King: Having some clear messaging that helps illuminate the spec (especially the spec for aria-current) makes this a more positive change

Matt_King: Okay. We can mark this issue as an editorial enhancement. I will do that, now.

Adam_Page: This also feels like a "good first issue" for folks who might be new to the APG or who are looking for an easy win

Matt_King: Yes, especially if we propose a draft wording in the issue

<Jem> https://www.w3.org/TR/wai-aria-1.3/#aria-current

Siri: In the note for aria-current, why does it say "aria-selected=true indicates [...]"

Matt_King: Does that note suggest that we should be using aria-selected?

[Jem reads the note]

"In some use cases for widgets that support aria-selected, current and selected can have different meanings and can both be used within the same set of elements. For example, aria-current="page" can be used in a navigation tree to indicate which page is currently displayed, while aria-selected="true" indicates which page will be displayed if the user activates the treeitem. Furthermore, the same tree can support operating on one or mo

re selected pages (treeitems) by way of a context menu containing options such as "delete" and "move."

Matt_King: In a single-select tree, often the item that is focused is true. It's not necessary for the author to specify aria-selected=true because the browser will do that automatically

Matt_King: You sometimes will see aria-selected set even though it wasn't set by the code

Matt_King: That's the page which will become current when the item is activated

Matt_King: It could also be the case that that navigation tree allows you to do things (like moving things up and down), aria-selected tells you which you will be operating on, while aria-current tells you which is displayed. You may be operating on a tree which is not displayed

Siri: aria-selected=true might confuse me because I would only use aria-selected or aria-current, not both

Adam_Page: I had no idea about this browser behavior!

Matt_King: Sarah and I worked on the user-agent language for this (for tree item, grid cell, option, and maybe more). We had the same language in different parts of the spec so that browsers know what they can do and when they're allowed to do it

Matt_King: The browser cannot do this if it's a multiple selection or if the author used aria-checked

Matt_King: Anyway, there's a little bit of user-agent code that's in there that allows you to do some things automatically

Matt_King: Okay, I've labeled the issue, so we're done with this

Issue 3370: How to manage focus for disable tabs

github:

github: w3c/aria-practices#3370

Matt_King: Let's save this for next week

Issue 2735: Should APG CI include running regression on macOS?

github: w3c/aria-practices#2735

Matt_King: howard-e points out that if we proceed with the open pull request for this, there would be other failures

Matt_King: If people are going to run this locally, it should match CI. If they don't match, then that defeats the purpose of running locally

howard-e: That's the value-add. That, and increased robustness

Matt_King: Ah, I see--you said that if you ran it with macOS in CI, it created issues that you didn't observe locally

howard-e: It looks like my final question here was whether we wanted to commit the time to figure out what's happening there

howard-e: I also wonder if we've seen other folks running into issues on their Macs

Matt_King: I think it would be more robust if the CI also ran Mac, but that adds more complexity

Matt_King: If this could turn into a rabbit hole, I don't mind leaving this open for another day (and perhaps another contributor with more experience)

howard-e: I could take the next step--I could at least check in on the updates that have happened since we last discussed this, and I could share the result of that research

Matt_King: That sounds good

Matt_King: Do the folks here develop on Mac?

Adam_Page: I do

arigilmore: I do

cbellew: I mostly develop on macOS, but I also develop in Windows

Adam_Page: I test in Windows, but I develop in macOS exclusively

Jem: I just assigned howard-e to this issue and added Adam_Page and arigilmore as reviewers

Jem: I think we're done. We'll see you all next Tuesday!

Minutes manually created (not a transcript), formatted by scribe.perl version 246 (Wed Oct 1 15:02:24 2025 UTC).

Diagnostics

Succeeded: s/wen/went/

All speakers: Adam_Page, arigilmore, cbellew, Daniel, howard-e, jem, Matt_King, siri

Active on IRC: Adam_Page, cbellew, Daniel, howard-e, Jem, jugglinmike, Matt_King, Siri