3 ms·

1. 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 y

1. 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 ago
For 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

danielnixon 12y ago

For 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