Monitoring Focus Visibility When Sticky Headers and Banners Keep Changing

November 4, 2026

Focus indicators pass an audit in January and fail by March, not because the CSS changed but because a sticky promo bar started covering the focused element. What to monitor, and how.

Focus visible is the criterion teams think they have settled. Somebody fixed the outline in a past audit, the ticket closed, and the stylesheet has not been touched since. Then marketing adds a sticky announcement bar, a cookie banner gets taller, and the chat button moves to the bottom right corner. Now a keyboard user tabs to a link that sits exactly underneath the sticky bar. The outline renders. Nobody can see it.

WCAG 2.4.7 Focus Visible asks that a keyboard focus indicator be visible, and 2.4.11 Focus Not Obscured, new in WCAG 2.2 at AA, asks that the focused component not be entirely hidden by author created content. That second criterion is the one sticky furniture keeps breaking, and it breaks without a single line of focus CSS changing. Monitoring has to watch the overlap, not just the outline.

What actually obscures focus on a store

Sticky headers, sticky add to bag bars on mobile product pages, cookie and consent banners that sit in the viewport until dismissed, chat widgets, and back to top buttons. All five are added or resized by tools outside the theme, which is why a theme only check misses the regression. The failure is geometric: two elements occupying the same pixels, with the wrong one on top.

Scroll behaviour makes it worse. Anchor jumps and focus moves after a modal closes often land the target at the very top of the viewport, directly behind a sticky header. scroll-margin-top on focusable elements and section headings is a small CSS fix that prevents a whole class of these, but it has to be set for the current header height, and header height changes when a promo bar is switched on for a sale.

A monitoring check that catches it

Load key templates, tab through the interactive elements programmatically, and for each focused element compare its bounding box against the sticky elements present on that page. Flag any element whose box is fully covered, and screenshot the partially covered ones for human review. Partial cover is not an automatic AA failure under 2.4.11, which is about a component being entirely hidden, but a half covered outline is a usability problem worth seeing.

Run the check in the states a real visitor gets: banner present and banner dismissed, sale bar on and off, mobile and desktop viewports. A single default state will pass on the day the banner is short and fail on the day it wraps to two lines on a narrow screen. States, not pages, are the unit that changes.

Signals worth alerting on

Alert on new fixed or sticky positioned elements appearing in the page, on the total height of fixed top furniture crossing the scroll margin you set, and on the focus indicator contrast dropping. Measuring indicator contrast against adjacent colours is fiddly, since the indicator often sits on mixed backgrounds, but a sudden change after a redesign is a reliable prompt for a manual pass.

Keep a short manual tab run in the routine regardless. Automated geometry catches coverage. It does not catch an indicator that is technically visible and practically useless, such as a one pixel dotted line in a pale grey on a white sale page. Five minutes of tabbing through checkout tells you more about that than any score.

Related reading: Monitoring Heading Levels After a Section Redesign, Monitoring Error Identification in Checkout and Account Forms, Monitoring Focus Order in Sticky Add to Cart Bars.

Frequently asked questions

What does WCAG 2.2 say about focus being covered?

Criterion 2.4.11 Focus Not Obscured at AA requires that when a component receives keyboard focus, it is not entirely hidden by content the author created, such as a sticky header. The AAA version, 2.4.12, requires that no part of the component is hidden.

Can I just make the outline thicker?

A thicker, higher contrast outline helps visibility and is worth doing, but it does not fix an element sitting underneath a sticky bar. Covered is covered, however strong the outline. Fix the overlap with scroll margin and positioning, then strengthen the indicator.

Do cookie banners count for this criterion?

Content that a user can dismiss or that disappears is treated differently in the guidance, but in practice a banner that stays in place while someone tabs behind it is a real barrier. Test with the banner up, because that is the first run experience every new visitor gets.

How often should focus checks run?

After every theme, app, or banner change, and on a regular schedule in between. Focus regressions arrive with marketing changes more often than with platform releases, so tie the check to campaign launches as well as to code deploys.

Frequently asked questions

What is the main takeaway from An accessibility checklist before holiday traffic?

The main takeaway is to work through the basics in order, check each step as a real user would experience it, and fix patterns at their source rather than patching a single example. A short written record of what you checked makes the next review faster and more reliable.

How should I apply this guide in practice?

Pick one page, product, or routine and apply the steps there first. Note what changes, keep the change if the result improves, and only then roll the same pattern wider. Small verified changes beat a large unverified overhaul every time.

What should I check again later?

Recheck after any template, product, app, or routine change, and on a regular monthly rhythm in between. Conditions drift over time, so a dated check is what tells you whether a fix held or quietly broke again.