A partial archive of discourse.wicg.io as of Saturday February 24, 2024.

Reworking keyboard navigation styling (standardizing focus rings)

stuartpb
2015-09-19

Continuing the discussion from Exposing a user's input modality:

Thinking about the focus ring problem (the main problem case being discussed in the linked thread) a little more, I think the right solution (ie. rather than adding facilities for page authors to potentially do it better, doing it better at the browser level for everybody) should involve two things:

  • Adding a pseudo-element for styling the focus ring, which would replace any of the current, element-based, oft-mistakenly-normalized styles for denoting focus during keyboard navigation.
    • This focus ring pseudo-element would not collide with or be overridden by styles on the parent element, the way pseudo-selector states like :focus are (the notorious "don’t set outline: 0" problem).
    • This makes it easier to set an alternative style for the focus ring across the entire page, ie. giving it a better-contrasting color to the page’s background)
    • If an element is meant to have a focus style that really should override focus rings (and not merely an inconsistency that harms usability), the focus ring can be explicitly hidden for that element.
  • Only displaying the focus ring when interacting via keyboard-like mechanisms, which would be hidden (like any other accessibility UI element) when not navigating via focus-based interaction.
    • Pseudo-selectors like :focus could also be ignored when not interacting with the page via a modality where focus is meaningful (thus avoiding Button Focus Hell). This appears to be the way that Firefox already works.
stuartpb
2015-09-30

Link to discussion of focus-ring as a pseudo-element.