Success Criterion 2.4.11
Conformance level AA

Anchor Link Landing an Element Directly Under a Fixed Header

2.4.11 — Focus Not Obscured (Minimum)

Scenario

Setting

A bank's mobile money-transfer screen

What’s wrong

Anchor/scrollIntoView behavior placing focused element exactly under fixed header (fully hidden without scroll-padding (spacing that keeps sticky bars off content)).

Example

Here's a real case from a bank's mobile money-transfer screen: anchor/scrollIntoView behavior placing focused element exactly under fixed header (fully hidden without scroll-padding (spacing that keeps sticky bars off content)).

Why it matters

Sighted keyboard users when sticky chrome would otherwise hide the focused control. Here, on a bank's mobile money-transfer screen, the result is they can't complete the task using a keyboard alone.

How to test

Use an in-page anchor link or scrollIntoView-triggered navigation: if the target lands exactly under a fixed header with no scroll-padding offset, it's fully hidden and fails.

How to fix

The focused element must remain at least partially visible — never fully hidden behind sticky bars, banners, or overlays.

Outcome

After the fix, the same visitor to a bank's mobile money-transfer screen can now reach and operate the control without a mouse, specifically for the “Anchor Link Landing an Element Directly Under a Fixed Header” issue on a bank's mobile money-transfer screen.

Who is affected

Sighted keyboard users when sticky chrome would otherwise hide the focused control.

Learn more

Understanding Understanding document (opens in a new tab)