Review navigation menubar example revisions made through June 2017 #410
Comments
mcking65
added
Example Page
|
This example is in violation of the current ARIA spec, because the ARIA spec doesn’t actually allow the
The questioners there wonder why the W3C HTML Checker reports an error for And the answer to that is, as long as the spec prohibits it and the checker claims to conform to the spec, I don’t really have any choice other than to have the HTML Checker report an error for it. (Incidentally, this makes me wonder whether anybody is taking responsibility for auditing the examples in the WAI-ARIA Authoring Practices guide to ensure they actually conform to the requirements in the ARIA spec and ARIA in HTML spec. It’s obviously not a good thing when we’re confusing authors and web developers by providing examples to the community that aren’t actually conforming with spec requirements and that cause the W3C HTML Checker to report errors.) |
|
For what it’s worth, APG has a code conformance section on GitHub that states Perhaps we should add a note to that effect on the example page. |
|
So if we want to expose the expanded status for AT users we need to use aria-expanded with role=menuitem even though this is currently invalid according to the spec. |
|
Example 1 has a dropdown with an additional sub flyout menu. This requires a right arrow or enter key to activate. Should this not be provided in instructions? On Voice over they are not provided. |
|
@DavidMacDonald commented:
That is a VoiceOver design issue/decision. Currently in native menus, VO does not give instructions for parent menuitems. However, VO does announce the presence of the submenu, which it does not yet do for ARIA parent menuitems. That is a VoiceOver bug. |
|
|
Below, marked as code, is the value of the aria-label attribute for the UL just after "Facts", as seen with the Node Inspector in Safari for Mac (but same result with other browsers and inspectors): Obviously there are some closing tags missing somewhere. Same goes for "Campus Tours". Also (related?): keyboard navigation is broken when VO is on. Test steps:
Result: once the cursor is on "Facts", it jumps back to "About". |
|
Hi, I've been looking at this example and trying to understand how a user with assistive technology would interact with it. I'm using VoiceOver on MacOS 10.12.6 for my testing. When I interact with a menu item (e.g. "Admissions") by pressing "Control Option Space" as instructed by VoiceOver the menu item does not expand and focus does not move. Shouldn't the menu item expand and then allow me to navigate the child items within? I'm a developer and not that experienced with using Assistive Tech but have a basic knowledge of how to use VoiceOver. |
|
@OlivierNourry commented:
Hmm, not so obvious to me. When I inspect with screen readers, on both MacOS and Win, the label is getting calculated correctly. When I validate the document, there are not any missing closing tags. @jnurthen or @jongund, can you "see" this. The way that JAWS and VO read the DOM tree to me in the dev tools, I don't notice the issue.
First, it is important to understand that:
So, do not expect similar behaviors for ctrl-opt-up/down and up/down; they are quite different. When using up/down and quicknav is off, which is the best way in Chrome, there is wrapping from first to last and last to first items in these menus. That is optional behavior. And, when using left/right, the menus work exactly the same way your system menubar does on the Mac. VO provides much richer support for ARIA menus in Safari. It actually provides the same kind of support it does for system menus. So, for example, when you activate a menu, it gives you the cool popup sound. And ctrl-opt-up/down work inside the menus. Keep in mind, though, since those are VO commands, that navigation stops at the edge of the container. When using VO, ctrl-opt-space simulates a mouse click, not a key press. To open a menu, you can use enter or the appropriate arrow key, and that works. In Safari, ctrl-opt-space works in the menubar, but mysteriously does not work on the "Facts" submenu. In Chrome, ctrl-opt-space does not work. I do see that using the mouse with VO sometimes doesn't quite work right for the submenus. This is a clue to the issue with ctrl-opt-space on the "Facts" menu. If you:
I expect step 5 5to open the Facts submenu just like I assume it does if you are capable of using a real mouse. The fact that it does not indicates a possible Safari or VO bug. Oh, I am using MacOS 10.12.6. HTH. |
|
@WillsB3 commented:
It should, yes. And, it does in Safari, in the main menubar. But does not seem to do so for secondary submenus, e.g., "Facts". Oddly, it does not work that way in Chrome. I believe that is a VoiceOver bug. However, all the VO commands that start with ctrl-opt-SomeKey are more like using a mouse than using the keyboard. They do, generally, also move the focus, so it is sort of an odd blend. Once you have focus inside of an ARIA widget, it is usually best to have quicknav off (press left and right arrows at the same time to toggle). Then, when quicknav is off, the letter and arrow keys will be available to the web application instead of being slurped up by VoiceOver. We will someday add an appendix about screnen reader reading modes. And, after we do, it might be a good idea to add a link to it from all the example pages. |
|
@mcking65 You wrote:
I do confirm my observation. Checked with the Accessibility Inspector in XCode, not on the UL element itself because it can't be targeted directly, but through one of the child items. The value in the Parent parameter is akin to what I pasted in my initial post. Regarding the keyboard interaction -- ah well, I had quick nav activated, wasn't aware of it. With quick nav off, it works as intended, with the slight difference that the submenus are open on focus, not upon activation with the Right Arrow key. No biggie, though. |
|
@OlivierNourry commented:
I am not familiar with Mac inspection tools, but this hints at a possible bug in the tools because VO is picking up the correct label.
Yes, it does. Put focus on "History" in the "Facts" submenu. Then, disable cursor tracking with ctrl-opt-shift-F3 and use ctrl-opt-left. You will hear VO tell you the name of the menu and the number of items in it. It doesn't announce this info dynamically while reading. That is a VO design decision, not a problem with the menu.
I would dnot be surprised if Safari is behind that problem. Posinset and setsize attribs are calculated dynamically by the browser.
Displayed, not activated on focus. That is by design; it is to be like desktop menus.
Yes, VO is buggy here. The support for web-based menus in VO is not yet nearly as robust as for the desktop. And, that is part of the point of examples like this. Our goal is to help the browser and screen reader devs work all this stuff out so we can have fabulous experiences for AT users when they are using web-based GUIs. That does mean, though, that the example itself really does have to be correct. Unless I am missing something, so far, none of this seems to point to a problem with the example code.
As a VO user, I generally feel like it works quite well, especially in Safari. Although, you have pointed out that there is a lot of room for improvement in VO behavior, and possibly in Safari as well. We do have several outstanding issues related to the menu examples, most notably related to mouse behavior. You can see everything open related to the menu examples in the menu and menubar project. |
|
@mcking65 thanks again for the thorough answer, I certainly learned a few things in the process!
I spare you the whole content, it's actually the inner HTML content of the UL that is the container of the sub menu. Which is absolutely consistent with what it says with Chrome, and what is found out by the code inspectors in the 3 major browsers, plus the accessibility inspector in XCode. They can't all be wrong, can they? |
|
@OlivierNourry commented:
Well, that could be part of the problem. There are quite a few updates since we last published to w3.org. I have been refering to the editor's draft on github.io: Have a look at that and see if it helps. |
|
@mcking65 all right, mystery solved! |
|
I have tested this with keyboard only in FF and IE. When you are on the last item(Academics) in the menubar , navigate to the submenus using down arrow. Same thing is happening in IE browser. |
|
@shirsha commented:
Siri, thank you for finding this! This was another form of issue #346 that @jongund has now fixed with commit 2549421. |
|
I'm a little confused that the top level menu items are tags with an href. With a mouse click, it seems the link is being followed (it's a named anchor to the top of the page, but replacing the href attribute to an external link also seems to work). But, it doesn't seem possible to follow that link directly with wither VoiceOver or with Keyboard Only. This seems bad — if the top level page has important information that can't be accessed by a keyboard user or VoiceOver, those users are left unable to navigate to those pages. I haven't seen this mentioned in the preceding conversation (though I could have just missed it), and my developers / designers have been disagreeing about its merits. I find myself recommending against navigation menu widgets altogether because I can't provide a good answer to whether the top menu item should also operate differently on mouse click than on pressing Enter. Any thoughts would be appreciated. |
|
@michaelwayneharris87 commented:
The "About", "Admissions", and "Academics" menu items have @michaelwayneharris87 commented:
Having a link in a menu that both has a target URI and provides access to a submenu is a common pattern. But, it is not one that we recommend. There are a significant number of people that argue that it is not possible to consider that pattern accessible regardless of how you code it. This guide does not go that far. At least for now, we still have a plan to provide an example like that (issue #159). @michaelwayneharris87 commented:
Note 4 in the keyboard subsection of the menubar design pattern reads:
So, one way to make parent items that also have an href work is for space and enter to follow the URI in the href and for down arrow to provide access to the items in the dropdown. The main challenge is communicating that to users. This is somethig we still need to work on resolving. @michaelwayneharris87 commented:
For now, I would recommend not overloading parent menu items with both link and parent menu item behaviors. I hope your designers could learn to live with that. That constraint can increase clarity for all users, not just those who do not use a mouse. For example, on a clothing site, if you had a page about all pants, and sub pages for jeans, dress, etc. You could have a parent menu item for pants and the first item in the submenu could be "All Pants" or something like that. It is one extra click for some people, but more clarity for all people. Hope this helps. |
|
Wow. Thanks! |
|
@mcking65 It took me a while to go through all the comments. In particular, I loved to see the note about the validation error within the example. I have read through the example page and checked keyboard navigation info as well as coding structure. All looked correct for me. I cannot wait to see this example to be part of the spec soon since we have been working on this example for a while. |
|
Hey there, I'm wondering what consideration is being made to the issue that Adrian Roselli filed pertaining to this pattern. The reason I ask is that I had an instance recently where someone I was working with specifically pointed to this pattern as to the reason why they wanted My response to them was that by overwriting the semantics of their My response was politely considered a differing opinion due to it being in contrast to the "official ARIA practices" example. I can completely understand the need for a pattern like this, in recreating application-like menus, but as I also noted in Adrian's issue, I worry about promoting the use of Thank you |
|
scottaohara commented:
We are planning to address that issue fully in release 2 of the guide. Release 1, that will be published before the end of the year does not directly resolve it.
That could be good if they follow the pattern accurately and bad if they only cherry pick things like the roles.
That is most definitely bad. Makes me think that we should wrap a
Yes, that is correct. The landmark part is the bad part of that. The link part is not necessarily a problem, depending on the design of the site and the context of the navigation.
Right. And, if the design of the site does not provide ways of discovering the navigation easily, this could present a major usability challenge for some people, especially some screen reader users.
It is normal to tab to links, but it is not normal to tab through menus in a GUI. So, if a site has a flat list of links that is not terribly long, then tabbing is reasonable, if not ideal. if there is a hierarchical nav system that works like a GUI, it would be bad to force people to tab through all that. One of the beautiful things about bringing accessible GUIs to the web is that you can make keyboard navigation much, much more user friendly.
A menubar can be an excellent navigation pattern when done well. I think one of the problems is that the keyboard user who is sighted is a second class citizen in today's designs. No, I take that back; they have been second class citizens ever since the dawn of GUIs that are optimized for direct manipulation. Mouse users get all kinds of fancy, built-in clues to available affordances. For instance, the mouse pointer changes shape to indicate possible operations. Keyboard users, on the other hand, are lucky to get a focus indicator they can see. Visual design that makes keyboard affordances perceivable are extremely rare. Windows underlines accelerator keys, which is a mild help. But, is there any system support for indicating that you should navigate with arrow keys in the menubar of your browser? People who try to operate without a mouse for the first time feel like they have to go to school just to learn how to use their computer. We need to change this. It's worse on the web. Many people have become accustom to being forced to navigate to every element with just one key -- Tab. This degrades the keyboard UI to the point of unusability, forcing people to press the tab key thousands of times compared to a rapid click here and there for a mouse user. GUIs on the web that actually work and are fully accessible are the first step toward making web software practical for people who cannot use a mouse. But, in my opinion, we need to make the web better than native GUIs because, as I said, native GUIs are horrifically difficult to learn to use without a mouse. Some software is super easy and enjoyable with the keyboard, but only if you are in the know; you took time to RTFM. ARIA solves this problem for screen reader users. But, for sighted keyboard users, we need more work to make visual designs that help people understand what to do. You can see one small attempt at this in the example of a grid that presents a simple list of links. |
In response to feedback from @scottaohara in issue #410, modified examples/menubar/menubar-1/menubar-1.html: 1. Wrapped the menubar in a nav with aria-label equal to aria-label on menubar. 2. Fixed the menubar label; changed from "Mythical University menu 1" to "Mythical University". This should have been changed when the second example was removed from the page.
|
@mcking65, I understand this is getting outside the scope of the original issue, but you make some assertions above that I feel must be addressed.
All of this is well outside the scope of the menu pattern. If you feel this is not, then the menu pattern must also include thorough and cross-referenced statements about focus styles, contrast, and so on. This should include clear instructions and should not suffer from the issues itself (see the red arrows on the black background in the linked example). You cannot identify benefits and problems in a pattern you want to mimic and then fail to include them in your own pattern. For example, you identify accelerator keys in Windows (which are now only indicated when the user presses the Alt key) as a "mild help". Should the menu pattern also include those? Should the pattern include
The menu pattern does not change (nor improve) that overall experience. A keyboard user still must tab many times to get to the menu pattern, and once there, must switch keys but press it no fewer times to navigate within the menu itself. To address the problem you identify, browsers should expose landmarks. That is not in the scope of the menu pattern.
I do not disagree that native UIs are difficult for mouse users to use without a mouse. However, my and your opinion do not matter here. Proper user research can support or refute our opinions. I can shower you with results from my own studies, but more importantly I think this needs to keep to the scope of identifying how to make the pattern. Not trying to re-write how the web is used by using ARIA as a cudgel.
ARIA cannot solve this problem for non-SR keyboard users. It is not exposed in other AT. I agree that we need more work to make visual designs that help people understand what to do, as you say. To that end, this pattern will need to include instructions to keyboard users on how to use it. Otherwise, it is not a very effective pattern. The "simple" list of links that you link uses a technique that you should include in the menu pattern. Perhaps then we will have a full pattern we can test with non-SR keyboard users instead of just asserting that it is better. Coming out of your feedback, I have pulled 4 items you identified that it seems need to be included in the menu pattern before it can be wrapped up:
All that being said, the menu pattern does not belong on web site navigation. |
|
+1 for adding nav region and text about it under Accessibility Features! No issues noted. |
|
@aardrian commented:
Well, in my midnight mood, I did get a bit punchy and go off topic. Yes, this is outside the scope of the current work on the design pattern. However, I do one day want to get the community more focused on evolving visual design of GUIs on the web to better serve a wider variety of people.
I m not sure what would be the most practical approach here. The design supports first letter nav but not the equivalent of accelerators. I am definitely not a fan of
Menubars can definitely improve this.
So, it is possible to make a simple, efficient nav system with a menubar that provides real advantages over some other alternatives if you are ready to make the required investment in design and engineering.
Correct that is out of scope for this pattern. And, yes, browsers could expose landmarks. But, authors can do it too. The APG does not yet address this topic. However, we are experimenting with this at Facebook. Go to www.facebook.com and tab into the page or press alt+/ from inside the page. The first menu labeled "Sections of this page" reveals the landmark regions on the page. Keep in mind that this feature is still in its early days.
Possibly. We do not yet have enough feedback on that instructional popup or "NUX" and associated visual design to spread it more widely across the ARIA Practices examples. It is just an "idea" that I had put in to the grid example to see if it helps solve a problem that the naked ARIA does not address.
I agree that in some form or other, these general concerns need to be addressed someplace in the ARIA practices. I would leave out
I agree that most of the time it is not the best fit. But, whether it is a good fit depends on many factors, including the existing the design. If people make GUIs that behave like menubars and use them for web site navigation, which they sometimes do, then the menubar pattern belongs there. Without it, those GUIs will not offer users of assistive technologies the same benefits that the visual designs offer others. They won't really be accessible. We will treat the topic of choosing an approach for making site navigation accessible when we start work on the relevant issues in the "Do Later" column of the menu and menubar project: One of those issues, like the one you raised, is the best place to continue this conversation. I probably should have been writing there rather than here. |
|
@MichielBijl @mcking65 wai-eo-editors mailing list just received a possible bug report on this component: https://lists.w3.org/Archives/Public/wai-eo-editors/2018Nov/0011.html |
|
I've noticed a number of issues with this drop down; I'm happy to add more details i.e. steps to reproduce if these issues haven't been raised already:
|
|
In the On touch devices, we should have the link Right now, If I click with the mouse on the menuitem into the menubar I go to the link, but If I press enter It open the menu. So for users with controlling with keyboards, it is impossible to visit that page EDIT: improving description |
github-project-automation
bot
moved this to Complete
in Menu, Menubar, and Menu Button patterns and examples development project
The navigation menubar example
has been significantly revised to correct errors and rephrase for editorial consistency. It is ready for additional review.
Open issues
Reviews requested as of June 20, 2017
The text was updated successfully, but these errors were encountered: