W3C

– DRAFT –
ARIA and Assistive Technologies Community Group Weekly Teleconference

21 March 2024

Attendees

Present
Alyssa_Gourley, howard-e, James_Scholes, jugglinmike, Matt_King, Michael_Fairchild
Regrets
-
Chair
-
Scribe
jugglinmike

Meeting minutes

Review agenda and next meeting dates

Matt_King: Next meeting: Wednesday March 27

Matt_King: Requests for changes to agenda?

Matt_King: hearing none, we'll move forward as planned

Upcoming app fix patch

Matt_King: I've asked the Bocoup team to prioritize two bugs to fix with rapid patches

Matt_King: Issue 973: Candidate review start date is errantly reset when a test plan advances to candidate

Matt_King: Issue 799: Cannot view reports for draft test plans

howard-e: We have patches for both of these and they will be available for review on the "staging" server after the call

Matt_King: I'll try to review before Monday, so that hopefully we can merge and deploy on Monday

Toggle button test plan next step

Matt_King: We're waiting on some work from a few people, including Hadi and myself

Matt_King: I hope to get to my part this weekend

Matt_King: James_Scholes would you like to run this as Hadi or wait for Hadi's return

James_Scholes: Isa is out of the office this week, but we expect her to return some time next week

James_Scholes: If she returns before Hadi is able to share results, then we can ask Isa

Alyssa_Gourley: I'm also available to complete Hadi's work if necessary

Matt_King: I'm not sure if we can re-assign it to you, but we can look into it if necessary

Command button test plan next step

Matt_King: I'm looking at "report status dialog" for command button, and the app says that there are no reports

Matt_King: I seem to recall that howard-e was going to manually manipulate the data so that we wouldn't have to re-run this plan

Matt_King: It doesn't seem like it would be complicated to get the results from the prior version into the current version because the two differ so slightly

howard-e: I did volunteer to perform that operation. I can do that today, as well, after this call

howard-e: I've also been working on enhancing the "copy results" functionality

howard-e: It's issue #935. That includes a checklist, and the final item in the checklist concerns exactly this situation

howard-e: All that to say: I hope this process is easier in the future, but in the short term, I'll be performing that task manually later today

Matt_King: Great! Soon, we will have many plans in Candidate Review [Button, Link, Toggle, and Alert]. That's exactly where I want to be when I meet with Apple

Matt_King: I would love to get a 30 minute meeting with Apple by the end of the month

<jugglinmike> s/lists specific test plans/Button, Link, Toggle, and Alert/

Radio test plan

Matt_King: I thought this was ready to advance until just last week, when we recieved a question in APG

w3c/aria-practices#2954

Matt_King: [summarizes the issue]

Matt_King: We can be proactive here and just remove "Enter" key testing

Matt_King: Then, when APG updates, nothing about the test plan will need to change

Michael_Fairchild: That sounds like a fine course of action to me

Matt_King: I'd like the Test Plan to be run by the second week of April

Alyssa_Gourley: I can do that in time. I don't have a Mac, though

Matt_King: If you could do JAWS and Chrome, that would be great

Matt_King: We can use the NVDA Bot to gather the output, then we can assign it to you, and you would just be assigning verdicts

Matt_King: I encourage you to do some validation of the AT responses reported by the bot

Alyssa_Gourley: That sounds so much better

<Matt_King> V24.03.13 of radio test plan: https://aria-at.w3.org/test-review/75322

James_Scholes: This test plan doesn't have an "Enter" command

Matt_King: It looks like you're right--cool! That means we're already good to go

Matt_King: So we can just add this to the Test Queue for JAWS right now and assign Alyssa_Gourley

Matt_King: And I just assigned the NVDA Bot to run it for NVDA

Matt_King: It looks like there's some kind of component problem in the "assign tester" menu. Instead of using "aria-checked" on the checkbox, it declares the state as part of its name

howard-e: I'll make an issue for this later

Proposal to change terminology used for undesirable behaviors

Matt_King: GitHub issue Proposal for new terminology for the phenomena we currently call "undesirable behaviors" or "Other behaviors with negative impact" ยท Issue #1043

github: w3c/aria-at#1043

Matt_King: We have wording for additional behaviors which are undesirable: "Other behaviors that create severe negative-impacts are not exhibited" and "Other behaviors that create moderate negative-impacts are not exhibited"

Matt_King: There's been a little bit of confusion over the fact that we say "Other behaviors"

Matt_King: That has to be interpreted in the context of the behaviors that we assert

