What is WCAG?
The Web Content Accessibility Guidelines (WCAG) are the worldwide standard for making websites usable for everyone. They outline how to design and develop websites, apps, and online services so people of all abilities can access them. At their core, WCAG is built around four principles: content should be perceivable, operable, understandable, and robust.
But WCAG isn’t only about compliance — it’s a framework for creating better experiences. A high-contrast colour scheme doesn’t just support users with low vision; it also makes text easier to read in bright sunlight. Keyboard shortcuts aren’t just for people with motor challenges; they help power users fly through forms. Perhaps you remember the old DOS interface, where only keyboard input was used.
Where to start?
You don’t need to reinvent the wheel for each UI element, like a button or a modal. Modern frameworks provide us with tools that already address some of the most challenging accessibility issues.
If you’re in the React world, shadcn/ui, built on Radix UI, provides dialogues, dropdowns, and tabs with thoughtful focus management and ARIA support. Vue developers might reach for Vuetify or Vue A11y. Angular teams can lean on Angular Material. Even general-purpose systems, like: MUI, Bootstrap, Lightning Design System come with patterns that respect accessibility out of the box.
However, always keep in mind what you drag into your solution. I dare to see that there isn't a one-stop shop solution for your site. Use the elements that you need and verify the WCAG compliance yourself.
Keeping inclusion top-of-mind
Accessibility isn’t a one-off task; it’s a way of working. By adding acceptance criteria for accessibility in every pull request. Use tooling like eslint-plugin-jsx-a11y, Axe, or Lighthouse early during development to help ensure focus. Try using your app with just a keyboard — or turn on a screen reader for a few minutes. These small rituals can catch issues long before launch day. As always, the sooner you find a bug, the lower the time and costs of fixing it.
Another tool that can help you is Storybook. This tooling has features to help you develop an inclusive web. However, keep in mind these provide guidance, but they're far from complete. You'll still need to have some manual testing.
In summary
If you want your sites to be more inclusive, start by changing the mindset of the team. Get the team on board that this is a need. Do this throughout your development flow. From design, to development, to test and acceptance. Add accessibility to the acceptance criteria so they are clear for everyone.
For the developers out there, make sure to use the tooling available. Although this tooling doesn't provide you with 100% foolproof guidance, it's a good start.
