[focusgroup] tablist behavior token is misleading

[g12n]

If the intention is to limit the behavior of focusgroup strictly to focus navigation, without any concept of activation or triggering commands on the child elements, I would strongly suggest removing the "tablist" behavior token.

Especially for beginners, this naming is confusing and frustrating.

Initially, attempting to use the ARIA tablist role had no effect.

Then focusgroup="tablist" appeared promising, but it only implements a small part of the expected behavior.

In practice, it is technically just shorthand for focusgroup="inline wrap"

All remaining aspects of a tablist interaction still need to be implemented manually.
Because of this, the "tablist" behavior token implies functionality that is not actually providedd.

The name "tablist" strongly implies behavior aligned with the ARIA tablist pattern

Authors encountering focusgroup="tablist" may reasonably expect that it assists with:

• activating tabs
• managing the selected state
• coordinatin tab panels

Since none of this functionality is provided, the token name may lead developers toward incorrect assumptions.

Proposal: Remove the tablist behavior token

If the intention of focusgroup is to remain strictly limited to focus navigation, I suggest to remove the tablist and actually most of the other behavior tokens.

Ideally limit the set of tokens to directional cues, wraps and memory.

This would avoid implying support for a higher-level UI pattern that the feature does not actually implement.

Alternative Integrate focusgroup with invoker commands

Integrate focusgroup with invoker commands

If focusgroup were able to trigger invoker commands when focus changes, it could enable a declarative tab pattern.

<div focusgroup="inline invoke">
    <button focusgroupstart commandfor="tabpanel1" command="toggle">Tab 1</button>
    <button commandfor="tabpanel2" command="toggle-openable">Tab 2</button>
    <button commandfor="tabpanel3" command="toggle-openable">Tab 3</button>
</div>

<div id="tabpanel1" openable defaultopen name="tabs"></div>
<div id="tabpanel2" openable name="tabs"></div>
<div id="tabpanel3" openable name="tabs"></div>

In such a model:

• invoke would trigger commands when focus changes
• panels would be openable
• a shared name could enforce mutual exclusivity in openable elements , similar to the details pattern (see [openable] do we need exclusive openables? #1163)
• styling could rely on yet to define pseudo-classes for invoker (see [invokers] - how to style invoking element based on Invoker state? #622)

This would allow tabs to be expressed declaratively without JavaScript.

[lukewarlow]

One reason that doing it automatically and even the invokers suggestion won't work is that the tablist pattern can have a manual activation mode as well as an automatic mode. So selection shouldn't always follow focus.

Most of the patterns actually have a manual activation mode. Radio group is the only one where it's almost always selection follows focus and even in that case there's potentially situations it's not desirable (see #1414 )

[g12n]

@lukewarlow This is why I suggested an invoke keyword for the focusgroup attribute. This is related to #1030 where @flackr used a similar keyword for the same behaviour.

If you want to archive a tab-like behaviour with manual activation you would simply omit the keyword.

So instead of focusgroup="inline invoke" you would write focusgroup="inline"

<div focusgroup="inline">
    <button focusgroupstart commandfor="tabpanel1" command="toggle-openable">Tab 1</button>
    <button commandfor="tabpanel2" command="toggle-openable">Tab 2</button>
    <button commandfor="tabpanel3" command="toggle-openable">Tab 3</button>
</div>

<div id="tabpanel1" openable name="tabs" defaultopen></div>
<div id="tabpanel2" openable name="tabs"></div>
<div id="tabpanel3" openable name="tabs"></div>

This way you can opt in to the "automatic activation", the markup is really readable.

And the main point remains: instead of tablist I would prefer inline wrap invoke to lower the expectation, especially of new developers, to the level that matches the real goals and behaviour of the property.

[lukewarlow]

You would lose the automatic aria roles in that case though. (Not that that's such a big deal but worth being aware of).

[g12n]

Automatic roles are plagued by the same shortcomings as aria roles themselves: without additional code they don't provide a meaningful behavior.

That's why there is the saying "No ARIA is better than bad ARIA.". The same rule that applies to JavaScript is true for the native attribute:

If is doesn't provide the correct behavior it should not set the role.

If code is needed to provide the behavior this code can (and should be the only one to) set the role.

[lukewarlow]

I think the end goal for the tab pattern should really be something akin to the below markup. Where everything is handled for you. Some attribute for tablist could exist that controlled the automatic vs manual activation etc.

<tablist>
    <tab selected for="tabpanel1">Tab 1</tab>
    <tab for="tabpanel2">Tab 2</tab>
    <tab for="tabpanel3">Tab 3</tab>
</tablist>

<tabpanel id="tabpanel1"></tabpanel>
<tabpanel id="tabpanel2"></tabpanel>
<tabpanel id="tabpanel3"></tabpanel>

focusgroup just in the mean time gets you the arrow key navigation for the tablist. Also would allow you to make a custom element for this if you for whatever reason insisted on not using built-ins.

Though for other behaviours e.g. toolbar focusgroup does provide the core functionality required for a functional toolbar element. So it's <div focusgroup="toolbar"> vs <div role="toolbar" focusgroup="inline"> (though again this can just be a HTML element)

#1260 - some of the original discussion around this new focusgroup behaviour stuff was done here.

[lukewarlow]

One of the key desires was to stop people using this for patterns where it really shouldn't be used, such as doing

and suddenly your set for form controls are a single tab stop.

I guess the logic is that needing to do <form focusgroup="toolbar block"> would make people realise they've messed up. @janewman was any consideration made that focusgroup should only work on elements with no existing semantics? Because adding the behaviours doesn't actually enforce the scoped set of scenarios.

[g12n]

I guess the inflation of built-ins is a topic for another discussion.

Personally I like the clarity an readability of the combination of focusgroup and invokers. You see right there in the markup what really happens and this way it's easy to expose to assistive technology as well.

People hacking a look into an element, that's not canonical to the the original pattern is quite natural.

Of course people will use <tablist> to make a carousel (I said the dirty word). So it feels more realistic to give them the LEGO bricks first to build the behavior and avoid overloaded pattern definition that will be misused anyway.

[janewman]

My thoughts here:

• What you are proposing sounds a lot like the original focusgroup proposal from years ago, but that had trouble getting off the ground due to the very issues these behaviors address.

• Focusgroup manages focus, not selection or activation. This is true for all behaviors and is not something specific to tablist.

I guess the logic is that needing to do <form focusgroup="toolbar block"> would make people realize they've messed up.

Exactly, the idea is that this "requires" authors to pick a behavior so by default there is some way we can communicate to screen readers what this custom widget is. Of course, authors have the ability to override and do what they want, but with this design this needs to be an intentional act, not something that could easily happen accidentally.

---

I'm not fundamentally opposed to the idea of one day adding the ability via something like your invoker proposal, but similar to desire for 2D behaviors, I think this is best left for a future effort. I don't want perfect to be the enemy of good, and I think developers have waited long enough.

[lukewarlow]

intentional act, not something that could easily happen accidentally.

Fwiw it seems that toolbar doesn't override forms generic role in this example, so I'm not sure that's true is that perhaps a bug?

If we take <fieldset focusgroup="toolbar block"> as an example, the fieldset has the group role so that does win. Is that an intentional act, or an accident?

[g12n]

@janewman I understand the reasoning. And the impatience – trust me: I am waiting for that for ages as well.

But communicating to the screen reader something can cause more trouble, if it's done before it is clear that the elements behaviour matches the users expectation.

For APGs that specify only the the focus behaviour like the toolbar there isn't much of a problem.

But if the APG specifies selection and/or activation of child element, like the listbox, the radiogroup the tablist pattern, prematurely telling the screen reader role can cause the same harm as a prematurely placed ARIA-Role.

The gap between expected developer experience and real results is one of the reasons why a11y and especially ARIA is deemed so complicated by many developers.

To complete the expected bahavior you have two promising Proposals in the queue:

1. the Openable API
2. the future versions of Invokers