RESOLVED FIXED Bug 78499
FKA: The auto-generated label in a <details> element without a <summary> is not keyboard accessible
https://bugs.webkit.org/show_bug.cgi?id=78499
Summary FKA: The auto-generated label in a <details> element without a <summary> is n...
Mathias Bynens
Reported 2012-02-13 08:13:06 PST
Minimal test case: data:text/html;charset=utf-8,<!DOCTYPE html><title>Test</title><details>foo</details> (Note that this is invalid markup: http://bugzilla.validator.nu/show_bug.cgi?id=896) The spec is here: http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#the-details-element > The first `summary` element child of the element, if any, represents the summary or legend of the details. If there is no child `summary` element, the user agent should provide its own legend (e.g. "Details"). It seems to me that this legend should be keyboard accessible, just like a <summary>.
Attachments
Proposed patch (4.85 KB, patch)
2012-03-16 06:48 PDT, Arko Saha
morrita: review-
Mathias Bynens
Comment 1 2012-02-13 08:25:02 PST
When clicking the label once, it will get a focus outline, and from then on Space or Enter can be used to toggle the <details> element’s contents. So the only thing that doesn’t work (it seems) is tabbing to the label.
Steve Faulkner
Comment 2 2012-02-13 08:38:14 PST
seems like a summary element is added to the shadow dom even when not added by an author.
Radar WebKit Bug Importer
Comment 3 2012-02-13 09:24:27 PST
Mathias Bynens
Comment 4 2012-02-14 00:24:36 PST
FWIW, I recently proposed changing the behavior so that instead of a text label, an actual <summary> element would automatically be inserted. This would make it easier to polyfill this behavior, and possibly to implement the whole thing in a browser. Hixie said the following: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15455#c3 > You're not allowed to omit the <summary>, so IMHO it doesn't really matter what > happens when you omit it so long as it's the same everywhere. Sounds like he could be convinced to change this if it would make things easier for browser makers. (I may be wrong, but it seems like the proposed behavior would’ve avoided this bug. Feel free to ignore this comment if it’s irrelevant.)
Arko Saha
Comment 5 2012-03-16 06:47:40 PDT
If user forgot to add <summary> element as a child of <details> element, in such case a <summary> element is added to the shadow dom of <details>. All descendant elements in a shadow root are skipped if the host node of the shadow root is not focusable. Here <details> is non-focusable. So pressing tab does not transfer the focus to the focusable <summary> element in the shadow root. We need to override the supportsFocus() and focus() method in HTMLDetailsElement. So that it can transfer the focus to the focusable <summary> element in the shadow root on pressing tab to <details> element.
Arko Saha
Comment 6 2012-03-16 06:48:26 PDT
Created attachment 132273 [details] Proposed patch
Hajime Morrita
Comment 7 2012-03-19 03:38:55 PDT
Comment on attachment 132273 [details] Proposed patch View in context: https://bugs.webkit.org/attachment.cgi?id=132273&action=review This doesn't looks like right direction. We shouldn't take the auto-generate summary as a special case if possible. > Source/WebCore/html/HTMLDetailsElement.h:45 > + virtual void focus(bool restorePreviousSelection = true) OVERRIDE; Please don't give the default value on derived class. It can cause hard-to-find error.
Hajime Morrita
Comment 8 2012-03-19 03:40:26 PDT
HI Shinya, Could you explain how auto-generated summary work? I think there is some trick in its implementation. It would be great if you have a Wiki page entry for that.
Ryosuke Niwa
Comment 9 2023-09-11 07:15:39 PDT
EWS
Comment 10 2023-09-12 06:06:11 PDT
Committed 267899@main (2115ac47e427): <https://commits.webkit.org/267899@main> Reviewed commits have been landed. Closing PR #17651 and removing active labels.
Note You need to log in before you can comment on or make changes to this bug.