19:58:05 RRSAgent has joined #aria-at 19:58:09 logging to https://www.w3.org/2024/03/07-aria-at-irc 19:58:09 RRSAgent, make logs Public 19:58:10 please title this meeting ("meeting: ..."), Matt_King 19:58:33 MEETING: ARIA and Assistive Technologies Community Group 19:58:42 CHAIR: Matt King 20:02:06 jugglinmike has joined #aria-at 20:03:36 rrsagent, make log public 20:03:56 Zakim, start the meeting 20:03:56 RRSAgent, make logs Public 20:03:58 please title this meeting ("meeting: ..."), jugglinmike 20:04:33 Meeting: ARIA and Assistive Technologies Community Group Weekly 20:04:48 Sam_Shaw has joined #aria-at 20:04:56 present+ 20:05:01 scribe+ jugglinmike 20:05:04 howard-e has joined #aria-at 20:05:08 present+ Matt_King 20:05:13 present+ 20:05:26 present+ Sam_Shaw 20:05:47 present+ Alyssa 20:06:27 Topic: Review agenda and next meeting dates 20:06:34 Matt_King: Next meeting: Wednesday March 13 20:07:20 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 present+ Hadi 20:08:03 Hadi: I'll bet at the conference 20:08:16 Matt_King: If it's just Hadi, then I think we can still hold the meeting as scheduled 20:08:26 Topic: App update status 20:08:53 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 howard-e: There are additional details coming in the update which outline the "problematic behaviors" much more clearly 20:09:28 howard-e: These have been improved internally here at Bocoup and by Matt_King in the staging environment 20:09:49 howard-e: We plan to push this to production on Monday, when we can be available for support if necessary 20:09:59 howard-e: I'll inform PAC and Matt_King when the deployment occurs 20:10:50 Topic: Command and toggle button test plans 20:11:19 Matt_King: Done: Role changed to "toggle button" from "button" in role assertions - issue 1031 20:11:31 Matt_King: Any updates on Add 'b' quick nav to VoiceOver commands in button and toggle button test plans issue 1030? 20:11:38 present+ IsaDC 20:11:45 IsaDC: Not yet, but we're targeting Monday 20:12:41 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 Matt_King: By next week's meeting, we should be able to plan these out 20:13:17 Topic: Radio test plan 20:13:29 Matt_King: IsaDC and I will "deep dive" into this test plan on Tuesday of next week 20:13:49 Matt_King: We have a pull request that I think we'll be able to merge before that--#1042 20:13:57 https://github.com/w3c/aria-at/pull/1042#pullrequestreview-1905198701 20:14:20 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 howard-e: In that case, I can certainly merge it 20:14:54 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 Matt_King: I'm really excited about that improvement! 20:15:50 IsaDC: Can we preview it? 20:16:18 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 s/for your pull/attached to your pull/ 20:16:42 Topic: Assertion priority definitions and alert test plan 20:17:52 subtopic: Define meaning of assertion priorities: "MUST", "SHOULD", and "MAY" 20:18:00 github: https://github.com/w3c/aria-at/issues/1033 20:19:01 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 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 Matt_King: Similarly, we've received feedback from Apple about the "not pressed" state for toggle buttons 20:20:15 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 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 "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 Hadi: I completely support that 20:22:37 Alyssa: Yeah; there isn't much room for interpretation there 20:23:20 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 Matt_King: I'm trying to explain the consequence of any one of our thousands of assertions 20:24:46 Alyssa: It makes sense to me. It differentiates between something like "SHOULD" 20:25:03 Hadi: English is my third language. I think "likely" maybe doesn't go very well with "MUST" 20:25:29 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 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 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 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 Hadi: If I am uncertain at any stage, I call that a failure 20:28:37 Matt_King: Agreed. We're calling this a failure. We're just going on to explain what a "failure" means 20:29:26 IsaDC: I have a similar opinion, though English is also not my native language 20:30:03 Matt_King: The actual definition is just the first sentence. Everything after that is just an explanation 20:30:12 Hadi: Ah, in that case, I'm comfortable with this 20:31:58 Matt_King: Moving on to the definition of "SHOULD"... 20:32:14 "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 "[...] 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 Matt_King: Again, modeled after RFC2119 20:32:38 Alyssa: Makes sense to me! 20:32:45 Matt_King: Then, for "MAY" 20:33:31 "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 "[...] 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 Hadi: Can you elaborate a little bit on when vendors might choose? 20:34:08 Matt_King: Some screen reader developers have different ideas about what will better-serve their users 20:34:33 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 Matt_King: They may make decision decisions based on these differing goals 20:35:09 s/make decision decisions/make different decisions/ 20:36:37 Hadi: Thank you. The default setting is based on which level of verbosity? 20:37:14 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 Hadi: I'm concerned that AT vendors will map the "MUST", "SHOULD", and "MAY" to their verbosity levels 20:40:09 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 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 howard-e: The word "omit" in the definition of "MAY". To me, in English, that only sometimes represents intentionality 20:42:28 howard-e: Would it be safer to say something like, "while another vendor may not support the same behavior by default" ? 20:42:43 Matt_King: We actually do want that sense of intentionality 20:43:21 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 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 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 Matt_King: I wouldn't call it excess verbosity, I would call it confusing verbosity 20:50:28 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 Matt_King: doesn't happen 20:53:04 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 Matt_King: Lets push further discussion of Alert role to next week 20:53:49 Subtopic: Priority of alert role assertion: 20:53:49 no problem jugglinmike 20:54:03 Matt_King: We're almost out of time, so I'd like to push this topic to next week's meeting 20:54:13 Topic: Proposal to change terminology used for undesirable behaviors 20:54:24 github: https://github.com/w3c/aria-at/issues/1043 20:54:44 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 Matt_King: One of the problems I have here is with the phrase "other behaviors" 20:55:27 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 Matt_King: I was thinking of calling these other behaviors "negative side effects" 20:57:11 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 Matt_King: I wonder if other people find that simpler 20:58:19 Hadi: When we talk about "negative side effect", I'm not sure we defined what "negative effect means" 20:58:59 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 Hadi: When we say, "excess verbosity", do we have a kind of guidance where "excess" begins? 20:59:43 Matt_King: I think we're currently relying on peer review for that 21:00:28 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 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 Matt_King: We can continue this discussion next week, of course 21:04:28 Zakim, end the meeting 21:04:28 As of this point the attendees have been jugglinmike, Matt_King, howard-e, Sam_Shaw, Alyssa, Hadi, IsaDC 21:04:31 RRSAgent, please draft minutes 21:04:32 I have made the request to generate https://www.w3.org/2024/03/07-aria-at-minutes.html Zakim 21:04:39 I am happy to have been of service, jugglinmike; please remember to excuse RRSAgent. Goodbye 21:04:39 Zakim has left #aria-at 21:04:44 RRSAgent, leave 21:04:44 I see no action items