Feature requests

I’d like to suggest a feature enhancement for the cookie consent interface. Would it be possible to make the "Manage Cookies" option a visible button, ideally placed next to the "Accept All" button? This would allow for more flexibility in the layout—for example, enabling the option to remove the "Decline All" button if desired, while still offering users a clear path to customise their preferences. I’ve attached a screenshot to illustrate the kind of layout I am describing.

The misconfiguration errrors I'm seeing are from a Vercel staging environment where they inject a session id and another application cookie all on their own into the build process outside of the consent trigger - that won't be there in production. So it might be a good idea to add an exception to the error handling for websites that are in Vercel hosted staging environments since we have zero control over the cookies they're setting in those lower level environments.

When the "Show details" button is activated, a container appears with two tabs, "Cookie statement" and "More information about cookies." While it’s visually clear which tab is active, this is not conveyed in the code for assistive technologies. Recommendation: Implement the ARIA tablist pattern with correct roles (tablist, tab, tabpanel) and dynamically update states to indicate the active tab, as outlined here: https://www.w3.org/WAI/ARIA/apg/patterns/tabs/

Our new service focusses on Digital Accessibility and, as you can imagine, accessibility is very important to us. I have noticed the Cookie Script modal does not have a focus trap. Although the tabindex="0" attribute moves focus to the modal (when tabbing, but better if focus was automatically applied), if you continue to tab through the elements you eventually leave the modal panel. Do you think you would consider adding a focus trap for improved a11y?

In the cookie banner checkboxes like "Analytical cookies" and "Marketing cookies" have no visible focus indicator when navigated via keyboard. This makes it unclear which element has focus. Recommendation: Add a clear, visible focus indicator with sufficient contrast (at least 3:1) to all focusable elements such as checkboxes.

Before expanding "Show details," some interactive elements that are visually hidden immediately after it can still receive keyboard focus, leading to confusion for keyboard and screen reader users. Recommendation: Ensure visually hidden elements are also removed from the keyboard tab order, for example by using display: none instead of just visually hiding them.

The cookie banner displays inside a modal, but keyboard focus can move beyond the modal to interactive elements on the page behind it, which are visually obscured. This breaks logical keyboard navigation. Recommendation: Implement a focus trap within the modal so keyboard navigation is contained until the modal is closed.

Within the "Cookie statement" tab, there are three buttons: "Necessary cookies," "Analytical cookies," and "Marketing cookies." Although visually clear which is active, this information is not programmatically exposed to assistive technologies. Recommendation: Implement the ARIA tablist pattern with correct roles (tablist, tab, tabpanel) and dynamically update states to indicate the active tab, as outlined here: https://www.w3.org/WAI/ARIA/apg/patterns/tabs/

on pagespeed.web.dev cookiescript lowers my pagescore as it tells me Avoid serving legacy JavaScript to modern browsers and Legacy JavaScript. Would be great to have this fixed thanks