Compatibility of focusability with HTML & platform conventions

[AmeliaBR]

From @litherum / @rniwa

https://svgwg.org/svg2-draft/single-page.html#interact-Focus mentions how any element that generates a scrollable region should be treated as if tabindex=0 is set. This is a weird “should” statement given HTML doesn’t do this. It’s also problematic because it would mean that we can’t decide whether an element is focusable or not without layout information

The section also mentions “focusable” content attribute. But it doesn’t really specify what happens when its value is set to “auto” or whether it supersedes tabindex=-1 or not:
https://www.w3.org/TR/SVGTiny12/interact.html#focusable-attr

For example, this SVG tutorial asserts that “focusable” would override tabindex: https://allyjs.io/tutorials/focusing-in-svg.html#making-svg-elements-focusable

Given Firefox nor Chrome seems to implement this content attribute, it’s hard to tell what the right behavior is.

[css-meeting-bot]

The SVG Working Group just discussed focusability compatibility, and agreed to the following:

• RESOLUTION: Defer to HTML for focusability of foreignObject content
• RESOLVED: Clarify the interaction of tabindex and focusable; make it clear this only applies if the UA supports focusable; support is not required; authors are discouraged from using it.

The full IRC log of that discussion

<heycam> Topic: focusability compatibility
<heycam> github: https://github.com//issues/736
<heycam> rniwa: inthe current draft, it mentions that SVG elements that are scrollable should be treated as if tabindex is set to 0, so it's focusable
<heycam> ... that's not what HTML does
<heycam> ... to decide whether something is scrollable, you must update styles and layout
<heycam> AmeliaBR: this list was based on the accessibility desires that scrollable should be focusable
<heycam> ... since this isn't an SVG specific feature, it's about HTML nested in SVG, we should be consistent with HTML
<heycam> ... even if that means deferring to platform conventions that aren't ideal
<heycam> emilio: to compute whether an element has scrollbars, you need to run layout. but afaict the focusability of a scrollable thing only depends on style, not on layout
<heycam> ... if it *could* have scrollbars
<heycam> ... we do allow stuff with scrollable overflow to be focusable
<heycam> AmeliaBR: I think WebKit is the odd one out
<heycam> ... but it's an HTML issue
<heycam> ... I'm OK resolving to add a condition to that, that defers to HTML
<heycam> ... so element within a fO would be focusable accoridn gto the foreign language
<heycam> rniwa: the issue is more the consistency with HTML here
<heycam> emilio: I agree it should be consistent
<heycam> krit: anything else that could be scrollable?
<heycam> rniwa: HTML spec section 6.4.2 defines focusable area
<heycam> ... would be great if the SVG spec just delegates that to decide what's focusable
<rniwa> https://html.spec.whatwg.org/multipage/interaction.html#focusable-area
<heycam> RESOLUTION: Defer to HTML for focusability of foreignObject content
<heycam> AmeliaBR: second part of the concerns are more SVG specific
<heycam> ... the legacy focusable attribute
<heycam> rniwa: one thing that is unclear is the old SVG Tiny 1.2 talks about focsuable = true,false,auto
<heycam> ... new spec doesn't talk about any of the values
<heycam> ... it's unclear whether tabindex or focusable takes priority
<heycam> AmeliaBR: good criticism that we should have specified the interaction
<heycam> ... definitely want tabindex to take precendence
<heycam> ... only we mention focusable is to avoid breaking content that uses that attribute
<heycam> rniwa: do we still want to support the 3 values?
<heycam> heycam: do we still need to support that at all?
<heycam> AmeliaBR: it was working in Edge, at least
<heycam> rniwa: focusable=true is clear cut, to imply tabindex=0
<heycam> ... false, if it's set, it's like a noop
<heycam> AmeliaBR: focusable=false got used a lot since MS browsers were treating every inline SVG as a focusable item
<heycam> ... we can say focusable=false is respected, as long as tabindex overrides it
<heycam> rniwa: so your suggestion is to take the SVG Tiny 1.2 true/false/auto values into the spec, and allow tabindex to always override it?
<heycam> AmeliaBR: officially define focusable, but deprecated, with those three values
<heycam> rniwa: one tutorial I found says that focusable would override tabindex...
<heycam> heycam: but do we have any implementations of focusable?
<heycam> AmeliaBR: Edge does support it
<heycam> mstange: there's a Firefox bug, WONTFIXed 5 years ago
<heycam> ... saying it wasn't in SVG 2
<mstange> https://bugzilla.mozilla.org/show_bug.cgi?id=409404
<heycam> [some discussion about having it in the spec, allowed to implement, not required]
<heycam> rniwa: if Edge wasn't going to change, normative or not probably doesn't matter
<heycam> rniwa: I'm curious what Edge does in terms of priority between focusable and tabindex
<heycam> emilio: in the bug comment, IE <= 11 only supported focusable, and not tabindex
<heycam> rniwa: can we agree on a non-normative note?
<heycam> AmeliaBR: I think we should have a normative thing, if you implement it, this is how it interacts with tabindex
<heycam> ... I wouldn't mind saying every browser should implement it but it's deprecated
<heycam> rniwa: question is whether implementors will implement focusable
<heycam> myles: I think the answer is no
<heycam> krit: I think the note in the spec should advise against using it
<heycam> RESOLVED: Clarify the interaction of tabindex and focusable; make it clear this only applies if the UA supports focusable; support is not required; authors are discouraged from using it.

[AmeliaBR]

As promised I ran a test on EdgeHTML for the interaction of focusable and tabindex. I confirmed the information in the tutorial that @rniwa found, the focusable attribute takes precedence. Which is not ideal, but since this is an obsolete feature in an unmaintained rendering engine, we're not going to change it. If any other browsers find a web compat need to add focusable support, it should match this behavior.