W3C

– DRAFT –
ARIA Authoring Practices Task Force

09 September 2025

Attendees

Present
Adam_Page, CurtBellew, Daniel, howard-e, Jem, jongund, jugglinmike, Matt_King, siri
Regrets
-
Chair
-
Scribe
jugglinmike

Meeting minutes

Setup and Review Agenda

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

Jem: Any requests for change to agenda?

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

Jem: Next meeting: September 16

Jem: No meeting September 23

Publication planning

Matt_King: Per our discussion last week, we set publication for Wednesday of next week

Matt_King: We confirmed that with howard-e

Daniel: no problem on our side

Matt_King: We'll probably have six pull requests landed by then

Matt_King: There are two pull requests that are up in the air. 3213 is the "skipTo" links, but that has a mobile problem

Matt_King: Skip nav used to work, but people are having difficulty with this new version

jongund: I can't figure out why the new version isn't working. It isn't going to change any functionality, though

jongund: On my iPhone, it seems to work, but if I try my tablet, it doesn't work

jongund: And it didn't work on my iPhone on the week it was reported

Matt_King: Adam_Page and ari both reproduced the problem

jongund: It's some weird thing with VoiceOver on the phone, I think. I don't know. I'll keep working on it, but I won't spend time on it until October

Matt_King: Okay, then that will be for later

Matt_King: And then pull request #3311 is ready to go, I just need to merge it (it says that it's waiting on review, but I performed that review, already)

Matt_King: There are two others on the agenda today that I'm pretty confident that we can land by next week

Matt_King: So I guess five of the seven will be ready

PR 3328: Add Quantity Spin Button

github: w3c/aria-practices#3328

Matt_King: We talked about changes last week, and I saw that Adam_Page pushed a commit since then

Matt_King: It had to do with allowing people to type in essentially any value

Adam_Page: I read the meeting minutes and agreed, so I made the text inputs more permissive so that people can keep typing

Adam_Page: It introduced a validation pattern for APG. I think this is the first occurrence of aria-invalid in an APG example

Matt_King: That's one of the reasons I think this is pretty cool because we've been missing that for some time

Matt_King: What about ARIA error message?

Adam_Page: Ah, the white whale

Matt_King: Should we be modeling the usage of that?

Adam_Page: I haven't used it in a long time, so anecdotally, is it true that it isn't supported?

Matt_King: I don't know, actually. That might itself be a good reason to include it

Daniel: ARIA 1.2 is a recommendation, but ARIA 1.3 still isn't a recommendation

Matt_King: Error message is in 1.2

CurtBellew: The browsers do what they're supposed to do, but there's no requirement that the ATs actually use it

Matt_King: This is why we're working on interoperability

Adam_Page: Maybe this is a good opportunity to apply pressure--to role-model use of this and provide a nice example to start to socialize

Matt_King: We put the ARIA-AT test plan for "spin button" on hold a couple weeks ago because of this pull request

<Daniel> aria error message spec prose

Matt_King: Those plans are starting to get real traction. They certainly have traction with Vispero, and I'm hoping Apple will pick it up, too

Matt_King: So I do think this is an opportunity right now

Adam_Page: I'd be glad to look into it

Adam_Page: Basically, I'll be replacing aria-describedby

Adam_Page: I'm interested in seeing what happens. I'm assuming that AT support isn't great and that the user experience will suffer

Matt_King: I'm hoping that's not the case, but I guess we'll find out

Matt_King: We do want to publish next week. Has anyone looked at your latest work related to aria-invalid and the tests?

Adam_Page: I doubt anyone has reviewed--I only just pushed it at 22:00 last night

Adam_Page: Even those changes are non-trivial, so it would worry me to rush it out the door without another good round of review

Adam_Page: And I can add aria-errormessage today

Matt_King: Do we have reviewers available after today and before the next meeting?

howard-e: I can re-review the code changes. I'm assuming there are some test changes, too

