unexpected focus results for tabindex + <dialog>.showModal()

[danbeam]

@domenic @esprehn @tkent-google @TakayoshiKochi

Hi,

As spec'd (as far as I can tell), <dialog> has a few cases where the tabindex + focus behavior is unintuitive to me.

Specs:
https://html.spec.whatwg.org/multipage/forms.html#dialog-focusing-steps
https://html.spec.whatwg.org/multipage/interaction.html#sequential-focus-navigation-order
https://html.spec.whatwg.org/multipage/interaction.html#negative-tabindex

First case:

<dialog>
  <div tabindex="-1">
    i don't wish to participate in the tab order,
    but am focused when showModal() is called
  </div>
</dialog>

Second case:

<dialog>
  <button tabindex="-1">
    i get focused on showModal() even with a negative tabindex
  </button>
</dialog>

Third case:

<dialog>
  <button tabindex="-1">
    i get focused on showModal() even with a negative tabindex
  </button>
  <div tabindex="0">
    i lose even through I participate in the tab order
  </div>
</dialog>

It's obviously possible to remove the tabindex="-1" in cases 2 and 3, but some frameworks (i.e. Polymer) use .tabIndex = 0/-1 as if it's the same as calling setAttribute('tabindex', '0') or removeAttribute('tabindex').

Additionally, there's no easy way to remove an element that is tabbable by default (i.e. <button>, <a href>) without the ability to specify tabindex="-1".

I think this generally boils down to spec lingo about the "tabindex focus flag" or being "focusable" when it should be more like being in the "sequential focus navigation order".

This leads to unexpected mismatches in behavior (at least in my mental modal) which actually manifested in Chrome's settings page.

Note: while this currently only affects Chrome, Mozilla seems to be kinda/sorta interested:
https://bugzilla.mozilla.org/show_bug.cgi?id=840640

[domenic]

Could you explain what parts of the behavior are unintuitive to you, what spec lines lead to that behavior, and what behavior you think should happen instead?

[danbeam]

https://html.spec.whatwg.org/multipage/interaction.html#specially-focusable

If the value is a negative integer
The user agent must set the element's tabindex focus flag, but should omit the element from the sequential focus navigation order.

If the value is a zero
The user agent must set the element's tabindex focus flag, should allow the element and any focusable areas that have the element as their DOM anchor to be reached using sequential focus navigation, following platform conventions to determine the element's relative position in the sequential focus navigation order.

the simplest interpretation of this text is: tabindex=0 means focusable, tabindex=-1 means unfocusable (regardless of tag name, with no ancestors or disabled involved).

in my fiddles: pressing Tab before <dialog>.showModal() is called has different results than after.

[domenic]

Sorry, I'm still not really clear.

in my fiddles: pressing Tab before <dialog>.showModal() is called has different results than after.

So, you would expect it to have the same results whether or not a modal dialog is shown?

Which of the two results would you find more preferable?

[tkent-google]

Dan and I chatted before filing this, and I think Dan's main concern is that "dialog focusing steps" depends on DOM order, and is not manageable by tabindex attributes.

https://html.spec.whatwg.org/multipage/forms.html#dialog-focusing-steps

If there isn't one, then let control be the first non-inert focusable area in subject's control group.

https://html.spec.whatwg.org/multipage/interaction.html#control-group

Focusable areas in control groups are ordered relative to the tree order of their DOM anchors.

A solution would be

• Make "dialog focusing steps" tabindex-aware, or
• Expand "autofocus" attribute support to all elements

[danbeam]

Expand "autofocus" attribute support to all elements

ehhh, that didn't sound so awesome when I spoke about it to @freshp86. I don't really understand what autofocus helps when an element isn't focusable (i.e. <div autofocus> as <div> is not focusable by default).

Make "dialog focusing steps" tabindex-aware

right, this is what I was hoping for. but really, just that <dialog> essentially works like it's own document (as far as focus is concerned).

@domenic

what i expect from fiddle 1:

• step 0: click in blank space in result frame
• step 1: press Tab
  • expectation 1: focus skips over <div tabindex="-1"> and to <button>show dialog</button>
• step 2: click or press Enter while on <button>show dialog</button>, a dialog should show (in Chrome)
  • expectation 2: <div tabindex="-1"> cannot be focused, similarly to the <div tabindex="-1"> outside of the <dialog>
  • unexpected 1: the unfocusable <div tabindex="-1"> is focused (as seen by outline CSS)

