I'm really just wondering if anyone has stumbled across this...
In the Widgets API documentation for the Multiselect widget in Google App Maker, the "Styles" section includes a style name for a disabled item:
.app-MultiSelect-Item.disabled Style for the disabled item or items.
I have a case where I'm adding options and values to a multiselect by script based on data pulled from elsewhere. The initial values include the currently selected set of choices, but based on other actions taken by the user, they may not be eligible (via our internal rules and processes) to make that choice anymore.
If there's a way to set a specific item as disabled, I'm envisioning being able to style it with a strike through to communicate that even though that choice is selected now, it's not available as a new choice, and it's going to be removed from the other data source.
So it might be like this:
X Choice A
_ Choice B
X Choice C
_ Choice D
Thoughts?
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 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.
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 want to create a dynamic form in a Plone 4.3 site with PloneFormGen 1.7.15. Dynamic means that I want to disable an option, when a certain number of participants have chosen this option.
Is it possible the set the attribute "disabled" to a radio button? I have not found a way to do it manually.
I was looking at the article How can I generate a registration number in PloneFormGen, using a TALES Expression? which show how to implement a counter. But I have no idea, how to actually change the radio button, when the condition is met. Any hints on that?
I used http://plone.org/products/collective.signupsheet for the form. It has the functionality to limit the number of registrants for an event.
The solution I thought of when asking the question became obsolete.
I have a very simple webforms app that will allow field techs to order parts from the warehouse.
Essentially it work like so:
User selects a category from a filter dropdown, which then binds items of that category to a gridview control
User finds an item in the gridview and inputs a desired quantity (in a text box in a template field in each row)
User repeats 1 & 2 as needed
User sees a summary of the complete requisition
User confirms items and submits the requisition for processing
My no-brainer UI design so far is the generic dropdown-above-a-gridview where there's a category drop-down list that filters a gridview, like in the eye-catching asp.net ado tutorials:
http://static.asp.net/asp.net/images/dataaccess/15fig01vb.png
Each gridview row (in my app, not in the image above) lists an item's details and can accept a quantity input in the template textbox if the user wants to requisition that item.
Given that a user will want items from different categories during a single usage session, I'm trying to figure out a good, user-friendly way to allow users to input a quantity for an item, have a warm fuzzy feeling that their input has been accepted/stored, then change the category filter (thus binding the gridview to a different set of data) and select other items from the gridview as many times as necessary before summing up their order and submitting it.
I've thought about putting another grid below the first and adding items to it dynamically as the user selects each item. But that seems awkward. Ditto with an unordered list or similar simple structure under the grid.
I've also thought about just storing the user's picks in view state or session state and displaying a summary on another page, kind of like a shopping cart sort of functionality. Maybe do that and use some sort of ajaxy goodness on the main page to display something warm and fuzzy when a quantity is input?
WWYD? What Would You Do?
TIA.
I strongly agree with your first choice: users need to see somewhere what they have chosen or they will probably keep choosing it over again thinking it failed. Waiting to display it on a summary page shouldn't even be an option. I don't see much wrong with binding to another grid, although a repeater is also a decent option. Well, there are many options. Anyway, if there is room to do this off to one side or another - especially the left- I definitely would, rather than at the bottom. Also, bonus points for enabling users to change the quantities (or delete all) of an item they already selected, wherever you choose to display this.
I like the idea of a search, but be careful with auto-complete. Google style is good where it displays results below, but I've seen people develop some that are way too aggressive and love to write over what you're typing: this is awful. Good luck.
Probably because both your choices are fine - it comes down to personal preference. The shopping cart idea is well known. But sometimes it gets old if you have to keep going back and forth between the cart and the item selection.
What's wrong with the separate grid? -That way you keep the selection list separate from the ordered items list?
Why tie the user to selecting the correct category and then selecting the quantity and hitting a button?
Why not use some type of autocomplete search so they can type in the produce name they want? Then a user could type "widg", get a drop town of choices, hit tab to go to a quantity field, enter a number, and then hit enter.
Display a quickie preview with the aucocomplete too, like as single row of your data.
Then throw all these into another grid at the top of the page if its a critical part of the application, maybe at the bottom if you think the actual grid results are important.
The reason I don't like category drop downs is people who are familiar with their jobs or company usually know the names and even skus numebers for what they are trying to do. Having them select a category instead of typing just slows them down. Also I hate running into the "which category is this?" moment. For example, is a chicken a pet, food, livestock, or food producer?