Checkbox Hack, Accessibility Faliure?

In my latest bout of Javascript dodging I decided to experiment with the “Checkbox Hack”. It’s something I’ve been aware of for a while, but I only just got around to trying it out.
Earlier this year I put a new css only menu on this site…
…after discovering that the previous drop-down-hover menu was impossible to navigate with a keyboard. The new menu works with both mouse and keyboard. The slightly annoying thing about it is, because it uses the :target pseudo class to show/hide the sub-menus, it can lead to page jumps. The close menu “buttons” target href="#" which sends you to the top of the page if you back out of a menu without selecting anything. Bearing in mind this is a fixed position menu, so you could be half way down a very long article. Maybe it’s not that bad, since in a conventional “top menu” you would have to scroll all the way to to top to access the menu anyway.

But anyway, that’s why I decided to experiment with the checkbox hack, to make a css menu that lets you show/hide without page jump.
I have thrown the experimental code into a Codepen just so you can see it.
Yes, it’s ugly as hell, but that’s not the point, I paid no attention to aesthetic styling here, just trying to make it work (see above website for how it’s supposed to look/work).
Well it does work just fine… using a mouse that is…
The thing I overlooked (in my ignorance and inexperience of keyboard use) was how keyboards work with inputs.
I thought you would just tab over the labels and hit enter to check the box, just the same as tabbing over and following <a>s in a normal menu. But no, it’s space to activate a checkbox.
Then to complicate things further, I’m not actually using checkboxes, I switched them to radios. With checkboxes, I found you could check any number of them and end up with all the sub menus open, not good. So I switched to radios so only one can be checked at any time and there is one for closing all menus, and it works.
But, with the keyboard it seems, radios work differently again, you don’t tab from one button to the next and hit space to check, the group is one tab and you use arrow to go from one to the next.

So all in all, this seems to work great with the mouse. But for a keyboarder, I expect it is extremely confusing and difficult to use, switching from tabbing to arrowing to tabbing again.
Did I have a question?
I’m not sure now… :confused:
Can the checkbox/radio hack be keyboard accessible?

1 Like

No, I don’t think it can be made accessible to keyboard users who think that it is a ‘tabbable’ link but I guess screen readers may announce that it as a label and therefore a user would know to press space to activate it. Maybe if you show the checkbox as well then users will know they have to set the checkbox but of course that may look ugly.

I prefer to use JS for hide and show or at least have a back up with js for these sorts of issues.

You can usually get around that by having a fixed positioned target that you use to link to but then use the non fixed ajdacent element. This old example uses that method:

1 Like

It does sound like this will be confusing, awkward or difficult for keyboard users, and I know not all of them are using screen readers, which will be even more confusing I imagine.
But it’s always interesting to explore these possibilities and find these things out.

That could be the trick I was missing. My issue with the current menu is the jumping on exit, if I can cure that without re-inventing the wheel I’ll be happy.
I’ll give it a try, thanks.

1 Like

That seems to work just fine in my little off-line test. Plus it’s a much simpler fix than recreating the whole menu with radio inputs and suchlike. :smile:
Just one div added to the html and a little css to position it.
Time to try it no the live site.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.