Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
By using display: none on your checkboxes you make it so you can't use a keyboard as there is nothing to focus!
This means people using screen readers (generally people with vision impairments) or people unable / who prefer not to use a mouse (generally people with mobility / accuracy issues - or screen reader users who cannot see the mouse position on the screen!) cannot use your checkboxes!
Don't worry the fix is straight forward.
Step 1:
Remove
.rowlabelinput[type="checkbox"]{display:none;}
That way the checkboxes are focusable again.
Step 2:
Hide the checkboxes in a way that takes up no space. We do this with visually-hidden class that allows a screen reader to still access the information without interfering with the interface.
.rowlabelinput[type="checkbox"],.visually-hidden{border:0;padding:0;margin:0;position:absolute!important;height:1px;width:1px;overflow:hidden;clip:rect(1px1px1px1px);/* IE6, IE7 - a 0 height clip, off to the bottom right of the visible 1px box */clip:rect(1px,1px,1px,1px);/*maybe deprecated but we need to support legacy browsers */clip-path:inset(50%);/*modern browsers, clip-path works inwards from each corner*/white-space:nowrap;/* added line to stop words getting smushed together (as they go onto seperate lines and some screen readers do not understand line feeds as a space */}
Step 3
Add a focus indicator! (preferably a nicer one than I added!
No that is it, at that point that fixes the keyboard accessibility. 👍
Final thing on accessibility for you to explore at your leisure - colour contrast requirements. Your orange with white in front might be just a little too low contrast (as orange does not contrast well with white!).
Accessibility First DevRel. I focus on ensuring content created, events held and company assets are as accessible as possible, for as many people as possible.
The problem with that approach is semantics and the weird and wonderful compatibility world of web browser and screen reader combinations, landing on the label of a checkbox does not have the same semantic meaning as landing on the checkbox itself.
Some screen reader and browser combinations will not announce the checked state for example.
So it is certainly a good fix for keyboard accessibility, it is not so great from a screen reader and assistive tech perspective.
The other thing to consider is voice navigation, I do not know how something like "dragon naturally speaking" would behave with this. But as I do not know I cannot comment in any meaningful way other than an educated guess that this would not be very robust due to experience with Dragon not behaving well with workarounds.
Looks great but don't forget about accessibility!
By using
display: noneon your checkboxes you make it so you can't use a keyboard as there is nothing to focus!This means people using screen readers (generally people with vision impairments) or people unable / who prefer not to use a mouse (generally people with mobility / accuracy issues - or screen reader users who cannot see the mouse position on the screen!) cannot use your checkboxes!
Don't worry the fix is straight forward.
Step 1:
Remove
That way the checkboxes are focusable again.
Step 2:
Hide the checkboxes in a way that takes up no space. We do this with visually-hidden class that allows a screen reader to still access the information without interfering with the interface.
Step 3
Add a focus indicator! (preferably a nicer one than I added!
Step 4
Profit!
No that is it, at that point that fixes the keyboard accessibility. 👍
Final thing on accessibility for you to explore at your leisure - colour contrast requirements. Your orange with white in front might be just a little too low contrast (as orange does not contrast well with white!).
Any questions just ask! ❤
Thank you for beautiful suggestions whenever I use Checkbox that time I followed this 😊.
There is another way:
👍
The problem with that approach is semantics and the weird and wonderful compatibility world of web browser and screen reader combinations, landing on the label of a checkbox does not have the same semantic meaning as landing on the checkbox itself.
Some screen reader and browser combinations will not announce the checked state for example.
So it is certainly a good fix for keyboard accessibility, it is not so great from a screen reader and assistive tech perspective.
The other thing to consider is voice navigation, I do not know how something like "dragon naturally speaking" would behave with this. But as I do not know I cannot comment in any meaningful way other than an educated guess that this would not be very robust due to experience with Dragon not behaving well with workarounds.
I mean, Dragon even has problems with implicit labels so it shows how careful you sometimes have to be due to the scattered support across assistive tech.
👍😃