I am using office ui fabric react v 6.174.0.
I am using the dropdown component, and currently testing the accessibility. Let's say the menu has the following options:
Apple [selected]
Orange
Banana
When I focus the menu (before opening/expanding it), the narrator reads the following:
Apple selected. Selection contains 3 items. Apple. 1 of 3. Selected.
What I would like it to read is this:
Apple selected. Selection contains 3 items.
The added text is actually what is read when menu is opened and the Apple is focused. As I understand, this is because the dropdown component treats the items as if they were in the DOM, even when they aren't (from reading this thread on github). However, I would still like the item to only be read when it is explicitly focused while the menu is opened.
Is there an easy, non-hacky way to do this?
I am currently trying to hack my way around, making the whole component aria-hidden, and adding a surrounding div that will read only the text I want, but would prefer a less hacky way.
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 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).
Can anyone tell me how I might add buttons, or other components, to a title/tool bar without using the items array? For months I've been struggling to find a way to make the bar on all my views contain the same user buttons and icons.
It's a struggle mostly on List item detail views where only a back button shows. I want the back button but also own buttons on the same bar. This is so my app has a uniform look and accessible functionality across the entire build.
Toolbar and TitleBar extend Ext.Container.
In Sencha Touch containers always store their components inside the items array.
If you want to have a toolbar that always look the same just create your own by extending Ext.Toolbar. Use the initialize method of such extended Toolbar to add the buttons/icons.
To use it with a list you can create a wrapping container, which contains the extended toolbar and the list.
I have successfully added a dropdownlist(flextras) but its not working properly. Whenever I touch the dropdown, the list that pops up goes under the textboxes(which are placed below the dropdownlist). Therefore I'm not being able to select the item from list on top of the textbox, as the focus passes to the text box.
Pleased read this blog post on the subject.
The relevant quote:
The default skin for a TextInput in Flex 4.6 uses the
StyleableStageText. StageText is always drawn above the Flash
Display List, which is why the drop down's popup appears to be under
it. To quote the Adobe docs on StageText:
[start doc quote] Native text input fields cannot be clipped by other Flex content and
are rendered in a layer above the Stage. Because of this limitation,
components that use StageText-based skin classes will always appear to
be on top of other Flex components. Flex popups and drop-downs will
also be obscured by any visible native text fields. Finally, native
text fields' relative z-order cannot be controlled by the application. [end doc quote]
There are two possible solutions for this. The first is to architect
your mobile application so that popups never display above a
TextInput. This may be tough if you're building for multiple devices
with different screen sizes.
The second is to use the Flex 4.5 skin class for your TextInputs:
<textInput skinClass="spark.skins.mobile.TextInputSkin" />
Attached is the screenshot of the UI that I would like to have in my app. When I click on the listitems on the fragment on the left side I see a arrow pointing(question mark in red) on the list item which was clicked, I would like to know how can we achieve this in UI layout. Any special settings to be set?
I was looking at the same feature.
To implement similar, I'd suggest showing an image on the selected item in the list, this would require code rather than Layout XML, It would be controlled by the list fragment when an item is selected. That way you get the visual effect that the two fragments are related via the arrow image.
Did you end up giving it a go for yourself?