quite a lot of negative some critical 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:
- Arguments given: Add aria-expanded (dynamically updated via JS), aria-controls to triggering (role=button) element and if necessary aria-hidden to triggered element
- Arguments given: Add ARIA like above, make sure user knows what's focussed
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.
Possible concerns & solutions (intended)
- Keyboard friendliness
- <Tab> navigation reaches the button (role="button" carrying element)
- <Tab> key navigates from the button to the menu items if and only if the menu is open
- <Space> and <Enter> key strokes on button trigger the checkbox hack targeted element
- 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
- role="button" is not on the checkbox with its inherent role="checkbox" as we shouldn't override inherent roles in ARIA land
- Button-like element 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.