Bug 249904 – When <summary> is omitted, <details> does not receive keyboard focus.

• Status: RESOLVED
• Resolution: FIXED
• Component: Accessibility

[Estelle Weyl]

When the developer does not include a summary within a details, the browser creates the summary; this is correct.
Normally, all summaries, being buttons, are in the normal tabbing sequence. The summary created by Safari when the developer omits it within the details is not added into the default tabbing sequence and therefore does not receive keyboard focus. It works as expected with a mouse, but not via keyboard. 

See https://codepen.io/estelle/pen/BaPjjrW as a test case.

[Radar WebKit Bug Importer]

<rdar://problem/103723742>

[Ahmad Saleem]

@Aditya & @Ryosuke - adding 'supportFocus' function similar to HTMLSummary will fix this?

[Ryosuke Niwa]

(In reply to Ahmad Saleem from comment #2)
> @Aditya & @Ryosuke - adding 'supportFocus' function similar to HTMLSummary
> will fix this?

Maybe?

[sideshowbarker]

Is this caused by https://bugs.webkit.org/show_bug.cgi?id=191851?

Does the current code handle focus navigation with shadow trees that have slots?

For the record here, any <details> element in the WebKit DOM includes a user-agent shadow tree with a default <summary> element, like this:

<details>
  <slot name="summarySlot">
    <summary>Details</summary>
  </slot>
</details>

If the document supplies an explicit <summary>, then that explicit summary goes into the DOM in the normal way — but in addition to that default <summary> (and then that explicit <summary> becomes the active summary for that <details>.

But as far as that non-explicit default <summary> element that goes inside that <slot> for every <details>: There’s nothing exceptional about that default <summary> itself; specifically, for that default <summary> — when there’s no other explicit <summary> supplied by the document — isActiveSummary() is true, and so supportsFocus() is true, and defaultTabIndex() is 0.

And if you first click on that <details> element and then hit the tab key, that <summary> will get focus styling. So it’s actually focusable.

But what is exceptional about that <summary> element — unique, even — is that it seems to be the only case in the user-generated shadow DOM where an element goes in as a child of a <slot> like that.

So anyway, all that makes me wonder: Is the cause of this is a general lack of handling yet for focus navigation with shadow trees that have slots?

[sideshowbarker]

This is fixed in the sources by https://commits.webkit.org/267899@main. I assume Safari Technology Preview 179 will include the fix.