Assertion Priority Feedback: Should conveying collapsed state of a menu button be a 'MUST-HAVE' behavior - "Request information about a menu button" (Action Menu Button Example Using aria-activedescendant, Test 3, V24.09.18)

[mcking65]

If a screen reader does not convey the collapsed state of a menu button, wouldn't it be the case that users could still use the element?

Knowing the state is valuable, but it does not seem to me that it meets the bar for a 'MUST-HAVE' behavior defined in the glossary.

Test Setup

• Test File: test-09-reqInfoAboutMenuButton-jaws.collected.html
• Report Page: Link
• AT: JAWS (Version 2024.2406.121)
• Browser: Chrome (Version 130)

[css-meeting-bot]

The ARIA-AT Community Group just discussed action menu button state priority question.

The full IRC log of that discussion

<jugglinmike> topic: action menu button state priority question
<jugglinmike> github: https://github.com//issues/1150
<jugglinmike> Matt_King: I almost hate to be raising this issue so late in the process
<jugglinmike> Matt_King: I'm asking whether or not communicating the state "collapsed" should be a priority one or priority two
<jugglinmike> Matt_King: I'm starting to feel that the state is only a "should" because you could still operate this button if you didn't know the menu was collapsed
<jugglinmike> Matt_King: For a long time, we said to only put the "expanded"/"collapsed" state on the button when it's expanded because it seemed unnecessary when collapsed
<jugglinmike> Matt_King: It's sort of like what Apple talks about with "pressed" and "not pressed"
<jugglinmike> Matt_King: There were a couple reasons why we shouldn't be inconsistent in that way. That we should always have "aria-expanded" and it should be up to the screen reader to determine whether it was conveyed
<jugglinmike> Matt_King: One of the issues had to do with touch. When you are using these things on a touch device, you can focus the expanded or collapsed menu button regardless of the menu's state. It's really helpful to know the state of the menu in that case, especially when the menu doesn't appear adjacent to the button
<jugglinmike> Matt_King: So the question I'm asking is about the "collapsed" state itself (not the state change)
<jugglinmike> Matt_King: I suppose this would also apply to when you're navigating to...
<jugglinmike> IsaDC: Also when you close the menu. I think it should stay
<Joe_Humbert> q+
<jugglinmike> James: I'm inclined to say that if aria-expanded was not conveyed when it was "False" on a button, I would be concerned
<jugglinmike> James: However, a menu button is different than a regular button
<jugglinmike> Matt_King: The disclosure is completely different. You wouldn't know that, otherwise. In this case, because it's a menu button which has its own roles...
<jugglinmike> Matt_King: With a "must" assertion, basically, people wouldn't be able to perceive the interface at all if the screen reader didn't perform it
<jugglinmike> Matt_King: I'm thinking about if a screen reader fails to convey a "Collapsed" state on a menu button, what is the impact on a screen reader's ability to use the menu button?
<jugglinmike> Hadi: They would miss it
<jugglinmike> Matt_King: Well, if it said "Actions menu button", you would still recognize the menu button--even though it didn't say "Collapsed"
<jugglinmike> IsaDC: We didn't have state before, when we first ran the test plan, it didn't assert state at all
<jugglinmike> James: Reading the definitions, my view is that it should be a "may". The "should" says that it is "likely to impede users". I don't think the lack of state information is likely to impede users
<jugglinmike> Hadi: sometimes the children are not adjacent to the parent. The menu must be exposed, but it might not be immediately after that button. I don't know that, so I have to explore back and forth. It might be a long distance to travel to those children. I'm more toward "must", but I'm open to "should." Not "may", though
<jugglinmike> Matt_King: The menu button is supposed to move focus into the menu when it is expanded
<jugglinmike> Matt_King: If the menu is collapsed and it just says "action menu button" and you press it, then the focus is supposed to go inside of the menu
<jugglinmike> Matt_King: Would that impede you from using the menu button effectively?
<jugglinmike> James: To clarify my previous comment: going solely on the assertion descriptions in isolation, I think this is a "may" because if a menu button is collapsed, it's true that focus does not necessarily move into the menu. The state being conveyed as "collapsed" does not necessarily help you avoid that situation
<jugglinmike> Matt_King: Since we're not asserting "expanded", if it didn't convey "Expanded", then you'd be in a bad place
<jugglinmike> James: Since we don't have a test for "Expanded" and any such test would be convoluted and contrived, I believe it should be a "may" for collapsed
<jugglinmike> s/"may"/"should"/
<jugglinmike> Hadi: These things have been developed to improve the experience for everyone, including screen reader users. I am tired of meeting the minimum requirement. This minimum requirement means more work for people to get something done
<jugglinmike> Hadi: I know we have some protocol to follow, but I don't mind pushing to make it a requirement
<jugglinmike> Matt_King: Remember that we're not talking about the web page developer; we're talking about the screen reader developer
<jugglinmike> Hadi: Exactly, if the web page author made the effort, the screen reader should respect that
<jugglinmike> Matt_King: The reason having the difference between "must" and "should" applied consistently throughout the test--the reason that is important is that new or not-so-well supported ARIA features become available, it's really important that a web developer be able to look at the report and say, "it is basically safe for me to use this"
<jugglinmike> Matt_King: If there are too many "must have" behaviors that most screen readers don't support, then we end up in a situation where it inhibits the use of ARIA
<jugglinmike> Matt_King: I'm thinking about the future and how people will use these reports then
<jugglinmike> Hadi: I still push for "must"
<jugglinmike> Matt_King: In certain tests, it is failing. It would still be counted as a "fail" even if the assertion was a "should". In that case, the score is still not 100%. If we changed it to a "may", they might not fix it. If it's a "should", they're still gonna fix it
<jugglinmike> IsaDC: JAWS is failing this right now. I was quite surprised to see that
<jugglinmike> Matt_King: Me too
<jugglinmike> Matt_King: That's one of the reasons why I raised this issue. I wanted to make sure we had it classified correctly
<jugglinmike> Matt_King: And in a consistent way
<jugglinmike> Matt_King: It sounds like Hadi and James are both comfortable with a "should"
<jugglinmike> IsaDC: I also vote for a "should" to kind of soften the blow a little without losing the "hit"
<jugglinmike> Matt_King: Yeah. I want to be able to explain each of these assertions.
<jugglinmike> Matt_King: I don't know if we should be writing the rationales down, e.g. why is this a "should" or why is this a "must" or why is this a "may"
<jugglinmike> Matt_King: In this case, because we are not testing for aria-expanded, it becomes particularly important that aria-collapsed is conveyed because if you're interacting with this with touch, it's really important that you know at least one of the states. Otherwise you would be severely impeded
<jugglinmike> Joe_Humbert: Does the button always convey that it is a menu, though?
<jugglinmike> Joe_Humbert: The APG says that it has to have a role of "button"
<jugglinmike> Joe_Humbert: If aria-haspopup is true, does that convey that it's a menu?
<jugglinmike> Matt_King: Always
<jugglinmike> James: the element's implicit role is button, but as soon as you add aria-haspopup, it changes the role
<jugglinmike> Matt_King: Originally, aria-haspopup was a binary. We made "true" equal to "menu" in the interest of backwards compatibility
<jugglinmike> James: We should assert that the role of "menu button" MUST be conveyed
<jugglinmike> Matt_King: I don't know if haspopup is mentioned in the references, but it needs to be in the tests for "role"
<jugglinmike> IsaDC: I remember adding it to the references file...
<jugglinmike> James: We're saying that the user "should" convey them to the user, but if it doesn't, it wouldn't prevent them from using the button
<jugglinmike> James: In that way, WCAG is very binary, where this is three-state
<jugglinmike> Matt_King: Yup, aria-haspopup is in the test
<jugglinmike> Joe_Humbert: That answers my question
<jugglinmike> Matt_King: I think we'll update all three test plans
<jugglinmike> Matt_King: I'll do a pull request for this
<jugglinmike> Matt_King: It won't affect any of the test plan results. No one will have to re-test anything
<jugglinmike> Matt_King: Thanks everybody for this discussion!

[mcking65]

Result of discussion: Matt will write PR to change from MUST to SHOULD.