FacetWP Feedback Login
To vote or comment, enter your email and we'll send a magic link
A11y improvements
Use native form elements whenever possible for facet UI, especially simple facet types such as checkbox and radio buttons. Ideally done in conjunction with retiring the accessibility shim and making accessibility and semantic HTML first-class citizens of the plugin.
Comments (4)
Hello there,
If I may propose a solution : you could add an option (in the facet panel for radio buttons and checkbox) to let the user/developer choose between :
- "Use a native HTML form element"
- "Use a custom element with advanced styling capability (+ A11y JS shim)"
If they choose "Use a native HTML form element", it improves accessibility by default and also performance (you don't need to load the A11y shim). If they choose "Use a custom element with advanced styling capability", they can still style the <div> element as they see fit.
What do you think about it ?
This is my only complaint with the plug-in, and I’ve used it on more than 2 dozen sites in production. Extra CSS and markup to style native form elements is certainly more performant than using JS to make it more accessible. I’m currently relying on filters and my own custom JS to work around a lot of it, but it would be welcome to have semantic markup out of the box.
We've made recent improvements to our a11y shim, and will continue to do so.
It's not possible to "switch" to using only native HTML because of backwards-compat. It's just too big of a change, and would break all custom styling.
We'd be left with 2 different rendering options (more code + complexity) and double the JS event handling code (to support both native elements + facet divs).
It's ultimately a trade-off and I'm inclined to keep things simple (a11y shim).
Just to recap for anyone out of the loop:
FacetWP currently uses
<div>elements for most facet types. The original intention was that this approach would greatly simplify styling, while also keeping HTML output at a minimum.One example: native HTML checkbox inputs cannot be fully styled. Instead, you have to hide the checkbox, create a duplicate element that "simulates" the checkbox, then put it into a
<label>element so it reacts to a user selection.We decided to use
<div>s directly to keep things simple. The problem is that screen readers have no idea when a<div>should be treated like a checkbox.That's where ARIA comes in -- it lets you add HTML attributes to various elements, telling the browser / screen reader how to handle those elements.
Our A11y support uses JavaScript to dynamically add ARIA tags when needed. The support includes the following facet types, but admittdely ARIA isn't a perfect solution hence why this feedback exists in the first place: