Tech failure hover focus content not dismissable

[detlevhfischer]

The Rawgit version is here:
https://rawgit.com/w3c/wcag/tech-failure-hover-focus-content-not-dismissable/techniques/failures/tech-failure-hover-focus-content-not-dismissible.html

The questions I have around Techniques for 1.4.13 relate mostly to the aspect of "dismissible". Apart from implementing ESC to close hover / focus content, are there other conceivable ways of dismissing content without moving focus? Has anyone seen other documented keyboard commands in the wild? Presumably documentation would need to be included in the popup? Would that mean that such documentation would need to be fully accessible / key-focusable OR spoken via aria-live? Would it be enough to document commands for dismissing content generically somewhere else on a site? And outside keyboard shortcuts: While technically feasible, would or should activating the very trigger that brought up the popup content when it was focused be mentioned as an option for dismissal, implictly recommending it by appearing in Techniques? It seems counter-intuitive to dismiss something with activation that came up on focus/hover...

[detlevhfischer]

Understanding text for 1.4.13 has "Provide a mechanism to easily dismiss the additional content, such as by pressing Escape or selecting a close button." Would not providing a separate close button violate the requirement that focus remains on the trigger?

[alastc]

Hi Detlev,

I've had a change to review, my t'pence on your questions:

Apart from implementing ESC to close hover / focus content, are there other conceivable ways of dismissing content without moving focus?

I assume that (if you are in the mouse-hover condition) you could click to close? I.e. it pops up on hover, but closes onclick. Only viable if there is no other action assocated with the trigger element.

Has anyone seen other documented keyboard commands in the wild?

Nope, but I can see how an intranet application or other closed ecosystem app might want to take a different approach, so I'm happy to leave that option there.

Presumably documentation would need to be included in the popup? Would that mean that such documentation would need to be fully accessible / key-focusable OR spoken via aria-live?

I'm not aware that we have required documentation normatively. It is ok to suggest it should be documented, but I wouldn't got to hard on that.

And outside keyboard shortcuts: While technically feasible, would or should activating the very trigger that brought up the popup content when it was focused be mentioned as an option for dismissal, implictly recommending it by appearing in Techniques? It seems counter-intuitive to dismiss something with activation that came up on focus/hover...

Indeed, it is not very intuitive, but then this SC is about limiting the damage that this approach does.

For the purpose of this failure technique I wouldn't get stuck trying to think of everything, just focus on the failure scenario.

Understanding text for 1.4.13 has "Provide a mechanism to easily dismiss the additional content, such as by pressing Escape or selecting a close button." Would not providing a separate close button violate the requirement that focus remains on the trigger?

You could hover over a reasonably large element, the new content appears, as does an [x] in the corner of the trigger. You could then maintain hover over the trigger and select the close button.

It doesn't work (well) for the focus scenario, but for hover it's fine.

[mraccess77]

It seems like content that appears on focus could be dismissable by toggle which could allow this to be met without moving focus. For example, tab to something that causes additional content to appear -- but you can press enter on the element (e.g. button) to dismiss the additional content if you want. Admittedly this won't work for all situations where additional content appears as enter may be used for other actions such as going to a shopping cart. As pointed out another shortcut key could be used other than escape if accessibility supported.

[detlevhfischer]

Presumably documentation would need to be included in the popup? Would that mean that such documentation would need to be fully accessible / key-focusable OR spoken via aria-live?

I'm not aware that we have required documentation normatively. It is ok to suggest it should be documented, but I wouldn't got to hard on that.

@alastc what I meant is include something like "ESC closes the popup" (or any other kb shortcut) in the poup. I think that is an option for closing dialogs via kb commands ifd they are documented if there are no controls, so this was modelled on that case.

[alastc]

A failure technique has to be a clear failure, I think talking about documentation makes it less clear.

It is definately a failure if there isn't a way, but it isn't as clear to say it is not documented.

[detlevhfischer]

I'd say if there is a keybpard command but it isn't an obvious choice like ESC, but rather something like ALT + SHIFT + C, then it would need to be documented in the pop-up content OR it would be a clear FAIL.
The precedent of a similar situation is in G21: Ensuring that users are not trapped in content

If keyboard focus appears to be trapped in any of the content, check that help information is available explaining how to exit the content and can be accessed via the keyboard.

NOT covering documentation leaves a gray area both for authors and testers - is it a PASS if I use a weird kb shortcut (so it is technically possible to close hover/focus content) if there is no way to know? For testers it is similar - they'd need to work out if there are any kb event handlers for closing in some script. Much easier to test when the requirement is clear that anything other than ESC needs to be documented in situ (in the popup content). Failing that, I think 'dismissable' would be a sham.

[alastc]

The SC text for keyboard trap includes:

if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.

So G21 can include part 3 of the procedure which says "check that help information is available explaining how to..."

I think audio-control is a close parallel, so F23 is a good example to follow.

In practice I don't think it will make much difference, if you are testing an interface and there is no clear way of dismissing the content, you'll fail it.

[alastc]

(My approach to dealing with developers who say "but there is a method, it's documented over here..." doesn't work for everyone. I raise an eyebrow and start quoting Douglas Adams.)

[detlevhfischer]

Slightly edited the examples to make them easier to read (and corrected the broken links on the WCAG 2.1 Techniques page).

[alastc]

Thanks @detlevhfischer, I've done a couple of little updates for structure (matching previous F techniques) and standardising on "popup" rather than "pop-up", as per the understanding doc.

[alastc]

From the discussion on the last call, this was going to be converted to a sufficient technique instead (in this issue), so closing.