Closed jyasskin closed 2 years ago
See also :focus-visible
:
https://github.com/WICG/focus-visible/blob/master/explainer.md
https://drafts.csswg.org/selectors-4/#the-focus-visible-pseudo
I think these things could probably work together.
Probably needs to be limited to outline rules w/ :focus pseudo-class (if this is even a good idea; not sure).
:focus-visible: seems like probably a more reliable approach, but it requires adoption, the name is potentially confusing, and the explainer version at least has the problem of introducing circular dependencies into style resolution (because the resolution of selectors containing the :focus-visible: pseudo-class depends on computed value of a style property). CSS WG tends to hate this.
Update: the CSS WG draft doesn't have this problem at the cost of not having a customizability hook.
I'd really appreciate this change as a user who often relies on keyboard navigation. I sometimes rely on non-standard "reader modes", user stylesheets, or disabling CSS altogether as workarounds.
Moved to https://github.com/w3c/csswg-drafts/issues/7321 so that the right working group can consider this idea.
[Note that this is not well thought-out yet.]
A search for "outline accessibility" reveals a long history of accessibility advocates trying to convince web developers not to remove outlines from focused elements. Clearly this advocacy has not been effective. Instead, browsers should ignore CSS rules that remove the focus outline when the user is known to navigate using the keyboard.
The use of the
tab
key on a page is probably a good indication of the need to show focus indicators. Generating the accessibility tree might be another indication.