Originally posted on a11ywithlindsey.com.
Hey friends! Today we'll be creating custom keyboard accessible radio buttons! This blog post is a follo...
For further actions, you may consider blocking this person and/or reporting abuse
Is there a reason you went for wrapping each input-label combo in a div rather than using the label element?
Rather than
Or is it a simple case of either will do but you went with the div? 🙂
One reason to do it this way is that explicit labels (input+label combo) have better support with assistive tech. Implicit labels (label wrapping an input) don't work with Dragon Naturally Speaking.
a11ysupport.io/tech/html/label_ele...
I would take a look at the responses to this. I prefer explicit association but others put their reasons in.
Because I wanted to.
Cool, thanks 🙂
Was just checking there wasn't some reason I wasn't aware of 🙂
haha It's how I prefer to write my inputs.
I love the suggestions to keep the native radio buttons visible while you're working on a custom replacement and to use the
:checked
pseudo-class to style selected radio buttons. It's really easy to make custom radio buttons that are accidentally out of sync with the native controls.Quite similar to mine HTML State.
Behold the HTML State
Anton Korzunov ・ May 21 ・ 5 min read
And there is one moment I would like to change in your example - please don't use
position:absolute
to position "radio" visuals - it's not scalable.Let's try to do the same, but with
position:static
Thanks for this! I'm curious about
opacity: 0
instead ofdisplay: none
for the original radio button. Is this because screen readers are still using the original/hidden radio button?That's correct! I would check out @scottohara 's post about why: scottohara.me/blog/2017/04/14/incl...
Using this for some radio buttons right now, thank you for the helpful guide!