Meeting minutes
<ChrisCuellar> Test
1. Review agenda and next meeting dates
Lola: I have a topic to add
Matt will be item 6
Introductions
2 Current interop reporting status
Matt: moved rating radio moved to draft review
Matt: closed issues 1365 and 1246. Did a lot of research. We should treat this the same as radio button with active descendant. NVDA read all radio buttons when interacting. Roving tab index fixes
Matt: that inconsisstent behavior is consistently reproducable with NVDA. Reported excess verbocity to NVAccess
Matt: No other changes
Matt: have 2 other test plans that could soon advance. Minimal data grid we'll look at today. Another blocked by app, which is next on agenda
3. App outage tomorrow
Matt: servers down 9am pacific tomorrow, for ~1hr
4. App engineering opportunity
Matt: need help marketing an issue - 1666 tabs test plan has unexpected conflicts error, can't advance. Need help figuring out what is going on
Matt: Chris or Elizabeth, can you look at this? We can give you some mentoring assistance
Chris: I should have some time this coming month. Happy to mentor anyone who wants to help. will help you understand the system!
<liz> Yes I am
Matt: need to check with daniel at w3c - some of our repositories have moved to github.com/w3c-cg/aria-at (from w3c/aria-at) which has changed permissions. This issue is still in the old one. Most of us aren't in new one, can't be assigned
(debugging discussion)
5. Issue 1394: Resolve conflicting JAWS results in Minimal Data Grid test plan
Github: w3c-cg/
Matt: Murray and Joe were testing, had conflicting results. Joe's doesn't include new column header and name, Murray's does, when you nav letf in the grid
Matt: Might be related to applications mode vs. forms mode
Matt: ran setup on page, put jaws in forms/app mode, and got murray's result
Matt: did set up after ins-z did the other
Joe: difference seems to be automatic forms mode vs. manually toggling PC cursor
Murray: did confim I was in PC cursor mode
Matt: did close read of test instructions. I interpret them to be how Murray did it. do alt-del after setup button
Matt: Joe did you interpret it differently?
Joe: Not in forms mode until you active setup button. Need to do alt-del after. Told me Forms PC cursor not PC cursor.
Matt: we specify which cursor is active. I think Vispero would always consider inconsistencies between forms and apps mode a bug
Murray: should be consistent no matter how you switch mode
Matt: both are wrong in JAWS 2026
Joe: In other tests, if you switch mode, it typically does PC cursor and Virtual Cursor mode. Now it's dropping "forms." is that a different mdoe?
Joe: should I make a screen recording?
Matt: alt-del and ins-z give different answers
Matt: to resolve issue, Joe to change to Murray's results
Matt: even though this passes with JAWS 2025, it's going to fail with JAWS 2026
Matt: will report separately that you can get different results
(debugging discussion)
Matt: there might be an app bug related to saving those results. Conflict has vanished. Had a similar problem with rating test#5. might be an issue with submitting edited results
6 issue 1396 Create reusable test modules for APG and HTML-AAM
Lola: I've been funded by STF to work on ACD related to web standards, includign this group!
Lola: HTML-AAM tests are pulling in from APG pattern tests. e.g. there are 500 tests for button. this is cumbersome.
Lola: Matt, I think you talked about having reusable compoent tests (liek button tests)
Lola: but now I'm not sure that will work after all. Web Features accessibiltiy can change based on context
Lola: Now I'm thinking of separate set of HTML-AAM tests. We could use the ARIA-AT app.
Matt: we did work on this last august (Chris did). We have 3 sets of test cases
Matt: that's separate from the mappings
Matt: We have have a directory of APG, one for HTML test patterns, and one for ARIA test patterns
Matt: they are separated that way so we can identify the more "atomic" test cases, where there isn't context, or attribute is tested in single very specific context
Matt: one example - aria-required on text field is separate from aria-required on radio button or other form components
Matt: there are tons of patterns in APG where aria-selected is tested. but we could have an atomic test for aria-selected on a list box
Matt: for ACD, you will need to be careful, because you can get different behaviors for different commands (liek we saw in earlier issue today)
Matt: Not sure you want to throw away context-dependent results in ACD?
Lolo: that depends. We want to surface 2 kinds of data. "Raw data" and also updates to docs (e.g. MDN) based on data
Lola: For nuanced ones, MDN already has an accessibility considerateions section that we can add to
Lola: I don't see the HTML tests in the repo
Lola: looking at the code, each APG test has a csv that has refernces to (for example) the button in html-aam
Lola: using that to populate the data for the web feature. Chris is that right
Chris: yes, I think so
Matt: It's simpler. The csv gets turned into JSON. Every assertion can map to one or more specs. If an APG pattern uses a native html button, and the assertion is related to the button role (e.g. named from content), we map those assertions to HTML-AAM, so we can determine if any give AT treats a native button differently
Lola: That makes sense for ARIA-AT, but not necessarily for ACD
Lola: Can we make an HTML-AAM directory that tests individual elements
Matt: we set up the ability, but there aren't any tests. We can make a directory named HTML and it should work
Matt: we did test this. Maybe it was on staging?
(debugging discussion)
Lola: confirming that I'm ok to start writing tests for html-aam?
Matt: yes, we can write tests for html elements and attributes, should go in an html directory in ARIA-AT
Matt: hopefully this will work
Matt: whether we can separate it with our api is a different quesgtion
Lola: haven't looked at it, but probably not