| Summary: | When <summary> is omitted, <details> does not receive keyboard focus. | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Estelle Weyl <estelle> |
| Component: | Accessibility | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | ahmad.saleem792, akeerthi, andresg_22, mike, rniwa, webkit-bug-importer, webkit.org |
| Priority: | P2 | Keywords: | InRadar |
| Version: | Safari 15 | ||
| Hardware: | Unspecified | ||
| OS: | macOS 12 | ||
| Bug Depends on: | |||
| Bug Blocks: | 252223 | ||
|
Description
Estelle Weyl
2022-12-27 02:12:08 PST
@Aditya & @Ryosuke - adding 'supportFocus' function similar to HTMLSummary will fix this? (In reply to Ahmad Saleem from comment #2) > @Aditya & @Ryosuke - adding 'supportFocus' function similar to HTMLSummary > will fix this? Maybe? 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? This is fixed in the sources by https://commits.webkit.org/267899@main. I assume Safari Technology Preview 179 will include the fix. |