5 accessibility checks to run on every component
5 accessibility checks to run on every component êŽë š
Accessibility has become part of most web teamsâ workflows â as we realize that itâs the right way to build and that it increases the number of people who can use (or buy!) our products. There are also legal obligations, such as the European Accessibility Act, which took effect on 28 June 2025.
Luckily, your design system can help! Components donât just improve your design and development workflows; they can actually have a massive impact on product accessibility. Letâs examine five key aspects we can test and document during development.
Note
Accessibility exists in context, so if youâre testing WCAG conformance, do it on* full pages and processes.
1. Keyboard accessibility
People use all sorts of input devices to interact with your UIs, whether thatâs a touch screen, a mouse, or a keyboard. To make sure your components work well with just a keyboard, as WCAG 2.1.1 requires, check that any element that a user can click on â such as links, buttons, and form controls â can also be activated using a keyboard.
If there are many controls within one component (for example, a selection widget, toolbar, or calculator), you usually donât want them all to go into the Tab order. For complex controls, the expected behavior is that the user can tab to the control and then navigate within the control itself using arrow keys. For instance, in a calendar picker, the user would access the picker with the Tab key and then navigate between days with their arrow keys.
Some things to test for keyboard accessibility:
- Can you reach all controls with Tab or arrow keys, and use them with Enter and Space? (Check out Adrian Roselliâs post on Enter and Space.)
- Can you see where you are at all times?
- Are you accidentally focusing on elements that arenât interactive? Those probably shouldnât be focusable.
- Can you press all keys on the keyboard without triggering some kind of action? (Single key shortcuts donât meet WCAG.)
2. Accessible tokens
Design tokens are a great way to document your design decisions in one place. They are also an opportunity for accessibility. The default values for your tokens can set the right example.
The three types of tokens most important for accessibility are:
Color
If there are pairs commonly used together, like foreground and background colors, youâll want to ensure they meet WCAGâs minimum contrast requirements and that they are combinations that work with all types of color blindness.
Spacing
For anything that can be used with a âpointerâ, such as a mouse or finger, youâll want to ensure the defaults are big enough, so that they work better with large fingers, on small screens, and for people with impairments like hand tremors.
Breakpoints
Accessible interfaces need to be completely responsive, so that users donât need to scroll in two directions. With good default breakpoints, your design system can facilitate this effort.
If your design system allows for documentation, cough zeroheight cough, take that opportunity to remind colleagues about accessible defaults while theyâre in the right frame of mind.
Some things to test for design tokens:
- Do the defaults meet accessibility requirements, such as contrast and spacing?
- Does your documentation explain which values would not meet accessibility requirements?
3. Named controls
People who use screen readers can navigate by specific types of content. They can pull up a list of all the headings, form controls, or links. These lists lack context, however, so itâs super important for the items to be self-explanatory.
Imagine a list of links that goes like this:
- Click here
- Click here
- Click here
Without context, it would be impossible to make out where each of them goes. Users are left with no other option but to try them all. If, instead, we make sure the link text clearly conveys what it links to â for example, âAbout usâ, âProductsâ, or âContact usâ â everyone saves time.
A similar principle applies when using controls, like buttons and form fields, on a website: Youâll want them all to have a name that clearly describes what will happen.
Some things to test for control names:
- Does the control have an accessible name?
- Is the name unique?
- Is the name descriptive and obvious without extra context?
- Is the name short and to the point? Avoid âClick here to submit applicationâ or âSubmit application buttonâ; use âSubmit applicationâ instead.
4. Zoom and user preferences
Lots of users zoom in when they use your application. For UI design, that means your available space will vary. Especially when zoomed in, less space means youâll need to get creative.
People may also be using platform-specific preferences: from color preferences (like dark mode on macOS/iOS and forced colors on Windows) to reduced motion.
Some things to test for zoom and user preferences:
- Zoom in to 400% and confirm all elements remain visible and usable.
- For any sticky elements, check that they donât cover non-sticky content.
- Try out the component with different user settings turned on.
5. Screen reader compatibility
To get your components to work well with screen readers, they need to expose the so-called âaccessibility meta informationâ for each element they contain. Broadly, it comes down to information about:
Roles
What kind of element is this? For example, a link, button, heading, or plain text.
States
Whatâs happening with the element? For instance, is it expanded or pressed? Ensure your ARIA works correctly.
Properties
What else do we need to know about the element? Sometimes they change, for example, sometimes they donât (like aria-multiline).
We only need to add and check for these, if they are elements that are identified in ARIA.
Note that some elements already include implicit metadata. For instance, a button element has a button role built in, so itâs not necessary to add one.
Itâs also perfectly fine for elements to not have any roles, states, or properties. If itâs just text, for example, itâs just text.
This is what to test for screenreader compatibility (use the browserâs accessibility tree):
- Do any of the roles have the expected children, parents, states, and properties?
- Do elements use roles that you would expect? Check if they have the expected role (for instance, a div that looks and behaves like a button, but has no such role), and that they donât have the wrong role (for example, a link that has a button role).
In addition to these checks in the browser, also test in real screen readers, such as VoiceOver on the Mac and NVDA or JAWS on Windows. Or, even better, test with users who rely on them, so that you can get the most realistic feedback on whether your UI works well.
Summing up: Accessibility checks for components
In this post, weâve looked at five things you can test against all of your design system components. They give you a fast, practical way to catch accessibility issues at the component level.
Conducting these tests doesnât replace a full WCAG evaluation. They need the context of whole websites and apps. However, these tests give you a head start: Mistakes are a lot cheaper to fix in a component than after an application goes live.