Fix ARIA semantics in detailed banner tabs and category labels
Iustin Diac
We identified two accessibility issues in the detailed CookieScript banner on:
Banner ID: 8451d44314159f788dc964e673f406ed
Reproduced on 24 October 2026 in anonymous Chrome 155 sessions, using desktop (1440×900) and mobile emulation (390×844). Lighthouse 13.4.1 was run in snapshot mode after opening the detailed panel.
- Missing presentation role on the tab list items
The generated structure is:
<ul role="tablist" class="cookiescript_fsd_tab">
<li class="cookiescript_fsd_tab_option">
<a role="tab" ...>Descriere</a>
</li>
...
</ul>
The intermediate <li> elements retain their implicit list-item semantics. Lighthouse reports:
- aria-required-children: the tab list.
- aria-required-parent: all three tabs.
- listitem: all three intermediate list items.
Proposed minimal correction: add role="presentation" to those three <li> elements, preserving the existing anchors, IDs, ARIA states, tabindex values and event handlers.
This matches the W3C example for tab lists:
- Missing text separator between category names and counts
For example, a category button has aria-label="Strict necesare (6)". Its child elements contain "Strict necesare" and "6", but there is no whitespace text node between them. Consequently, textContent becomes "Strict necesare6", although the two values are visually separated.
Lighthouse reports label-content-name-mismatch for the numbered categories: three on desktop and two in the visible mobile area.
Proposed minimal correction: insert a literal space between the category-title element and the count element, while retaining the existing accessible label and visual styling. Parentheses alone are not the issue: W3C guidance allows punctuation differences:
We have not demonstrated an actual voice-control failure; this is a reproducible automated mismatch with an identifiable text-spacing cause.
Keyboard navigation currently works in both tested layouts: Tab/Shift+Tab, arrow keys, Home/End, and Enter/Space for expanding and collapsing categories. Please preserve this behavior.
We have not applied either proposed correction. Could you confirm whether these changes can be made in the banner generator? The category content is rebuilt when switching tabs, so a generator-level fix would also cover subsequent renders.
Thank you.