Mechanism for setting the tabindex focus flag without sprouting tabindex attribute?

[alice]

Certain HTML elements are focusable without having an explicit tabindex attribute:

• a elements that have an href attribute
• link elements that have an href attribute
• button elements
• input elements whose type attribute are not in the Hidden state
• select elements
• textarea elements
• summary elements that are the first summary element child of a details element

It would be nice if custom elements could also opt in to being focusable without having to sprout a tabindex attribute - such that if page authors removed the tabindex attribute, the element was still focusable.

It seems like this would be something that might fit in with whatever new API comes out of #758.

[domenic]

Strong +1.

Do you think it's worth exposing both of tabindex's capabilities here, or just one? They are:

• tabindex >=0 : reachable by sequential focus navigation, and also focusable in other ways (e.g. by the mouse or by .focus())
• tabindex = -1: generally not reachable by sequential focus navigation, but focusable in other ways. (May also be reachable by sequential focus navigation in some circumstances; see the spec's "One valid reason to ignore the requirement"...)

I think there are common built-in elements whose behavior falls into each of these categories, although it may be OS dependent.

[bkardell]

+1 and I would like to see both 😀

[alice]

In all honesty, I've never understood why tabindex = -1 is a thing, other than for excluding things from the tab order - i.e. why aren't all elements programmatically focusable? What do we gain from focus() sometimes being a no-op? Who is out here trying to call focus() on a <div> and hoping it ... fails?

But that aside, I guess allowing focusable things to also opt out of the tab order is probably useful for managing focus within complex components.

[annevk]

@alice tabindex="-1" also affects what you can click and will get a focus ring, iirc.

[alice]

@annevk True, although I've seen that cause more undesirable behaviour than desirable.

[rniwa]

Whatever mechanism we use for tabindex should be flexible enough to default ARIA role & other ARIA attributes as well.

[alice]

@rniwa Agreed, I'm hoping all of the use cases mentioned in #758, plus this one, can share the same mechanism.

[SiTaggart]

Wouldn't it be great if an element became focusable just by setting its role to something that is known to be an interactive element as per the ARIA spec. Just like a button is implicitly focusable, if I set the role of an element to be a button, I would love for the browser to just take care of it for me.

[alice]

I seem to recall ARIA affecting behaviour in that way was a deal breaker in the past - ARIA's contract is that it only affects accessibility tree computation.

(Edited to add:)
The reasoning being that if ARIA affected behaviour, it might discourage authors from using it.

[chaals]

Discussion at TPAC: We should keep in mind the concern that platform conventions differ, so we don't want to be in a position where authors can't match behaviour of the platform they are on. Consider a mode where you match some other element's behaviour...

[alice]

https://allyjs.io/data-tables/focusable.html