Adam_Page: Minimal changes to the tests, honestly. There is one change I made along the way when I added aria-invalid. I'm using aria-disabled and aria-invalid (both boolean). When I added aria-invalid, I was reminded of some work that Rahim is doing about the reflection of these attributes, where the absence of a value is interpreted as "null." In that vein, I updated my usage of both boolean attributes to toggle between the "true" va

lue and the absence of the attribute.

Adam_Page: ...and I updated the tests accordingly

Matt_King: For a screen reader, the only way to get there is with the virtual cursor

Adam_Page: Right

Matt_King: These are going to make for some really good tests!

Adam_Page: I think that's the only interesting change that I made on my own--the only change that wasn't a direct reaction to feedback

jongund: I can help review

CurtBellew: I should be available this week

Jem: I'm busy with a big conference

Jem: But I can certainly assign the other reviewers

Siri: I can review, as well

Matt_King: Great! Hopefully we'll get all this review and land this in time for publication next week

Adam_Page: I have one last question. One of Siri's other question was that in iOS, VoiceOver will express the value as a percentage (presumably as a result of the min and max values being set). That feels a bit awkward. I'm wondering there's any action I can take

Matt_King: I don't think so

Adam_Page: I thought I could use aria-valuetext...

Matt_King: That is intended to prevent that from happening, but I believe that in fact, it currently does not

Matt_King: In this case, though, because we have numeric min and max, it's not necessarily a screen reader bug. I think it's an acceptable behavior; it's maybe just a little superfluous

Matt_King: They should do it for sliders, not for spin buttons

Adam_Page: It's certainly a little awkward for my use-case in the hospitality industry

Adam_Page: One last thing: when I pushed up my commit last night, I got a spell-check failure. The string that's failing is "inval". It's apparently triggering this failure from the CSS file.

Adam_Page: Why are we doing spell checking on CSS, and do we have to? If so, it seems like there's a bug

Matt_King: I didn't know that we were spell-checking the CSS

<Adam_Page> https://github.com/w3c/aria-practices/actions/runs/17573152826/job/49912867040?pr=3328#step:5:244

jongund: I've noticed that, too--that I've had to change CSS names to satisfy the spell checker

howard-e: I can't speak to why that's there

Adam_Page: I was tempted to add "inval" to our allow-list

Matt_King: I would rather not because then if "inval" shows up in regular content, we won't catch it

howard-e: I'd be inclined to remove CSS spell-checking. I will investigate further and advise.

Matt_King: I'd support that

Matt_King: I'm totally fine with CSS not being spell-checked

Adam_Page: It also failed on the same word as present in the HTML

Adam_Page: When I added "aria-invalid" to the attributes table, I think it caught that

Matt_King: It seems like a cspell error because it's not after the whole word

Adam_Page: As howard-e mentioned, it's suspicious that the letters it seems to be ignoring are "id"

howard-e: It might also have something to do with the equals sign...

<Jem> cspell.json

howard-e: I can take this on

Editorial correction in grid pattern

github: w3c/aria-practices#3356

Jem: We need one more reviewer

Matt_King: I reviewed this, and I'm reasonably confident in my review, but I would like one other person to verify

Jem: I can do that. I'll assign myself

PR 3304 : Removed timeout code for reseting search string in select only combobox

github: w3c/aria-practices#3304

Matt_King: This is a pull request that jongund raised

Matt_King: I think it's related to testing in response to another comment or issue. It might be a throwaway pull request...

jongund: Yeah, it was an odd issue related to a timeout when resetting a select box

jongund: It's just a throwaway pull request

Matt_King: There's no information here about a related issue

<Jem> w3c/aria-practices#3289

jongund: It's not related to 3289

jongund: It's related to another issue

Matt_King: I'll tie it to that other issue and close

Issue 3319: Use of ABBR in date picker

github: w3c/aria-practices#3319

Matt_King: We started talking about this last week

Matt_King: We had a pretty small crew, though, and we didn't come up with a clear next step

Matt_King: Really, in issue 3319, David is just asking us to re-open a prior issue that's related to ABBR

Matt_King: Five years ago, I boldly said that it's imminent that we're going to test the date picker in 2020

