Meeting minutes
Review agenda and next meeting dates
Matt_King: see https://
Matt_King: Next meeting: March 7
Matt_King: Requests for changes to agenda?
Matt_King: Hearing none, we'll move forward with the agenda as planned
Automation subgroup meeting planning
Matt_King: Lola ran a poll; thank you, Lola!
Matt_King: This is for folks who are interested in automation; it's for the AT Driver spec which is now happening in collaboration with the Browser Testing and Tools W3C Working Group
Matt_King: The meeting we're considering, though, is supplemental to that
Lola: Monday noon PST (the time we used in 2023) seems to have the most votes
Matt_King: Isn't that time inconvenient for you?
Lola: Yes. The second choice is at 9AM PST on Tuesday. However, I think that between jugglinmike and myself, we can accommodate the Monday morning
Lola: My priority with the automation subgroup meetings is that we get as much public input from people who cannot attend the BTT meeting. I don't want my presence to interfere with an otherwise-optimal time
Matt_King: I don't have a strong preference between those two times. Like you, my preference is for maximizing the number of participants outside of BTT
Lola: There were 10 participants in this survey. Nothing came close to satisfying all 10
Lola: The survey did not track respondants' e-mail addresses, so apart from Sam and James, I can't tell who voted for what
Matt_King: Okay, then I suppose I'm comfortable with the Monday meeting time
Matt_King: Maybe when you post the decision on the mailing list, you could offer that if folks have a strong interest in this work but could not make the meeting, then they can reach out
Matt_King: Just as a way to help avoid letting folks be excluded
Lola: Also, we have the Wednesday after this meeting is sometimes the BTT meeting, but is otherwise an additional opportunity for further public discussion
Matt_King: In other words, during this CG meeting, when it follows a BTT meeting, we will make space to discuss automation
Matt_King: Perhaps we can help James_Scholes attend the BTT meetings by joining as a W3C-invited expert
Lola: I can look into that
Lola: Also, Vispero intends to attend the BTT meetings moving forward
Command and toggle button test plans
Matt_King: Thanks to IsaDC for help with issue #1031
Matt_King: I also found issue #1030
Feedback: "Navigate backwards to a pressed toggle button" (Toggle Button, Test 12, V23.12.14)
github: w3c/
murray_moss: "b" is a quicknav command
Matt_King: "j" is kind of like "f" in JAWS, but they're not quite equivalent
Matt_King: "f" in VoiceOver only goes to text fields, making it more like "e" in JAWS and NVDA
murray_moss: Wouldn't this also require a change to the instructions for how to test?
James_Scholes: yes, the nice thing is that the new test format allows this succinctly
Matt_King: We're writing the instructions for the latest verison of MacOS
IsaDC: So we are adding "b" to command and toggle button?
Matt_King: Yes; I think it's relevant. I think it should work for toggle button
Matt_King: It truly is Apples choice whether they distinguish buttons and toggle buttons within quicknav
Matt_King: I will assign this to IsaDC. It has a comment from me which just has a "todo" item in it
Matt_King: I'll write a comment in the issue right now
To preserve as much existing manual test data as possible, waiting on deployment of new app code before advancing new test plan versions to draft review.
Matt_King: I was doing some testing of the app of this feature in sandbox, and it does work, which is awesome
Matt_King: However, I found some issues that are blocking deployment to production
Matt_King: Issue #738 feedback, which I see you already have two pull requests out for that one--#939 and #1016
Matt_King: Do you know how much work is needed to those?
howard-e: There is just one more approval required to land those, specifically for #939
howard-e: My hope is that it can be reviewed by either today or tomorrow. If not, then by early next week
Matt_King: If it gets merged and goes into the sandbox by today or tomorrow, then that gives me an opportunity to verify so that we can shoot for deployment next week
Matt_King: I didn't see a response about #745
howard-e: I spoke with Paul from Bocoup who will be addressing that.
howard-e: It's underway, and we should have an update on the work before the end of the week
Matt_King: Can we set a target for being ready to deploy on Tuesday of next week?
Matt_King: Both #745 and #738?
howard-e: I think it depends on the task sequence that we have. I'd rather confirm internally and follow up
Matt_King: Something I didn't test: the changes to the "button" plan will affect ONLY VoiceOver. It shouldn't effect the JAWS plans at all. I'm curious to see what happens when we merge that and we already have the JAWS reports in place for "button"...
Matt_King: So next week, if we deploy a new verison of the app, there will be a couple of JAWS tests for "toggle button" which will be incomplete. IsaDC: when we talked before, I think you said you could do "run as another user" and just fix those tests for the JAWS report.
IsaDC: Yes, that's right
Radio test plan
Matt_King: This is temporarily on hold as we try to work out a technical change to the test plan
Matt_King: howard-e has already done some amazing work along these lines
Matt_King: I added some clarifying comments this morning. howard-e did those help?
howard-e: I didn't merge the V2 enhancement with your pull request. The order seems to be correct. It sounds like, based on the feedback, there is still something that you may be seeing differently. That's confusing to me
Matt_King: I merged your branch into my branch, and then I did a build of the tests. Then, the assertions came out in the wrong order
howard-e: I'm not seeing the change I made this morning
Matt_King: Oh! I didn't see that commit go out
howard-e: That explains my confusion
howard-e: Regarding the additional context you provided: there are assertions that are defined in test.csv, and [scribe unable to capture technical details]
Matt_King: I'll test out howard-e's work and if it looks good, I'll let you know later this afternoon
Assertion priority definitions
github: w3c/
Matt_King: People have been asking, "what do MUST, SHOULD, and MAY mean?"
Matt_King: I read RFC2119 which defines those terms for normative specs, and I came up with definitions for ARIA-AT
Matt_King: So I'm looking for feedback
Matt_King: In the first comment of this GitHub issue, you'll find my proposal for the definitions to place in the glossary
Matt_King: The first question: ignoring for now whether you agree with what's written here, do people understand what is written here?
James_Scholes: I don't understand the final sentence of the "MAY" definition.
James_Scholes: that is, "An AT which does not provide the asserted behavior MUST be prepared to interoperate with another AT that does provide the behavior, though perhaps with reduced functionality."
James_Scholes: Do you have a practical example?
Matt_King: I borrowed that language directly, just inserting the word "behavior"
Matt_King: I was thinking about an ARIA feature like something related to digital publishing or "annotations" in the ARIA working group...
Matt_King: ... Screen readers provide a lot of different kinds of presentations of that sort of material
Matt_King: I'm imagining that there might be something asserted that happens by default
Matt_King: "SHOULD" is that "we really think you should do this" but with "MAY", it's that "we think you could interoperate regardless of whether this is done"
Matt_King: When it says "must be prepared to interoperate", then the AT which doesn't exhibit the described behavior, it should exhibit some other equivalent
Matt_King: But we might want to leave that statement out
James_Scholes: I expect that this is likely to come up often (particularly because it uses the word MUST), and because it requires so much explanation, it would be better to leave it out
Matt_King: Let's say we hypothetically thought it was a good idea that screen readers automatically announce all insertions. We would say that they "may" do this. If a screen reader didn't do this automatically, but did do it as they entered elements, that would be satisfied...
Matt_King: ...unlike a third hypothetical screen reader which never announced insertions
James_Scholes: My intuition is telling me to leave that off
Lola: So because this is in a spec, we're talking about tests. When it comes to "MAY", it's possible that VoiceOver does something that is a "MAY", and that JAWS doesn't do that thing. To call JAWS's behavior "acceptable" sounds weird to me from an interoperability standpoint
Matt_King: We'll discuss the subsequent agenda item here in this context
Matt_King: Vispero does not think the word "alert" should be spoken when an alert is announced
Matt_King: We've already demoted the relevant assertion to a "should" based on this feedback. They'd like it further demoted to a "MAY" assertion
Matt_King: Given that much information and these definitions alone, what do others think?
Hadi: There are a lot of visual elements which speak for themselves.
Hadi: When we, as screen reader users, we don't have the visual cues. I am for the idea to have the role of "alert" spoken aloud
Matt_King: That's a perfect explanation for the original motivation back in 2010
Matt_King: Here's what's happened since 2010. Many chat apps right now use alert. On every single message, you hear "alert" as a prefix constantly
Matt_King: As a result, it no longer serves the "attention grabbing" purpose it was originally designed to serve
Hadi: Perhaps within a web application. But when an alert comes up in the context of another application, that's a different story
Matt_King: Agreed. Vispero can't fix that, but Microsoft is working on a technical solution to this. It will be available in a year or two
Matt_King: Vispero's argument right now is that in the current state of the world, "alert" is kind of meaningless
Lola: I am inclined to push back a bit. I'm not married to this perspective, but it sounds like we are adapting our tooling to match tooling which is not accessible in the first instance
Lola: If a web developer misuses alert, that's not accessible. It seems strange to me to change our tests to match that
Matt_King: I very much agree. That's where we fall almost all of the time. It's just that this is a strange case: if you're a developer, you have no other choice
Matt_King: This is why the APG has not written guidance for live regions
Matt_King: If you want live regions to work across browsers and ATs, you have to use alert
Matt_King: If you're targeting only certain user-agents, then sometimes you can make live regions work without alert
James_Scholes: I am sympathetic to Vispero's comments, but it's kind of a multi-pronged issue. As a user, their stance makes sense to me. As an accessibility professional, this is less the case.
James_Scholes: "aria live" still doesn't work after 14 years. At some point, you have to say "enough is enough". The same goes for "role=status".
James_Scholes: If something has not worked well for a decade, my sympathy for the people who should be implementing somewhat dips
Matt_King: But this isn't something Vispero can fix. The problem is on the browser side
James_Scholes: Good point
James_Scholes: But of course, Vispero's feedback is valid and based on authentic real-world experience
James_Scholes: I'm really torn, to be honest. One of the points that's made here in this issue is about users possessing certain skill levels. I really think that's an issue here. For a novice user, knowing the difference between an alert and a focus change, I think is key.
Matt_King: We're out of time for the day, but we didn't get to hear from everybody.
Matt_King: I encourage folks here to comment on the definitions (aria-at #1033), and you can also comment on this specific example there