E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 12 (In chronological order)

From: Maraikayar Prem Nawaz
Date: Thu, Oct 30 2014 10:41PM
Subject: Styling Radio elements to look like Button element?
No previous message | Next message →

Greetings,

One of the Collaborator of Bootstrap plugin says
"Folks wanted easy to use form-based components, but with the style of our
bootstrap buttons, so we gave it to them in an easy to implement way."
https://github.com/twbs/bootstrap/issues/14635#issuecomment-55935879


This is example link which talks about functional "radio" button groups.

http://getbootstrap.com/javascript/#buttons-checkbox-radio

What do you think of styling Radio Button to look exactly like Button? I'm
not sure about the use case for this example.



Thanks
-Nawaz

From: Jesse Hausler
Date: Fri, Oct 31 2014 3:19PM
Subject: Re: Styling Radio elements to look like Button element?
← Previous message | Next message →

I haven't looked at your code, but we've styled radio buttons to look like
big buttons and things like that.

Sometimes we'll place the real <input type="radio"> off screen and wrap an
associated label around the click target. That way when a user clicks on
it, the radio is triggered.

We'll usually use an anchor with javascript to trigger the radio with a
keyboard.

Jesse



On Thu, Oct 30, 2014 at 9:41 PM, Maraikayar Prem Nawaz < = EMAIL ADDRESS REMOVED = >
wrote:

> Greetings,
>
> One of the Collaborator of Bootstrap plugin says
> "Folks wanted easy to use form-based components, but with the style of our
> bootstrap buttons, so we gave it to them in an easy to implement way."
> https://github.com/twbs/bootstrap/issues/14635#issuecomment-55935879
>
>
> This is example link which talks about functional "radio" button groups.
>
> http://getbootstrap.com/javascript/#buttons-checkbox-radio
>
> What do you think of styling Radio Button to look exactly like Button? I'm
> not sure about the use case for this example.
>
>
>
> Thanks
> -Nawaz
> > > >

From: Birkir R. Gunnarsson
Date: Sat, Nov 01 2014 10:38AM
Subject: Re: Styling Radio elements to look like Button element?
← Previous message | Next message →

Make sure that appropriate ARIA markup is used if you are creating
faux radiobuttons, and that the selected state is always clearly
indicated.
What do you do for keyboard behavior?
People expect radiobuttons to consist of a single focusable element
with arrow key navigation to select a different option from within the
group.
For buttons you expect each button to be focusable.
I would recommend implementing keyboard navigation consistent with
user expectations for the perceived element(s), (so JavaScript to
allow for arrow navigation of radiobutton groups), though one could
argue either way on whether not doing so it a WCAG violation (4.1.2).
Cheers
-B

On 10/31/14, Jesse Hausler < = EMAIL ADDRESS REMOVED = > wrote:
> I haven't looked at your code, but we've styled radio buttons to look like
> big buttons and things like that.
>
> Sometimes we'll place the real <input type="radio"> off screen and wrap an
> associated label around the click target. That way when a user clicks on
> it, the radio is triggered.
>
> We'll usually use an anchor with javascript to trigger the radio with a
> keyboard.
>
> Jesse
>
>
>
> On Thu, Oct 30, 2014 at 9:41 PM, Maraikayar Prem Nawaz < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> Greetings,
>>
>> One of the Collaborator of Bootstrap plugin says
>> "Folks wanted easy to use form-based components, but with the style of
>> our
>> bootstrap buttons, so we gave it to them in an easy to implement way."
>> https://github.com/twbs/bootstrap/issues/14635#issuecomment-55935879
>>
>>
>> This is example link which talks about functional "radio" button groups.
>>
>> http://getbootstrap.com/javascript/#buttons-checkbox-radio
>>
>> What do you think of styling Radio Button to look exactly like Button?
>> I'm
>> not sure about the use case for this example.
>>
>>
>>
>> Thanks
>> -Nawaz
>> >> >> >>
> > > >


--
Work hard. Have fun. Make history.

From: Bryan Garaventa
Date: Sat, Nov 01 2014 12:06PM
Subject: Re: Styling Radio elements to look like Button element?
← Previous message | Next message →

Just a quick note, it's the checked state you want to convey with radios, not selected. This is often misimplemented for ARIA roles
such as 'radio', where aria-selected is used instead of aria-checked, which is what it should be. The use of aria-selected is not
valid on role=radio.

Live demo:
http://whatsock.com/tsg/Coding%20Arena/ARIA%20Radio%20Buttons/ARIA%20Radio%20Buttons/demo.htm

From: Maraikayar Prem Nawaz
Date: Sun, Nov 02 2014 9:30PM
Subject: Re: Styling Radio elements to look like Button element?
← Previous message | Next message →

Thank you guys for the input. So how should the keyboard navigation be?
Because in the same example (
http://getbootstrap.com/javascript/#buttons-checkbox-radio) , checkboxes
are styled as button and next same visual effect but with radio buttons.
To make it consistent, should it be tab +shift tab as it appears as buttons
or should it be arrow key navigation, as it appears in ARIA widgets or in
Radio buttons?
Yes Bryan, noted your point about aria-checked state.


On Sat, Nov 1, 2014 at 11:36 PM, Bryan Garaventa <
= EMAIL ADDRESS REMOVED = > wrote:

> Just a quick note, it's the checked state you want to convey with radios,
> not selected. This is often misimplemented for ARIA roles
> such as 'radio', where aria-selected is used instead of aria-checked,
> which is what it should be. The use of aria-selected is not
> valid on role=radio.
>
> Live demo:
>
> http://whatsock.com/tsg/Coding%20Arena/ARIA%20Radio%20Buttons/ARIA%20Radio%20Buttons/demo.htm
>
>

From: Bryan Garaventa
Date: Sun, Nov 02 2014 11:36PM
Subject: Re: Styling Radio elements to look like Button element?
← Previous message | Next message →

Since the checkbox role maps to equivalent control types on the OS, as with the radio role, then the keyboard model should match the
functionality of each accordingly.

So, checkbox controls should have separate tab stops unless otherwise disabled, and grouped radio controls should have one tab stop
and the arrow keys should switch between them or skip one if otherwise disabled.

Basically, the keyboard functionality should match the equivalent control type observed on the native OS.

From: Maraikayar Prem Nawaz
Date: Mon, Nov 03 2014 3:05AM
Subject: Re: Styling Radio elements to look like Button element?
← Previous message | Next message →

Is the keyboard interactions differ for 2 different components which looks
the same, wouldn't it confuse Keyboard only users?

Should the keyboard interaction match the hidden control or the one which
is visually shown. For example, span element shown as a link imitates a
link behavior correct?

On Mon, Nov 3, 2014 at 12:06 PM, Bryan Garaventa <
= EMAIL ADDRESS REMOVED = > wrote:

> Since the checkbox role maps to equivalent control types on the OS, as
> with the radio role, then the keyboard model should match the
> functionality of each accordingly.
>
> So, checkbox controls should have separate tab stops unless otherwise
> disabled, and grouped radio controls should have one tab stop
> and the arrow keys should switch between them or skip one if otherwise
> disabled.
>
> Basically, the keyboard functionality should match the equivalent control
> type observed on the native OS.
>
>
>

From: Scott González
Date: Mon, Nov 03 2014 4:58AM
Subject: Re: Styling Radio elements to look like Button element?
← Previous message | Next message →

The keyboard interaction is always based on the semantic meaning, not the
visual presentation. When the visual presentation of checkbox groups and
radio groups are the same, the developer should make sure that users know
whether the options are mutually exclusive (radio) or not (checkbox). The
user can know this from common/prior knowledge (e.g., a group of bold,
italic, underline settings in a text editor), or via a note in the user
interface.

On Mon, Nov 3, 2014 at 5:05 AM, Maraikayar Prem Nawaz < = EMAIL ADDRESS REMOVED = >
wrote:

> Is the keyboard interactions differ for 2 different components which looks
> the same, wouldn't it confuse Keyboard only users?
>
> Should the keyboard interaction match the hidden control or the one which
> is visually shown. For example, span element shown as a link imitates a
> link behavior correct?
>
> On Mon, Nov 3, 2014 at 12:06 PM, Bryan Garaventa <
> = EMAIL ADDRESS REMOVED = > wrote:
>
> > Since the checkbox role maps to equivalent control types on the OS, as
> > with the radio role, then the keyboard model should match the
> > functionality of each accordingly.
> >
> > So, checkbox controls should have separate tab stops unless otherwise
> > disabled, and grouped radio controls should have one tab stop
> > and the arrow keys should switch between them or skip one if otherwise
> > disabled.
> >
> > Basically, the keyboard functionality should match the equivalent control
> > type observed on the native OS.
> >
> >
> >

From: Birkir R. Gunnarsson
Date: Mon, Nov 03 2014 6:09AM
Subject: Re: Styling Radio elements to look like Button element?
← Previous message | Next message →

Thanks to Bryan to point out my oversight there re aria-checked vs.
aria-selected.
Since I keep preaching the importance of using the correct ARIA role
to the people I work with, I don't know how I accidentally posted
this, my bad.
From a usability perspective, make sure you do not confuse the user.
You need to clearly communicate to the user whether he can only select
one option in a group of controls (radiobutton) or he can select
multiple choices (checkboxes).
Each checkbox control is focusable and you should be able to select
them with the spacebar (on Windows, or the equivalent for other OS´s).
No arrow key navigation expected.
Make sure the visual appearance of the UI element clearly communicates
the intended functionality, and then match the accessibility
implementation to that.
If this is impossible I woul go with semantic meaning for
accessibility implementation, but I would ask myself why there is a
need to style one element to look like a different one, and be aware
of potential end user problems.
-B



On 11/3/14, Scott González < = EMAIL ADDRESS REMOVED = > wrote:
> The keyboard interaction is always based on the semantic meaning, not the
> visual presentation. When the visual presentation of checkbox groups and
> radio groups are the same, the developer should make sure that users know
> whether the options are mutually exclusive (radio) or not (checkbox). The
> user can know this from common/prior knowledge (e.g., a group of bold,
> italic, underline settings in a text editor), or via a note in the user
> interface.
>
> On Mon, Nov 3, 2014 at 5:05 AM, Maraikayar Prem Nawaz < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> Is the keyboard interactions differ for 2 different components which
>> looks
>> the same, wouldn't it confuse Keyboard only users?
>>
>> Should the keyboard interaction match the hidden control or the one which
>> is visually shown. For example, span element shown as a link imitates a
>> link behavior correct?
>>
>> On Mon, Nov 3, 2014 at 12:06 PM, Bryan Garaventa <
>> = EMAIL ADDRESS REMOVED = > wrote:
>>
>> > Since the checkbox role maps to equivalent control types on the OS, as
>> > with the radio role, then the keyboard model should match the
>> > functionality of each accordingly.
>> >
>> > So, checkbox controls should have separate tab stops unless otherwise
>> > disabled, and grouped radio controls should have one tab stop
>> > and the arrow keys should switch between them or skip one if otherwise
>> > disabled.
>> >
>> > Basically, the keyboard functionality should match the equivalent
>> > control
>> > type observed on the native OS.
>> >
>> >
>> >

From: Mallory van Achterberg
Date: Mon, Nov 03 2014 8:01AM
Subject: Re: Styling Radio elements to look like Button element?
← Previous message | Next message →

On Mon, Nov 03, 2014 at 06:58:35AM -0500, Scott González wrote:
> The keyboard interaction is always based on the semantic meaning, not the
> visual presentation. When the visual presentation of checkbox groups and
> radio groups are the same, the developer should make sure that users know
> whether the options are mutually exclusive (radio) or not (checkbox). The
> user can know this from common/prior knowledge (e.g., a group of bold,
> italic, underline settings in a text editor), or via a note in the user
> interface.

So as a sighted keyboard user, when I come across something
visually styled to look like buttons, I'm supposed to go find some
instructions on how to use them because they won't work like buttons?
Like most other humans, I'll first try to use it the way I expect.
Then I'll get frustrated that it doesn't seem to work. And then finally,
if I haven't left the site, I'll see if I missed some instructions
somewhere, or I might semi-randomly try hitting other keys.

Whether they are mutually exclusive or not won't tell me whether tab
works, only what I should reasonably be able to select.

I've run into this before ("tabs" requiring magical-mystery-meat arrow
actions), and I call it bad UX, because I have to think about and
fight with the interface to get my task done.

