UPDATE June 2018: I would like to assume that, based on this post/ conversation, Google has updated the checkbox web component guide with the following warning:
Great job team!
At the Polymer conference, a new resource
How To: Components
was announced to help developers build web components responsibly. I
was a little intrigued because the screenshot attached to the tweet
showed code on
Of course, I had to ask, what's wrong with a plain
<input type="checkbox" /> and surprisingly I got
a response from someone on the Chrome dev team.
I won't argue that point, leaving form design up to browsers is just
no fun. As I pointed out though, for checkboxes and radio buttons we
can use some basic CSS to style. In fact, with the exception of
<select> you can style pretty much all
form elements with pure CSS. Even with native select's, you can
style everything except for the options.
I got another response though, and this one was even more surprising than the first:
I can appreciate the attention to accessibility and this team is doing some good work. Any time you can expose developers to accessibility, an angel gets wings in heaven. In this instance, I would have to invoke the first rule of ARIA:
Of course, the rule goes on to state an exception for not being able to style an element as desired. I just want you to know that if you are only using web components so that you can style a checkbox, then you may not need a web component after all. Over-engineering not required!
The screen reader and keyboard experience are identical to the web component for the most part, but there are some really important benefits that I want to point out:
- Reduced surface area for bugs. No JS to break.
- No ARIA! Relying on ARIA for something as simple as a checkbox puts you at the mercy of assistive technology/ browser combinations. See item 1.
- No additional JS to get the value of the checkbox to post back to a server.
- No additional HTTP requests for images. The image used in the web component demo took a noticeable amount of time to download on my mobile phone after checking the input.
- Using the label as a target is still in tact. Users heavily rely on this.
- Indeterminate state included. Not the web component couldn't, I just added it to mine.
- At the end of the day, it's still a plain checkbox. It will work!
The other examples they have for tabs and tooltips are fine and use
the official ARIA Authoring Practices as a source, I think those
definitely make better sense as a web component. In this case, I
think it would be more responsible to at least mention in the
documentation that using a plain checkbox would be the preferred
route since this web component makes it harder to be as accessible
as intended, considering things I mentioned above. We often use the
cautionary tale of trying to create you own button instead of using
<button> element, and I think trying to
reinvent the checkbox in this manner falls in that category. For
checkboxes and radio buttons, you might not need a web component.