- From: Maciej Stachowiak <mjs@apple.com>
- Date: Thu, 23 Dec 2010 02:26:16 -0700
- To: Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com>
- Cc: Steve Faulkner <faulkner.steve@gmail.com>, HTMLWG WG <public-html@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>, David Bolter <dbolter@mozilla.com>, Marco Zehe <marco.zehe@googlemail.com>, Richard Schwerdtfeger <schwer@us.ibm.com>, Cynthia Shelly <cyns@microsoft.com>
On Dec 23, 2010, at 12:51 AM, Benjamin Hawkes-Lewis wrote: > On Thu, Dec 23, 2010 at 7:37 AM, Maciej Stachowiak <mjs@apple.com> wrote: >> In Safari on Mac, the set of elements that is actually focusable depends on user preferences. > > Per spec, you are describing differences in whether the elements "can > be reached using sequential focus navigation". The set of "focusable" > elements includes elements that /cannot/ be reached using sequential > focus navigation. > > That is, the spec distinguishes the concept of focusable from the tab > cycle. See especially the normative requirement for negative tabindex: > "The user agent must allow the element to be focused, but should not > allow the element to be reached using sequential focus navigation." > > http://dev.w3.org/html5/spec/editing.html#focus My mistake. Turns out we have separate concepts for keyboard focusable, mouse focusable, and tab focusable, and the settings affect only keyboard focusability. However, per platform convention, I don't think we make all the suggested elements mouse focusable in WebKit, and I don't think the set of elements that is mouse focusable matches the set that is programmatically focusable, by calling focus(). HTML5 doesn't actually define the effect of being focusable. Is that list the suggested list of things that should get focus when mouse-clicked, or tapped on a touch device? Is it the set of things that gets focus when you call their focus() method? Are these two sets allowed to be different? Regards, Maciej
Received on Thursday, 23 December 2010 09:26:57 UTC