If it looks like a button, I expect to be able to tab to each button.
If it looks like a radio-button input, I expect to be able to tab into
the group and then arrow around between them. I expect to be able to
select both with spacebar.

Unless the website is so awesome it can bring me to Mars or cure
cancer, I'm going to be sceptical as a user that this is somehow
worth my user-time relearning a user interface I already thought I
spent time learning. The nice thing about a standard web interface is,
I only had to learn it once (so this is why *sometimes* a web-app
might get a pass-- if you're building controls with no previously-
learned set of interface rules... similar rules *might* hold for
an interface people must return to and re-use regularly, like
a learning program or specialised data-entry at a job).

So yes, to Maraikayar, confusion might be a problem, and you might
need to rethink if radio buttons styled as button-buttons are
still a better thing. Depends on your users and what they expect.

_mallory

>
> On Mon, Nov 3, 2014 at 5:05 AM, Maraikayar Prem Nawaz < = EMAIL ADDRESS REMOVED = >
> wrote:
>
> > Is the keyboard interactions differ for 2 different components which looks
> > the same, wouldn't it confuse Keyboard only users?
> >
> > Should the keyboard interaction match the hidden control or the one which
> > is visually shown. For example, span element shown as a link imitates a
> > link behavior correct?

From: Scott González
Date: Mon, Nov 03 2014 7:53AM
Subject: Re: Styling Radio elements to look like Button element?
← Previous message | Next message →

