I have a radio input with 2 options. Then I have 2 text inputs paired with the radio options.
When one radio option is selected, one input is shown and the other one is hidden.
I tried to achieve that with simple aria-controls, aria-hidden and aria-expanded. aria-controls simply contains 2 (space-separated) ids. But how to handle aria-expanded if both controlled elements can have different state?
Or is there some other ARIA role I should use in this case? tabpanel came to my mind, but it didn't seem right after further consideration.
Related
I have created a dynamic table in Google App Maker to display class attendance information. Each row contains information for one student and there are multiple rows for the entire class. I would like to use a radio group so the teacher can select a one of several attendance options (i.e., Present, Tardy, Excused, Unexcused). However, the radio group buttons are displayed vertically within each row and take up a lot of space. Is there any way in Google App Maker to change the orientation of the radio group to display horizontally?
I have checked the Google App Maker Widget API which describes properties for the radio group and there is some discussion about in-flow widgets and how they behave with different layout widgets. I am using a vertical panel for the table. However, the radio group behaves the same for horizontal and fixed panels. Other app programs (like for Android) include properties for orientation, however, I see no such property in Google App Maker.
I prefer to use a radio group since the options are mutually exclusive. If I can't change the radio group orientation, I could use individual check boxes but I would need to add the code so the options are automatically treated as mutually exclusive.
Thanks for any help!
Thank you, Markus! I'm including a picture and repeating your answer to highlight it for others.
Towards the top next to your 'Widgets' menu, there is a dropdown menu to select style variants. Horizontal is listed as an option under this category for a radio group. For other objects, this menu usually lists the background color or text style.
I am using an adapted version of some nice CSS radio buttons that I found here, but I need them to have symbols in them, as each one will represent a specific user action. Specifically, I am using a plus symbol and an arrow symbol. I am able to change the "X" symbol in the custom radio buttons to a plus symbol and an arrow symbol, but I cannot figure out how to have them still appear before the radio button itself is selected. Right now, you can only see it after it is selected. I have tried moving the content: '\25B2' property to every other selector in the CSS, but it never seems to appear, I still have to select the radio button before it becomes visible. I really need these symbols to be visible at all times so they user knows which one to select.
fiddle
you need to set checked pass **checked** attribute in input type radio like
below.
here is code
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'm trying to implement accessibility (keyboard only) ability on my site, but I'm having problems with Radio Button lists. When using radiobuttonlists, when initially, none of the radio buttons is selected, I am able to tab through every single value and select one upon hitting "enter". However, after a value is selected, I can only tab to the selected values, which presents a problem if I want to change the selected value.
From what I understand, radio buttons are grouped at the container controller level, thus when it is considered a group, only one can be selected at a time.
Any ideas on how to fix this issue?
Actually, this is not an issue at all. If a value is not selected, the browser will go through each value within the group. Once a value is selected, the browser will only jump to the chosen value within that group. Thus to change values within the group, the user is to use the keyboard arrows.
I believe you're correct about the RadioButtonList being one control (and therefore tabbing doesn't work). An alternative could be to create individual radio buttons and use the GroupName property to assign them all into one group. This should let you tab between them and still ensure they work in sync with each other.