WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Styling Radio elements to look like Button element?

for

From: Scott González
Date: Nov 3, 2014 7:53AM

On Mon, Nov 3, 2014 at 10:01 AM, Mallory van Achterberg <
<EMAIL 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.