On Mon, Nov 3, 2014 at 10:01 AM, Mallory van Achterberg <
= EMAIL ADDRESS REMOVED = > wrote:

> On Mon, Nov 03, 2014 at 06:58:35AM -0500, Scott González wrote:
> > The keyboard interaction is always based on the semantic meaning, not the
> > visual presentation. When the visual presentation of checkbox groups and
> > radio groups are the same, the developer should make sure that users know
> > whether the options are mutually exclusive (radio) or not (checkbox). The
> > user can know this from common/prior knowledge (e.g., a group of bold,
> > italic, underline settings in a text editor), or via a note in the user
> > interface.
>
> So as a sighted keyboard user, when I come across something
> visually styled to look like buttons, I'm supposed to go find some
> instructions on how to use them because they won't work like buttons?
>

No, developers shouldn't be creating UIs that confuse you and require
instructions.

Like most other humans, I'll first try to use it the way I expect.
> Then I'll get frustrated that it doesn't seem to work. And then finally,
> if I haven't left the site, I'll see if I missed some instructions
> somewhere, or I might semi-randomly try hitting other keys.
>

Bad UX is bad UX. This is not limited to styling of radio buttons.

Whether they are mutually exclusive or not won't tell me whether tab
> works, only what I should reasonably be able to select.
>

It should, otherwise the UI design is just bad. The question to ask
yourself is not "is it possible to create a confusing UI that will annoy
users by doing X." The question to ask yourself is "Is the specific case I
have in mind obvious to users?"

You'll notice in this entire thread, there's only one actual use case
presented and it was presented by me: bold, italic, and underline options
in a text editor, which is a set of checkboxes so you would be able to tab
to each. Nobody has presented a specific use case yet for radio buttons.
Even the Bootstrap examples linked to are just generic demos that don't
show a real-world scenario.

I've run into this before ("tabs" requiring magical-mystery-meat arrow
> actions), and I call it bad UX, because I have to think about and
> fight with the interface to get my task done.
>

Tabs have specifically documented keyboard interactions, and using arrows
is correct.

If it looks like a button, I expect to be able to tab to each button.
> If it looks like a radio-button input, I expect to be able to tab into
> the group and then arrow around between them. I expect to be able to
> select both with spacebar.
>

Sure, but context is also very helpful, and so far it's been completely
missing from this conversation. Accessibility is almost never black and
white.


> Unless the website is so awesome it can bring me to Mars or cure
> cancer, I'm going to be sceptical as a user that this is somehow
> worth my user-time relearning a user interface I already thought I
> spent time learning. The nice thing about a standard web interface is,
> I only had to learn it once (so this is why *sometimes* a web-app
> might get a pass-- if you're building controls with no previously-
> learned set of interface rules... similar rules *might* hold for
> an interface people must return to and re-use regularly, like
> a learning program or specialised data-entry at a job).
>
> So yes, to Maraikayar, confusion might be a problem, and you might
> need to rethink if radio buttons styled as button-buttons are
> still a better thing. Depends on your users and what they expect.
>

"Depends on your users and what they expect" is exactly my point. Without
specific examples, the best answer you can get is the general sentiment
you've gotten: In general, making radio buttons look like regular buttons
with no context is confusing and therefore bad UX. However, depending on
the specific scenario and the intended user base, there may be exceptions.

From: Patrick H. Lauke
Date: Mon, Nov 03 2014 9:03AM
Subject: Re: Styling Radio elements to look like Button element?
← Previous message | No next message

On 03/11/2014 14:53, Scott González wrote:

> You'll notice in this entire thread, there's only one actual use case
> presented and it was presented by me: bold, italic, and underline options
> in a text editor, which is a set of checkboxes so you would be able to tab
> to each. Nobody has presented a specific use case yet for radio buttons.
> Even the Bootstrap examples linked to are just generic demos that don't
> show a real-world scenario.

Old-skool Google Maps embedded maps, options to switch between "Map" and
"Satellite" top right - for instance in
https://dev.opera.com/articles/keyboard-accessible-google-maps/demo02.html

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