i'll fill in more steps for 2 and 3, but same basic theme: pressing Tab in a document works differently than when opening a <dialog>, which essentially causes everything underneath it to become inert and restarts the focus logic with its contents. this is my mental modal at least (when a dialog is shown modally). please let me know if i'm just thinking of this incorrectly.

[domenic]

OK, thanks for the background; I think I am starting to understand the problem. It seems like the conflict is essentially that tabindex="" is used to impact sequential focus navigation, but most of the focus mechanisms in the spec do not have to do with sequential focus navigation---that's only related to pressing TAB to sequentially tab through the document.

In particular, in fiddle1, the outside-the-dialog div is not focused at first because the whole browsing context is focused. And you cannot then focus it through pressing TAB, of course. But you can focus it by clicking on it. (Or by calling .focus(), or similar.)

When you open the dialog, the user agent then wants to move focus to the dialog. Since this isn't related to pressing TAB, we don't care about the tabindex="" attribute; we just use the normal focus rules that apply for clicking and for .focus().

I guess what might be strange is the choice to focus the first element of the dialog, instead of focusing the dialog as a whole. Focusing the dialog as a whole would match the behavior for the outer document, where we initially focus the browsing context instead of focusing the first focusable element inside of it.

My guess is that it was deemed more user-friendly to focus something inside the dialog. Maybe it is also complicated since "the dialog" is kind of part of both the outer document and the dialog focus control group; maybe if we focused the dialog then the rest of the spec would get confused about what to tab to next, or similar. (I'm less sure about that part, and it doesn't matter much.)

So I think there might be an inconsistency here, but I don't think extending tabindex="" to have meaning outside of sequential focus navigation is the right way to fix it.

[danbeam]

My guess is that it was deemed more user-friendly to focus something inside the dialog.

That's possible, but for assistive technology users that's like deeming it "more user-friendly" to start scrolled half-way down the page (if you focus something half-way in the middle of the dialog's contents, that's where a screenreader likely shifts to).

Additionally, if there's a <button> at the bottom of a <dialog>, it actually does force scroll to it (example).

Also, focus rings are often just noise on mobile (other than maybe in editable areas i.e. <input>, <textarea>); not a ton of keyboard nav going on there.

I guess what might be strange is the choice to focus the first element of the dialog, instead of focusing the dialog as a whole. Focusing the dialog as a whole would match the behavior for the outer document, where we initially focus the browsing context instead of focusing the first focusable element inside of it.

YES. It would be way more sane, IMO, to just focus the dialog as a whole and respect autofocus if it exists. Just like in outer documents (AFAIK).

[domenic]

If you're interested in changing Chromium in that fashion, I'm happy to change the spec too. Let me know?

[danbeam]

I'm hacking around in Blink, but have some questions:

1. should the <dialog> that we're calling show() or showModal() on receive focus events?
   note: <body> does when initially focused
2. does this mean that <dialog> should be focusable by default?
   note: is often focusable in Blink, though user agent styles hide the outline
3. I assume that document.activeElement should be the top-level <dialog> while 1+ <dialog>s are showing?
   note: I think there are issues with the current implementation

[TakayoshiKochi]

In my opinion,

1. Yes, it would receive focus event.
2. The spec says "The tabindex attribute must not be specified on dialog elements.", but I'm not sure "by default" or not. Maybe <display>.tabIndex = -1 when it is not on the top-level, and <display>.tabIndex = 0 when it is.
3. Yes, document.activeElement can only point to at most one element in a document.

[danbeam]

additional context from the crypt:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23366
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24718
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23475

[domenic]

@danbeam thanks for digging them up.

If we were to make these changes, I'd say the answers to your three questions would be yes, yes, and yes.

However looking through that first long bug thread does make it seem to me like the more reasonable behavior is to focus the first control. Testing a few native apps they seem to all work that way too. Do you still think focusing the dialog is the best choice?

I was going to say, "maybe the best strategy is 1) autofocus; 2) first focusable control; 3) the dialog". But that is actually what the spec already does! The confusion in this thread is just about confusing "focusable" with "part of the sequential focus navigation order"; tabindex="-1" causes something to be focusable, but takes it out of the sequential focus navigation order. So given that we have this distinction, everything seems to be working pretty well to me; you just have to remember to not put tabindex="-1" on your divs, since doing so makes them focusable.

