Skip to content

The Carbon Design System bakes in WCAG 2.2 AA standards, so most of the heavy lifting is already done. That means instead of chasing every accessibility guideline, I could focus on fixing the smaller, trickier issues in my app.

Accessibility tools making the job easier

Chrome's Lighthouse on large screens

Lighthouse is my go-to for quick accessibility checks. It runs right in Chrome DevTools and flags issues with clear guidance. For example, it caught a skip link that wasn’t focusable because I hadn’t connected it to the page’s main content.

Figure 1: Screenshot of Lighthouse score spotting a "Skip links are not focusable" issue on the home page.
Figure 1: Screenshot of Lighthouse score spotting a "Skip links are not focusable" issue on the home page.

It also flagged a problem with headings in my blog cards — they weren’t ordered sequentially. That’s a developer slip-up, and exactly the kind of issue Lighthouse makes easy to spot.

Figure 2: Screenshot of Lighthouse score spotting a "Heading elements are not in a sequentially-descending order" issue on the blog page.
Figure 2: Screenshot of Lighthouse score spotting a "Heading elements are not in a sequentially-descending order" issue on the blog page.

Chrome's Lighthouse on smaller screens

Testing on mobile gave me different insights. Lighthouse showed that my sidebar navigation had nested <ul> elements without proper <li> wrappers. Not something I would’ve noticed right away, but a real accessibility concern.

Figure 3: Screenshot of Lighthouse score spotting a "Lists do not contain only <li> elements and script supporting elements (<script> and <template>)" issue on the mobile navigation.
Figure 3: Screenshot of Lighthouse score spotting a "Lists do not contain only <li> elements and script supporting elements (<script> and <template>)" issue on the mobile navigation.

Additional testing with Chrome's WAVE

While Lighthouse is great for big-picture checks, WAVE adds another layer by visually marking accessibility issues right on the page. It makes it super easy to catch ARIA roles, contrast errors, and structural hiccups I might otherwise miss.

Figure 4: Screenshot of Chrome's WAVE displaying accessibility validation results.
Figure 4: Screenshot of Chrome's WAVE displaying accessibility validation results.

Testing components in isolation with storybook

I also ran tests directly inside Storybook using the a11y addon. This was a game-changer: I could check each component in isolation before plugging it into the app. It saved me from spreading accessibility mistakes across multiple pages.

Figure 5: Screenshot of Storybook's a11y addon displaying accessibility validation results.
Figure 5: Screenshot of Storybook's a11y addon displaying accessibility validation results.

✨ Takeaway

When assessing your React app’s accessibility:

  • Start with a strong foundation (Carbon helps a lot).

  • Run Lighthouse scans on desktop and mobile.

  • Use WAVE for deeper semantic and ARIA insights.

  • Test components early in Storybook with the a11y addon.

  • And remember: tools guide you, but accessibility depends on developer choices.

The goal isn’t just passing tests — it’s building experiences everyone can use.

Loading contact information, navigation links, and published work....