Last updated on October 13, 2025
If you are anything like me, you don’t want your data sold to third parties. You probably run ad blockers. Maybe a VPN. Some governments are trying to help by requiring the site to declare what cookies are used and providing the user to opt out. But the current method of displaying this information tends to have some serious accessibility issues. I have another way of thinking about them I’d like to propose.
Now let’s establish first that there are accessible ways to make a cookie dialog work. As they are dialogs, when they render to the screen they need to alert the user to their presence. If they are modal, they must gain focus. However, cookie banners tend to load after the main content of the page. This causes some users to begin engaging in the page to only have their focus stolen and moved to a dialog they did not trigger. This action alone violates
- 1.3.2 Meaningful Sequence
- 2.4.3 Focus Order
- 3.2.1 On Focus
- And in most cases 4.1.3 Status Messages
If you follow Karl Groves, his company Afixt recently released a package on NPM that will create an accessible cookie dialog.
But I have a different thought on how they should be presented.
The <details> element
If you aren’t familiar with the <details> element, it is basically a no-JS accordion. I wrote a little on in my First Rule of ARIA post. When we add the the attribute of open, the accordion will be open to begin with. Hold that idea.
Most cookie dialogs load at the bottom of the page. We want this information to be told to the user as soon as possible. Well, that means it should probably be first in the reading order. This can eliminate the three major violations. We still want the “skip to content” link as our first focusable element. This is important depending on how the user decides to interact with the cookie information and that this would be on just about every page. Let’s see what this might look like:
<a href="#main" class="skipLink">Skip to Main</a>
<details open>
<summary>My site's cookie information</summary>
<p>My site has cookies. Eat 'em up! I only track how many people visit, where they visit, and what source sent them.</p>
<button>Stop Tracking</button>
</details>
[...] </body>
Proposed usage
If you can load the cookie data to render first, have the <details> set to be open. Then when the user comes to read the page, they will see the information right away.
If you can’t, have the details remained closed until it is loaded. We then send a status message that the cookie information is available. Let them navigate to it and open as they see fit.
Depending on what cookies you use and what options there are, you can modify it from here. For instance, if you use a cookie to track whether they want to allow 3rd-party cookies, you might have one that tells JS to hide the banner.
Thoughts? Let me know what you think on LinkedIn or BlueSky.
Update 10/13/2025: I do realize the irony.
If you are reading this and have visited my site before, you might see a difference. Including a cookie banner! Currently it is in the default settings, but I mean to explore implementing it as a <details> element. It was enough work this week to get the hosting transferred new theme up and add the banner.