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

The tested form elements that have been styled either directly, or with some specific markup patterns, are all listed on the introductory page to The Accessibility of Styled Form Controls, which provides some additional context for each pattern. Most of these controls can be restyled without needing any JavaScript, save for but a few, such as file uploads, and ARIA reliant controls that would otherwise not function.

But if you want to jump to a particular demo and test page, here are the links to each:

• Styled Checkboxes
• Styled Radio Buttons
• Radio Button Star Rating
• Radio Button Pill
• Switch Checkbox
• ARIA Switch Button
• ARIA Toggle Button
• Switch Radio Button Group
• File Upload
• Range Slider
• Select
• Progress bar
• Meter
• Search Component

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 and meter elements.

While 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:

• HTML5 Accessibility: Form Controls
• What does accessibility supported mean? – By Léonie Watson (2016)