[focusgroup] Add the focusgroup attribute - #11723
Conversation
|
Opening up for review, but please keep in mind this is an early draft. |
|
@annevk, during TPAC you expressed interest in taking a look at this draft spec change - I would really appreciate any feedback you had as I work to move this towards something we think accurately captures the behavior and fits in with the existing logic. |
|
It is unclear to me what happens if the page has keydown, or keyup event listener and calls preventDefault() when arrow key is used. Which event listener has some affect and which doesn't? |
…ng section, improve segment definition with example, and simplify key conflict element handling
I've added a new section that should answer all of these questions, please let me know what you thank and if it still isn't clear. |
I'm still looking into what we can do here. Regarding having WebDriver toggle the MacOS keyboard setting, I've reached out to James Craig who I've worked with in aria and WPT regarding our options here, waiting to hear a response. In the meantime, I've adjusted all WPTs to accommodate, with all buttons having a tabindex of 0 manually set. |
|
Is there an HTML aam PR for this feature? I think it's a relatively straightforward mapping of roles right? |
Yes, should be fairly straightforward, I'll get a PR up soon. While I vaguely remember this not being needed, I don't recall the reasoning. In any case I'll get a PR up and then we can discuss if we want to land it or not on the PR itself. w3c/aria#2778 |
Adds an entry for the focusgroup content attribute documenting that it has no direct accessibility API mapping, but that user agents infer ARIA composite-widget roles for the focus group owner (and, for button items, the corresponding item roles) when a behavior token is used and the element would otherwise have a generic role with no explicit role or non-generic native semantics. Companion to whatwg/html#11723.
Adds an entry for the focusgroup content attribute documenting that it has no direct accessibility API mapping, but that user agents infer ARIA composite-widget roles for the focus group owner (and, for button items, the corresponding item roles) when a behavior token is used and the element would otherwise have a generic role with no explicit role or non-generic native semantics. Companion to whatwg/html#11723.
|
It seems the Build is failing. It also seems that this PR needs significant integration work with the various accessibility specifications. Has any progress been made on that front? In particular I'm not sure ARIA role inference should be specified here. We don't define that for HTML elements either today. |
|
Looks like the |
keithamus
left a comment
keithamus
left a comment
There was a problem hiding this comment.
This isn't a full review, because I think some of my commentary may have broader impacts on this spec, but here's what I have so far:
| <p>The <dfn>effective modifiers</dfn> of a <span>focus group owner</span> are determined | ||
| by starting with the <span>behavior token</span>'s <span>default modifiers</span>, then | ||
| applying any explicit <span data-x="modifier tokens">modifier tokens</span> from the | ||
| attribute value. For axis modifiers, an explicit <code | ||
| data-x="attr-focusgroup-inline">inline</code> or <code | ||
| data-x="attr-focusgroup-block">block</code> token overrides any default axis restriction. |
There was a problem hiding this comment.
This feels like a confusing aspect of the design when combined with the concept that behaviours have default modifier tokens, and "block inline" allows both axes. For example I anticipate confusion around "menubar" vs "menubar block" vs "menubar block inline". I vaguely recall litigating this in OpenUI and I definitely don't like the idea of having a noblock token but... something isn't right here, or at least needs a lot more precision in the exact semantics.
There was a problem hiding this comment.
Let me know if the latest wording helps mitigate this concern for confusion, or let me know if you have any ideas on what we can do here.
- Define formal "determine the focusgroup state" algorithm; remove
ARIA Role Inference (defer to HTML-AAM)
- Decouple Directional Navigation from keyboard; parameterize with
logical direction; add notes for non-keyboard input modalities
- Currently-focused item is always the entry element of its segment;
broaden key conflict element to focusable areas
- Make Top layer interaction the normative source ("treated as if
focusgroup='none'")
- Editorial: bulleted definitions, attributes index, terminology
consistency, RFC2119 fixes
- Use [SameObject, PutForwards=value, Reflect] readonly attribute DOMTokenList pattern (matches sandbox, sizes, blocking, etc.) - Define the focusgroup attribute's supported tokens so that DOMTokenList.supports() can be used for feature detection
- Lowercase the focusgroup attribute value upfront in the state algorithm (matches the blocking attribute pattern), so subsequent token comparisons are exact - Use linked Directional Navigation references in concept-related prose (modifier table descriptions, attributes index, examples) - Drop tutorial-style "Each segment operates independently" bullets and the inaccurate horizontal-scrolling bullet from examples - Replace "enables" with "provides" in opening attribute definition; trim "automatically configure the correct axis and wrapping" from menubar example intro
I've stripped out the ARIA sections from here, these concepts will live in w3c/aria#2778 |
Really appreciate the feedback! Let me know what you think of the latest. |
- Wrap: use "exactly one of nowrap or wrap" framing so non-conforming (both present) falls into the same "otherwise" branch as neither, using the behavior default - Axis: state directly that both inline and block means Directional Navigation operates on both axes; reword DN's axis check to test whether effective modifiers restrict DN to an axis other than the one being navigated, rather than testing for a specific opposite token in the effective modifier set
- Trim "What to notice" in tablist example to a single terse paragraph - Use "focus group" (concept) consistently in prose where "focusgroup" referred to the concept rather than the attribute - Drop non-keyboard-modifier-key note (UA discretion is implicit)
…e first token (#1450) * [focusgroup] Update explainer to match whatwg/html#11723 Aligns the explainer's Feature detection section with the IDL landed in whatwg/html#11723: focusGroup as a DOMTokenList and focusGroupStart as a boolean, both on the HTMLOrSVGElement mixin. Adds a short DOMTokenList ergonomics example so authors know they can use .add/.toggle/.contains/.remove rather than parsing the attribute value. Links the WHATWG PR from the intro metadata and refreshes the Last updated date. * fixup: align Feature detection prose with new IDL casing Customs review iteration 1: prose at line 837 referred to a `focusgroup` property (lowercase) but the IDL the previous commit introduced declares `focusGroup` (camelCase) and adds a separate `focusGroupStart` boolean. Rewrites the sentence to name both IDL properties correctly and distinguish them from the content-attribute names. Adds one bridging sentence noting that direct string assignment continues to work alongside the DOMTokenList methods. * fixup: reword string-assignment note for register Customs review iteration 2: RR1 (spec-accuracy) and RR3 (prose-voice) independently flagged "still works" as conversational and as assuming the reader knew the prior DOMString IDL. Rewrites the sentence in the spec-adjacent register used by the rest of the section. * fixup: remove DOMTokenList ergonomics section Drops the per-token API discussion (Because focusGroup is a DOMTokenList... plus the JS example) and the readonly/PutForwards string-assignment note. Both patterns are well known to authors who reach for the IDL, and removing them keeps the Feature detection section focused on the new IDL surface. * fixup: drop enforced token-order claims Token order in the focusgroup attribute is not significant per the spec PR algorithm — only the SET of tokens matters. The explainer previously implied an order requirement in several places (mostly via "first token" phrasings used to mean "the behavior token"). Replaces those with "behavior token" where the meaning was semantic, drops the explicit "Order: first token MUST be ..." claim in the Index of focusgroup values, softens the Authoring guidance "Put the behavior token first" imperative to a readability recommendation, and notes "in any order" in the Focusgroup tokens introduction. * fixup: clarify token-order convention in Focusgroup tokens intro The bracket notation immediately after the intro sentence shows tokens in a conventional order (behavior, axis, wrap, memory); the rewritten intro labels that order as conventional and explicitly states any order is valid.
Align the focusgroup attribute parsing with the formal "determine the focusgroup state" algorithm defined in the HTML spec PR: whatwg/html#11723. With this change, "none" and the behavior token can appear at any position. Before, the these were required to be the first token or parsing would fire an error. Bug: 40210717 Change-Id: Ic258d4fc39f9850c5cabac2b4afa0dbcf6c32d95 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7871960 Commit-Queue: Jacques Newman <janewman@microsoft.com> Reviewed-by: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#1637192}
Align the focusgroup attribute parsing with the formal "determine the focusgroup state" algorithm defined in the HTML spec PR: whatwg/html#11723. With this change, "none" and the behavior token can appear at any position. Before, the these were required to be the first token or parsing would fire an error. Bug: 4021071 Change-Id: Ic258d4fc39f9850c5cabac2b4afa0dbcf6c32d95 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7871960 Commit-Queue: Jacques Newman <janewman@microsoft.com> Reviewed-by: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#1637192}
…latest spec draft, a=testonly Automatic update from web-platform-tests [focusgroup] Align ParseFocusgroup with latest spec draft Align the focusgroup attribute parsing with the formal "determine the focusgroup state" algorithm defined in the HTML spec PR: whatwg/html#11723. With this change, "none" and the behavior token can appear at any position. Before, the these were required to be the first token or parsing would fire an error. Bug: 40210717 Change-Id: Ic258d4fc39f9850c5cabac2b4afa0dbcf6c32d95 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/7871960 Commit-Queue: Jacques Newman <janewman@microsoft.com> Reviewed-by: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#1637192} -- wpt-commits: ea921feb8d626629aebe857e774864f8679f0977 wpt-pr: 60231
20 participants
#11641
This adds the
focusgroupattributes needed to allow for declarative focus navigation using the directional navigation (arrow keys, d-pad).This specs the behavior detailed in the explainer on OpenUI.
/dom.html ( diff )
/index.html ( diff )
/indices.html ( diff )
/infrastructure.html ( diff )
/interaction.html ( diff )