E-mail List Archives

Search E-mail List Archives for

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

From: jeffgutsell@fuse.net
Date: Sat, Mar 23 2024 12:22PM
Subject: wondering about radio buttons and check boxes
No previous message | Next message →

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



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

From: Steve Green
Date: Sun, Mar 24 2024 1:16AM
Subject: Re: wondering about radio buttons and check boxes
← Previous message | Next message →

There's nothing wrong with using replacement techniques for radio buttons and checkboxes as long as they are implemented correctly. I can't comment on the use of "appearance: none" because I've not seen it used in any of the replacement techniques we've encountered.

Steve Green
Managing Director
Test Partners Ltd


-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of = EMAIL ADDRESS REMOVED =
Sent: Saturday, March 23, 2024 6:23 PM
To: 'WebAIM Discussion List' < = EMAIL ADDRESS REMOVED = >
Subject: [WebAIM] wondering about radio buttons and check boxes

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



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

From: Max Starkenburg
Date: Sun, Mar 24 2024 3:23AM
Subject: Re: wondering about radio buttons and check boxes
← Previous message | Next message →

*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 ADDRESS REMOVED =



On Sat, Mar 23, 2024 at 2:22 PM < = EMAIL ADDRESS 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
>
>
>
> > > > >

From: Max Starkenburg
Date: Sun, Mar 24 2024 3:43AM
Subject: Re: wondering about radio buttons and check boxes
← Previous message | Next message →

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 ADDRESS REMOVED =



On Sun, Mar 24, 2024 at 5:23 AM Max Starkenburg < = EMAIL ADDRESS 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 ADDRESS REMOVED =
>
>
>
> On Sat, Mar 23, 2024 at 2:22 PM < = EMAIL ADDRESS 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
>>
>>
>>
>> >> >> >> >>
>

From: jeffgutsell@fuse.net
Date: Sun, Mar 24 2024 2:21PM
Subject: Re: wondering about radio buttons and check boxes
← Previous message | Next message →

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

Jeff Gutsell

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Max Starkenburg
Sent: Sunday, March 24, 2024 5:44 AM
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED =



On Sun, Mar 24, 2024 at 5:23 AM Max Starkenburg < = EMAIL ADDRESS 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 ADDRESS REMOVED =
>
>
>
> On Sat, Mar 23, 2024 at 2:22 PM < = EMAIL ADDRESS 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
>>
>>
>>
>> >> >> >> >>
>

From: Laurence Lewis
Date: Sun, Mar 24 2024 3:20PM
Subject: Re: wondering about radio buttons and check boxes
← Previous message | No next message

Adrian Roselli wrote a series of helpful articles on custom styling form
controls.

- Under-Engineered Comboboxen?
<https://adrianroselli.com/2023/06/under-engineered-comboboxen.html>
- Under-Engineered Multi-Selects
<https://adrianroselli.com/2022/05/under-engineered-multi-selects.html>
- Adrian Roselli search for Under-Engineered
<https://adrianroselli.com/?s=Under-Engineered>


Laurence Lewis
Accessibility Senior Specialist - Telstra
Creator of the A11y Quick Check
<https://chromewebstore.google.com/detail/a11y-quick-check/jlamgighkcjniljcdfpnhiemcakibepi>
and Visual ARIA
<https://chromewebstore.google.com/detail/visual-aria/lhbmajchkkmakajkjenkchhnhbadmhmk>
Chrome
extensions

On Mon, 25 Mar 2024 at 04:00, < = EMAIL ADDRESS REMOVED = > wrote:

> Send WebAIM-Forum mailing list submissions to
> = EMAIL ADDRESS REMOVED =
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://list.webaim.org/cgi-bin/mailman/listinfo/webaim-forum
> or, via email, send a message with subject or body 'help' to
> = EMAIL ADDRESS REMOVED =
>
> You can reach the person managing the list at
> = EMAIL ADDRESS REMOVED =
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of WebAIM-Forum digest..."
> Today's Topics:
>
> 1. wondering about radio buttons and check boxes
> ( = EMAIL ADDRESS REMOVED = )
> 2. Re: wondering about radio buttons and check boxes (Steve Green)
> 3. Re: wondering about radio buttons and check boxes
> (Max Starkenburg)
> 4. Re: wondering about radio buttons and check boxes
> (Max Starkenburg)
>
>
>
> ---------- Forwarded message ----------
> From: < = EMAIL ADDRESS REMOVED = >
> To: "'WebAIM Discussion List'" < = EMAIL ADDRESS REMOVED = >
> Cc:
> Bcc:
> Date: Sat, 23 Mar 2024 14:22:31 -0400
> Subject: [WebAIM] wondering about radio buttons and check boxes
> 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
>
>
>
>
>
>
>
> ---------- Forwarded message ----------
> From: Steve Green < = EMAIL ADDRESS REMOVED = >
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Cc:
> Bcc:
> Date: Sun, 24 Mar 2024 07:16:26 +0000
> Subject: Re: [WebAIM] wondering about radio buttons and check boxes
> There's nothing wrong with using replacement techniques for radio buttons
> and checkboxes as long as they are implemented correctly. I can't comment
> on the use of "appearance: none" because I've not seen it used in any of
> the replacement techniques we've encountered.
>
> Steve Green
> Managing Director
> Test Partners Ltd
>
>
> -----Original Message-----
> From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
> = EMAIL ADDRESS REMOVED =
> Sent: Saturday, March 23, 2024 6:23 PM
> To: 'WebAIM Discussion List' < = EMAIL ADDRESS REMOVED = >
> Subject: [WebAIM] wondering about radio buttons and check boxes
>
> 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
>
>
>
> > > at http://webaim.org/discussion/archives
> >
>
>
> ---------- Forwarded message ----------
> From: Max Starkenburg < = EMAIL ADDRESS REMOVED = >
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Cc:
> Bcc:
> Date: Sun, 24 Mar 2024 05:23:15 -0400
> Subject: Re: [WebAIM] wondering about radio buttons and check boxes
> *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 ADDRESS REMOVED =
>
>
>
> On Sat, Mar 23, 2024 at 2:22 PM < = EMAIL ADDRESS 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
> >
> >
> >
> > > > > > > > > >
>
>
>
>
> ---------- Forwarded message ----------
> From: Max Starkenburg < = EMAIL ADDRESS REMOVED = >
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Cc:
> Bcc:
> Date: Sun, 24 Mar 2024 05:43:48 -0400
> 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 ADDRESS REMOVED =
>
>
>
> On Sun, Mar 24, 2024 at 5:23 AM Max Starkenburg < = EMAIL ADDRESS 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 ADDRESS REMOVED =
> >
> >
> >
> > On Sat, Mar 23, 2024 at 2:22 PM < = EMAIL ADDRESS 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
> >>
> >>
> >>
> >> > >> > >> > >> > >>
> >
>
> > > > >