Matt_King: David is probably right that it is not imminent

Matt_King: What we use ABBR for in the date picker combo box is that the grid has column headings for the days of the week--the content in the column headings is just two character (e.g. "Mo" for "Monday")

Matt_King: The column headers have ABBR, which specify the full form of the day of the week

Matt_King: When you do that in regular tables, some screen readers (I don't know how many) will read the ABBR across the row (eg "Monday 1, Tuesday 2, Wednesday 3")

Matt_King: However, in this implementation in grid, none of the screen readers are doing that

Matt_King: Instead, you hear something like "Mo 1 Tue 2 We 2"

Matt_King: We could use aria-label. That's one solution

Matt_King: Another solution is not to use two-character abbreviations

Matt_King: What should the ARIA best-practice be for a date-picker grid like this?

Matt_King: First, let's answer the basic question: can we re-open 1570?

CurtBellew: I think so. This hits us everyone once in a while. There's not a good way to announce the un-abbreviated version of the day of the week

Matt_King: Okay, I've re-opened the issue

Daniel: Last week in ARIA we had a discussion about ABBR. It was on the other side--saying that ABBR should not be part of the accessible name (which I would agree with)

Daniel: In this case, as long as it's on the description, that's fine with me. But we should be careful with the message that we're communicating. That ABBR is a secondary piece of information, and in this case, the number of the day should be the accessible name

Matt_King: Column headers and row headers do not name cells. They are not labels; they're an association

Matt_King: This is a really complex issue!

Matt_King: The content of the content-header for Tuesday of this month is "2 Tu". If you were to put a label on the column header, I thin that would hide the "t u"

Matt_King: If that's case, it would be a fix, but it would have the side-effect of screen readers not being able to know that it's actually just a "T u" there and not the full word "Tuesday"

Matt_King: Hiding text that's on the screen has always been something that I think we should approach pretty gingerly

Daniel: From a screen-reader user's perspective, is that something we really want?

Matt_King: My bigger concern here isn't this specific use-case, but it is the more general use-case of: what do you do when you have a very verbose column header (with a lot of content), but then you're reading across in the table below, and you have to hear the whole header every time. The ABBR element was a good way to abbreviate that

Daniel: That's a very good point. I wonder if this is more screen-reader configuration (on whether to read the header after reading the cell or before reading it)

Matt_King: I switch it around fairly often. It's a lot of work to switch it, but sometimes you really want it before, and other times you really want it after

Matt_King: But it still seems that there is a problem that needs a solution, and it seems like ABBR was doing exactly what we want in that case. It reads the content of the header cell, but it doesn't force you to hear the entire content when you are reading cells that are not the header cell

Matt_King: That's why I suggested using ABBR here, to kind of push this as the solution

Daniel: Yeah, I don't mean to push hard, but I did want to share another perspective with the group

Matt_King: The title of issue 1570 is "date picker announces days of the week as letters". It sounds like Daniel is saying that it is a problem but it isn't a big deal

Daniel: Right. We're also using a shorthand, but this isn't technically what ABBR was meant to do

Daniel: In this particular case, you observe it correctly, but that may not be so in other cases

Matt_King: The actual purpose of ABBR is to provide the expansion

Matt_King: so when we have ARIA, the ABBR tag would include the content "Accessible Rich Internet Application"

Daniel: Right, and for "Tu", you would have "Tuesday" in the abbreviation

Matt_King: The code uses an "abbr" attribute, not an "abbr" element

<Jem> https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/abbr

Matt_King: In light of that, I don't know whether what we're doing here is to-spec or not to-spec

Matt_King: If anyone wants to do some investigation about whether what we're doing here is in-line with the specification, then that would be helpful

Adam_Page: It is a legitimate use

Adam_Page: I just checked the specification

<Adam_Page> https://html.spec.whatwg.org/multipage/tables.html#attr-th-abbr

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

Diagnostics

Succeeded: s/Matt_King/jongund/

Succeeded: s/related/not related/

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

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