The spry menu bar as autogenerated by Dreamweaver (CS4/5/6) (all defaults maintained)
According to the API you can enable keyboard navigation by changing the boolean value enableKeyboardNavigation in the list of parameters as such:
var MenuBar1 = new Spry.Widget.MenuBar("MenuBar1", {imgRight:"SpryAssets/SpryMenuBarRightHover.gif", enableKeyboardNavigation: true}, );
Unfortunately this does not appear to work. According to other sources I could find (a few years old) the keyboard navigation is itself buggy; making it preferable to design one's own interface.
Tabbing the menu is successful - but will not prompt flyout sub menus - meaning that all submenu navigation through tabbing is blind (ironically that is, unless all css and javascript is stripped away, thus revealing the base html unordered list and hrefs).
Much to my surprise, keyboard interaction (via arrow keys) is enabled by default. Tabbing is only suitable for selecting non-submenu items.
Related
I have a design that displays a list of content that you can filter by different categories. Each filter is displayed in a dropdown menu that lets you choose one or more options, which when activated (either through click or keyboard), will update the results on the page. The page url does not change in response to the filter and there is no "submit" button to apply the filter.
I'm confused which ARIA pattern to use: Menu (with menu/menuitem roles) or Combobox (with listbox/option roles).
In my opinion you should go with a combobox.
Otherwise, it should be a menubar rather than menu:
A menu that is visually persistent is a menubar.
Managing focus
Aside from the question which role to use, you need to decide whether to manage focus or not. It is recommended (should) for menu and menubar, which would mean that the whole bar only has one tab stop, and navigation between the single dropdowns is done via arrow keys.
Website or application?
This depends on how much your site feels like an application overall. If it’s more of a website, keyboard users in general are more accustomed to tabbing than to managed focus. For users it is sometimes a surprise that you need to navigate within components by means of arrow keys.
If there are other composite widgets as well that manage focus, you absolutely could do so for this part as well.
Responsive Design
A menubar should allow left and right arrow keys to navigate the filters, and up and down to focus the options. Managing focus would get complicated with Responsive Design: Once items wrap, it becomes less obvious how to navigate to them.
Actions vs Selections
A menu is usually used for actions. To quote some references (emphasis mine):
A menu is a widget that offers a list of choices to the user, such as a set of actions or functions.
– Menu or Menu bar pattern
The WAI ARIA standard defines an actual `nole="menu"' widget, but this is specific to application-like menus which trigger actions or functions.
– Bootstrap
Since the filters only allow choosing options, and not executing commands or functions, I would rather go with combobox.
Searchability
Combobox also implies that it’s a flat list of options, maybe grouped. This is immediately known. A menu can potentially have sub menus, so it’s less clear what to expect when opening a filter list.
Since combobox is a flat list, users can type Printable characters to directly jump to a list item. This is not the expectation for menus.
Show the user’s selection
Since the filters close once a selection is made, it is best practice to display the chosen value or values in the closed item. Also known as the Visibility of System Status.
A combobox will do so, and screen readers would even announce the current choice without opening the list. A menu does not have that behaviour.
I am trying to implement keyboard accessibility in one of my website for blind people. I have a hamburger menu on my website. While navigating using the "Tab" key on the keyboard, the focus moves to this hamburger menu item. While clicking on "Enter", it will expand and while press the "Tab" key again, it is navigating through the open hamburger menu elements. Once the last item reached, it will focus on the content.
In that case, is it possible to close the hamburger menu once the user focus-out using the keyboard "Tab" keypress?
Example here https://www.impressivewebs.com/demo-files/hamburger-menu/. It is possible to close the side menu after focus out?
Short answer
It's possible, but it isn't a good idea.
You'd better use a classic toggle button.
Longer answer
For a blind person, doing something on focus out essentially means that it happens without notice. It may be hard to understand and is at best a source of confusion.
The elements that are successively reached in tab navigation and their order aren't supposed to change without explicit conscious user action.
It's even more confusing if the way in which the menu appears and disappears aren't symetric (in your case, explicit press enter vs. focus out).
Both should be symetric. This means that, whether:
The same button toggle the menu on and off
The menu appears on leaving the link just before the menu (focus in), and disappears when leaving the last item of the menu (focus out)
There are several important cons in implementing the second:
Tab isn't the only way to navigate on a page for screen reader users. This concretely means that the menu may not be reachable for no apparent reason, and there may not be any way to make it appear.
Keyboard-only users having vision will probably be surprised of unexpected appearance/disappearance of the menu
Technically it isn't as easy as it looks like: you must think about it in the two directions (tab and shift+tab)
The toggle button hasn't these problems. Correctly implemented, it's always reachable, explicitly triggered by the user and has predictable behavior.
Additionally, it's much simpler to implement.
To wrap it up, the classic toggle button is therefore by far the simplest and safest solution, both for you and for users of various kinds.
Background: for Windows users on Chrome and IE, dropdowns that reload or change the page are no good for accessibility. As soon as a user presses the down arrow button, the page reloads. This means that the user can only access the very first menu option. Here is an example: http://html.cita.illinois.edu/script/onchange/onchange-example.php
This is covered in the WCAG rule:
“Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component. (Level A)”
EXCEPT the user can very easily open up the dropdown and explore all the options without triggering an onchange event. The user does this with a space bar press. This is a very commonly known keyboard trick that I've seen all tested users to already be aware of or be able to figure out quickly.
In my system, we are using a dropdown for pagination in long directories.
EG: "you are on page [1^] of 16" (with the [1^] being a browser default dropdown menu). The designers will not allow any kind of visual [go] button. This happens across thousands of pages, javascript fixes I've seen need to account for every dropdown, and this is impossible on our case.
Using space bar, the user can see all the options and make a selection from anywhere on the list using only the keyboard. So why are dropdown page menus that automatically reload onchange still considered inaccessible? And would they be considered accessible if we included screen-reader only text which said "press space bar to open this menu, making a selection will load your next page"
Well except that in Firefox, the keyboard command is actually F4, you are correct - this is not a WCAG 2 violation but rather a best practice
Here is a page where you can test this: http://dylanb.github.io/onchange_select.html
I have an application that shows multiple subpanels & the client wants to show different menus for each subpanel.
Mac apps can only have one menuBar per system window, apparently, and it's minimally modifiable (if at all.) I need to remove/add or enable/disable menus on the menubar.
I've thought about making each of the subpanels a system window and attaching a menubar to each, but I don't see any provision for switching to a window's menubar. Besides, I suspect that doing so would create a state/positioning mess for the subpanels.
What I've Found
I've found that if I create the actions as children of the main window, I can add and remove them at will from the menus themselves. So, I can modify the menu contents, but I can't modify the menubar contents.
I've found I can also change the title of the menu to anything at any time. So, if I clear the contents and set the title to an empty string, it has the apparent effect of removing the menu (although it's still there and still highlights).
Barring another solution, have to do that, for now.
Is this possible at all on Mac? If I went down into Cocoa (don't know Cocoa), would I be able to maybe set up multiple menubars, or at least modify the menubar when the subpanel changes?
I was searching something else but as precisely I've just been working this one, what I do is
- delete the current menuBar if there's one
- menuBar=new QMenuBar(0);
- menuBar->setNativeMenuBar(true);
And it seems to work fine. Just for what it's worth.
A Cocoa application has only one menubar active at any given time, and you can modify and replace it. For instance, the (Cocoa) code below adds a new menu (with three items) to the menubar. It is also possible to edit and remove menus as well as menu items.
NSMenu *menubar = [NSApp mainMenu];
NSMenuItem *newBarMenuItem = [[[NSMenuItem alloc] initWithTitle:#"" action:NULL keyEquivalent:#""] autorelease];
NSMenu *newMenu = [[[NSMenu alloc] initWithTitle:#"New Menu"] autorelease];
NSMenuItem *menuItem1 = [[[NSMenuItem alloc] initWithTitle:#"Action 1" action:#selector(action1:) keyEquivalent:#""] autorelease];
NSMenuItem *menuItem2 = [[[NSMenuItem alloc] initWithTitle:#"Action 2" action:#selector(action2:) keyEquivalent:#""] autorelease];
[newMenu addItem:menuItem1];
[newMenu addItem:[NSMenuItem separatorItem]];
[newMenu addItem:menuItem2];
[menubar addItem:newBarMenuItem];
[menubar setSubmenu:newMenu forItem:newBarMenuItem];
[NSApp mainMenu] returns the application menu. A new menu item is added to the main menu/menubar, representing a submenu that contains three items, one of them being a separator.
It is also possible to replace the menubar by crafting an appropriate menu and sending [NSApp setMainMenu:menubarReplacement].
Yes, this is possible in a Qt app, and fairly common. :)
In your app you probably have code to build your menus, and install them into the menubar (using QMenuBar) in the first place. As Juan correctly points out, to alter the menu bar, you can delete that instance and regenerate a new menubar and its menus as needed.
In my own code, I just keep my original QMenuBar around, and call QMenuBar::clear() on the instance. This is an alternative to the delete/re-instantiate that Juan recommends, although either approach is likely valid. Then I repopulate the menubar with the currently needed menus.
I typically only rebuild the whole QMenuBar when the set of top-level menus, or the title of a top-level menu needs to change. More commonly, I am dynamically regenerating the actual menu items (QActions) and/or their state (like their text, whether they are enabled or not, checked or not, etc) within a given menu.
To dynamically regenerate a single menu's contents only, you can connect a method callback to that particular QMenu's aboutToShow signal, and rebuild the menu's items dynamically within that callback (don't forget to start with QMenu::clear() on the instance or you may end up with duplicate items in the menu!). When the QMenu pops up, it will show your dynamically rebuilt items/states. This method also works for dynamic regeneration of popup/context menus.
I am looking to create a menu bar with a specic type of "action"
Similar to the bar on this website
BBC Sport
Its totally static and has no dynamic or "pop out" sections. When the top menu is clicked the page will re-load and display the lower level in a diffrent colour.
Can this be achived with the Standard ASP:Menu control?
I am not a big fan of the pop out feature however I do not want all my options to be visible to my users at root
Hope that makes sense
Check out this basic ASP.Net Menu control page. You can click on the "Run" buttons to see very basic versions of the menus.
The advantage of using this particular approach is that you can tie it to a sitemap, so you don't have to keep updating the menu code. You just add the page(s) to the sitemap, and the menu picks it up.
You can also dynamically link the menu to different sitemaps, such as one for the admin menu and another for regular users' menu.
The Menu control is in the navigation section of the toolbox.
To experiment with the built-in functionality (before writing your own code to do what it will do for you), just drag and drop a menu control onto your form. Then, use the common tasks menu to:
autoformat -- good for quick & dirty because it sets hoverstyle too
set the data source
set the view type (static or dynamic)
define menu items with an editor
work with templates to set appearance
You have to go to properties to set menu appearance.