** The problem ** Many websites are not accessible for keyboard users because the focus is hidden. As soon as the user begins to tab through they are already lost. ** Examples ** - http://blackberry.com - http://www.apple.com/search/?q=iphone (search page) - http://www.microsoft.com/windowsphone/en-us/default.aspx (Microsoft's Windows Phone 7 page) - http://twitter.com (in the header) ** Background ** There are two main reasons that websites do this: 1. They use a standard reset.css which has :focus {outline: 0; } -- since many developers are primarily mouse users this can go unnoticed 2. The designer of the page does not like the focus outline to appear on buttons and links when a user simply clicks them (they don't mind the focus outline when the user tabs -- that's not the case they care about). (Note: IE (at least older versions) do not allow the focus outline to be hidden and don't show the problem.) ** Proposed solution ** When the focus was not set from the mouse (keyboard or via script), do not allow the focus outline to be hidden. Just because the author specifies something in CSS does not mean we have to adhere to it. There is a tradition of removing web usability problems such as popups, even when the author has coded the page to have them -- making the web not suck. We'll need to think slightly differently about :focus and how to make sure it's used as a good thing -- not making the web unusable for keyboard users. There is really no reason to hide the focus for someone trying to tab around. Some section 508 fodder if that helps: From http://section508.gov/index.cfm?fuseAction=stdsdoc (c) A well-defined on-screen indication of the current focus shall be provided that moves among interactive interface elements as the input focus changes.
A user can do that by specifying a custom stylesheet with !important rules in Safari preferences. Especially with forms, authors may add another indication of which input is focused while disabling built-in outline - showing both would be quite weird.
(In reply to comment #1) > A user can do that by specifying a custom stylesheet with !important rules in Safari preferences. This is extremely unlikely to ever happen. Users are not generally that sophisticated. Maybe 1/1000 people will create a custom stylesheet. I don't see the point in requiring programming skills for basics like showing keyboard users where they are. > Especially with forms, authors may add another indication of which input is focused while disabling built-in outline - showing both would be quite weird. If it is landed with it pref'd off by default, we can see how much of an issue it really is. Even if all we did was turn this on for the outline: 0 cases where there is no other rule for :focus, we'd be fixing the vast majority of the cases.
In fact, users with special accessibility needs use custom style sheets a lot. I don't really see a need for WebKit code changes here.
(In reply to comment #3) > In fact, users with special accessibility needs use custom style sheets a lot. Trying to find a diplomatic way to say that's unrealistic. If you research this you will find that those users are simply not having their needs served by this approach. Users with special needs, like everyone else, need things that "just work". Navigating by the keyboard is one of those things which should "just work".
Thought experiment. A usability test with 10 users (who already normally use the keyboard so know about tabbing). "Please navigate the Windows 7 phone page with the keyboard" 0/10 successes, with comments like "Oh, I don't know where I am" "Please find a setting to make your browser help you see where you are" 0/10 successes If you think in terms of user-centered design (not simply what's easiest/best to engineer) you will get optimal answers for the user experience.
I think Alexey is right that there isn't anything actionable here in WebKit. It sounds like your issue is that it should be easier for a user to prevent web page authors from hiding the focus outline. Each browser could implement that as a GUI user preference, but the implementation would likely still be a user style sheet. Unless there something like a W3C specification that is not being followed (even UAAG defaults to User CSS in this case), this bug isn't actionable for WebKit. You might try filing a bug enhancement request for Safari at bugreport.apple.com.