When a form field is hidden within a collapsed `<details>` element, it still receives focus when FKA is enabled. For example: ``` <details> <summary>1. Text input</summary> <label for="field01">Text field</label> <input type="text" id="field01"> </details> ``` The text field acts as a tab-stop and fires focus events. Example: https://cdpn.io/aardrian/debug/gOZppYp Steps: 1. Open the console. 2. Tab through the page. 3. Observe the focus style disappears when tabbing off a `<summary>`, with focus seemingly going nowhere. 4. Observe the ID of each field is written to the console as it gets focus. * Oddly, the select menu breaks the tabbing overall, but if you put keyboard focus on the next item it resumes hitting all hidden fields. * Links do not seem to get focus even when the `<details>` is expanded. * I did not test other interactive controls. * Chrome and Firefox are unaffected. This affects Safari 16.5 and TP 176, and probably earlier. When using VoiceOver, it does not announce the hidden field. The value is written to the console, so it has focus, but the field is not announced and announcement of the `<details>` is uninterrupted. Essentially I have to press Tab twice to move to the next `<summary>`, but I have no idea why as a user.
I can reproduce the problems in Safari 16.6 (on macOS 13.5.1). Additionally, I found two more element types that remain in the focus order within a collapsed `<details>` element, a `<div>` with `tabindex="0"` and a linked `<area>` in an image map. Example (fork with tabindex and image map examples added): https://cdpn.io/pen/debug/PoXqPYJ I cannot reproduce the problem in mobile Safari with a hardware keyboard and Full Keyboard Access enabled (on iOS 16.6).
Note it is not necessary for FKA (Full Keyboard Access) to be enabled to reproduce the problem. It's also not necessary for the macOS Keyboard navigation to be enabled. Even Safari's "Press Tab to highlight each item on a webpage" doesn't have to be enabled for some of the elements to still be in the focus order because they're ones Safari focuses by default (input text, textarea, tabindex="0", linked <area> elements). Related ticket: "Focus moves to items in a closed details element with tabindex=0". https://bugs.webkit.org/show_bug.cgi?id=251728
I believe this might be fixed if https://bugs.webkit.org/show_bug.cgi?id=228843 is implemented — that is, the spec requirements added in https://github.com/whatwg/html/pull/6466. But I’m not familiar enough with that yet myself to know whether it handles the tabbing case.
<rdar://problem/114641776>
(In reply to sideshowbarker from comment #3) > I believe this might be fixed if > https://bugs.webkit.org/show_bug.cgi?id=228843 is implemented — that is, the > spec requirements added in https://github.com/whatwg/html/pull/6466. But I’m > not familiar enough with that yet myself to know whether it handles the > tabbing case. I don't think opening `details` on the focusing of any elements within is a part of that proposal. One of the use cases for `details` is to allow a keyboard-only user to close it and tab past it instead of having to tab through all the focusable items within. I can still reproduce the problem in Technology Preview 179.
I can reproduce the problem in Safari 17.0. I can't reproduce the problem in Technology Preview 181.
Confirmed I can reproduce it in Safari 17 / macOS 14, but not in Safari Technology Preview 181 / macOS 14.
This appears resolved in Safari 17.4.
With STP 190 and going to https://cdpn.io/pen/debug/PoXqPYJ 1. When details are open, the focus is happening on every items, on both summary and the element inside with this sequence in the console. [Log] field01 (PoXqPYJ, line 68) [Log] field02 (PoXqPYJ, line 74) [Log] field03 (PoXqPYJ, line 80) [Log] field04 (PoXqPYJ, line 86) [Log] field05 (PoXqPYJ, line 92) [Log] field06 (PoXqPYJ, line 101) [Log] field07 (PoXqPYJ, line 106) [Log] tabindex01 (PoXqPYJ, line 110) [Log] JavaScript (PoXqPYJ, line 121) [Log] CSS (PoXqPYJ, line 127) 2. When details are collapsed, the focus is happening only on summary. 3. Link after, in both cases, does not receive the focus. So this seems indeed to be fixed in STP 190.