Should you use CSS to fix the position of cookie consent banners and other elements? Here’s what designers should know.
Many websites use CSS to position elements in a set place relative to the user’s screen. For example, if you’ve got a table of contents on a long page, you might make a fixed menu that stays in place as the user scrolls.
That would improve usability for many readers. But fixing the position of elements isn’t always helpful, particularly for people who use assistive technologies.
Setting the CSS position property to fixed will ensure that the element is positioned relative to the viewport. Setting the value to sticky will position the element based on the user’s scroll position.
In other words, a sticky element will toggle between relative and fixed positions. It’s relative until the user’s viewport reaches a certain offset position, at which point it “sticks" in place and becomes fixed.
In either case, we’re eventually fixing an element’s position relative to the viewport. There are practical reasons to do this. For example, if the content is part of a step-by-step process, you’ve got a great reason to include navigation components and keep them in the same position throughout the process.
Before changing the position of elements, though, you’ll need to ask questions:
By default, elements are static: They’re positioned by the normal flow of the page, and their position doesn’t change as the user scrolls.
That is predictable behavior, and you generally don’t want to make your content operate in an unpredictable way. If you’re altering the position of an element, you want to be absolutely sure that doing so will improve the user experience. You also want the element to work the same way for every user, regardless of their abilities or the technologies they use.
Related: How CSS Benefits Accessibility
So, how could non-static elements impact actual users?
If you’re browsing the web with a keyboard alone (no mouse), focusable elements are extremely important. Sticky or fixed elements may prevent you from identifying the element that is currently receiving keyboard focus, which could make navigation difficult.
The Web Content Accessibility Guidelines (WCAG) addresses this scenario in WCAG 2.2 Success Criterion (SC) 2.4.12, “Focus Not Obscured (Minimum),” that seems to directly address fixed and sticky content:
You might fail this criterion if certain fixed content obscures the user’s keyboard focus. For example, if you use a cookie consent banner, the banner might appear in front of a focusable element — that’s bad news for accessibility.
Non-static elements may also create accessibility issues for people who magnify their screens. That’s particularly true for sticky elements, which might become unpredictable for devices with limited viewports (including magnified web browsers).
Related: Tips for Meeting WCAG 2.2's "Focus Not Obscured" Success Criteria
As is often the case, thoughtful CSS can help with WCAG conformance. The CSS padding and scroll-padding properties can be used to prevent fixed elements from obscuring focus. Review this WCAG technique page to learn how to use these properties.
However, it’s important to remember that some visitors ignore aspects of CSS, particularly if they’re using assistive technology. You’ll still need to establish an appropriate accessibility tree for the sticky/fixed content, and you’ll need to consider how the elements will appear to non-visual users and other folks with disabilities.
By testing your website against WCAG — and thinking carefully before fixing the position of elements relative to the viewport — you can ensure that your content works for as many people as possible.
For guidance with a specific CSS issue, send us a message to connect with an accessibility expert.