778061 - Feature for ensuring there's a visible keyboard focus indicator

Status: NEW

(Core :: CSS Parsing and Computation, enhancement)

Description

[Henri Sivonen (:hsivonen) (on vacation)]

Steps to reproduce:
1) Browse the Web for a while without a pointing device.

Expected results:
Expected to be able to move focus through Web pages by pressing tab. Expected to be able to see visual indication of what is focused.

Actual results:
Very often, there is no visual indication of what is focused, because the page author has specified styles that remove the default focus outline without replacing it with some other indication.

Additional info:
Removing the default focus outline is quite common. This is probably because there are popular code samples to copy from that remove the default focus outline, for example http://meyerweb.com/eric/tools/css/reset/reset200802.css . I believe it would be an exercise in futility to try to locate and evangelize all Web sites that have copied this code and failed to manually re-introduce a focus indicator for focusable elements.

There are actually pages, though rare, that remove the the focus outline but still indicate focus in some legitimate way. A high-profile example is the top navigation bar at http://www.apple.com/ . Merely using the user style sheet to always force an outline of 1px would break clueful and visually pleasing custom focus indicators such as the solution seen on Apple's site.

Therefore, I suggest the following feature:
Add a preference worded something like "Display keyboard focus indicator even when the page author has removed it". Let the pref be off by default in order to avoid authors taking countermeasures. If the pref is on and an element gaining focus would not result in different painting given the data from the style system, paint the default focus outline for the element.

Comment 1

[Henri Sivonen (:hsivonen) (on vacation)]

Needed even for Mozilla’s own Web properties: bug 794419. :-(

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Things that make this sort of hard:
 (a) we coalesce style changes, which make it hard to tell what's the result of a change in focus vs. what's the result of other changes around the same time
 (b) the focus-dependent styling that we'd want to detect might be on the descendants of the element rather than the element itself
 (c) Hooking into what we already do for HasStateDependentStyle isn't going to work because it counts styles that are overridden.