Re: [w3c/webcomponents] Mechanism for setting the tabindex focus flag without sprouting tabindex attribute? (#762) from TAMURA, Kent on 2019-11-11 (public-webapps-github@w3.org from November 2019)

From: TAMURA, Kent <notifications@github.com>
Date: Mon, 11 Nov 2019 00:03:32 -0800
To: w3c/webcomponents <webcomponents@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <w3c/webcomponents/issues/762/552334763@github.com>

In my understanding, the consensus at TPAC 2019 was to introduce hight-level categories of elements, and we should avoid enums representing concrete behaviors such as "non-keyboardable" because of future platforms and macOS's "Full Keyboard Access" setting.

So, if we don't apply Alice's UA-decides idea, the options would be something like:

 * `unfocusable`
 * `general` -- [click-focusable](https://html.spec.whatwg.org/C/#click-focusable) and [sequentially-focusable](https://html.spec.whatwg.org/C/#sequentially-focusable); e.g. &lt;div tabindex=0>, &lt;input>
 * `control` -- **Safari**: not-user-focusable or sequentially-focusable depending on "Full Keyboard Access" setting.  **Chrome**: same as `general`.
 * anything else -- A future platform might introduce a new category. Current UAs should assume unknown keywords as `general`.





-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/762#issuecomment-552334763

Received on Monday, 11 November 2019 08:03:34 UTC