E-mail List Archives
Thread: Radio buttons using input tag, or aria radiogroup role?
Number of posts in this thread: 10 (In chronological order)
From: AutoMagicMike
Date: Tue, Apr 25 2017 2:32PM
Subject: Radio buttons using input tag, or aria radiogroup role?
No previous message | Next message →
Hi everyone.
I've seen developers starting to use the aria roles "radiogroup" and
"radio" as an alternative to
a plain old HTML5 <input> element.
for example using an input tag inside a <fieldset> <legend> -
https://www.w3.org/WAI/tutorials/forms/grouping/#radio-buttons
<input type="radio" name="radio_stations" id="txt" value="radio1" checked>
<label for="radio1">radio1</label>
and radiogroup example at
https://www.w3.org/TR/2016/WD-wai-aria-practices-1.1-20160317/examples/radio/radio.html
<div role="radio"
aria-checked="false"
tabindex="-1">
radio1
</div>
Both solutions look good and appear to work well with my screen reader
browser combinations.
My understanding is that the solutions which are semantic should be used in
preference to those that are not, and
solutions that are not reliant on JavaScript should be used in preference
to are.
That's two strikes against the aria solution.
Are there any advantages to using the aria approach? better support in
assistive technologies ? mobile devices?
If not, while I understand that both are technically valid the plain old
<input> looks like a better practice.
Thanks
Mike
From: Patrick H. Lauke
Date: Tue, Apr 25 2017 2:42PM
Subject: Re: Radio buttons using input tag, or aria radiogroup role?
← Previous message | Next message →
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 | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke
From: Birkir R. Gunnarsson
Date: Tue, Apr 25 2017 6:50PM
Subject: Re: Radio buttons using input tag, or aria radiogroup role?
← Previous message | Next message →
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 ADDRESS 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 | 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.
From: Guy Hickling
Date: Wed, Apr 26 2017 12:26PM
Subject: Re: Radio buttons using input tag, or aria radiogroup role?
← Previous message | Next message →
Is there another major advantage of using the straight HTML5 approach, in
that older browser and/or assistive technology versions are more likely to
be fully up to date with HTML5 than with the ARIA needed? Particularly
since the official release of ARIA 1.1 is so recent.
JAWS, for instance, charges large amounts for upgrades, $400/£300 to
upgrade 3 or more versions at a time, so I imagine a lot of users (since
many screen reader users are likely on lower incomes than average) must be
several versions behind the current version 18.
Regards,
Guy Hickling
From: Birkir R. Gunnarsson
Date: Wed, Apr 26 2017 12:46PM
Subject: Re: Radio buttons using input tag, or aria radiogroup role?
← Previous message | Next message →
The radio button elements were not changed between ARIA 1.0 and 1.1,
so those roles have been around for awhile.
You can test an example of radiobuttons purely implemented with ARIA over at:
https://dequeuniversity.com/library/aria/custom-controls/sf-checkboxes-radios
(I wrote this back in 2014).
In general, you should use the HTML version of a widget, it has better
a.t. support and the accessibility is the responsibility of the
browser.
You must have strong reasons for rolling your own, as I said before.
On 4/26/17, Guy Hickling < = EMAIL ADDRESS REMOVED = > wrote:
> Is there another major advantage of using the straight HTML5 approach, in
> that older browser and/or assistive technology versions are more likely to
> be fully up to date with HTML5 than with the ARIA needed? Particularly
> since the official release of ARIA 1.1 is so recent.
>
> JAWS, for instance, charges large amounts for upgrades, $400/£300 to
> upgrade 3 or more versions at a time, so I imagine a lot of users (since
> many screen reader users are likely on lower incomes than average) must be
> several versions behind the current version 18.
>
> Regards,
> Guy Hickling
> > > > >
--
Work hard. Have fun. Make history.
From: Jeremy Echols
Date: Wed, Apr 26 2017 12:54PM
Subject: Re: Radio buttons using input tag, or aria radiogroup role?
← Previous message | Next message →
I'd love an answer to this question in a more general sense. It's my understanding that the browser tells the AT what to do, so Jaws wouldn't have to know about a specific ARIA attribute; rather, the browser would have to know how to tell Jaws about the element in terms Jaws can understand. For elements like radios that pre-date the web, Jaws would already know very well how to handle them, so even an ancient version of Jaws would work.
But I'm not certain about this. Is it true that Jaws itself does not need to know about specific HTML ARIA attributes?
From: Birkir R. Gunnarsson
Date: Wed, Apr 26 2017 1:58PM
Subject: Re: Radio buttons using input tag, or aria radiogroup role?
← Previous message | Next message →
Bryan Garaventa has a very thorough and good explanation of the hand
off between the author, the browser, the operating system and the
screen reader here:
http://whatsock.com/training/
On 4/26/17, Jeremy Echols < = EMAIL ADDRESS REMOVED = > wrote:
> I'd love an answer to this question in a more general sense. It's my
> understanding that the browser tells the AT what to do, so Jaws wouldn't
> have to know about a specific ARIA attribute; rather, the browser would have
> to know how to tell Jaws about the element in terms Jaws can understand.
> For elements like radios that pre-date the web, Jaws would already know very
> well how to handle them, so even an ancient version of Jaws would work.
>
> But I'm not certain about this. Is it true that Jaws itself does not need
> to know about specific HTML ARIA attributes?
>
>
From: Steve Faulkner
Date: Wed, Apr 26 2017 1:59PM
Subject: Re: Radio buttons using input tag, or aria radiogroup role?
← Previous message | Next message →
On 26 April 2017 at 19:54, Jeremy Echols < = EMAIL ADDRESS REMOVED = > wrote:
> Is it true that Jaws itself does not need to know about specific HTML ARIA
> attributes?
In general, yes, the browser maps semantics to an accessibility API which
assistive tech can use to convey the information to users. AT don't see
ARIA attributes in these cases, they 'see' roles/states/properties from the
acc APIs
In some cases where legacy browsers don't convey the semantics correctly AT
hack around the lack of support by picking up info via the HTML DOM rather
than acc APIs.
This article may be helpful: Accessibility APIs: A Key To Web Accessibility
<https://www.smashingmagazine.com/2015/03/web-accessibility-with-accessibility-api/>
--
Regards
SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
From: AutoMagicMike
Date: Wed, Apr 26 2017 4:51PM
Subject: Re: Radio buttons using input tag, or aria radiogroup role?
← Previous message | Next message →
Hi everyone
Thanks for all your answers
If anyone has examples of the types of styling issues / work workarounds
they have had with
radio buttons that would be really useful.
Do you think those issues are are "bugs" which browser vendors should
correct in the future versions.
Going the CSS route requires scripting to replicate native functionality.
That will require effort to build and then test on a number of different
platforms.
Are there any open sourced standard scripts out there that people have used.
Just looking through the Aria Spec again at:
https://www.w3.org/TR/aria-in-html/#rule1
Rule 1: 2.1 First rule of ARIA use
If you can use a native HTML element [HTML51] or attribute with the
semantics and behaviour you require already built in,
instead of re-purposing an element and adding an ARIA role, state or
property to make it accessible, then do so.
So unless there are styling issues Native Semantic HTML might be the way to
go.
Thanks for your help everyone
Mike
From: Joseph Sherman
Date: Thu, Apr 27 2017 7:02AM
Subject: Re: Radio buttons using input tag, or aria radiogroup role?
← Previous message | No next message
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 ADDRESS 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 ADDRESS 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.