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.
Related
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.
I want to reveal some hidden text/elements(whatever) when some checkboxes/radio buttons are selected(assume there is a list of checkboxes/radio buttons to choose from).
What should I do to meet the WCAG 2.0 AA standards?
And how exactly radio buttons/checkboxes are understood by AT users, because obviously this isn't the supposed behavior of checkboxes/radio buttons.
Thanks!
Your last statement gives me pause: "And how exactly radio buttons/checkboxes are understood by AT users, because obviously this isn't the supposed behavior of checkboxes/radio buttons."
If you have non-standard behavior for your radios/checkboxes, will the sighted user be confused too?
With 'normal' behaving radios/checkboxes, the AT user will understand them just like a sighted person does - experience. You learn that a radio is a group of mutually exclusive choices whereas a list of checkboxes allows multiple choices. The screen reader will read the role of the object so the AT user will know what to do.
Now, if you're hiding/unhiding objects based on those selections, the AT user needs to be notified. That's typically done with aria-live. By default, an aria-live region will be read if the text changes or an object is added to the DOM which should include being unhidden if you're doing it via display:none. If you unhide by moving an offscreen object to onscreen, or changing the clipping rectangle, or changing the size of the object, aria-live will not help.
Also look at aria-relevant. By default, it's value is 'additions text', which is the behavior I mentioned above. If you need the aria-live region to be read on other conditions, look at the other values of aria-relevant.
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 a list of options from which one can be selected. For all intents and purposes HTML's <select> element covers this. Since we need a different visual presentation, I'm looking at using WAI ARIA role="listbox". I'm unclear on how to use aria-activedescendant, aria-selected and aria-checked.
Questions regarding focus/active state:
If I use aria-activedescendant on the listbox to point to the [role="option"] that is currently active (has "virtual focus"), I would use [aria-selected]. How would best I tell the option element itself that it is active (has "virtual focus") to represent that visually? (:focus is on the listbox, after all)
an [role="option"] can have [aria-checked] and [aria-selected]. I guess I need [aria-selected] but don't see what I'd use [aria-checked] for.
Is there a trick to avoid having to put IDs on every option simply so it can be referenced by aria-activedescendant?
Questions regarding keyboard interaction:
"Checkbox - Space toggles checkboxes, if the list items are checkable" - how do I figure out if they are checkable or selectable?
Questions regarding validation:
If the listbox has [aria-required="true"] some sort of validation has to be performed. specifically if an option has been selected (or checked).
when do I trigger the validation? is on blur sufficient?
when invalid, what do I have to do besides setting [aria-invalid="true"] on the listbox?
aria-checked is indeed more something for a list of very closely related options with actual visible checkboxes that can be toggled on or off. This is most common in the Windows world. Explorer can be set to such a pseudo multi-select mode, or some apps use that to activate or deactivate a set of accounts. On the Mac, you can think of the list of accounts in Adium, which can be either checked (active) or not. A selection will always be there, and one or more of their checkboxes can be checked or not.
aria-selected is always the right one to indicate the selected state of an option. E. g. when traversing the list with the arrow keys, aria-selected="true" moves from item to item, while the others must then get aria-selected="false". As Patrick said, you can use this to also generate some nice looking CSS.
As for keyboard interaction: arrows up and down will select an item, and if the items are checkable, too, space will toggle the checked or unchecked state of the currently selected item.
In a true multi-select, like html:select #size>1, and multiselectable being true, the interaction would be:
Arrow keys select a single item.
Ctrl+Arrow keys would move focus from item to item, but not select the item yet.
Ctrl+Space would select the item.
Shift+up and down arrows would select contiguous items.
This is, again, standard Windows paradigm, can be observed in Explorer in Details view, for example.
As for validation: onBlur is sufficient, or you could dynamically do it via changes in selection/focused item, make sure at least one item is selected, or whatever validation you need.
aria-invalid="true" is sufficient for screen readers to know, but an error message and possibly a visual indication would be nice for everyone to know what's wrong.
How would best I tell the option element itself that it is active (has "virtual focus") to represent that visually?
Generally, you'd add aria-selected="true" and then craft some CSS that takes care of it using attribute selectors, e.g. div[role=option][aria-selected=true] { ... }, or add a css class dynamically?
[aria-checked] and [aria-selected]
This is more of a philosophical question I guess. aria-selected more closely matches what you'd have with a select...but then again (particularly for multi-select widgets) you can imagine the listbox actually being a series of checkboxes, and in that case you'd use aria-checked. there's no definitive right or wrong about either one (something you'll find a lot once you dive into more complex ARIA widgets).
Is there a trick to avoid having to put IDs on every option simply so it can be referenced by aria-activedescendant
Hmm...perhaps you could dynamically generate IDs for all options on page load via script? Or - but not tested - you could have something like a "roving" ID that moves around the options depending on which one is active (adding/removing the ID to the relevant option).
I have a single web page with master detail form/input layout. Currently the form works in a way like
User opens the page containing both master/detail data entry controls and enters the master information (The details save button is disabled)
When he saves the master information, the save master button gets disabled and save details is enabled
User continues to enter multiple details which get populated in a gridview at the bottom of page
All works well
Problem is that, the master part contains a lot of data entry controls (drop down lists gridviews etc)
How do I facilitate the user much more then the current layout? Should he be redirected to a new page after he enters the master record ? How can I improve on this?
If the user doesn’t need to refer to the entire master to complete the detail, and isn’t navigating among multiple masters to view/edit their details, then you don’t need a master-detail, and you can divide the input into two or more windows. A window for the details can repeat a few fields from the master that users need to complete the details.
Assuming it is desirable to keep everything on the same page, I think I see few things you can do:
Use edit-in-place for both the master and detail, so you don’t need space for both editing/creating a record and space to display it. Every field should only appear once.
Pack your controls more tightly together. You can do this without appearing too cluttered if you adopt a quieter visual style (e.g., lose the reverse-video and the rules). Allocate about 20 vertical pixels per single-row control
Adopt an object-selection-action syntax so you don’t need to take space repeating the same command buttons/links for every record. That leaves mores space for fields.
Put your tables in their own panes with vertical scrolling. The tables you have now are already pretty short (5 or fewer rows), but limiting them to 5 or fewer visible rows will keep the window from being too long for cases when there are a lot of rows.
Assuming you have edit-in-place, use wider tables, each set in their own pane with horizontal scrolling in order to reduce the height by moving fields out of the “overflow” spaces and into the tables. Be sure you have row headers that do not scroll away.
Divide fields up into tabs, especially on the master. That reduces the space the master needs to a fraction. You can have tabs within a portion of the master if your users need to keep key fields constantly visible.
Put some fields within the master or detail in expanders or secondary windows, especially for fields the user doesn’t necessary need to interact with (e.g., where usually the default values are correct). Show an aggregate, abbreviation, or summary of what the users don’t see to cue them on when they do need to interact with the fields.
Consider using a “paging” interface for your stack of multi-row text boxes at the bottom of the master so they’re “stacked” in the z-dimension rather than the y-dimension and thus take up the space of a single text box.
Consider using more compact drop-down lists rather than radio buttons, especially for fields the user is less likely to change (e.g., the default is very often correct). A dropdown list is more work to set a value (takes two clicks) but no more to see the value, and you can weigh the editing effort against navigation effort (scrolling, tab-clicking, etc.)
Consider putting the entire master in its own scrolling pane so the detail is always in view at normal window size and the user can scroll the master to whatever portion is relevant for entering details.
If users are telling you that everything in the window must be constantly in view, then you’re going to have to dig deeper, prioritize fields, and make trade-offs because that’s not going to happen unless your client buys everyone a suite of big-ass monitors. Some fields will be out of view, even it that just means scrolled out of view.
There can be various options:
Page may show master and summary (gridview) of details. Save button will only work for master data. Add/Edit details will happening in a modal pop-up.
Have a tabbed view - one tab will show master while other tab will show details. There will be one save button per tab. Tab switching will happen on client side.
Have both master and details always open for editing. Any changes in details will be temporarily held in view-state/session-state. The save button for master will save changes for both master and details. No need to disable any UI.
We typically prefer #1 - IMO, its simple UI from user's perspective.