WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: wondering about radio buttons and check boxes

for

From: jeffgutsell@fuse.net
Date: Mar 24, 2024 2:21PM

Thanks Steve and Maxwell,
Good information from both of you.

Jeff Gutsell

-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Max Starkenburg
Sent: Sunday, March 24, 2024 5:44 AM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] wondering about radio buttons and check boxes

Oof, before writing all that, I should have first checked the interwebz to see if somebody else (more expert than I) had perhaps already dug into this (years ago, and more thoroughly):
https://www.scottohara.me/blog/2021/09/24/custom-radio-checkbox-again.html

Max
--
Maxwell M. Starkenburg
<EMAIL REMOVED>



On Sun, Mar 24, 2024 at 5:23 AM Max Starkenburg < <EMAIL REMOVED> >
wrote:

> *TL;DR:* I think techniques like those in the article can be accessible
> (happy to be corrected), and prior to today I hadn't previously tried
> appearance:none for something similar, but my initial testing with it was
> promising, including possible benefits over the article's technique, though
> more testing would be prudent.
>
> *Long-winded version:*
> I've used similar techniques as described in the article to style
> checkboxes/radios differently from browser defaults in the past, though
> with some different CSS (e.g. I wouldn't have used opacity:0, on the
> assumption, perhaps false, that it might hide things from some AT, instead
> using a "visually-hidden" mixin; and I didn't use SVGs, instead relying on
> the label's ::before and ::after pseudo-content to indicate :checked
> status). I also didn't mess with appearance:none then (since input was
> already visually hidden, and I'm guessing it was less supported back then).
>
> One limitation of that technique (that I don't think the article
> explicitly mentions) is it requires the input to precede the label in
> order to work (otherwise input:checked + label or similar forward-looking
> selectors can't effectively update the custom styling to reflect :checked
> status). So the technique may be useless if dealing with opposite or
> unpredictable DOM order.
>
> IIRC during a later a11y remediation effort, none of my custom styling
> negatively affected keyboard or screen-reader functionality (though I may
> have had to adjust :focus styling to make that visibly clearer, given the
> visually-hidden input). Though I'd be happy to be disabused of any false
> sense of security of the relative accessibility of this technique. I also
> wasn't aware then or now of notions that the technique was a kludge, but
> may simply not have been in the right circles or paying attention.
>
> Regarding appearance:none (which I haven't used much in general), I did
> some quick & dirty checking today to see if I couldn't recreate the
> behavior/styling I used on that old project, but this time with
> appearance:none and without visually-hidden techniques. I also tried
> adding the pseudo-content to the input this time (instead of the label),
> which seemed to work fine in all the browsers I checked (this surprised me,
> but it may be just an exception for appearance:none inputs
> <https://stackoverflow.com/a/36073063/5285945>). I then tested mouse
> clickability of the inputs, their keyboard navigability, and screen
> reader navigability. On Windows I checked in FF/Chrome/Edge (and used
> NVDA), and on Mac I checked in FF/Chrome/Safari (and used VoiceOver). I
> found no behavioral differences between my custom inputs and
> default/unstyled ones. Nice!
>
> Two additional benefits of appearance:none: (1) potentially no longer
> worrying about DOM order, given the apparent (but maybe tenuous?) support
> for pseudo-content in inputs with appearance:none, and (2) the non-hidden
> input retains the ability to use a browser's default focus rings (I saw
> them present on all the browsers I tried, nicely surrounding the custom
> appearance).
>
> Then again, I certainly didn't check all browsers or AT, with mobile
> devices notably absent from my testing. And the MDN page on CSS appearance
> includes a kinda ominous (if potentially outdated?) warning about testing
> it <https://developer.mozilla.org/en-US/docs/Web/CSS/appearance#sect1>
> thoroughly on different browsers.
>
> Max
> --
> Maxwell M. Starkenburg
> <EMAIL REMOVED>
>
>
>
> On Sat, Mar 23, 2024 at 2:22 PM < <EMAIL REMOVED> > wrote:
>
>> Hi All,
>>
>> The following article made me recall a discussion here several years ago
>> that covering up traditional radio buttons and check boxes with custom
>> designs is a bit of a kludge. Is that still the consensus?
>>
>>
>> https://webdesign.tutsplus.com/how-to-make-custom-accessible-checkboxes-and-
>> radio-buttons--cms-32074t#page-content
>> <https://webdesign.tutsplus.com/how-to-make-custom-accessible-checkboxes-and-radio-buttons--cms-32074t#page-content>
>>
>>
>>
>> That has also gotten me to wonder about the relatively new CSS technique
>> of
>> setting "appearance: none" to create some opportunity for making these
>> controls more attractive and standardized across platforms. I can no
>> longer
>> see the screen enough to tell whether these techniques really work. Would
>> like to hear your thoughts . It seems to me that these techniques could
>> have
>> a lot of appeal to Web designers and developers.
>>
>>
>>
>> Jeff Gutsell
>>
>>
>>
>> >> >> >> >>
>