Sanity check focusable items under cookie notification 2.4.11 Focus Appearance (Minimum)

[jake-abma]

Sanity check focusable items under cookie notification 2.4.11 Focus Appearance (Minimum)

When a focusable item is under a (semi transparant) cookie notification (laying on top of, and at the bottom of a page), will this fail this SC?

In this case they are "completely hidden / behind the notification (like lot's of footer links)

[mraccess77]

If the control behind receives focus and it's totally obscured then it seems to fail the proposed wording of SC 2.4.11. I personally likely also say it fails 2.4.7.

[jake-abma]

Thx @mraccess77 that is my impression too!

This will be of huge impact though I think as lots of sites have this, encountered it twice today when asked for a quick scan. Expect lots of pushback when really out there...

Do we need / want to also mention this specifically? Provide options for this? Examples?

They are often pretty much "in the face" and will not go away until a choice is made / even a required mandatory thing.

[jake-abma]

(and I did not even start the focus order thingy... :-) )

[jake-abma]

Luckily we have an example in the Deque Demo pages too: https://dequeuniversity.com/demo/dream if we want to discuss it / provide an example

[patrickhlauke]

once behind a semi-transparent overlay, i'd assume (beyond failing focus order) these focus indicators will also fail contrast in general (as they'll appear dimmed, against a dimmed background)

[alastc]

They are often pretty much "in the face" and will not go away until a choice is made / even a required mandatory thing.

In which case, they should be top of the source order and keep the focus inside the cookie thing until dismissed in some way.

The other solutions are to use scroll-padding so that the focus indicator doesn't go behind the banner, or make the banner inline (like gov.uk) so that it is not an overlay.

If the banner were semi-transparent and you could see the element & indicator somewhat, then I think it would pass 2.4.7 and 2.4.11, but fail the AAA version of focus-appearance.

[mraccess77]

The cookie notice should only restrict focus if the mouse user is also restricted. I don't think we should restrict keyboard users to accept the cookie if mouse users aren't forced to accept it.

[patrickhlauke]

Exactly. most cookie banners (as opposed to full-blown cookie dialogs) are non-modal, so should not trap focus. but be the first stuff that gets focus so they're not "missed" (IANAL but i'd argue that the cookie stuff needs to be prominent to "count" under cookie legislation)

On 26 Aug 2021, at 13:49, Jonathan Avila @.***> wrote:

 The cookie notice should only restrict focus if the mouse user is also restricted. I don't think we should restrict keyboard users to accept the cookie if mouse users aren't forced to accept it.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[detlevhfischer]

Agree that keyboard focus should go to the cookie banner first but would you see a FAIL of 1.3.2 Meaningful Sequence if the banner is still at the end of the source code (so SR users in read mode may be unimpeded by it and get to it at the end of the page)?

[mraccess77]

If the focus and reading order are out of sync in this case it does seem like a fail. But would we fail all sites that have a cookie with focus and reading order at the end of the page if it's passive? I don't know - that seems outside of current guidelines. I'm thinking it could be solved by an in-page link at the top that would take the user to the bottom and let them know about the notice.

[mraccess77]

@patrickhlauke so I think we are talking about 2 things - WCAG conformance and conformance to privacy laws - there may be some difference in terms.

[alastc]

most cookie banners (as opposed to full-blown cookie dialogs) are non-modal, so should not trap focus.

Agree, but I have come across quite a few which are modal, and I got that impression from Jake's description.

[patrickhlauke]

you could see the cookie banner as a form of notification, so not having it at the start of the reading order may open up other potential failures. but yes it'd not be a completely cut-and-dry reading order fail, normatively (unless you argue that the cookie banner is so important that logically it MUST come before the rest of the page content, since the user - from a privacy law POV - must give consent before any further interaction with the page/site)

[jake-abma]

check test page: https://new.ingwb.com/

Notification first in DOM, optional choice

• Focus indicators behind notification in footer
• Focus direct in notification but at bottom
• Zoom 200% / 400% / Landscape on mobile => blocking big parts of page

[jake-abma]

relates to: #2016

[alastc]

check test page: https://new.ingwb.com/

I'd say that's a good case for adding scroll-padding to the bottom, which is removed when the cookie banner is removed.

Given that it is slightly transparent, it probably passes 2.4.7.

If it were not transparent, it would fail 2.4.7 & focus-appearance.

I guess the question is whether we should apply the change-of-contrast check for 'under' the cookie banner?

My first thought is no, check the declared styles, if they pass then it passes those bullets. So it could pass focus-appearance min but not the AAA enhanced version.

[mraccess77]

It is one thing if a focus indicator is semi-transparent temporarily - but if the semi-transparency can not be changed to show the intended CSS values by shifting focus then my personal opinion is that the visually rendered version colors should be tested for SCs related to focus and non-text contrast.

[alastc]

@mraccess77 no disagreement, I was assuming that the usual case (once the cookie banner is closed), that you'd get the declared styles.

@jake-abma can we close this? I'm not seeing an update to make.