JAWS Feedback: "Change insert+Up assertions for Request information about an unchecked radio button" (Radio Group Example Using aria-activedescendant, Test 14, V24.03.13)

[RFischer-FS]

Description of Behavior

We would like to adjust the requirements for Insert+Up Arrow(Say Line).
Insert+ Up Arrow and Insert+tab are both used to request information. However, Say Line should provide basic information, while Insert+Tab should provide more comprehensive information, like the description and context.

Please remove the following requirements from the Insert+Up Arrow test:

• Position of the radio button
• Number of radio buttons in the group
• Role 'group'
• Name of the group

Differnciation between Insert+Up Arrow(Say Line) and Insert+Tab:

Insert+Up Arrow
It should provide basic element information, excluding the environment and description.
Similar to: Name, State, Value, Role

Insert+Tab
Should provide more comprehensive information
Similar to Name, State, Value, Role, Position, Number of items, description, and Group Name

Could we make the adjustments and follow this separation for our upcoming tests?

Test Setup

• Test File: test-40-reqInfoAboutUncheckedRadio-jaws.collected.html
• AT: JAWS

[jugglinmike]

The ARIA-AT Community Group discussed this during their meeting today. Due to technical difficulties, the IRC bot did not post the minutes here, so I'm doing so manually (I've also added the minutes from the final part of the discussion, as these are omitted from the version published on the web, presumably due to the same error).

Minutes from the ARIA-AT Community Group's discussion of this issue

