Does 2.4.12 Focus not obscured encourage a keyboard anti-pattern

[WilcoFiers]

In yesterday's AGWG call the group seems to have decided against adding an exception to SC 2.4.12 Focus not obscured regarding things like cookie popups which can be closed. I raised this last week on the cal too, but I think it's worth repeating.

In my opinion one of the easiest way to solve a SC 2.4.12 Focus not obscured violation with something like a cookie popup is to trap the keyboard focus in the popup, and force keyboard users to deal with the cookie popup before allowing them access to the rest of the content. You can do that without blocking the page for mouse / touch screen users.

It was suggested that this may be a violation of SC 2.1.1 Keyboard. That feels like stretching the meaning of 2.1.1 a bit. Especially if closing the cookie popup is a single-button action. What it does create is a very confusing experience for screen reader users. They'll be able to read the page with the virtual cursor, but the actual keyboard focus will be stuck in the cookie popup.

Just having an exception for things that can be closed would have given an easy "out" for these popups. I appreciate why AGWG didn't want to go with that solution. An exception for this is not ideal, but then I do think something is needed to discourage trapping the keyboard focus to solve for SC 2.4.12 Focus not obscured

[alastc]

force keyboard users to deal with the cookie popup before allowing them access to the rest of the content. You can do that without blocking the page for mouse / touch screen users.

In which case that content isn't available via the keyboard when it is for pointer users, therefore a 2.1.1 issue.

What it does create is a very confusing experience for screen reader users. They'll be able to read the page with the virtual cursor, but the actual keyboard focus will be stuck in the cookie popup.

That sounds like many modals which are almost right but don't work to lock access to the modal. I think we usually fail that aspect under 1.3.1 as the main content area is dimmed, but that isn't programmatically available to AT. Why is this type of modal different?

I'm not seeing how this SC is an incentive to create poor cookie banners (which generally fail many SCs anyway), and if it did, I don't see that creating an exception would help...

Adding 'duplicate' tag, I think this duplicates #2551. As that is closed I'll leave this open, but the history is there.

[alastc]

Notes from the issues meeting:

• It is an in-equitable experience.
• Unfortunately the negative scenario Wilco outlined probably doesn't fail 2.1.1 (or 2.1.2).
• There are good implementations, both modal and not (see iicsa.org.uk, gov.uk).
• We should add positive examples to the understanding document, which is our main place to influence people implementing this SC.
• We should consider the concepts of "equivalent facilitation" and "inequitable experiences" for WCAG 3 (e.g. the various ways that people can be disadvantaged without failing specific criteria.)
• If we add an exception along the lines of "anything dismissible is exempt", that would be a large loophole in this SC.

There is already text in the understanding doc which says:
"Ways of passing include making the banner modal so the user has to dismiss the banner before navigating through the page, or using scroll padding so the banner does not overlap other content."

Perhaps we could add a couple of (positive) examples in the examples section?

[bruce-usab]

I plan to propose update Understanding in the next few days to emphasize -- without out mentioning antipattern as a terrible way to meet. Probably.

[fstrr]

I've got a proposed technique for this for Focus Appearance as pull request. See: PR 2746 and also this rawgit preview. Note that that example uses the HTML non-modal dialog—here's the same thing but as an HTML modal dialog.

[alastc]

From the meeting today, need another PR to close the issue.

[PHL: corrected the empty link there]

[alastc]

@bruce-usab I've assigned this to you as you said you'd update the understanding doc.

[bruce-usab]

PR includes items from this thread excep:

We should consider the concepts of "equivalent facilitation" and "inequitable experiences" for WCAG 3 (e.g. the various ways that people can be disadvantaged without failing specific criteria.)

There was already a branch including @fstrr new technique.

Almost the entire Understanding (Minimum) is applicable to Understanding (Enhanced). So should it be copied over?

• Second paragraph of Intent would be a little different.
• The failure would be adjusted a little.