Basic Custom Control Requirements
If you are working on a custom control, a complex widget, or a novel interface element to integrate into a project, library, or framework, there are some core features you need to build.
These represent not just what works for users across the most contexts and preferences, but also what usability, accessibility, and internationalization practitioners (among many others) review to evaluate whether a solution can be used (purchased, integrated, discarded).
- Internationalization (i18n) support:
- System settings:
- Uses appropriate ARIA roles and attributes for its purpose;
- When there is no ARIA role that fits, is treated as a group of distinct controls with appropriate ARIA roles for each;
- Uses ARIA states and properties, being careful to use ones appropriate for defined widgets;
- Does not use ARIA to define native / operating-system-style controls that are not a fit for a web control or web document;
- Clearly conveys disabled, read-only, and required states along with name, role and value;
- Maintains good contrast of content and contrast of controls across use, states, and context;
- Has tested (by real users) screen reader support (beyond just code compliance);
- Uses progressive enhancement;
- Has print styles;
- Does not have unnecessary dependencies (packages, libraries, images, styles, etc).
You may notice that there is a lot of overlap with the considerations listed at Does My Site Deserve Recognition? (and the Custom Control Accessible Development Checklist from the W3C). Ideally building good components will contribute to all the items listed on that site. More importantly, building good components is good for users.
Consider using this list as you work on your design system or pattern library as well. Integrating these best practices as the most basic component level makes it easier to enforce it across everything you build.
Similarly, before choosing a pattern (or framework or library), use this list as a quick way to vet it. Check the CSS, check the HTML, check the examples. Just because a thing implies it is accessible does not mean it is.
It is easy for me to cherry-pick examples from my own work, but I will list a few (so you may steal code). In each case I try to explain the logic for the decisions I made.
- Under-Engineered Custom Radio Buttons and Checkboxen
- Under-Engineered Toggles
- Under-Engineered Toggles Too
- Under-Engineered Text Boxen
- Periodic Table of the Elements
If you don’t code, you can at least apply these suggestions to drive how a thing might be developed. You can see some of this code-free approach in other posts of mine:
The Web Accessibility Initiative (WAI) tutorials have examples for a custom share button and star rating widget.
If you have your own suggestions for making a thing work for as many users as possible, and that is not dependency monster, offer it in the comments.
This reminded me of Heydon Pickering’s Inclusive Design Checklist as well: https://github.com/Heydon/inclusive-design-checklist
Amy, similar but different. His is broader and applies to more than controls. Mine is focused on controls. But you should see a lot of overlap. The W3C example I linked is probably a closer analogue.