Accessibility issues

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

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.

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

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.

Hi @titelala,

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

Kind regards, Kim

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 ??

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

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 !

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, 8 months ago by Aert Hulsebos.

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