19:58:05 <RRSAgent> RRSAgent has joined #aria-at
19:58:09 <RRSAgent> logging to https://www.w3.org/2024/03/07-aria-at-irc
19:58:09 <Zakim> RRSAgent, make logs Public
19:58:10 <Zakim> please title this meeting ("meeting: ..."), Matt_King
19:58:33 <Matt_King> MEETING: ARIA and Assistive Technologies Community Group
19:58:42 <Matt_King> CHAIR: Matt King
20:02:06 <jugglinmike> jugglinmike has joined #aria-at
20:03:36 <jugglinmike> rrsagent, make log public
20:03:56 <jugglinmike> Zakim, start the meeting
20:03:56 <Zakim> RRSAgent, make logs Public
20:03:58 <Zakim> please title this meeting ("meeting: ..."), jugglinmike
20:04:33 <jugglinmike> Meeting: ARIA and Assistive Technologies Community Group Weekly
20:04:48 <Sam_Shaw> Sam_Shaw has joined #aria-at
20:04:56 <jugglinmike> present+
20:05:01 <jugglinmike> scribe+ jugglinmike
20:05:04 <howard-e> howard-e has joined #aria-at
20:05:08 <jugglinmike> present+ Matt_King
20:05:13 <howard-e> present+
20:05:26 <jugglinmike> present+ Sam_Shaw
20:05:47 <jugglinmike> present+ Alyssa
20:06:27 <jugglinmike> Topic: Review agenda and next meeting dates
20:06:34 <jugglinmike> Matt_King:  Next meeting: Wednesday March 13
20:07:20 <jugglinmike> Matt_King: CSUN is the week of March 18. Does this effect anyone's ability to join this meeting (it's currently scheduled for Thursday the 21st)
20:07:25 <jugglinmike> present+ Hadi
20:08:03 <jugglinmike> Hadi: I'll bet at the conference
20:08:16 <jugglinmike> Matt_King: If it's just Hadi, then I think we can still hold the meeting as scheduled
20:08:26 <jugglinmike> Topic: App update status
20:08:53 <jugglinmike> howard-e: There's now an updated Test Plan page in the application. It matches the page that you can see in the Netlify link
20:09:14 <jugglinmike> howard-e: There are additional details coming in the update which outline the "problematic behaviors" much more clearly
20:09:28 <jugglinmike> howard-e: These have been improved internally here at Bocoup and by Matt_King in the staging environment
20:09:49 <jugglinmike> howard-e: We plan to push this to production on Monday, when we can be available for support if necessary
20:09:59 <jugglinmike> howard-e: I'll inform PAC and Matt_King when the deployment occurs
20:10:50 <jugglinmike> Topic: Command and toggle button test plans
20:11:19 <jugglinmike> Matt_King: Done: Role changed to "toggle button" from "button" in role assertions - issue 1031
20:11:31 <jugglinmike> Matt_King: Any updates on Add 'b' quick nav to VoiceOver commands in button and toggle button test plans issue 1030?
20:11:38 <jugglinmike> present+ IsaDC
20:11:45 <jugglinmike> IsaDC: Not yet, but we're targeting Monday
20:12:41 <jugglinmike> Matt_King: Hopefully we won't need to re-run complete test plans, but we WILL need to run the "b" commands for VoiceOver
20:12:53 <jugglinmike> Matt_King: By next week's meeting, we should be able to plan these out
20:13:17 <jugglinmike> Topic: Radio test plan
20:13:29 <jugglinmike> Matt_King: IsaDC and I will "deep dive" into this test plan on Tuesday of next week
20:13:49 <jugglinmike> Matt_King: We have a pull request that I think we'll be able to  merge before that--#1042
20:13:57 <jugglinmike> https://github.com/w3c/aria-at/pull/1042#pullrequestreview-1905198701
20:14:20 <jugglinmike> Matt_King: It looks good to me (I reviewed it about an hour prior to this meeting), and Alex_Flenniken approved it as well
20:14:27 <jugglinmike> howard-e: In that case, I can certainly merge it
20:14:54 <jugglinmike> Matt_King: Maybe on Wednesday of next week, we will also be able to assign people to run the new version of the Radio test plan
20:15:24 <jugglinmike> Matt_King: I'm really excited about that improvement!
20:15:50 <jugglinmike> IsaDC: Can we preview it?
20:16:18 <jugglinmike> Matt_King: I will push a few more changes to your pull request, and then I'll e-mail you. At that point, you can see the changes in the preview for your pull request
20:16:28 <jugglinmike> s/for your pull/attached to your pull/
20:16:42 <jugglinmike> Topic: Assertion priority definitions and alert test plan
20:17:52 <jugglinmike> subtopic: Define meaning of assertion priorities: "MUST", "SHOULD", and "MAY"
20:18:00 <jugglinmike> github: https://github.com/w3c/aria-at/issues/1033
20:19:01 <jugglinmike> Matt_King: We have "required" and "optional" defined in the glossary, but that's now out of date. This issue proposes definitions for "MUST" "SHOULD" and "MAY" that we can add to the glossary
20:19:34 <jugglinmike> Matt_King: We're able to consider these in terms of feedback we've recently received from Vispero about some specific expectations in the "alert" test plan
20:19:57 <jugglinmike> Matt_King: Similarly, we've received feedback from Apple about the "not pressed" state for toggle buttons
20:20:15 <jugglinmike> Matt_King: Last week, we were just talking about "SHOULD" and "MAY"; it didn't seem like there was any feedback on the "MUST"
20:20:40 <jugglinmike> Matt_King: I do want to consider "MUST" in this meeting, though, because I'd like to arrive on a final decision on the meaning
20:22:21 <jugglinmike> "The assertion is an absolute requirement. The command or event being tested MUST result in the behavior described by the assertion. Failure to do so could block users of the command from perceiving, understanding, or operating the type of content represented by the test case."
20:22:28 <jugglinmike> Hadi: I completely support that
20:22:37 <jugglinmike> Alyssa: Yeah; there isn't much room for interpretation there
20:23:20 <jugglinmike> Matt_King: I'm trying to take the definition of MUST from RFC2119 and translate it to an assertion in a test (e.g. "the role alert is conveyed")
20:23:42 <jugglinmike> Matt_King: I'm trying to explain the consequence of any one of our thousands of assertions
20:24:46 <jugglinmike> Alyssa: It makes sense to me. It differentiates between something like "SHOULD"
20:25:03 <jugglinmike> Hadi: English is my third language. I think "likely" maybe doesn't go very well with "MUST"
20:25:29 <jugglinmike> Matt_King: Well, we're not certain that it will block users because we can't be sure that something will block them
20:26:16 <jugglinmike> Matt_King: We don't know for sure if one single failed assertion would block somebody. It could, but it might take multiple failures
20:27:10 <jugglinmike> Hadi: I am for equal access. For instance, if you tab to an element and you get information that's different than if you arrive at it some other way. That's unecessary cognitive load
20:28:01 <jugglinmike> Matt_King: That sounds right to me. We have an assertion for "the role 'toggle button' is conveyed". If an AT conveyed only "button", you could still use that button--it wouldn't block you
20:28:14 <jugglinmike> Hadi: If I am uncertain at any stage, I call that a failure
20:28:37 <jugglinmike> Matt_King: Agreed. We're calling this a failure. We're just going on to explain what a "failure" means
20:29:26 <jugglinmike> IsaDC: I have a similar opinion, though English is also not my native language
20:30:03 <jugglinmike> Matt_King: The actual definition is just the first sentence. Everything after that is just an explanation
20:30:12 <jugglinmike> Hadi: Ah, in that case, I'm comfortable with this
20:31:58 <jugglinmike> Matt_King: Moving on to the definition of "SHOULD"...
20:32:14 <jugglinmike> "The assertion is a strongly recommended requirement. The command or event being tested SHOULD result in the behavior described by the assertion. Failure to do so is likely to impede users of the command from perceiving, understanding, or operating the type of content represented by the test case. [...]"
20:32:23 <jugglinmike> "[...] There may exist valid reasons in particular circumstances to ignore this assertion, but the full implications must be understood and carefully weighed before choosing a different course."
20:32:33 <jugglinmike> Matt_King: Again, modeled after RFC2119
20:32:38 <jugglinmike> Alyssa: Makes sense to me!
20:32:45 <jugglinmike> Matt_King: Then, for "MAY"
20:33:31 <jugglinmike> "The assertion is truly optional. The command or event being tested MAY result in the behavior described by the assertion. Failure to do so is not likely to impede users of the command from perceiving, understanding, or operating the type of content represented by the test case. [...]"
20:33:44 <jugglinmike> "[...] One assistive technology (AT) vendor may choose to provide the asserted behavior because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same behavior."
20:33:55 <jugglinmike> Hadi: Can you elaborate a little bit on when vendors might choose?
20:34:08 <jugglinmike> Matt_King: Some screen reader developers have different ideas about what will better-serve their users
20:34:33 <jugglinmike> Matt_King: Some screen reader vendors might prioritize a certain market, e.g. people who aren't blind but are using a screen reader for some other purpose
20:34:49 <jugglinmike> Matt_King: They may make decision decisions based on these differing goals
20:35:09 <jugglinmike> s/make decision decisions/make different decisions/
20:36:37 <jugglinmike> Hadi: Thank you. The default setting is based on which level of verbosity?
20:37:14 <jugglinmike> Matt_King: Whatever the AT provides immediately after installation. In other words, we use the setting that the vendors themselves implement as default
20:39:29 <jugglinmike> Hadi: I'm concerned that AT vendors will map the "MUST", "SHOULD", and "MAY" to their verbosity levels
20:40:09 <jugglinmike> Matt_King: I doubt it. I don't think it's that neat and simple. Especially when it comes to "SHOULD". It's hard to imagine that they would stop doing those things on a medium verbosity
20:41:17 <jugglinmike> Matt_King: For instance, announcing the position within a radio group (e.g. "one out of three" or "two out of three"). We mark that as a "SHOULD" because you can technically get by without that
20:42:05 <jugglinmike> howard-e: The word "omit" in the definition of "MAY". To me, in English, that only sometimes represents intentionality
20:42:28 <jugglinmike> howard-e: Would it be safer to say something like, "while another vendor may not support the same behavior by default" ?
20:42:43 <jugglinmike> Matt_King: We actually do want that sense of intentionality
20:43:21 <jugglinmike> Matt_King: Sometimes, users of one AT actively don't want certain behaviors, so the implementers want to leave it out on purpose
20:46:33 <Sam_Shaw> jugglinmike: We are both saying you are able to do what you want within reason, and also you shouldn't do these things. My Questions is, if you do one of these things that we are saying they may do, we will consider it excess verbosity
20:48:25 <Sam_Shaw> Matt_King: With Voiceover or NVDA there is a message it gives, the help message, which we don't test, is wrong. If it is wrong, I think its legitmate to call it out as a problem
20:48:40 <Sam_Shaw> Matt_King: I wouldn't call it excess verbosity, I would call it confusing verbosity
20:50:28 <Sam_Shaw> Matt_King: The other reason for this, is if one SR developer does something and another doesn't, if you are unfamiliar with SR and your testing your component with a SR that does this behavioir, then test with another SR that doesn't, you would think its a bug in your code, and if not then you would think its okay that this behavoir does or doesn'
20:50:48 <Sam_Shaw> Matt_King: doesn't happen
20:53:04 <Sam_Shaw> jugglinmike: I want to guard against confusion when we say you can do anything you want, and you may do this. For me tying into the excessive verbosity reasoning helps clarify that
20:53:41 <Sam_Shaw> Matt_King: Lets push further discussion of Alert role to next week
20:53:49 <jugglinmike> Subtopic: Priority of alert role assertion:
20:53:49 <Sam_Shaw> no problem jugglinmike
20:54:03 <jugglinmike> Matt_King: We're almost out of time, so I'd like to push this topic to next week's meeting
20:54:13 <jugglinmike> Topic:   Proposal to change terminology used for undesirable behaviors
20:54:24 <jugglinmike> github: https://github.com/w3c/aria-at/issues/1043
20:54:44 <jugglinmike> Matt_King: I'm having a hard time not thinking more and more about the wording of this and wanting to simplify it further
20:54:56 <jugglinmike> Matt_King: One of the problems I have here is with the phrase "other behaviors"
20:55:27 <jugglinmike> Matt_King: That phrase means you have to read all the other assertions. If you read the assertion out of context, it's not clear what it means
20:56:07 <jugglinmike> Matt_King: I was thinking of calling these other behaviors "negative side effects"
20:57:11 <jugglinmike> Matt_King: We'd have an assertion for "Severe negative side-effects do not occur" and "Moderate negative side-effects do not occur"
20:57:19 <jugglinmike> Matt_King: I wonder if other people find that simpler
20:58:19 <jugglinmike> Hadi: When we talk about "negative side effect", I'm not sure we defined what "negative effect means"
20:58:59 <jugglinmike> Matt_King: We have a list of them in the test form. things like "excess verbosity", "sluggish behavior", "crashing", and even a text entry field where Testers can explain in some other behavior
20:59:30 <jugglinmike> Hadi: When we say, "excess verbosity", do we have a kind of guidance where "excess" begins?
20:59:43 <jugglinmike> Matt_King: I think we're currently relying on peer review for that
21:00:28 <jugglinmike> Matt_King: It's why we have two people running tests. If one person classified something as "excessive" and another person did not, then that would cause a conflict which we would subsequently discuss in this meeting
21:01:40 <jugglinmike> Matt_King: I'd love more feedback on this issue--please post it as a reply. I'm trying to improve the clarity for the reports.
21:01:54 <jugglinmike> Matt_King: We can continue this discussion next week, of course
21:04:28 <jugglinmike> Zakim, end the meeting
21:04:28 <Zakim> As of this point the attendees have been jugglinmike, Matt_King, howard-e, Sam_Shaw, Alyssa, Hadi, IsaDC
21:04:31 <Zakim> RRSAgent, please draft minutes
21:04:32 <RRSAgent> I have made the request to generate https://www.w3.org/2024/03/07-aria-at-minutes.html Zakim
21:04:39 <Zakim> I am happy to have been of service, jugglinmike; please remember to excuse RRSAgent.  Goodbye
21:04:39 <Zakim> Zakim has left #aria-at
21:04:44 <jugglinmike> RRSAgent, leave
21:04:44 <RRSAgent> I see no action items