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:
  • Correctly uses lang attribute;
  • Has right-to-left (RTL) text support;
  • Uses writing modes (for more than just LTR and RTL) where appropriate;
  • Is planning for or using CSS logical properties (in anticipation of support);
• Keyboard:
  • Has built-in keyboard support;
  • Leans on defaults where known;
  • Includes focus styles (that are obvious);
• System settings:
  • Supports Windows High Contrast Mode (WHCM);
  • Honors users’ color scheme preferences (dark mode);
  • Honors reduced motion preferences;
  • Will honor new user-preference-based feature queries as they become available;
• Scaling:
  • Does not disable zoom;
  • Does not fall apart on zoom;
  • Does not override user font size settings;
  • Leans on relative sizing — lines, text, borders, spacing, etc.;
• ARIA:
  • 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.

Examples

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:

• Baseline Rules for Scrollbar Usability
• So You Think You’ve Built a Good Infinite Scroll
• Defining ‘Toast’ Messages

The Web Accessibility Initiative (WAI) tutorials have examples for a custom share button and star rating widget.

Suggestions

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.