[danbeam]

The confusion in this thread is just about confusing "focusable" with "part of the sequential focus navigation order";

But that's exactly the issue: someone probably would add tabindex="0" to affect initial focus (not just "sequential focus navigation order"). But they can't configure it in reverse, i.e. skipping over a default focusable element (what I tried to accomplish with <button tabindex="-1">). This asymmetry was the root of my misconception.

you just have to remember to not put tabindex="-1" on your divs

Yeah, I understand what you're saying, and we're (Chrome UI folks) probably having issues because we're using Shadow DOM, which intentionally hides a bunch of stuff (and currently doesn't work with the way that <dialog> considers its initial focus candidate, which is probably just a bug).

---

In general, I think there's a few things we (and the context) agree upon:

1. valid [autofocus] should be respected
2. the <dialog> should get focused when focusable (i.e. <dialog tabindex="0">)

What I'm not sure makes sense is:

1. any focusable element (i.e. <a>) inside a <dialog> should be focused initially
   1. it seems like this should be configurable in some way, many have asked
2. the main use case for <dialog> and what it brings to the web. I see a few possibilities:
   1. add a new level of modality, filtering events through a first (or only) responder for certain events or modes of browsing
   2. make an often replicated UI paradigm easier to create

Regarding 1. if we agree to let some validly opt out of the default behavior (initial focusing logic), maybe canceling a 'show' event via preventDefault() would be a natural fit? Or maybe [optionally] parameterizing show()/showModal()?

Regarding 2. I suspect that @Hixie, @cookiecrook, and @stevefaulkner went at eachother for many rounds because it wasn't insanely clear to them what <dialog> wants to accomplish. I interpreted (and hoped for) "add a new level of modality" because of the concept of inertness. The user agent styles (unspecified, I get that) of showModal() in Chrome match that of "common UI paradigm". It's all fairly muddy to me; I'm uncertain and fearful for the future of <dialog> because it hasn't received much usage or implementation support (I think its unclear purpose may be a partial cause).

---

tl;dr - the absolute best thing I could see happening is the ability to harness just inertness, maybe via an inert attribute or makeInert() imperative API. This allows folks access some of the underlying magic of <dialog> without forcing the default behavior when it doesn't suit well.

[domenic]

Regarding 1. if we agree to let some validly opt out of the default behavior (initial focusing logic), maybe canceling a 'show' event via preventDefault() would be a natural fit? Or maybe [optionally] parameterizing show()/showModal()?

I like parameterizing show/showModal, among these. Although I'd appreciate more info on the use cases---I don't quite remember that showing up in the megathread, but maybe it escaped my brain...

the absolute best thing I could see happening is the ability to harness just inertness, maybe via an inert attribute or makeInert() imperative API.

Yeah, definitely! We're hoping for implementer interest in #1474, but haven't seen much yet :(.

---

So to recap our learnings, there are three separate but related concepts:

1. Unfocusable vs. focusable
2. In sequential tab order vs. not
3. Inert vs. not

tabindex controls (1) and (2) together. Specifically, setting it to anything will control (1) by making the element focusable---but you cannot make the element unfocusable. And using -1 vs. 0 you can control (2).

The spec factors (3) separately from (1) and (2), but in practice they are tied together: the algorithms for focusing and sequentially navigating focus consult inertness, in addition to consulting focusability specifically and in-sequential-tab-order specifically. It might be an unobservable refactoring of the spec to say that all inert elements are unfocusable and not in sequential tab order. But probably there is some subtle difference; I wonder what it would be.

---

So. What should we do with this bug, given our new deeper understanding of focus? Maybe add a clarifying note delineating the difference between these three concepts, for one. But should we do any behavior changes? Maybe parameterizing show/showModal? Or just hope that #1474 gains ground and the issues can be solved there?

[minorninth]

I like the idea of changing the spec so that opening a dialog respects autofocus, and doesn't autofocus controls with tabindex=-1. Those seem consistent with the spirit of the original spec, and they're unlikely to break any existing code or tests.

I'm a bit hesitant to parameterize showModal because we're already having trouble getting buy-in to ship dialog in other browsers, so changing the API seems like it shouldn't be done unilaterally.