Re: [w3c/webcomponents] Mechanism for setting the tabindex focus flag without sprouting tabindex attribute? (#762)

> Safari would need to determine click/sequential focusability of focusable elements based on ElementInternals role.

"Safari would need to" may not be true. I see at least two options:

1. Safari _could_ (No opinion yet on whether it should) use the focusable state plus role as a way to determine whether elements appeared by default in the tab order, based on the existing platform keyboard behavior as modified by system and browser settings. 
 - This would be an example of accessibility-related code (the role) resulting in changed behavior (follow-up "slippery slope" argument)
 - Ryosuke brought up an implementation concern (re: `firstResponder`) that achieving focus (even programmatic-only) would be incompatible with the `unfocusable` state. I'll let him explain that concern in further detail.
 - There's the interop risk that Safari would doing something different that other browsers. We already have this interop challenge with native controls like `<button>` but it's always been so. We'd be adding a _new_ interop problem here.

2. For custom elements, Safari could treat them like it does ARIA elements (E.g. `<div role="button" tabindex="0">`), where focusability and tab order is controlled by the focusable/unfocusable state (role ignored), and programmatic `.focus()` calls would be ignored on non-focusable elements.
- The primary downside of option 2 is that this would formalize an API/behavior that ignores the platform convention of Mac/Safari, where users expect certain element types to be tab-focusable or not based on their user settings. 



-- 
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-689225812