[webkit-dev] Exposing WebKit/Safari's unique full keyboard access setting to web applications

James Craig jcraig at apple.com
Mon May 12 18:44:02 PDT 2014


WebKit Dev,

Safari is unique among desktop browsers in that "full keyboard access" (FKA) is off by default, and the Tab key moves focus only to textfields and select elements. You can modify this behavior using a system-wide setting (System Prefs > Keyboard > Shortcuts > All Controls) and/or a Safari-specific setting (Safari > Prefs > Advanced > Press Tab to…). If you change both settings, you'll have a keyboard focus behavior that is similar to that of other desktop browsers, such that every "focusable" control appears in the sequential Tab order.

Many JavaScript UI libraries capture default Tab behavior for a variety of reasons, and maintain their own concept of a "first responder." In these cases, we need to expose the user's FKA setting so that keyboard behavior can be appropriately managed by web applicationk according to the user's expectations.

We've been discussing a number of solutions internally with WebKit engineers, and externally with other browser developers and standards bodies. One of the proposed solutions is to expose a new property and change event on the Navigator object:

> var fbSetting = navigator.webkitFocusBehavior;
> navigator.addEventListener("webkitfocusbehaviorchanged", handleFocusBehaviorChanged);


Another solution is to implement this as a vendor-prefixed key in the "userSetting" interface of the IndieUI User Content ED:
https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-context.html

> var fbSetting = window.userSetting("-webkit-focus-behavior");

> window.addSettingListener("-webkit-focus-behavior", handleFocusBehaviorChanged);


Despite this behavior being unique to Safari, we do not believe the setting is unique to WebKit or Safari, so either implementation may be proposed for standardization to the various W3C working groups. For example, "focus behavior" setting may be useful in mobile contexts, where the concept of "focus" is not necessarily related to a keyboard interface or the Tab key.

Are there objections to implementing either proposal behind a flag? Are there preferences for or comments on either approach?

Thanks,
James Craig



More information about the webkit-dev mailing list