(15:32:06) Matt_King: This seems like a straightforward request
(15:32:26) Matt_King: This has come up before: Is there really a difference between "Insert + Tab" and "Insert + Up"?
(15:32:44) Matt_King: As a result of our work here, Vispero has decided that they're going to define that difference
(15:33:08) Matt_King: They're basically saying that "Insert + Up" should give less information, and "Insert + Tab" should give more and richer information
(15:34:28) Matt_King: I think what they're really talking about here are the things like sliders, radio buttons, etc--anything where there is a composite with some kind of a container
(15:34:45) Matt_King: That's my interpretation
(15:35:08) Matt_King: They requested that we remove the assertions for things that are not name, role, value, or state
(15:35:28) Matt_King: So that would be information like the name of the radio group (if it's a radio group) or text like "one of four"
(15:35:51) Matt_King: My inclination is that for things that are about the immediate control (e.g. "one of four"), those probably ought to just be optional (not a should or a must)
(15:36:15) Matt_King: ...but anything about the container, you wouldn't assert anything at all--only for "Insert + Up"
(15:36:56) Matt_King: Only when you press "Insert + Tab" would it be optional assertion that it conveys the role of the container
(15:37:19) Matt_King: That seems to be in alignment with what Vispero has written here; does anyone in the meeting have concerns about going in this direction?
(15:38:57) jugglinmike: Why would we remove assertions rather than make them optional? Removing them risks insinuating to testers that those details are excessively verbose
(15:40:09) Matt_King: IsaDC, do you think it would be a problem to keep that assertion and mark it as optional?
(15:43:54) IsaDC: I agree with removing the assertions. Then we make sure that Testers do not feel that those assertions are mandatory
(15:44:30) James_Scholes: but the presence of the assertions does communicate to Testers the idea that we believe some output is reasonable
(15:44:56) James_Scholes: I think it's a good thing that Vispero is making the distinction clearer in their product
(15:45:19) James_Scholes: I don't think that we should include a optional assertion for this case
(15:45:37) Dean_Hamack: I'm totally with you on that, James_Scholes
(15:45:51) Dean_Hamack: when I focus on a button, I don't need to know everything else about it
(15:46:09) present+ Hadi
(15:46:39) Hadi: If we keep the assertion, and the result is that they do not mention the name of the group upon pressing "Insert + Up", we are not considering that a failure, right?
(15:46:55) James_Scholes: that's right, we are not considering that a failure because the assertion is optional
(15:54:18) Matt_King: The only part of this that is not completely clear from Vispero's feedback is the difference between leaving an assertion out and including it as optional
(15:54:58) James_Scholes: I think the optional assertion communicates the idea that we're okay with it, and I don't think we want to do that here
(15:55:58) Joe_Humbert: Would this impact other behaviors that are "may"?
(15:56:17) James_Scholes: there is always space for this project to do "consistency sweeps"
(15:57:04) Matt_King: I think Vispero is asking us to be consistent with the way we test Insert+Tab and Insert+Up across all tests. It would definitely effect "radio group" and maybe "slider" and "menu button"
(15:57:40) Matt_King: I implemented this change in the "menu button" test plan. For the "insert+up", I left speaking the position as "may", but I removed the assertions about speaking the name of the containing menu and the role of the containing menu
(15:57:56) Matt_King: I think that as we are running the test plan, that we are thinking about what we really want
(15:58:19) James_Scholes: My view is a bit extreme because I don't think a "say line" command should always speak the role
(16:00:31) jugglinmike: If what we're actually saying is that we believe the extra information is excessive, then do we instead need a "SHOULD NOT" assertion here, then?
(16:00:54) Matt_King: We may have an assertion like that, already--something that reads "Does not convey" or similar
(16:04:05) Matt_King: In terms of this feedback, I think we're aligned with Vispero. There is a minor implementation detail on which we may want to get their feedback.
(16:04:40) Matt_King: I'm happy to make a patch to "radio group" in order to drive this conversation forward

[css-meeting-bot]

The ARIA-AT Community Group just discussed Request for change to radio test plan.

The full IRC log of that discussion

<jugglinmike> Topic: Request for change to radio test plan
<jugglinmike> github: https://github.com//issues/1094
<jugglinmike> Matt_King: This seems like a straightforward request
<jugglinmike> Matt_King: This has come up before: Is there really a difference between "Insert + Tab" and "Insert + Up"?
<jugglinmike> Matt_King: As a result of our work here, Vispero has decided that they're going to define that difference
<jugglinmike> Matt_King: They're basically saying that "Insert + Up" should give less information, and "Insert + Tab" should give more and richer informatino
<jugglinmike> s/informatino/information/
<jugglinmike> Matt_King: I think what they're really talking about here are the things like sliders, radio buttons, etc--anything where there is a composite with some kind of a container
<jugglinmike> Matt_King: That's my interpretation
<jugglinmike> Matt_King: They requested that we remove the assertions for things that are not name, role, value, or state
<jugglinmike> Matt_King: So that would be information like the name of the radio group (if it's a radio group) or text like "one of four"
<jugglinmike> Matt_King: My inclination is that for things that are about the immediate control (e.g. "one of four"), those probably ought to just be optional (not a should or a must)
<jugglinmike> Matt_King: ...but anything about the container, you wouldn't assert anything at all--only for "Insert + Up"
<jugglinmike> Matt_King: Only when you press "Insert + Tab" would it be optional assertion that it conveys the role of the container
<jugglinmike> Matt_King: That seems to be in alignment with what Vispero has written here; does anyone in the meeting have concerns about going in this direction?
<jugglinmike> jugglinmike: Why would we remove assertions rather than make them optional? Removing them risks insinuating to testers that those details are excessively verbose
<jugglinmike> Matt_King: IsaDC, do you think it would be a problem to make that assertion optional?
<jugglinmike> s/make that assertion/keep that assertion and mark it as/
<jugglinmike> IsaDC: I agree with removing the assertions. Then we make sure that Testers do not feel that those assertions are mandatory
<jugglinmike> James_Scholes: but the presence of the assertions does communicate to Testers the idea that we believe some output is reasonable
<jugglinmike> James_Scholes: I think it's a good thing that Vispero is making the distinction clearer in their product
<jugglinmike> James_Scholes: I don't think that we should include a optional assertion for this case
<jugglinmike> Dean_Hamack: I'm totally with you on that, James_Scholes
<jugglinmike> Dean_Hamack: when I focus on a button, I don't need to know everything else about it
<jugglinmike> Hadi: If we keep the assertion, and the result is that they do not mention the name of the group upon pressing "Insert + Up", we are not considering that a failure, right?
<jugglinmike> James_Scholes: that's right, we are not considering that a failure because the assertion is optional
<Matt_King> rrsagent, make minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2024/08/08-aria-at-minutes.html Matt_King
<Matt_King> zakim, bye
<Zakim> leaving. As of this point the attendees have been jugglinmike, mmoss, Michael_Fairchild, IsaDC, Hadi, Dean_Hamack, James_Scholes, Murray_Moss, Joe_Humbert, Matt_King