Matt_King: I've been giving this a lot of thought, and I was thinking that we might be able to make these statements more clear

Matt_King: We might switch from "negative impacts" to "negative side-effects"

Matt_King: I looked through the list of things that we currently classify as "negative impacts", and to me, it sounds like they could all be called "negative side-effects"

Matt_King: Then the assertions would read, "Severe negative side-effects do not occur", or "Moderate negative side-effects do not occur"

Matt_King: Do other folks feel like this would be an improvement?

James_Scholes: It works for me

Alyssa_Gourley: That would be clear to me, too.

Matt_King: I'm thinking about when we put this in the reports. For someone who isn't familiar with the testing, when they see "severe negative side-effects did not occur" or "moderate negative side effects did not occur", and those both pass. It seems like that would be clear to me

Michael_Fairchild: That sounds like it makes sense. I'm a little concerned about complexity, but I don't have a better solution

Matt_King: To be clear, we already have all of this implemented, I'm just talking about changing the wording

Matt_King: I'll take the next action on this

Assertion priority for alert role

Matt_King: I took the language that we previously discussed for the definitions of MUST, SHOULD, and MAY, and I inserted those definitions into the project's glossary

<Matt_King> New glossary definition of must should and may: https://github.com/w3c/aria-at/wiki/Glossary#assertion-priority

Matt_King: Does anyone have any objections to closing this issue and thereby formalize the definitions of the assertion priorities?

Alyssa_Gourley: Not from me

James_Scholes: I support this

Matt_King: Okay, great

Matt_King: Relatedly, we've been talking about the Alert pattern--specifically whether conveying the concept of "alert" should be a "MAY" assertion or a "SHOULD" assertion

Matt_King: In the ARIA specification, the Alert role is intended to capture peoples' attention in some way that is distinct from other assistive technology responses

Matt_King: We don't test that the "alert" interrupts other prior speech. I don't know if we should or even could do that

Matt_King: I think that's separate from the role, though; I think that's testing the property "aria-live" (the value "assertive")

Matt_King: In that case, we wouldn't be testing specifically the alerted value, but rather how the value is conveyed

Matt_King: There's a camp that believes that we should stay true to the spec even though that in the wild, the role has been so misused that it has lost its original meaning

Matt_King: On the other hand, there are folks who believe that the reality is more important than the theoretical language of the specification, and that asserting the latter doesn't actually help anyone

Matt_King: For this meeting, I'm not looking for a final decision that may never change, but I would like to come to a conclusion that represents this group's stance today

Michael_Fairchild: Could we consider an interruption as the indication that this is an alert?

Alyssa_Gourley: That alone could be confusing because in some contexts, it wouldn't be clear if an alert occurred--the interruption could seem like the literal text on the page

Alyssa_Gourley: Could it be a thing were in the verbosity settings, somehow, if users have the verbosity set to "beginner" or "intermediate", then it says "Alert" every time. Otherwise, it does not

James_Scholes: I think that Vispero would have it on by default and expect advanced users to turn it off

Matt_King: We didn't get a firm word from Vispero about whether or not this totally blocks them

Matt_King: We didn't discuss whether we give vendors an opportunity to communicate why they intentionally chose to fail a "should" assertion

Matt_King: Vispero was strongly advocating for using "pass" and "fail" to discuss "should" assertions

James_Scholes: I don't disagree with Vispero's user-oriented answer (rather than a more ARIA-focused answer). I mostly want to move forward on this

[continued discussion of the intricacies of the issue]

Matt_King: I'm still not hearing consensus here

Matt_King: If Vispero was adamanet that this be made a "MAY" assertion, would anyone strongly object to that?

Michael_Fairchild: No

Alyssa_Gourley: No

Matt_King: I will continue speaking with Vispero on this topic

Matt_King: Thanks to Michael_Fairchild (and folks at Microsoft) for securing compute time on Microsoft Azure for our use in automation!

Minutes manually created (not a transcript), formatted by scribe.perl version 221 (Fri Jul 21 14:01:30 2023 UTC).

Diagnostics

Failed: s/lists specific test plans/Button, Link, Toggle, and Alert/

Succeeded: s/lists specific plans/Button, Link, Toggle, and Alert/

Succeeded: s/Queue right/Queue for JAWS right/

All speakers: Alyssa_Gourley, howard-e, James_Scholes, Matt_King, Michael_Fairchild

Active on IRC: howard-e, jugglinmike, Matt_King