Accessibility Shortfalls in the Cookie Banner
-
Hi,
First I wanted to say thank you for providing such as thorough wizard. It educated me with questions that I didn’t know I needed to consider.
For that reason I want to use your plugin, but I also have to consider how it’s usable for all of my users including those with disabilities.
I noticed a few problems that should be addressed. I’ll list them below and provide references to WCAG Success Criteria (SC) so that the evidence for these issues is clear.
#1 Missing HTML Headings
This fails SC 1.3.1 Info & Relationship for visually conveying structure that is not programmatically perceivable to other users.The “Text on the manage consent tab” setting is used to add text that summarises the consent banner information. For instance, adding “Manage consent” then adds visually boldened text at the top of the source order, summarising the following paragraph and call to action controls.
While sighted users can perceive the heading, blind screen reader users do not receive that structure. In addition, screen reader users cannot reach the banner through the Heading Navigational shortcuts available to them.
To resolve this, we should implement a HTML Level 2 heading around the text. If we want to achieve a smaller font size, we can do so via CSS that either comes with the plugin itself or the “Use Custom CSS” option.
#2 Checkbox Is Not Named
This fails SC 4.1.2 Name, Role, Value for missing an accessible name.
When viewing preferences within the banner, a checkbox is present inside each applicable consent category, for instance, “Statistics” has a checkbox. Beside the checkbox is a visual label “Statistics”, but this is not programmatically associated. As a result, the checkbox is missing an accessible name.
Screen reader users are not told what is being expected of them when reaching the control. In addition, Voice Control users cannot navigate to the control using direct commands.
Use aria-labelledby to programmatically associate the label (e.g. “Statistics”) with the checkbox for each category.
Simplified example:
<span id=”checkbox1-name”> Statistics </span>
<input type=”checkbox” aria-labelledby=”checkbox1-name”>
-
I’ve re-reviewed issue #1 in light of this being a modal dialog, and I don’t think it’s much of an issue.
It’s true that it should be a HTML heading, but the modal dialog is already named by the same text via
aria-labelledby. This does the job of summarising the content for screen reader users.In addition, their heading navigation shortcut isn’t that applicable here, as the only content available is one section inside of a modal dialog. There is no other content to skip over.
However, issue #2 is something real and quite important. It’s going to make using the main purpose of the plugin difficult for some people with disabilities.
An update for issue #2.
I understand what’s going on now. The underlying issue is due to a somewhat incorrect implementation of the
<label>element.While the
<label>element is meant to programmatically associate labels with form fields, it’s intended for visible labels.In addition, something I hadn’t spotted earlier but is also problematic, the
<label>has atabindex="0"attribute. That’s not right or needed because the<label>interaction is redundant. The only interaction a keyboard user should experience in the context of a form control is on the control itself.Considering this, I recommend two options:
Option A: remove the<label>and usearia-labelledbywith the pre-existing category text.Option B: If that isn’t possible, remove the
tabindex="0"attribute on the<label>and then replacedisplay: noneCSS styles on the inner contents of the<label>withvisually-hiddenstyles.
Option B HTML example<label for="..."> <span> ... </span> </label>Option B CSS example:
.cmplz-cookiebanner .cmplz-categories .cmplz-category .cmplz-category-header .cmplz-banner-checkbox label > span {
clip-path: inset(50%);
height: 1px;
overflow: hidden;
position: absolute;
white-space: nowrap;
width: 1px;
}Hello @anevins ,
Thank you for reaching out and for the detailed points, they’re very helpful :).We’re currently working on several accessibility-related improvements, and some of the issues that our community helped point out have already been fixed and are ready to be included in the next release. We’re just wrapping things up to make sure we don’t miss anything related to accessibility moving forward. You can find a summary of our efforts on this page: https://complianz.io/accessibility.
If you’d like, you’re welcome to submit your suggestions and fixes via GitHub. In any case, no worries! I’ve already submitted everything to the team for a thorough review.
Thank you again for your feedback!
Best regards,
Antonio
You must be logged in to reply to this topic.
