Bottom pop-up drawers are everywhere. Cookie notices. Chat widgets. “Need help?” prompts. They slide up from the bottom of the page and seem harmless enough.
Until they’re not.
If your drawer appears on scroll, covers part of the footer, and forces users to close it before they can continue, you may be violating several WCAG requirements — even if keyboard focus technically behaves “correctly.”
Let’s unpack why.
The Scenario
Here’s the behavior we’re looking at:
- A drawer appears automatically when the user scrolls.
- It attaches to the bottom of the page.
- It covers part of the footer until closed.
- Keyboard focus moves into the drawer.
- Focus returns to the next logical element when the drawer is closed.
On paper, that might sound reasonable. In practice, it can still create real accessibility barriers.
The Biggest Issue: Focus That Gets Hidden
WCAG 2.4.11 — Focus Not Obscured (Minimum) (Level AA)
This is the most direct and serious problem.
WCAG requires that when something receives keyboard focus, users must be able to see it. If a bottom drawer covers footer links or buttons, those elements may still receive focus — but users can’t see where they landed.
For a keyboard user, this feels like the page suddenly stops making sense. Focus moves, but there’s no visible cue telling them where they are.
If your drawer hides even part of a focused element, that’s a failure of 2.4.11. If it completely hides it, it also fails the enhanced version, 2.4.12 (Level AAA).
Key takeaway:
If focus can land behind your drawer, the drawer is too intrusive.
Automatic UI That Gets in the Way
WCAG 1.4.13 — Content on Hover or Focus (Level AA)
This success criterion isn’t just about hover tooltips. It also applies to content that appears automatically and blocks other content.
When a drawer appears on scroll without a clear user request, it becomes a problem if:
- It obscures existing content.
- Users must dismiss it before continuing.
- It interrupts normal interaction with the page.
WCAG expects this kind of content to be dismissible, persistent while interacting, and non-blocking. A drawer that forces itself into the experience and covers the footer struggles to meet those expectations.
Unexpected Changes in Context
WCAG 3.2.1 — On Focus (Level A)
Users should not experience major changes just because focus moved.
If the drawer appears and steals focus without a clear user action, that’s a context change the user didn’t ask for. Even if focus handling is technically correct, the timing matters.
Good rule of thumb:
If a component feels surprising to a sighted keyboard user, it’s probably violating 3.2.1.
Focus Order Can Still Be Fragile
WCAG 2.4.3 — Focus Order (Level A)
You mentioned that focus returns to the next logical element after closing the drawer, which is good. But bottom drawers often introduce subtle focus order problems:
- The drawer appears late visually but early in the DOM.
- Focus jumps in a way that doesn’t match reading order.
- Focus skips content that was visually below the drawer.
Even small inconsistencies here can disorient users relying on keyboards or screen readers.
Reflow and Zoom Issues Are Often Overlooked
WCAG 1.4.10 — Reflow (Level AA)
This one shows up during testing at 200–400% zoom.
A drawer that barely covers the footer at normal zoom may completely block it when zoomed in or viewed on a small screen. If users can’t access footer content without dismissing the drawer, that’s a reflow failure.
Reminder:
Reflow is not just about layout — it’s about access.
Supporting Criteria That Often Get Missed
Depending on implementation, these may also apply:
- 2.4.7 — Focus Visible (AA)
Focus indicators must remain visible inside the drawer and on the page behind it. - 2.1.1 — Keyboard (A)
All drawer actions must be keyboard accessible, including closing it. Bonus points for supporting the Escape key. - 1.1.1 — Non-text Content (A)
If the close button is just an “X” icon, it still needs an accessible name like “Close drawer.” - 4.1.2 — Name, Role, Value (A)
Screen readers need to understand what the drawer is. Is it a dialog? A complementary region? That choice matters.
The Core Problem Isn’t the Drawer — It’s the Overlay
Bottom drawers aren’t inherently inaccessible. The problem usually comes down to this:
They cover content instead of making room for it.
Accessible drawers tend to:
- Be opened by an explicit user action.
- Push page content up instead of sitting on top of it.
- Never hide focused elements.
- Clearly announce themselves without hijacking the experience.
Inaccessible drawers tend to:
- Appear automatically.
- Cover footers and navigation.
- Force users to dismiss them before continuing.
- Hide focus and confuse keyboard users.
Final Thought
If someone has to close your UI just to use the page, that UI needs another look.
A good accessibility test is simple:
Can a keyboard user reach and see everything on the page without fighting your design?
If the answer is no, WCAG agrees with them.
InHouse Inclusive 
Leave a comment