DEV Community: Michaël Vanderheyden

Beyond compliance: Building accessibility into quality with test automation

Michaël Vanderheyden — Tue, 12 May 2026 10:00:00 +0000

I’m hyped to share a new deep-dive article I’ve co-authored with Jörg Jakoby, now live on the Atos blog!

We’ve been exploring how to make accessibility a "business as usual" part of the development lifecycle. The secret? Don't reinvent the wheel.

In this post, we dig into:

How to start checking accessibility directly in your CI pipeline.
Why automation is a massive lever for preventing regressions (even if it doesn't cover 100%).
Practical ways to extend the tools you already have in place to save time and effort.

Building inclusive tech doesn't have to be complex and expensive. It’s about working smarter with the automation you’ve already built!

Read the full story over at Atos: Beyond compliance: Building accessibility into quality with test automation

[Boost]

Michaël Vanderheyden — Wed, 15 Apr 2026 13:14:59 +0000

Michael Fairchild

Mar 12

Embedding Accessibility into AI based software development

#a11y #llm #ai #benchmark

Comments 2

5 min read

Labels: Automatic Checks and Manual Validation

Michaël Vanderheyden — Tue, 14 Apr 2026 09:00:00 +0000

Labels are essential for screen reader users and overall accessibility. While automated tools can verify that labels are present on interactive elements, determining whether a label is meaningful and contextually appropriate still requires manual testing.

Screen reader testing can be challenging for developers and testers who aren't regular users. Practical alternatives include:

Inspecting labels and roles through the browser DevTools accessibility tree.
Using voice navigation to verify that elements are reachable and operable by spoken commands.

Screen reader setup
If you do test with a screen reader, the results will only be reliable if your environment is correctly set up. The right screen reader depends on both your operating system and the browser you're testing with. Sara Soueidan's guide to setting up an accessible testing environment covers screen reader and browser pairings for macOS and Windows, virtual testing, mobile screen readers, and keyboard configuration.

DevTools Accessibility Tree

For developers who aren't regular screen reader users, browser DevTools offer a practical way to inspect how labels and roles are exposed to assistive technologies. Both Chromium-based browsers (like Edge and Chrome) and Firefox include an Accessibility Tree view that mirrors what screen readers perceive.

This tree shows the semantic structure of your page - including roles, names, states, and relationships - allowing you to verify whether interactive elements are properly labeled and accessible.

Inspecting accessibility like a pro: Both Edge (Chromium) and Firefox offer built-in tools to explore the accessibility tree. Just open DevTools and follow the arrow to find the menu - it's easier than you think.

How to access the Accessibility Tree

Edge / Chrome:

Open DevTools (F12 or Ctrl+Shift+I)
Open DevTools settings through the 3-dot menu
Go to the experiments tab and activate the Enable full accessibility tree view in Element panel option
Go to the Elements tab
Click the floating Accessibility button in the top right of the pane

Firefox:

Open DevTools (F12 or Ctrl+Shift+I)
Go to the Accessibility tab directly
Navigate the tree or select elements to inspect roles, names, and states

The screenshot above compares both views using a demo from this CodePen, showing how a checkbox labeled "Read" is exposed in the accessibility tree. You can see its role, name, and state - all critical for screen reader compatibility.

Voice Navigation

Screen readers aren't the only way to validate whether labels are meaningful and usable. Voice navigation tools let you interact with a page the way users relying on speech commands would - asking the system to "click," "open," or "select" elements by name. This is a powerful way to check if your labels are both present and practical in real-world use.

Why it matters

If a button or link can't be activated by its label, it's a sign the label isn't descriptive enough.
Voice navigation highlights issues that automated checks often miss, such as ambiguous or duplicated labels.
It helps ensure that your interface works for users who rely on voice control for accessibility or convenience.

How to test with voice navigation

Desktop

Windows (Voice Access)

Enable Voice Access in Accessibility settings.
Use commands like "Click Read" or "Open Settings" to test if elements respond correctly.

macOS (Voice Control)

Turn on Voice Control in System Settings (or System Preferences in older versions) → Accessibility.
Try commands such as "Click Log In" or "Select checkbox".

Mobile

Android (Voice Access)

Go to Settings → Accessibility and enable Voice Access (you may need to install it from the Play Store first).
Tap Open in the Voice Access notification to start a session — numbered overlays will appear on interactive elements.
Try commands like "Tap Read" or "Scroll down" to verify that elements are reachable by their label.

Voice Access Numbers
Android also shows interactive element numbers on screen during a Voice Access session. If an element only gets a number but no spoken label, it is a strong signal the accessible name is missing or unclear.

iOS (Voice Control)

Go to Settings → Accessibility → Voice Control and toggle it on.
Try commands like "Tap Log In" or "Tap checkbox" to verify that elements respond to their visible or programmatic label.

Voice Navigation as a Developer Tool

Voice navigation isn't just for end users with accessibility needs. Developers themselves may benefit from it at some point in their careers. For example, those experiencing hand mobility issues such as carpal tunnel syndrome can use voice commands as an alternative input method.

Building with accessibility in mind ensures that these options are available when you or your users need them most.

Wrapping Up

Properly associating labels with interactive elements isn't just a screen reader concern. As this article shows, labels are the backbone of voice navigation, the anchor for DevTools inspection, and a key signal for any assistive technology or automated agent, whether it's a switch device, a browser extension, an AI assistant filling out a form on your behalf, or a future input method we haven't seen yet.

When a label is clear and correctly linked, everyone benefits: screen reader users hear the right name, voice control users can activate elements by speaking them, and sighted keyboard users get a larger click target for free.

You have more testing tools at your disposal than you might think. Use whichever fits your workflow — open the accessibility tree, try a voice command, or both. The important thing is to make label validation a deliberate step, not an afterthought.

Originally published at Th3S4mur41.me

[Boost]

Michaël Vanderheyden — Thu, 26 Mar 2026 16:45:47 +0000

Burton Smith

Mar 24

How Declarative Custom Elements (DCE) Could Improve Web Components

#html #javavscript #webcomponents

Comments 3

8 min read

Making Scrollable Code Blocks Accessible

Michaël Vanderheyden — Fri, 20 Feb 2026 11:59:17 +0000

When you work on the web long enough, you get used to browsers disagreeing on the small things. But sometimes those “small things” quietly break accessibility in ways that aren’t obvious until you test with a keyboard.

This is exactly what happened with scrollable elements.

Most browsers like Chrome and Firefox automatically make scrollable regions keyboard‑focusable. That means if the content overflows, a keyboard user can tab into it and scroll through the content using the arrow keys. It’s intuitive, consistent, and aligns with WCAG’s requirement that scrollable regions must be keyboard accessible.
Safari, however, doesn't follow this behavior. There's a long‑standing bug report in WebKit Backlog where scrollable elements (like long code blocks or tables) do not receive keyboard focus, as reported by Adrian Roselli, making them inaccessible to keyboard users.

Safari doesn’t make scrollable elements focusable

In Safari, an element that becomes scrollable (e.g., long code snippets) does not receive focus by default. That means:

You can see the scrollbar.
You can scroll with a mouse or trackpad.
But you cannot tab into it.
And therefore you cannot scroll it using the keyboard.

This is a direct accessibility failure under WCAG 2.2’s Keyboard criterion, which states that all functionality must be operable through a keyboard interface — including scrolling inside overflow regions.
For keyboard‑only users, this effectively traps content. They can see the beginning of the content, but not the rest.
And because Chrome and Firefox “do the right thing,” most developers never notice the issue.

Why this matters more than it seems

Scrollable code blocks are everywhere:

Documentation sites
Developer blogs
Design system pages
API references
Tutorials
...

Code blocks are usually implemented using <pre> elements. The <pre> element is one of the most common non-interactive elements that becomes scrollable by default because it's designed to preserve formatting and not wrap content.
If a code block is long enough to require scrolling, it becomes inaccessible to keyboard users in Safari.

If a user can’t scroll them, they can’t read them. And if they can’t read them, the content might as well not exist.
This is one of those accessibility issues that isn’t flashy, but has a real impact on real people.

The Solution

There is a simple solution to the problem: make scrollable elements keyboard‑focusable by adding tabindex="0". This allows keyboard users to tab into the element and use arrow keys to scroll through the content.
However, this requires developers to manually add tabindex="0" to every scrollable <pre> element, which is not ideal. It’s easy to forget, and it adds extra maintenance.
Moreover, it’s not ideal to make every <pre> focusable, since not all of them will be scrollable.

The polyfill is only a temporary workaround until Safari implements the expected behavior. It’s not a permanent solution, but it helps bridge the gap in the meantime.

Automatically adding tabindex="0" when needed

To fix this gap, I created a small polyfill: scroll-focus-polyfill that is pretty easy to use by simply including it on your page.

<script src="https://unpkg.com/scroll-focus-polyfill"></script>

The idea is simple:

Detect when a <pre> element becomes scrollable.
Automatically add tabindex="0" so it becomes keyboard-focusable.
Only apply this where the behavior is not already provided by the browser.

This keeps the behavior consistent across browsers without forcing developers to manually annotate every code block.
It’s intentionally lightweight, unobtrusive, and standards‑aligned.

Why not just add `tabindex="0"` everywhere?

You could, but that introduces its own problems:

Non‑scrollable <pre> elements don’t need to be in the tab order.
Adding unnecessary focus targets creates noise for keyboard users.
It also breaks expected semantics — not every <pre> is interactive.

The polyfill only applies focusability where it's actually needed.

What about other scrollable elements?

While this polyfill focuses on <pre> elements by default for performance reasons, it can be configured to also apply the same logic to other elements like tables, divs with white-space: nowrap, or any other scrollable container.
For example, if you have a class scrollable that prevents an element from wrapping, you can easily extend the polyfill to handle any element with that class.

<script src="https://unpkg.com/scroll-focus-polyfill"
        data-selectors="pre, .scrollable"></script>

A subtle bug with real accessibility impact

This is a great example of how accessibility issues often hide in the details.
Safari’s behavior isn’t “wrong” in a spec sense — but it’s inconsistent with user expectations and with other browsers’ accessibility affordances.
And because developers don't always test keyboard navigation explicitly in Safari, the issue slips through unnoticed.
The polyfill bridges that gap until Safari aligns with the behavior of other engines.

Conclusion

Making scrollable code blocks accessible is a small but important step towards a more inclusive web.
By understanding the issue, implementing a simple polyfill, and advocating for better cross‑browser consistency, we can ensure that all users have equal access to content — regardless of their browser or input method.
If you maintain a documentation site, developer blog, or any content with scrollable code blocks, consider implementing this polyfill to improve accessibility for your keyboard users. It’s a small change that can make a big difference.

Join the conversation on Bluesky or LinkedIn

Originally published at https://th3s4mur41.me.

Contrast: Beyond WCAG Compliance

Michaël Vanderheyden — Wed, 14 Jan 2026 10:00:00 +0000

Contrast is one of the easiest accessibility aspects to evaluate because it can be measured with algorithms. Whether through automated tools or semi‑automatic checks, developers can quickly verify if text and background combinations meet established standards. This makes contrast a practical starting point for improving accessibility - though, as we'll see, compliance alone doesn't always guarantee the best user experience.

WCAG vs APCA: Understanding the Difference

While WCAG guidelines provide a solid foundation for color contrast, strict compliance sometimes leads to suboptimal results with certain colors. Consider using the APCA (Accessible Perceptual Contrast Algorithm) as an alternative or in addition to WCAG checks. APCA offers a more nuanced approach to contrast that better reflects human perception.

Visual clarity vs legacy metrics: Though WCAG favors black text on orange background, users often find white more
readable. APCA captures this perceptual nuance, challenging traditional contrast assumptions.

Try the demo interactively:

WCAG Levels in Brief

Real-world example: Stack Overflow

For example, Stack Overflow recently transitioned to APCA for their accessibility design, improving readability and user experience. You can read more about their approach and lessons learned in their blog post: Accessibility by Design at Stack Overflow.

To keep contrast checks in their automated accessibility testing, they also built custom Axe rules that validate APCA contrast levels (instead of the traditional WCAG contrast ratio checks). That work is available publicly as StackExchange/apca-check.

How to check contrast (DevTools + quick tools)

Even if you run automated checks, it’s useful to spot‑check contrast right in the browser while you build.

Chrome / Chromium-based browsers

You can see contrast information in a few places:

Use the element picker (“Select an element in the page to inspect”, usually + + ) to inspect the text you care about.
In the Styles panel, open the color picker for the color property; DevTools can display contrast results for the foreground/background pairing.

Chrome DevTools: use the element picker to target the exact text you want to evaluate, or use the
picker to view contrast results.

Known DevTools issue: Chrome DevTools has a known issue (Chromium bug 1414206) where contrast ratios aren’t displayed if a color is applied to an element containing children (or even a comment node). Until it’s fixed, check contrast directly on the actual text node(s), or use an external checker.

If you want to switch DevTools to the APCA algorithm, open DevTools Settings → Experiments and enable the APCA contrast option. The main downside is that DevTools typically shows either WCAG or APCA results, not both at once.

Firefox

Firefox DevTools also shows contrast in the color picker for the color property.

Firefox DevTools: check contrast in the color picker for the property.

When you want WCAG and APCA side-by-side

VisBug is a good alternative for quick checks, since its contrast checker shows WCAG and APCA results side by side.

VisBug: handy for quick spot-checks when you want WCAG and APCA at the same time.

Warning: Contrast tools have limits

All of these tools are helpful, but they have a limitation: they can only reliably validate contrast by following the normal DOM and paint flow to determine the “effective” background behind text.

If you use visual stacking (for example via CSS Grid overlap, positioned layers, or a background created with a pseudo-element like ::before) where the foreground and background colors live on different elements, tools can pick the wrong background to compare against.

In the following demo, both boxes look identical, but most tools report a contrast of 1 (no contrast) for the second box because they compare the text against the page background (e.g. body) rather than the yellow background painted by ::before.

Conclusion

Tools and rules are there to help you make better decisions, not to replace judgment. The real goal of contrast work isn’t “passing a checker”, it’s making content that people can comfortably read and use.

Ideally, aim to satisfy both WCAG and APCA. But when you can’t (or when the two point you in different directions), favor real user experience over compliance: validate with real content, real contexts, and—when possible—real users.

Originally published at Th3S4mur41.me

DEV Community: Michaël Vanderheyden

Beyond compliance: Building accessibility into quality with test automation

[Boost]

Embedding Accessibility into AI based software development

Labels: Automatic Checks and Manual Validation

DevTools Accessibility Tree

How to access the Accessibility Tree

Edge / Chrome:

Firefox:

Voice Navigation

Why it matters

How to test with voice navigation

Windows (Voice Access)

macOS (Voice Control)

Android (Voice Access)

iOS (Voice Control)

Voice Navigation as a Developer Tool

Wrapping Up

[Boost]

How Declarative Custom Elements (DCE) Could Improve Web Components

Making Scrollable Code Blocks Accessible

Safari doesn’t make scrollable elements focusable

Why this matters more than it seems

The Solution

Automatically adding tabindex="0" when needed

Why not just add tabindex="0" everywhere?

What about other scrollable elements?

A subtle bug with real accessibility impact

Conclusion

Contrast: Beyond WCAG Compliance

WCAG vs APCA: Understanding the Difference

WCAG Levels in Brief

Real-world example: Stack Overflow

How to check contrast (DevTools + quick tools)

Chrome / Chromium-based browsers

Firefox

When you want WCAG and APCA side-by-side

Warning: Contrast tools have limits

Conclusion

Why not just add `tabindex="0"` everywhere?