The challenge
HTML elements like check buttons, radio buttons or select options can be hard to style with CSS in a custom design. There are many workarounds for this, based on two different approaches:
- Hide the form elements from sight and apply the styling on a container or related element
- Hide the form elements from sight and rewrite the functionality, using styleable elements like <div>s and JavaScript
The tests that these constructions need to pass is:
- is the label attached to the input field with a proper for/id construction
- can the selection be made with keyboard only
- does a screen reader give feedback on the choice made
1: Apply the styling on a container
Some examples of styling form elements using containers or related elements. Not all are fully accessible, but can be adjusted to be.
For select drop downs:
- Style a Select Box Using Only CSS by Bavota
- The alternative to custom styling of the SELECT elements from cssglobe.com
For check boxes and radio buttons:
- Styling check boxes and radio buttons using CSS, Using the checked pseudo-class in CSS3, keyboard accessibility needs improvement here
- CSS3 Checkbox Styles, codepen, not accessible, but can be adjusted into something decent.
Advantage: the native HTML stays the same, so it’s accessible and works for every device.
Disadvantage for select options: the options are not styled, only the select box.
2: Use styleable elements like divs and JavaScript
The most used library for restyling select boxes is Select2, build on jQuery. Other frameworks are Project Clarity, build on Angular .
Combobo and and Cauldro (the Dequelab pattern library) aim to be accessible for keyboard and screen reader.
WooCommerce recently created a fork of Select2, SelectWoo, with some accessibility improvements.
Advantage: all elements can be styled exactly as the designer wants
Disadvantage: all functionality has to be added with JavaScript to replace the native HTML behavior.
Accessibility concerns
Select2 is not accessible for screen reader users. They get no feedback on the suggestions and selections. The WordPress Accessibility team did a complete review and since then nothing much happened to improve this. I’ve tested Project Clarity and that is not accessible too.
I did some testing on SelectWoo and it works for keyboard and in Apple VoiceOver there is feedback announced. This also needs testing with other screen readers and voice recognition software. The examples with Ajax don’t have a no-javascript fallback.
Cauldron claims to be accessible. And my initial test prove it gives decent screen reader feedback and works with keyboard. But the HTML is very complex and we need to introduce a new JavaScript framework for this. Also the GitHub repo has open issues that get not much response from the authors.
Most assistive technology like screen readers and voice recognition software depend on semantic HTML. An element should be used for what it is intended. Replacing for example a select with <div>s means you also have to add all the functionality with JavaScript that natively comes for free with the semantic elements.
https://twitter.com/martenbjork/status/933073498569891840
Using native functionality always is a guarantee that it works on every device and is also not JavaScript depended to work well.
The first technique (apply the styling on a container) is accessible for all devices because it only uses extra CSS and doesn’t touch the semantics. All the functionality is already there and default handled by the browser.
It is impossible to style select option. But is that really necessary? Is it worth abandoning the native browser behavior for a complete rewrite in JavaScript of the functionality?
The days that a website must be pixel perfect and must look the same in every browser are over. There are so many devices these days, that an identical design for all is not doable. Or we must take a huge effort for custom form elements design.
Progressive enhancement
When a web page is loaded into a browser, the content (HTML) shows first, then the styling (CSS) and the JavaScript loads last. If a visitor has a slow connection, this means that the content must make sense, also without the CSS and JavaScript.
Using semantic, native elements for forms, makes sure that a visitor doesn’t have to wait until all the JavaScript is loaded before she can use forms like search.
Recommendations
As we aim to build accessible and for the future, robust and sustainable, let’s use the right element for the job. Don’t rewrite already existing functionality in JavaScript, that needs also a lot of ARIA to make it work for a screen reader.
So for select: only style in select box using CSS and let the display of the drop down options to the browser. Sam Miller created a Codepen as basic example.