DEV Community: Michaël Vanderheyden

href="#" and the Focus Trap

Michaël Vanderheyden — Wed, 17 Jun 2026 00:00:00 +0000

Have you ever added a link to your footer to help users navigate back to the top? It usually looks like this:

<a href="#">Back to the top</a>

I've seen and used that pattern many times, including on this very website. From an HTML perspective it is absolutely valid (7.4.6.4 Scrolling to a fragment), and I always assumed it was a harmless shortcut that worked well enough.

Then I updated Biome to 2.5 and it flagged it. I opened a bug report expecting to close it quickly, but the answer changed my mind: Biome is not rejecting it because of HTML validity, but because of accessibility behavior.

This Is Not Just a Biome Thing

The rule is actually not new and inspired by other tools that already enforced it:

The difference is scope. So far these checks mostly hit JSX workflows, which is why many of us never stumbled on this in plain HTML. Biome is the first tool (in my daily workflow, at least) that called this out on pure HTML.

Good news

With Biome extending these checks to plain HTML, this broken pattern may finally get broader visibility.

What Is Actually Broken?

Focus desynchronization

An empty hash (#) does not point to a specific element ID. When activated, the browser scrolls the page visually, but keyboard focus stays on the trigger element (for example, the footer link you just clicked).

The result is confusing:

The page looks like it moved to the top.
Focus did not move with it.
The next Tab keystroke jumps the user back to the bottom context.

WCAG impact

That behavior creates a mismatch between visual reading sequence and interactive focus sequence, which is exactly the kind of failure WCAG 2.4.3 (Focus Order) is trying to prevent.

The Workaround (And Why It Works)

Instead of href="#", give the top container an explicit ID and target it:

<body id="_top">
  <!-- page content -->
  <a href="#_top">Back to top</a>
</body>

You get the same practical scroll effect, but without focus desync.

What you will notice:

The classic empty # keeps focus on the original footer link after scroll. This is visible through the pink outline and background that stays in the footer.
The explicit fragment target behaves like normal fragment navigation: focus moves with the scroll, the outline disappears from the link and background color is removed.

Although both solutions scroll to the body element, only the second one behaves consistently with any other fragment link pointing to a heading.

Real-World Impact on Screen Reader Users

NVDA Issue #19190 — "Focus shifts to top of page when activating a link using href="#" on Chrome" describes exactly what happens to screen reader users in Chromium-based browsers:

The viewport jumps to the top.
The virtual reading context follows that jump.
Native keyboard focus remains on the original footer element.
Press Tab, and you are yanked straight back down.

Why Browser Vendors Haven't "Fixed" It

This is a classic boundary problem between assistive technology and browser engines, and the issue trail reflects that.

Screen reader side

The NVDA issue was initially closed as not planned — the reasoning being that the screen reader is simply reacting to where the browser moved the viewport. It was later reopened and triaged, and the question of who owns the fix is still open.

Browser engine side

Chromium has addressed a related focus behavior in Issue #40403681: when a fragment identifier points to a non-focusable element, focus handling was improved in that scope.

The empty fragment case (href="#") was not part of that change and can still be reproduced in Firefox and Safari as well.

My Take

What makes this especially frustrating is the asymmetry:

href="#" scrolls the page without moving focus.
href="#_top" often targets the same unfocusable element at the top and yet focus behaves correctly.

Same destination. Completely different focus outcomes. That's hard to defend as intentional design.

I still see this primarily as a browser behavior problem, not a screen reader problem. But because the spec does not define what should happen to focus for an empty fragment navigation, it may need to be updated first.

My expectation is that when navigation to an empty fragment identifier happens, the body element should become the sequential focus navigation starting point.

Conclusion

So the fix on our side is straightforward: use the explicit ID approach. It eliminates an accessibility issue with just one line of code. And it's a good reminder that "technically valid" and "actually usable" are not the same thing — sometimes you have to work around browser limitations to deliver a coherent user experience.

Originally published at Th3S4mur41.me

headingoffset Is Coming: How to Prepare Today

Michaël Vanderheyden — Thu, 04 Jun 2026 00:00:00 +0000

Jake Archibald recently announced that Firefox implemented headingoffset in Firefox Nightly.

This is big news for anyone building reusable UI components with semantic headings. For a long time, developers had to choose between awkward workarounds:

Ask consumers to provide heading elements via slots.
Build custom heading-level logic into each component.
Duplicate components just to avoid broken heading structure.

Now that browser implementation has started, we can finally prepare for a cleaner pattern.

Why this matters

Reusable components often need to appear in different contexts:

A card title might be an h2 on one page.
The same card title might need to be an h3 inside a nested section.

Without contextual heading adjustment, one reusable component can easily create skipped or flattened heading levels. That hurts document structure for everyone, especially screen reader users.

headingoffset gives us a semantic way to keep component internals stable while adapting heading levels to surrounding context.

What we do today (and why it is painful)

Workaround 1: Slot-based heading ownership

We let consumers provide headings from outside the component:

<article-card>
  <h2 slot="title">Billing Settings</h2>
</article-card>

This can work, but it shifts structure responsibilities to every caller, which leads to inconsistency.

Workaround 2: Custom heading-level APIs

We pass a level and render dynamic heading tags:

<article-card heading-level="3"></article-card>

Inside the component:

const level = Number(this.getAttribute("heading-level") || 2);
const tag = `h${Math.min(6, Math.max(1, level))}`;

This is repetitive, easy to misuse, and often re-implemented differently across codebases.

What changes with headingoffset

With headingoffset, a component can keep meaningful internal heading markup, while parent context controls the effective level.

<h1>Heading level-1</h1>
  <article-card headingoffset="1">
    <h1>Heading level-2</h1>
  </article-card>

If article-card contains an h1, it can be treated as a deeper-level heading in that context.

That means we can write components with clearer semantics, similar to the second workaround but without the need for custom heading-level logic.

Can we use it today?

Not in stable browsers yet, but we can prepare now.

The headingoffset polyfill helps bridge the gap. It checks support and, where needed, applies aria-level to mimic headingoffset behavior.

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

This makes progressive enhancement possible:

Native behavior when supported.
Polyfilled fallback elsewhere.

Firefox + Narrator currently has an announcement quirk

For cases like <h1 aria-level="2">, Firefox with Narrator may announce:

"heading level 1"

then the title

then "at level 2"

The same content is announced as expected with Firefox + NVDA/JAWS and with Edge/Chrome + Narrator. At this point, this looks like a Firefox-Narrator interpretation issue rather than a general aria-level model problem.

CSS styling requirements (deeper dive)

As soon as heading levels no longer match the literal element name, targeting styles with h1 to h6 selectors is no longer a viable long-term strategy.

That is exactly where the new :heading() selector comes in: it lets you style by effective heading level instead of raw tag name.

Unfortunately, support is not there yet either, so we still need a fallback strategy today.

:heading(1) {
  /* heading level 1 styles */
}

:heading(2) {
  /* heading level 2 styles */
}

/* Fallback when headingoffset and :heading() are not supported */
@supports not selector(:heading(1)) {
  /* Specific heading without aria-level set, 
     or any heading with aria-level set to the target value. 
   */
  h1:where(:not([aria-level])),
  :is(h1, h2, h3, h4, h5, h6):where([aria-level="1"]) {
    /* heading level 1 styles */
  }

  h2:where(:not([aria-level])),
  :is(h1, h2, h3, h4, h5, h6):where([aria-level="2"]) {
    /* heading level 2 styles */
  }
}

This could also be done as progressive enhancement and that may be a better fit if you still support very old browsers. I personally prefer the structure above because once :heading() support is good enough, I can delete the @supports block and keep the rest unchanged.

Check it out live in the CodePen

If browsers ship headingoffset before :heading() support, this fallback can break. You can already observe that scenario in Chrome Canary and Edge Canary where headingoffset works, but :heading() is still unsupported.

Practical preparation checklist

You can start preparing now, but this should stay out of production for the moment: the fallback proposal is mostly working, yet there is still release risk because browsers may ship headingoffset and :heading() at different times.

Audit components that currently accept heading-level props.
Identify places where slot-owned headings are used only for hierarchy control.
Add exploratory examples behind feature flags or internal demos.
Add the polyfill in non-supporting browsers and test with real assistive tech combinations.
Keep fallback CSS explicit for aria-level mappings where needed.

Final thought

This is an exciting transition period: we are moving from custom component logic and one-off heading APIs toward a shared, standards-based model for contextual heading structure.

That shift can reduce complexity across many contexts, for example in design systems and CMS implementations, improve long-term maintainability, and keep accessibility behavior more consistent across projects.

What do you think? When will you start replacing your custom heading-level logic with a standards-first approach?

Originally published at Th3S4mur41.me

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

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

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.

black. A striking example of how contrast standards can diverge." width="737" height="330">

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.

popover." width="178" height="254"> colors." width="277" height="397">

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.

color." width="260" height="246">

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

Frameworks are tools, not gatekeepers: Rethinking web developer hiring

Michaël Vanderheyden — Mon, 01 Sep 2025 07:00:00 +0000

Another week, another missed opportunity. A seasoned web developer, 20+ years of experience, expert in Angular, certified in accessibility, and a proven leader, was dismissed from a job application. The reason? Not enough practical experience with React. Not because the role demanded deep React internals or framework-specific wizardry. They were hiring someone to build features. And yet, the checkbox hiring mentality struck again.

The checklist problem

Too many hiring processes are driven by rigid requirement lists, often crafted by people who don't truly understand how the web works. They treat frameworks like qualifications, not tools. And in doing so, they overlook developers who bring deep, transferable knowledge - people who understand the web's foundations and can adapt to any framework thrown their way.

This isn't just frustrating. It's wasteful.

Hire for fundamentals, not familiarity

If I were hiring for a web development role, I'd choose someone who understands:

Semantic HTML and why it matters
How to build accessible, inclusive interfaces
The principles of progressive enhancement
How the browser actually works

These are the skills that transcend frameworks. React, Angular, Vue, Svelte - they're all just tools. A good developer can learn them. A great developer knows when to use them, and when not to.

So, when we have open opportunities and I'm hiring, this is exactly what I'm looking for. I'm not scanning for the latest buzzwords on a résumé or checking off a list of libraries someone has used. I'm searching for people who think deeply about the web, who understand its foundations, and who care about building resilient, user-first experiences. If you bring curiosity, clarity of thought, and a strong grasp of the fundamentals, you're already speaking my language.

Frameworks fade, standards endure

Remember jQuery? It was revolutionary. It solved real problems. But most of what made it essential has now been absorbed into native web standards. The same fate awaits today's frameworks. In 10 years, React may be a footnote. Web standards, however, will still be here, evolving, expanding, and forming the bedrock of everything we build.

So why invest in developers who are deeply tied to a single framework, rather than those who build on enduring principles?

Build for the future, not just the stack

Hiring someone who sees frameworks as tools instead of crutches means investing in solutions that can evolve. It means building products that aren't locked into a single ecosystem. It means fostering a team that can pivot, adapt, and innovate.

Framework fluency is useful. But framework dependency is dangerous.

Let's stop filtering out great developers because they haven't ticked the right box. Let's start hiring people who understand the web, not just the latest abstraction of it.

Originally published at Th3S4mur41.me

DEV Community: Michaël Vanderheyden

href="#" and the Focus Trap

This Is Not Just a Biome Thing

What Is Actually Broken?

Focus desynchronization

WCAG impact

The Workaround (And Why It Works)

Real-World Impact on Screen Reader Users

Why Browser Vendors Haven't "Fixed" It

Screen reader side

Browser engine side

My Take

Conclusion

headingoffset Is Coming: How to Prepare Today

Why this matters

What we do today (and why it is painful)

Workaround 1: Slot-based heading ownership

Workaround 2: Custom heading-level APIs

What changes with headingoffset

Can we use it today?

CSS styling requirements (deeper dive)

Practical preparation checklist

Final thought

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

Frameworks are tools, not gatekeepers: Rethinking web developer hiring

The checklist problem

Hire for fundamentals, not familiarity

Frameworks fade, standards endure

Build for the future, not just the stack

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