WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Radio buttons using input tag, or aria radiogroup role?

for

From: Joseph Sherman
Date: Apr 27, 2017 7:02AM

I had the "pleasure" of doing a quick evaluation of our new online bookstore vendor webpage. All the inputs are non-html divs and none of them follow the ARIA specs so it's inaccessible. The remediation required looks extensive. All could have been avoided using normal html.

http://qc.textbookx.com/institutional/?action=browse#books/1429210,1427170/

Joseph

On Apr 25, 2017 8:50 PM, "Birkir R. Gunnarsson" < <EMAIL REMOVED> > wrote:
Radiobuttons come with certain madnatory behaviors for assistive
technology and keyboard navigation.

* The common label for the radiobuttons should be announced by
assistive technologies (if we put the radio buttons and their labels
in a <fieldset> element and put the common label in its <legend> this
is taken care of by the browser).
* Only the currently selected radiobutton should be in the focus
order (you can tab to it), from there you should be able to navigate
to, and select, other radio buttons in the set using the arrow keys
(up and down). This is achieved if the radio buttons in the set share
a common "name" attribute.
* (less important) assistive technologies should be able to tell you
how many radiobuttons there are in the set (again, the "name"
attribute is used to determine this).

You can construct a fully functioning set of ARIA radio buttons using
the type="radio" on individual radio buttons and aria-checked="true"
on the selected aadio button, type="radiogroup" and aria-labelledby or
aria-label to assign the common label to the container element,
aria-setsize and aria-posinset to indicate the total number of radio
buttons in the set and the relative position of each individual radio
button, and then you need JavaScript to implement the arrow key and
click behavior.

THe only advantage oo using ARIA radio buttons (and one is incidental
and small) is that you can put aria-required="true" on the element
with role="radiogroup" to indicate that selecting from the radio
buttons is required. That is one heck of a small advantage, since a
radio button in a set of radio buttons should always be pre selected,
and users cannot unselect them, which makes the required attribute
unnecessary.

But, again, there are visual styling advnatages. That ss fine, as long
as people understand the implementation cost of implementing custom
radio buttons, and do not only create radio buttons that work with the
mouse.

If we have an HTML element or elements that give us a fully accessible
widget, but we choose not to use them in favor of a custom widget, we
are responsible for making the custom widget at least as accessible as
the HTML one.

It can be done, but it takes a fair amount of scripting.



On 4/25/17, Patrick H. Lauke < <EMAIL REMOVED> > wrote:
> On 25/04/2017 21:32, AutoMagicMike wrote:
> [...]
>> Are there any advantages to using the aria approach? better support in
>> assistive technologies ? mobile devices?
>
> Browsers make it very flaky and difficult to style regular radio inputs
> and checkboxes (without using ugly CSS hacks). Going the ARIA route with
> more generic underlying elements allows for far greater control over the
> visual output.
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk<;http://www.splintered.co.uk>; | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > >


--
Work hard. Have fun. Make history.