In an effort to cut down on JavaScript usage, there is more and more adoption of checkbox hack in different skins and usages (e.g. T225213, T195053, also in Vector menus). At the same time, you can read quite a lot of negative feedback about this checkbox hack (given that it exists for a long time, we just were, as usual, late to adoption) from those concerned with web accessibility, see, for example, here:
- https://dev.edenspiekermann.com/2016/03/07/introducing-a11y-toggle/
- https://ux.stackexchange.com/questions/81122/what-are-the-accessibility-concerns-of-a-checkbox-based-navigation
Before we adopt the checkbox hack seemingly everywhere, can someone do an assessment on whether it is good to use checkbox hack in the first place? This could be, for example, accessibility testing or asking someone specialised in web accessibility for their thoughts on this kind of solution.
=== Example page
* https://en.wikipedia.org/wiki/Classical_guitar
=== Possible concerns & solutions (intended)
- Keyboard friendliness
- The hidden checkbox needs to be associated to its label (which receives mouse/pointer events) using the label's `for` attribute, see https://codepen.io/Volker_E/pen/vYNPBON
-- Checkbox needs to carry additional `aria-labelledby`, specifically for the case where the `label` element comes after it in DOM
- Basic interaction is provided in a No-JS environment
- Screen-reader experience is enhanced by JS dynamically changing ARIA attributes (`aria-expanded` is set to `true`/`false`) to announce the menu's state.