Skip to content
This repository has been archived by the owner on Jun 30, 2018. It is now read-only.

Success Criterion 1.4.14 Content on Hover or Focus #350

Closed
GreggVan opened this issue Sep 1, 2017 · 5 comments · Fixed by #569
Closed

Success Criterion 1.4.14 Content on Hover or Focus #350

GreggVan opened this issue Sep 1, 2017 · 5 comments · Fixed by #569

Comments

@GreggVan
Copy link

GreggVan commented Sep 1, 2017

When content becomes visible when triggered by a user interface component receiving keyboard focus or pointer hover, the following are true, except where the visual presentation of the content is controlled by the user agent and is not modified by the author:

Visible trigger
Either the additional content does not obscure any essential content within the triggering user interface component, or the additional content can be closed or repositioned by the user.

Hover
If the additional content is triggered via pointer hover, then that content remains visible when the pointer is moved over it.

Focus
The additional content remains visible while the triggering user interface component has keyboard focus, unless the user dismisses the additional content.

NOTE
Examples of additional content controlled by the user agent include browser tooltips created through use of the HTML title attribute.

NOTE
Custom tooltips, sub-menus, and other nonmodal popups which display on hover and focus are examples of additional content covered by this criterion.

==================================================================
issue
You could satisfy the " visible trigger" provision by simply saying that the user can move off of the element. I don't believe that is the intent

POTENTIAL SOLUTION
add " without moving the focus or hover off of the trigger "to the end so that it reads

Visible trigger
Either the additional content does not obscure any essential content within the triggering user interface component, or the additional content can be closed or repositioned by the user without moving the focus or hover off of the triggering user interface element.

@steverep steverep self-assigned this Sep 6, 2017
@steverep
Copy link
Member

steverep commented Sep 6, 2017

You could satisfy the " visible trigger" provision by simply saying that the user can move off of the element. I don't believe that is the intent

The criterion is specific to only be applicable "when additional content becomes visible" in order to mitigate any claim like that. This can certainly be emphasized in Understanding so I'll make a note to do so.

@GreggVan
Copy link
Author

GreggVan commented Sep 6, 2017 via email

@steverep
Copy link
Member

steverep commented Sep 6, 2017

I did see your point, but I thought the criterion had it covered. On second thought, I agree with you. This is an artifact of adding the ability to close the content later on as satisfactory, which was not in the original language. The closing mechanism is meant to be an action without moving focus or pointer as you said, such as a button or pressing ESC. Thanks for catching this.

@steverep
Copy link
Member

@GreggVan, pending working group approval of pull request #569, the proposed new language should address your issue.

@GreggVan
Copy link
Author

GreggVan commented Dec 6, 2017 via email

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants