Meeting minutes
<Joe_Humbert> I have to miss due to a work All Hands. I am very behind on my outstanding work, but I will get it done this week.
2026 meeting schedule and updates
<mfairchild> Matt: The first big change is that Meta won't be funding the project. We will still continue the project, but won't have funding for current contracts.
<mfairchild> Matt: Fortunately the project will have most of the tools set up such that we can continue to move forward, but likely at a slower pace.
<mfairchild> James: Expressed thanks for all of the work that folks have contributed to the project
<mfairchild> Matt: This doesn't in any way mean that ARIA-AT is ending, but it is changing. It has always been the plan that Meta would bootstrap this project.
<mfairchild> Matt: If you know anyone that wants to dive in and help (co-chair, admin, assist in project, etc.) - please contact me.
<mfairchild> Matt: For the 2026 meeting schedule, I'm thinking about changing it to a bi-weekly meeting.
<mfairchild> Michael: supports bi-weekly. Thursdays would be better.
<mfairchild> Matt: one thing we can do is to run a poll
<mfairchild> Matt: there are two big things that I have planned for next year. Deque, who will pick up some support for this project, and will provide some level of engineering support, has asked Matt to give a Keynote at axe-con on the project.
<mfairchild> Matt: I'm also speaking with folks, including Preety and Michael at CSUN.
<mfairchild> Matt: these are two big opportunities and we can leverage these to keep the project moving forward.
<mmoss> preset+
Running tests for Switch Example Using HTML Checkbox Input
mmoss: Will be finishing up JAWS testing by end of week
Dean: I will get the switch with HTML checkbox done this week
Mike: For VoiceOver we have four conflicting results
Matt: The assertions were both marked as untestable, but showing as conflicting
Matt_King: There's another build that I'm testing right now. Unsure if Bocoup is aware of this issue.
Dean: Both of us marked the test as wrong
Dean: Impact Severe, exactly the same.
Matt_King: That had a negative side effect
Dean: Yes, exactly
Matt_King: I don't know if we want to call this a negative side effect
Matt_King: In the case of operate a switch that is off with the Enter key, nothing happening isn't really a side effect unless Enter caused something unexpected to happen. The assertion just failed.
Matt_King: Just because there was no output, doesn't mean it wasn't testable.
Matt_King: Mark the assertion as failing and remove the negative side effect
Dean: Ok
Matt_King: Then Joe needs to do the same
Dean: I'm looking at test 8 and that's the same. I'll change that too.
Matt_King: Yes, if it has the same behavior with no output for the Enter key
Dean: Control+Option+Space passed. I just changed 7 and 8. I'll look at 4.
Dean: number 4 was also marked as untestable.
Matt_King: Number 4 is untestable since the focus goes to the wrong place. That's an issue with the app
Dean: Test 2 and 4 are legitimate app issues.
Matt_King: Correct, your results look accurate to me.
Quantity spin button test plan questions
Matt_King: We do need people to understand the quantity spin button. I put a link to the test plan in the agenda.
Matt_King: First thing everyone has to understand, is that the spin button is an HTML input with type number is an edit field where you can type the value or change the value with the arrow keys.
Matt_King: Normally in all of our test plans we test navigating, reading (request information about), and operating. In the spin button test plan we have two operations testing increment and decrement with the arrow keys. There's a question about the other way of operating with the spin button. You can directly enter a value by typing one. The
question is if we want to test that kind of operation.
Matt_King: In general when web authors check the test plan reports they're likely trying to determine if their own implementation is working correctly compared to the implementation we test. That's one argument in favor of providing the test, without touching on the complications with being able to test that kind of interaction.
Matt_King: If we were to test directly entering a value into the spin button, how do we do it?
Matt_King: What happens when you type a value. The focus gets set on the spin button in the test plan when you click setup. The spin button allows values one through eight. We'll have a test where the user types a new value, say two—if the user does, what do we expect the screen reader to do? What would be the assertions?
Matt_King: We actually don't know if there's any expectation at all.
Matt_King: The user should be able to read the value two, but we already have a test for that.
Matt_King: NVDA has character echo on by default, so the user would hear "two, two". The assertion would be "the value two is conveyed,"
James: We have a test to check for an invalid value, but testing typing something into an input field isn't necessarily testing something meaningful
James: It feels prone to error unless we ask users to turn off character echo
Isabel: Are we testing the edit field
Matt_King: That is what we're doing. And at some point someone is going to say we need to do interop testing of an edit field.
Matt_King: Maybe what we're doing is enough.
Matt_King: All tests have an automatic assertion of "there aren't any negative side effects" but I don't know how to have that assertion without having at least one additional assertion. We can't have a test with zero assertions.
Matt_King: If we have the test for typing an invalid value, then we would capture any invalid side effects from that one.
Isabel: I think that would be enough
Matt_King: And that one only has a single assertion, the screen reader may convey. I wonder if it is should be a "may" or a "should".
Matt_King: We have a decision. We'll have two assertions for an invalid assertion. Both will be "may".