Forem: Michaël Vanderheyden

[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

[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 1

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.

Forem: Michaël Vanderheyden

[Boost]

Embedding Accessibility into AI based software development

[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?