Accessibility issues

Resolved Aline K.
(@titelala)

1 year, 6 months ago
Hi,

I just installed the “Complianz Cookie Consent” plugin – so far the best I’ve tested. Unfortunately, I noticed some accessibilty issues in the cookie banner. Since you claim that your plugin complies with WCAG 2.1, I can imagine that you will want to fix them:
1. The x button to close the cookie banner has no visual focus indicator – also, if possible a <button> element would be better for usability than a <div role="button">.
2. Focus should be trapped inside the modal window, so that users don’t tab outside of it while it is still visible. That means that after the last interactive element of the window (the ‘settings’ button or the document links), the focus should go back to the close button
3. In the “Cookie settings” window, the checkboxes #cmplz-statistics-optin and #cmplz-marketing-optin have no accessible name. They do have an explicit <label>, but the <span> inside has display:none which hides it also for screen readers. You need to use an accessible hiding method on the .screen-reader-text class instead of display:none. I would recommend this method: https://www.scottohara.me/blog/2017/04/14/inclusively-hidden.html#hiding-content-visually
4. The same labels have a tabindex="0", which makes them focusable. When I tab through the window, it creates a “blank” tab after the <input>.
5. In the same window, the <summary> elements have no visual focus indicator.
6. Interactive controls must not be nested, so <input type="checkbox"> should not be located inside <summary>. That create issues for screen reader users who might not be able to access the checkbox.
Let me know if you need more details ! I really hope that you will fix these issues in a future release 🙂
- This topic was modified 1 year, 6 months ago by Aline K..
The page I need help with: [log in to see the link]

Viewing 10 replies - 1 through 10 (of 10 total)

Plugin Contributor Aert Hulsebos
(@aahulsebos)

1 year, 6 months ago

Hi @titelala,

Let’s start with 1: The x button to close the cookie banner also has no visual focus indicator – also, a <button> element whould be better than a <div>.

Is this what you mean? https://snipboard.io/auRWXm.jpg

regards Aert

Thread Starter Aline K.
(@titelala)

1 year, 6 months ago

Hi @aahulsebos ,

Thank you for your quick answer ! Yes, that’s exactly what I’m talking about. A <button> element would have a default :focus outline defined by the browser, but this one is made with a <div> so we need to manually add the :focus / :focus-visible state styles.

Plugin Contributor Aert Hulsebos
(@aahulsebos)

1 year, 6 months ago

Hi @titelala,

In this case, I tabbed in Chrome to the X icon. Do you have an example where this is not the default?

regards Aert

Thread Starter Aline K.
(@titelala)

1 year, 6 months ago

Hi @aahulsebos,

My bad, it seems that my theme is responsible for that one – really sorry about that, I should have checked better. It looks fine with WP base themes. Same for point 5 about the :focus on the <summary> elements.

Kim van Dijk
(@kimvdijk)

1 year, 6 months ago

Hi @titelala,

No problem, good to hear it is solved! I will close the thread.

Kind regards, Kim

Thread Starter Aline K.
(@titelala)

1 year, 6 months ago

Hi @kimvdijk and @aahulsebos,

The 4 other issues in my initial message are not resolved (and the theme is not responsible for those ones, I checked twice 😅). In particular, points 3 and 6 are detected by automated accessibility testing tools and create non-compliance with WCAG:

In the “Cookie settings” window, the checkboxes #cmplz-statistics-optin and #cmplz-marketing-optin have no accessible name. They do have an explicit <label>, but the <span> inside has display:none which hides it also for screen readers.

=> https://dequeuniversity.com/rules/axe/4.6/label

Interactive controls must not be nested, so <input type="checkbox"> should not be located inside <summary>. That create issues for screen reader users who might not be able to access the checkbox.

=> https://dequeuniversity.com/rules/axe/4.6/nested-interactive

About point 2:

Focus should be trapped inside the modal window, so that users don’t tab outside of it while it is still visible. That means that after the last interactive element of the window (the ‘settings’ button or the document links), the focus should go back to the close button

When the cookie banner behaves as a modal dialog, it would be nice if it followed the WAI pattern: “TAB: If focus is on the last tabbable element inside the dialog, moves focus to the first tabbable element inside the dialog.”

=> https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/

Thank you in advance 😊

Plugin Contributor Aert Hulsebos
(@aahulsebos)

1 year, 6 months ago

Hi @titelala,

Still here:-) There’s a label;

<label class=”cmplz-label” for=”cmplz-statistics-optin” tabindex=”0″><span class=”screen-reader-text”>Statistics</span></label>

In HTML at least, but maybe it doesn’t work on the toggle? You can switch under setting to a default checkbox. Maybe this works?

regards Aert

Thread Starter Aline K.
(@titelala)

1 year, 6 months ago

Hi @aahulsebos ,

Yes the <label> is there in the HTML, but the <span> inside it has display:none in the CSS, which makes the label inaccessible (screen readers will ignore elements with display:none).

Here is a screenshot of the CSS in the browser dev tools:

This happens with the toggle and the regular checkbox. The .screen-reader-text class on the <span> already hides the text – while still keeping it accessible for screen readers.

I hope my explanation is clearer. Thank you !
Plugin Contributor Aert Hulsebos
(@aahulsebos)

1 year, 6 months ago
Hi @titelala,

Check, let me setup an example without display:none, and see if it’s true!

https://soxenomorph-zeyi.instawp.xyz/

regards Aert
- This reply was modified 1 year, 6 months ago by Aert Hulsebos.
Plugin Contributor Aert Hulsebos
(@aahulsebos)

1 year, 6 months ago

Hi @titelala,

regarding; `Focus should be trapped inside the modal window, so that users don’t tab outside of it while it is still visible. That means that after the last interactive element of the window (the ‘settings’ button or the document links), the focus should go back to the close button

When the cookie banner behaves as a modal dialog, it would be nice if it followed the WAI pattern: “TAB: If focus is on the last tabbable element inside the dialog, moves focus to the first tabbable element inside the dialog.”

=> https://www.w3.org/WAI/ARIA/apg/patterns/dialog-modal/`

I’m still unsure if a consent banner has the same urgency as a dialog, or alert modal.

Both the latter seem to interupt an action for confirmation, or extra help, a new step etc and focussing here would be logical.

A consent banner, is informative and the choices can be made later, or on the content blocks that need consent. In the example here; https://soxenomorph-zeyi.instawp.xyz/ there’s a mode where this happens automatically, if soft cookie wall is enabled.

regards Aert