Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

2.4.7 limits focus visible to keyboard. 1.4.11 doesn't appear to have the same limitation #1401

Closed
DavidMacDonald opened this issue Sep 11, 2020 · 9 comments

Comments

@DavidMacDonald
Copy link
Contributor

DavidMacDonald commented Sep 11, 2020

Designers want to remove the visible focus because they don't like the way it looks during mouse use. Historically our requirements have been for keyboard users, because when using a mouse the user can put the focus wherever they click. Its set by the pointer, so it's not the same problem.

One dev asked about the :focus-visible pseudoclass, to limit the focus ring visibility to keyboard users. He says there’s a polyfill to make it work with Safari and IE.

Under 2.4.7 this would be OK,because it says "keyboard focus indicator..."
The new focus visible for 2.2 SC 2.4.11 also limits focus requirements keyboard users.

1.4.11 is grey because there is no limitation to keyboard, even though I believe that is the intention of the group with 1.4.11. I suggest we amend the understanding of 1.4.11

Active User Interface Components
For active controls any visual information provided that is necessary for a user to identify that a control is present and how to operate it must have a minimum 3:1 contrast ratio with the adjacent colors. Also, any visual information necessary to indicate state, such as whether a component is selected [remove] or focused [/remove] must also ensure that the information used to identify the control in that state has a minimum 3:1 contrast ratio. [add]The keyboard focus indicator should also have a minimum contrast ratio of 3:1 [/add]

@patrickhlauke
Copy link
Member

patrickhlauke commented Sep 11, 2020

i assume for 1.4.11 you refer to this "Visual information required to identify user interface components and states". i'd say the argument here would hinge on "if i click on a control with a mouse, do i as a user need to 'identify' that this now has the focus?" - and i'd argue that no, i don't need to, so then there's also no explicit requirement on the author of making that visual information clear.

i raised the quirk about :focus-visible a few times in the past, btw. see for instance #1001 (comment)

wonder if it's worth adding an explicit focus indicator requirement to 1.4.11, when there's now going to be already other much more specific focus visible SCs...too much overlap in the end?

@DavidMacDonald
Copy link
Contributor Author

@DavidMacDonald
Copy link
Contributor Author

@patrickhlauke
I think of it more of "limiting" the requirement to keyboard rather than letting it spill over to mouse use. I think this was our intention with the SC.

@patrickhlauke
Copy link
Member

instead of adding the whole sentence about keyboard focus and contrast requirement again, how about just changing "focused" to "has keyboard focus".

... such as whether a component is selected or [remove]focused[/remove] [add]**has keyboard focus**[/add] must...

@DavidMacDonald
Copy link
Contributor Author

sure!

@DavidMacDonald
Copy link
Contributor Author

nice!

@alastc
Copy link
Contributor

alastc commented Oct 21, 2020

We'll be looking at the re-write in #1403 soon, which starts "When user interface components receive keyboard focus", so I think it addresses this concern for Focus Appearance.

For non-text contrast, I'd rather leave 2.1 as-is but separate them better in 2.2.

I.e. remove any focus aspects from 1.4.11.

@alastc
Copy link
Contributor

alastc commented Oct 29, 2020

I think #1490 covers this now?

@alastc
Copy link
Contributor

alastc commented Jan 7, 2021

The SC now starts:

When user interface components receive keyboard focus

So closing this issue.

@alastc alastc closed this as completed Jan 7, 2021
WCAG 2.2 automation moved this from To do to Done Jan 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
WCAG 2.2
  
Done
Development

No branches or pull requests

3 participants