WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: question about design for either-or buttons

for

From: Steve Green
Date: Jul 18, 2022 11:19AM

I agree with regard to toggle switches. I sometimes report a non-conformance if the state is not conveyed in text - it depends on how the label is worded and how different the two visual states are. Apple's design is a clear failure of SC 1.4.1 (Use of colour). Some other designs are less ambiguous, but I often find it a significant cognitive load to translate the visual state into its actual meaning.

You may well choose to use radio buttons for two options if you want the user to make a positive choice. Leaving a checkbox unchecked doesn't meet that objective. Of course that doesn't matter if your business logic means the user cannot proceed without checking the checkbox.

Steve Green
Managing Director
Test Partners Ltd


-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of glen walker
Sent: 18 July 2022 18:09
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] question about design for either-or buttons

I've never liked Apple's iOS toggle switch. It's either gray or green depending on whether the switch is on the left or right. To me that doesn't tell me if it's on or off, especially if I can't see the green.
With VO running, it adds additional context because it'll read the switch label and say "on" or "off". That's the kind of feedback that's helpful to everyone but you only get it with VO. Occasionally I'll see a switch that indicates if it's selected or not as part of the label, so that helps. But if you have to add context to a label, then it feels like there's something inherently wrong with the design of the widget.

Radio buttons have been around for a long time and are the standard when selecting one element from a group of mutually exclusive choices. But when you only have 2 choices and it's just yes/no, then a checkbox is typically the pattern but the label for the checkbox has to be worded so that it's clear that checking the box means you are choosing that option. And sometimes I see a third option of using a dropdown list (combobox) where the two choices in the list are yes and no.


On Mon, Jul 18, 2022 at 9:23 AM < <EMAIL REMOVED> > wrote:

> Hi all,
>
> I have been experimenting with creative designs for a widget that
> provides for "yes/no" sort of input. The obvious approach would be to
> just use radio buttons, but my friend does not want that.
>
> My first experiment was to use a div container with roltrole
> =radiogroup, then use a pair of button elements with role=radio. The
> effect seemed nice, but I felt that a lot of JavaScript would be
> needed to prvide correct arrow key support.
>
> So now I am experimenting with real radio buttons where the button is
> covered by the label element. The keyboard support is good, and I
> have d been able to achieve what I would call a rocker button look
> that my friend likes
>
> I know that some developers do not like designs that make radio
> buttons appear to be another sort of widget. So what do you think?
>
> Here is the HTML snippet:
>
>
>
> <div id="radio-btns-wrapper" >
>
> <input id="btn-yes" type="radio" name="yesno-btns"
> value="0">
>
> <label for="btn-yess">Yes</label>
>
> <input id="btn-no" type="radio" name="yesno-btns"
> value="1">
>
> <label for="btn-no">No</label>
>
> </div>
>
> The CSS has a selector using the :checked pseudo-event to trigger a
> style that makes the selected element look depressed.
>
>
>
> I think I recall a discussion about two years ago that may have
> covered this topic, but for the life of me I cannot find it in the
> archives.
>
> My poor senior brain only recalls that the discussion included
> mention that a toggle button differs from this sort of component.
>
> The user navigates this with arrow keys, and pressing Tab moves to the
> next control.
>
>
>
> Jeff Gutsell
>
>
>
> > > archives at http://webaim.org/discussion/archives
> >