Short note on the accessibility of styled form controls
Sticking with a native form control will almost always give your users a more accessible experience than trying to recreate one from scratch. Though the issue with native form controls is that they have an infamous reputation for being problematic to style.
Outside of some of the HTML5 form controls, which have browser prefixed CSS selectors for styling hooks, this reputation still holds true. In some cases (e.g.
option elements) styling support has actually decreased in some browsers. Fortunately, there have been many experiments with markup and CSS over the years to (mostly) get around the limitations of many native form controls, without having to disregard them completely.
Styled and “Styled” form controls
But if you want to jump to a particular demo and test page, here are the links to each:
Be sure to check out the GitHub repository for these form controls. If you come across anything I missed with my testing, or have a pattern you think should be included, I’d appreciate it if you file an issue or create a pull request.
Some are better than others
While I wasn’t expecting all form elements to work perfectly with screen reader and browser combinations, there were some that stood out as having more problems than others. Particularly the
progress has better accessibility support than
meter, the manner in which screen readers announced the elements did not always match up with the browser’s accessibility support. Furthermore, styling these elements actually lead to further issues in how they were exposed to screen readers (to the point that styling each could result in them being completely hidden to screen readers…)
For more information on the accessibility support for HTML5 form controls, and the term accessibility support in general, you can review: