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.
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.
The arrow keys navigation works fine when NVDA is off, but as soon as I open NVDA in the background I can't use it to navigate in tab groups.
Did you ever experience this and do you have any suggestions on how to resolve it? Thank you.
The role is set to 'presentation', I tried changing it to tablist and it does not work. Role 'tab' alters the entire navigation behavior of the tab group so I want to avoid that as the expected behavior is to navigate with left/right arrow keys.
It would be helpful to have some code posted, otherwise we're just guessing.
When you tab to the tab navigator does the focus move to the tab that is selected within the group? (When tabbing to it the first time, I presume the first tab is selected.) Once the tab navigator has focus, then you can use the left/right arrow keys to navigate to the other tabs (when NVDA is not running)?
(It's unfortunate that pattern is called a "tab" which is confusing when also talking about the tab key)
I would first start with making sure you're following the "tab navigator" design pattern. If everything works as explained in that design pattern, in particular, the "Keyboard Interaction" section, then it sounds like you don't have the roles set on the right elements.
The behavior you're describing sounds like the left/right arrow keys are going to NVDA instead of to the tab navigator. You didn't say what happens when you press left/right when NVDA is running. Are characters read one by one? That would definitely mean the left/right arrow keyboard events are going to NVDA.
If that's true, then you don't have the role="tablist" set on the right element (and possibly role="tab" is not set on the right elements.) Confirm again you're following the design pattern.
When you have role="tablist", that will automatically switch NVDA from "browse mode" (where keyboard events are sent to NVDA) to "forms mode" (where keyboard events are sent to your application). When keyboard events are sent to your application, the left/right arrow keys should work just like when NVDA is not running.
You can see a list of roles that cause NVDA to switch modes automatically for you at "Fundamental Keyboard Navigation Conventions". The tab pattern is one of those roles.
You should be able to confirm your left/right arrow keys work by tabbing to your tab navigator with NVDA running then pressing INS+space. That will toggle the "browse mode" to "forms mode" and then your arrow keys should work.
Where would the first focus be on when a modal window opens? Some say the focus order should be sequential, so the first tab stop should be on the close button and some say, it should be on the first logically actionable element.
According to me, it should be on the first actionable item. Let's say if a modal window is opened to Search something, then the focus should be on the search edit box.
What are your thoughts? Which is better and what are the reasons?
The answer is, it depends®.
In fact it's mostly a question of good sense. You should put the focus where the user is the most likely to do his first action in the modal. Therefore:
If you are prompting for input, the most logical is to put the focus on the first required field
If you are asking a yes-no or multiple choice question, the focus should go on the most probable or recommanded answer
Exception to the previous one: if you are asking a question about whether or not to proceed on a unrecoverable action such as "are you sure to delete ?", the focus should be set to the no button eventhough the most probable answer is yes, so that the user has a last chance to cancel something triggered by misstake
If the modal dialog is just showing a message, it's logical to put the focus on the OK or close button, since it's the only possible action
Putting the focus on the close button when something else is expected is kind of weird, especially for screen reader users, who don't necessarily know what the dialog is for immediately.
I always put it on the first heading or label, so blind users can confirm where they are after clicking the link or button which opened the modal. Then focus can move to the close button as the next item in sequence - if opening the modal was a mistake (happens often when you can't see the layout or with ambiguously labelled links) this makes it easy to correct.
Jumping to the first focusable item isn't technically wrong but gives poor usability for screenreader users while only saving one click for sighted keyboard users.
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'm trying to design a UI in Qt and I can't find anywhere in the designer a button which can be "droped down" like combobox. What I mean by that is that I would like to have this button with his "default" option choosen so if I like it I would have to just click on it but if I would like to choose different option I would be able to clik the little arrow on the right side of this button and then pick option suitable for me at that moment.
You're looking for a QToolButton that has a set of actions or a menu set on it. From the documentation, the QToolButton::ToolButtonPopupMode...
Describes how a menu should be popped up for tool buttons that has a menu set or contains a list of actions.
Of it's values, the two that I see most frequently are DelayedPopup:
After pressing and holding the tool button down for a certain amount of time (the timeout is style dependant, see QStyle::SH_ToolButton_PopupDelay), the menu is displayed. A typical application example is the "back" button in some web browsers's tool bars. If the user clicks it, the browser simply browses back to the previous page. If the user presses and holds the button down for a while, the tool button shows a menu containing the current history list
And MenuButtonPopup:
In this mode the tool button displays a special arrow to indicate that a menu is present. The menu is displayed when the arrow part of the button is pressed.