aria-practices
aria-practices copied to clipboard
w3c
The Disclosure (Show/Hide) Navigation Menu disclosure pattern is potentially adding confusion, not clarity
I opened a ticket against ARIA-AT on one of their tests to do with a disclosure menu implementation, and the response (and immediate closure) has led me to open an issue against this ARIA Authoring Practices example instead.
I'm doing so because I am seeing a growing number of implementations of menus that are almost unworkable for a sighted keyboard use due to someone making a menu that is, in the words of this pattern, only a menu in the "colloquial sense."
First, a couple of obvious errors in this example's guidance:
If a dropdown is open and focus is inside the navigation region, pressing Esc will close the dropdown. Moving focus out of the navigation region also closes an open dropdown. Implementing this Esc behavior is necessary to meet the WCAG 2.1 1.4.13: Content on Hover or Focus criterion.
This is simply not true. The dismissible behaviour for 1.4.13 was created to address situations where content appears on hover or focus. In this example, neither hover nor focus triggers new content in the disclosure. Instead, the faux menus are open on activation. As such, 1.4.13's dismissible requirement (Esc) does apply.
Second, the example lists 7 keyboard operators (some optional), but the APG disclosure pattern has only 2 keyboard requirements: when the disclosure control has focus, Space and Enter activate the disclosure control and toggle the visibility of the disclosure content.
So why has this example added Esc functionality? It's done because that is what anyone using a "menu" expects. And if it doesn't offer that, people will consider it broken. The same goes for all the optional arrow key operation. The same also goes for the automatically collapsing behaviour: "Moving focus out of the navigation region also closes an open dropdown".
You can see examples of failed "menus" (in the colloquial sense) all over the place these days. My favourite one in the past week was this monstrosity from H.E.B., Texas's biggest grocery chain.
H.E.B. has created a menu where the user keyboards to it, and then is forced to navigate by tab through every single item and sub-item in it in sequence, before going on to the next menu's contents and repeating. The result? Just to get past the Shop 'menu', I need to press Tab 134 times!
The interesting thing about this 'menu' is that it essentially uses the basic APG disclosure pattern properly. It botched it by revealing the 'menu' on focus instead of on activation. Disregard this glitch (just pretend it opens on activation instead of focus and hover), and this works exactly as the basic APG disclosure descriptions states:
A disclosure is a widget that enables content to be either collapsed (hidden) or expanded (visible). It has two elements: a disclosure button and a section of content whose visibility is controlled by the button. When the controlled content is hidden, the button is often styled as a typical push button with a right-pointing arrow or triangle to hint that activating the button will display additional content. When the content is visible, the arrow or triangle typically points down.
The only part of that H.E.B hasn't followed (besides the hover/focus activation) is that their arrows do not "point down" when the content is visible. I'm assuming we can agree that H.E.B's implementation is essentially unusable?
BTW, note that H.E.B adds in additional functionality that is NOT part of the basic Disclosure pattern: they collapse the disclosed information when focus leaves the construct. But a nuts and bolts disclosure does not have this requirement, and in fact, if you started closing disclosures that a user had opened, you'd likely hear about it.
All of this is to say that the Disclosure (Show/Hide) Navigation Menu is not a pure disclosure pattern but a mash-up of a bunch of Aria designed to behave like a menu. I know there is a proviso at the top of this example cautioning about this (hidden, interestingly, by a true disclosure). But if one looks at the behaviour on the ARIA-AT against which I opened the issue, it's possible to see a compounding of fractured guidance which ends up creating a test pattern that is essentially NOT "working as expected", to quote the closer of the ticket.
I'll add more to this, but am going to submit now before I lose the whole thing!
BTW, I've made prior comments on this kind of thing before, but an essential problem I'm trying to get addressed here is that the more we push accessibility left in the dev cycle, the more it is going to be designers assessing and conceiving interaction. The vast majority of them use visual cues for interaction, and bias to visual conventions (even if many do keep trying to create Frankenstein hybrid mashups). So the APG material must concentrate on harmoizing the construction under the covers with the visual cues and operation of a component. The more the two divide, the more problems we're going to create.
The dismissible behaviour for 1.4.13 was created to address situations where content appears on hover or focus.
The reference to 1.4.13 should be removed, of course. Can you create a PR for it? Or wait for https://github.com/w3c/aria-practices/issues/2261
I'm afraid I don't really understand the rest of what you're saying. What is your intention? Not to offer this example anymore because there are different menu variants and it is not visually recognizable how I have to operate it? Yes, I see that as a problem too, but keyboard users are always confronted with that on the web.
- a bar with 3 buttons - is a toolbar with arrow key operation or none, so navigating with TAB.
- a table: is it a grid with arrow key operation or a table with TAB operation
- a menu: is it simply a link list with TAB operation or an ARIA menu with arrow key operation
It would be nice if there were clear visual indicators for all cases to indicate operation, as the HTML and ARIA roles do for AT users. But is that realistic? And if so, is this what ARIA Practice is for?
@JAWS-test Up against a deadline so I will try to respond in next few days. But briefly...
It would be nice if there were clear visual indicators for all cases to indicate operation, as the HTML and ARIA roles do for AT users. But is that realistic? And if so, is this what ARIA Practice is for?
Yes, I think that is realistic or at least approachable. To the degree there are clear indicators, I think the APG needs to reinforce consistent ties between visual behaviour and coding (roles, states, etc). If it can't do that, we are in a highly problematic area where (just to choose 3 user personas) a blind screen reader user, a sighted screen reader user and a sighted keyboard user will not be able to use the same implementation successfully (or at least easily).
The other thing I'm driving at is somewhat abstract, but crucial. The Disclosure pattern in APG contains nothing about use of the Esc key, yet it appears in this example. The reason stated is to meet the 1.4.13 requirement, which is untrue. My conclusion is that this is not a true Disclosure pattern -- or put in another way the disclosure pattern alone cannot support a pseudo menu experience and needs to be dressed up with a lot of add-on coding and keyboard operators. As the warning on the APG pages implies, this kind of complexity and variance is likely to lead to gaffs or poor user experience, and that is born out in the ARIA-AT test build of this example, which clearly has something wrong with it. Almost every one of these disclosure menu patterns I encounter, on a demo page or in the wild, has something wrong with it. A properly functioning one is the exception. So how can we get to a point where we reach a more universal user experience? I wonder if the material that is in the pattern should focus on interaction, and reserve the roles/states for examples instead of listing them in the pattern? Thinking about the disclosure menu example, it's using the interaction of the menu pattern (primarily), not the disclosure pattern (which only involves Enter/Space to toggle). If the model can be swivelled so something like this example can logically reinforce the pattern guidance, it may reduce friction.
@mbgower
I had the impression that there was so much criticism of the menu with menubar and menuitem that exactly for this reason further variants for a menu were developed, which are more oriented to the classic HTML menu without ARIA (see https://www.w3.org/WAI/tutorials/menus/flyout/). That in the menu with disclosure now ESC is used to close, I do not consider at all problematic, but this corresponds exactly to my expectations. The fact that ESC is not mentioned on the pattern page can be fixed by mentioning ESC as an optional key to close a disclosure.
The fact that ESC is not mentioned on the pattern page can be fixed by mentioning ESC as an optional key to close a disclosure
But except for this menu-like function, Esc would be a pretty bad thing to advocate for in a disclosure, wouldn't it?
Also, ESC is just one of the changes in behaviour. The collapse on loss of focus is another crucial part needed to echo a menu experience, and that's also not something one would want considered as part of a typical Disclosure pattern.
To me, a button with aria-haspopup seems like the closest to replicating a menu-like experience. It's unclear to me from reading the spec whether such a button HAS to contain menu-items, or if it can have a list of links. The latter would obviously address various concerns expressed about links losing some functionality when given a role of menu-item (although I personally think that in the context of a menu, there are decent counter-arguments to much of that).
menuitem role An option in a set of choices contained by a menu or menubar.
That "option" wording seems to suggest that maybe using menuitem inside menu is optional, and so it may be possible to have a consistent keyboard experience for menu-like constructs, regardless of whether they contain menu-items or links. Or maybe they don't mean "optional" here, but literally one item/option in a set?
Or maybe they don't mean "optional" here, but literally one item/option in a set?
"An option" means one item/option in a set and not "optional"
But except for this menu-like function, Esc would be a pretty bad thing to advocate for in a disclosure, wouldn't it?
I don't see it that way. I would like ESC to close each disclosure, but I would not consider it necessary, so it is only optional. Why should it not be good if other disclosures can also be closed with ESC?
The collapse on loss of focus is another crucial part needed to echo a menu experience, and that's also not something one would want considered as part of a typical Disclosure pattern.
That's absolutely correct, but I don't see why that should be a reason not to use a disclosure as a menu. An element can have different characteristics depending on the purpose of use
It's unclear to me from reading the spec whether such a button HAS to contain menu-items, or if it can have a list of links.
According to the ARIA specification of aria-haspopup, a button with this attribute can open anything: a menu, a linklist, a tree or something completely different.
However, there is the problem that a button with aria-haspopup is mapped to menu button, so that actually only a menu should be used. This does not apply to other elements, such as links with aria-haspopup, for these it is unproblematic if you use aria-haspopup=dialog and the dialog then contains a linklist
I was just working on another disclosure 'menu' pattern with its own odd implementation decisions and found myself back at this issue again.
@JAWS-test, you said you didn't see a reason why a disclosure pattern can't be used to simulate a menu interaction. My original position was because it is trying to hybridize an interaction out of something else, and unintended consequences can happen. As exhibit A, I invite you to return to the test case that I originally opened a ticket against.
As per my last comment in that issue , if you have a sighted keyboard user try to interact with this example, they will get VERY frustrated because after the 'menu' has been opened, it continues to stay open despite making selections from it or navigating away from it, etc. That may be what one could expect from a disclosure pattern, but it is absolutely not what one expects navigating a menu. The result here is that it obscures content on the page.
Besides obscuring some content, it can also add confusion. On this particular page, if they focus their effort on the About menu as I did, none of the content seems to update when making any choices within the 'menu' because the only thing changed in the 'tab panel' underneath is the heading, which is visually obscured by the About menu contents. At least on the other menus, you can see the heading change as you select different items -- though you cannot read the rest of the content.
The experience for a screen reader isn't obviously bad like this, but when I Shift+tab back 'up' the page to get to my prior location, I discover that my expanded section has remained open. I would call that peculiar. But maybe someone interacting with that would be 'okay' with it, or only surprised once? What would that same user say, having established that expandable sections are going to remain expanded, when having opened up both the About expandable section and the Admissions expandable section, they find that the About section has, for some reason, collapsed?
I also question the use of 'same page' links to refresh content dynamically in what is essentially a small tab panel. My expectation of a bunch of same page links is that I'm going to be moved around in a big document. In this particular case, the text in the panel tells the user "sample content section. Activating the link above will update and navigate this region". Without that description, I'm not sure anyone would understand the interaction. Maybe this whole refreshable section is just here to allow something to happen when the user selects a menu item, but my take away is that we're now creating inconsistent menu-like AND tabpanel-like behaviour.
if you have a sighted keyboard user try to interact with this example, they will get VERY frustrated because after the 'menu' has been opened, it continues to stay open despite making selections from it or navigating away from it,
The behavior does not occur at https://w3c.github.io/aria-practices/examples/disclosure/disclosure-navigation.html#mythical-page-content. When I exit the menu with the keyboard or make a selection, the submenu is closed
I also question the use of 'same page' links to refresh content dynamically in what is essentially a small tab panel.
My understanding of the example is that it can be used for the main site navigation and the menu items would not normally contain same page links, but normal links to new pages, unless it is a single page application. Visually it appears different here because the example is embedded in a page. In reality, the example would be an entire page.
I think it would be useful for people who created the example or run this site (e.g. @mcking65. see: https://www.w3.org/WAI/ARIA/apg/about/#acknowledgements) to comment. I, as an outside observer, can only poorly defend the example, since I do not know the reasons why it was included here.
Yes, the example you pointed at does not have the persistent dropdown challenge, and is generally more usable. I find it a little odd that pressing the down arrow when on a menu does not open it (the optional pattern for a menu) but instead moves the focus to the left. I get how synchronizing the left/up and right/down arrow keys allows this pattern to work with both vertical and horizontal menus, but it is pretty counter-intuitive. But this is probably not the issue where I should go into details on a different example :)
Yes, the example you pointed at does not have the persistent dropdown challenge
and with which ARIA APG example do the problems you describe occur?
@mbgower
Do not consider the aria-at test cases as complete implementations. They are modified/reduced to support testing requirements. At some point in the future, aria-at will be able to pull test cases directly from the APG, but we need to make some modifications to the APG to support that.
The only source of examples you should use is the production site at w3.org/wai/aria/apg.
As @JAWS-test pointed out, we have an open issue to remove the WCAG reference about Escape.
It would be nice to have a crisp list of other problems but based only on the version of the examples on the production site.
Perhaps we could plan a discussion during one of the task force meetings and you could participate?
which ARIA APG example do the problems you describe occur?
@JAWS-test I link to the aria-at test case in my initial comment. And my description is based on that. Since my issue was immediately closed there, I decided to open it against the APG version (as was requested by the issue closer).
@mcking65
Do not consider the aria-at test cases as complete implementations.
Okay, that's useful to know. So I should ignore any problems on any of the aria-at tests, but flag any issues with the 'official' versions.
It would be nice to have a crisp list of other problems based only on the version of the examples on the production site... Perhaps we could plan a discussion during one of the task force meetings and you could participate?
I can attempt to do that going forward as I encounter a pattern that matches fairly closely something I'm assessing in the Carbon design system. I'll try to keep them as "crisp" as possible. Such brevity will almost certainly result in the need to discuss, as you note.