4 ms·
Lots of accessibility issues here. * Keyboard accessibility is completely busted (other comments have pointed this out). * Color contrast doesn't meet WCAG 2.
by danielnixon 12y ago
Lots of accessibility issues here.
* Keyboard accessibility is completely busted (other comments have pointed this out).
* Color contrast doesn't meet WCAG 2.0 AA (Bootstrap is bad here too).
* The <label class="button"> should have aria-role="button", tabindex="0" and a bit of JavaScript to trigger a click event when the space or enter keys are pressed while it has focus. This is for keyboard _and_ screen reader accessibility.
* The checkboxes and radio buttons need similar ARIA, tabindex and keydown tricks (because the inputs themselves are hidden [stupidly, in my opinion]). Again, this is for both keyboard and screen reader users.
Bootstrap commits a lot of the same mistakes with their button.js component (although it looks like it's improving). See this post [0] for details (disclaimer: I wrote it).
I wouldn't use this if I were you.
[0] https://danielnixon.org/improving-bootstraps-woeful-accessibility/ https://danielnixon.org/improving-bootstraps-woeful-accessib...
- uniclaude 12y agoI'm with you on the point that accessibility should be a concern of framework developers, but none of those issues should be too hard to tackle for them. Therefore, filing an issue on the Github project would help (at least, more than commenting here), especially because the project is still young.
- duncans 12y agoHave you submitted a pull request? There's plenty of accessibility related-stuff in Bootstrap so I think they care about it.
- franciscop 12y ago1. I opened the issue, this definitely needs fixing. 2. Can you share a tool (preferably online) where we can see the color contrast problem, please? How did you check that they didn't meet WCAG 2.0 AA (so I can check it and fix it). 3. Not really CSS problem 4. Not a CSS problem. Anyway, I think that something can be done with CSS though. This is a pure CSS tool, so the html and javascript problems should be addressed by the people using the tool, not by the css itself. So please, don't use it, or help me improve it until it can be used. If you see any other problem, don't hesitate to comment, open an issue in Github ( https://github.com/picnicss/picnic https://github.com/picnicss/picnic ) or just send a small push request fixing a problem at a time (I'm trying to address every problem by myself, which is daunting).
- danielnixon 12y agoFor contrast, maybe check out either HTML_CodeSniffer [0] or Vision Australia's Colour Contrast Analyser [1]. Also this Bootstrap issue [2], which references a couple more. The problem with being pure CSS is that you're hiding inputs and styling their labels to appear (visually) as their replacements (against the labels' semantics). If you're going to hide the inputs (in the three cases of labels with class "button", "radio" and "checkbox") and style labels against their semantics, you need to use JavaScript to fix the accessibility issues this introduces. I don't think there's a non-JavaScript, non-ARIA solution to the accessibility issues (other than not hiding the inputs in the first place). So I think there are three options: 1. Hide inputs, style labels (status quo) and use JavaScript, ARIA, tabindex, etc to fix accessibility issues. 2. Don't hide inputs, remain pure CSS, avoid accessibility issues in the first place. 3. Ignore accessibility issues. [0] https://squizlabs.github.io/HTML_CodeSniffer/ https://squizlabs.github.io/HTML_CodeSniffer/ [1] http://www.visionaustralia.org/digital-access-cca http://www.visionaustralia.org/digital-access-cca [2] https://github.com/twbs/bootstrap/issues/3572 https://github.com/twbs/bootstrap/issues/3572