"Tab" example in the Understanding doc of 3.2.2.

[anevins12]

Can you help me understand why activating a tab, assuming this is a tab control in a Tabs APG 1.2 pattern, is not changing the setting of the control? Doesn't a tab control have a "selected" setting?
I'm seeing implementations that move focus on activation of a tab and to me it looks unexpected. At least it doesn't match the behavior of the APG pattern, but I realise that APG is not normative.

[JAWS-test]

That a loss of focus after activating a tab is bad is correct. But that would be more of a problem with SC 2.4.3 Focus order.
The fact that the focus loss at tab cannot be evaluated at 3.2.2 is a deficiency of the SC, which cannot be changed easily. The SC is called "On Input" and refers to changing values in form fields. A tab is not a form field. A better SC would be one that prohibits context changes on operation. WCAG 3.0 may offer a chance to close this gap.

[anevins12]

Interesting, thanks for clarifying. For 3.2.2 then does the understanding wording supersede the criterion wording? The understanding doc says form controls, whereas the criterion says any UI component..

[JAWS-test]

does the understanding wording supersede the criterion wording?

No, that must not be the case because the SC is normative and the Understanding is not. If the Understanding contradicts with SC, the Understanding must be changed. The understanding tries to explain what is meant in the SC.

Yes, the SC says UIC, but it also says "on input" and "changing the setting"- and the Understanding explains that, for example, a link does not allow input nor can the setting be changed. And tabs are something like links or buttons, after activating them the display is changed, but an input is not possible.
I think this is not optimal - and if this can already be changed within the current WCAG, so that changing the setting also refers to tab, I have nothing against it. The restrictive concept of 3.2.2 in Understanding I think is rather bad.

[anevins12]

Thank you again for clarifying "On input" and "changing a setting." It was right there staring at me for years. Just so that it's clear, can I ask what is meant by "input"?

[JAWS-test]

can I ask what is meant by "input"?

I did not write the WCAG, which means that only those who were there at the time can really answer it. But my understanding of the SC+Understanding is that it means entering value into form fields, such as text entry fields, drop-down lists, checkboxes, or radio buttons - anything that has a value that is submitted via a submit button. A tab has no value, only a status (such as selected).

Problem is, at the time WCAG 2.0 was published, the line between form fields (which have a value and are submitted) and other controls (like buttons and links) was still very clear. Today there is a lot in between, thanks to ARIA and custom controls - that's why it would be worth considering whether 3.2.2 should be updated

[awkawk]

I would say that a set of tabs would be covered by 3.2.2. If I'm interacting with a set of tabs as a keyboard or AT user and when I move the focus/selection to the second tab the focus automatically jumps to the content within the tab and I need to shift+tab to move back to the selected tab and hit right arrow to move to the 3rd tab, that would be an example of a problem (and what if I needed to get to the 6th tab?).

This is very similar to the select box case in https://www.w3.org/WAI/WCAG21/Techniques/client-side-script/SCR19

[patrickhlauke]

@awkawk I'm guessing/hoping that what @anevins12 meant here was that it's a set of tabs where you can move between tabs using cursor keys, and THEN make an active selection using space/enter (i.e. a "tabs with manual activation" https://www.w3.org/WAI/ARIA/apg/example-index/tabs/tabs-manual.html but where, once you make that selection, it then also jumps focus into the newly shown tab). in which case I'm more inclined not to see this as a 3.2.2 violation per se as tabs are a navigation mechanism, so by their nature it feels less of a change/input here and more of an active selection (whether it's then a failure of, say, 2.4.3 Focus Order is possibly a different discussion ... I'd personally not fail it there either, but note as a best practice perhaps that it's a bit unorthodox)

[JAWS-test]

@patrickhlauke If you have Tabs with Automatic Activation - would a context change for arrow key navigation be a violation of 3.2.1 On Focus? Probably only if each tab and not the whole tab panel is considered as UIC.

[awkawk]

@patrickhlauke Sure, and that is fine. The more problematic situation would be the automatic version (https://www.w3.org/WAI/ARIA/apg/example-index/tabs/tabs-automatic.html) except that this example doesn't have focusable content within each tab that each tab loses focus to.

[JAWS-test]

@awkawk In Understanding, tabs that are clicked are excluded from SC 3.2.2. Problem is that when clicking there is no difference between Tabs with Automatic Activation and tabs with manual activation but with keyboard operation. Therefore maybe the understanding should be adjusted or the TAB example should be removed.

[patrickhlauke]

@patrickhlauke If you have Tabs with Automatic Activation - would a context change for arrow key navigation be a violation of 3.2.1 On Focus? Probably only if each tab and not the whole tab panel is considered as UIC.

to me, yes, that'd fail 3.2.1 On Focus (even when technically the focus as in document.activeElement may not have changed if the tablist uses a aria-activedescendant rather than a roving tabindex implementation)

[awkawk]

@JAWS-test The note under https://www.w3.org/WAI/WCAG21/Understanding/on-input#dfn-changes-of-context clarifies that content changing inside a set of tabs is not a change of context.

[patrickhlauke]

@awkawk

Sure, and that is fine. The more problematic situation would be the automatic version

oh, for sure, those would be unworkable for keyboard users. but I am strongly hoping that @anevins12 didn't mean this kind of tab pattern (though he should really have been more explicit/specific in the OP about what exactly he's asking about here)

[awkawk]

What is good about the pair of on input/on focus SC here is that whether you consider the tab set to be the UIC or each tab to be its own UIC, one of these SC catches this issue. For me, I think of a set of tabs as a component and the user changes the setting of that set.

[JAWS-test]

@awkawk and @patrickhlauke

It is about this sentence in the Understanding:

Clicking on links or tabs in a tab control is activating the control, not changing the setting of that control.

If a focus loss happens when clicking, this would be a context change by definition - but the question is whether it is allowed and whether it falls under 3.2.1 or 3.2.2 for tab with automatic activation.

one of these SC catches this issue

3.2.2 does not catches this issue due to the above quoted sentence from the Understanding (as long as it is in there like that).
Only 3.2.1 catches this issue. That's why I asked if 3.2.1 applies (which is only the case if each tab is a UIC and not the entire tablist).

In any case, this should be explained in more detail in the Understanding, because for radio buttons, as far as I know, the entire group is considered UIC and not the individual radio button. For most elements that are operated with arrow keys, the entire element is considered UIC and not the child elements (such as options in selection lists, treeitems in trees, menuitems in menus, gridcells in grids).

[patrickhlauke]

@JAWS-test that sentence in the understanding is a bit crap to begin with... "clicking"? should be more generally about activating, and then yes should really explain the difference between automatic and manual activation.

@awkawk

whether you consider the tab set to be the UIC or each tab to be its own UIC, one of these SC catches this issue

not ideal from a consistency of test results point of view though, admittedly...

[JAWS-test]

@patrickhlauke Maybe you want to create a PR to adjust the sentence?

[patrickhlauke]

@JAWS-test maybe if i have time...and maybe if any of my other dozens of PRs get some movement at some point ;)

[JAWS-test]

and maybe if any of my other dozens of PRs get some movement at some point

I gave up for the same reason (even though I don't have dozens of PRs on hold, but very old ones...). but I thought your PRs were more successful....

[anevins12]

Thanks for the discussion.

Implementation clarification

The implementations that I see in the real world are of the manual activation Tabs design pattern. Except that activating a tab control moves focus and I believe unexpectedly. The reason I believe that is because the manual activation APG pattern does not move focus on activation. However, I know APG is not normative. Note that I'm not caring where the focus moves right now.

WCAG clarification

The note in the Understanding doc of 3.2.2 does not specify whether this is a manual Tab or what it means by a Tab. I ASSUMED this was the APG tabs design pattern. Given what has been said above, that this criterion was written 20+ years ago, I do not know what a Tab was back then. Perhaps it's a browser tab activation?

@patrickhlauke , @awkawk, Taking a few steps back, can you each answer the following:

1. Do you agree that 3.2.2 applies to form controls-only, and why?
2. What does "input" mean to you?

[patrickhlauke]

1. 3.2.2 applies to controls where the value can be changed, but where you don't normally expect a change of context as a result of that - changing the option in a select, checking a checkbox, selecting a radio button, changing the value of a range slider, picking a date in a date picker input, toggling/untoggling a toggle button.
2. the concept of input in general is any interaction used by the user to indicate their intention. however, even though the SC is called "on input", it's more tightly scoped to "on change" on a control where you don't normally expect the change to also result in a change of context (see 1)

Now whether or not manual activation tabs are considered 1 is open to discussion/interpretation. as tabbed navigation falls somewhere in between a control where you just set a value/selection, and a control where you actually navigate, and because there are various different shades of what a "tabbed interface" actually is/does and how it behaves, i'd say there's no strong preconceived idea from a user's point of view about whether or not focus would move after selecting a tab. it's certainly less well defined than, say, how a <select> or something normally works, in my view. so whether 3.2.2 applies specifically to this case of manual activation tabs that then also move focus to the tabpanel when the user makes an active decision (which, to my mind, is more akin to an explicit action along the similar lines as "selecting a radio button and THEN hitting a submit button", conceptually similar to "select a tab you want and then active it"), i personally don't think this would fail 3.2.2. not even sure i'd fail it under 2.4.3 Focus Order. I might note it as a best practice, a la "this is a bit funky, consider not doing it/running some user testing".

There are similar other cases where the line between "is this a change of value or an explicit act of navigation/triggering something" - for instance, a button with aria-expanded and aria-haspopup that acts as the trigger for a dropdown menu ... you could argue that activating it changes aria-expanded from false to true, to it's a "change". but by its very nature it's not unexpected or outlandish if focus moves directly to the first item in the dropdown menu when it opens...

[awkawk]

1. Do you agree that 3.2.2 applies to form controls-only, and why?
   First you need to tell me what a form control is. :)

We do see controls that are used in forms as well as in general UI. For example, an accordion (or a tab control) may be used to guide or organize the user's input. The SC doesn't say anything about form controls, so I'd say no.

2. What does "input" mean to you?
   I think that the user's data entry process includes adding information (text in a text field, choosing a specific radio button, etc) and making selections that have an impact on the form or user interface. We talk about input in a variety of ways in WCAG (e.g., pointer input, input errors, keyboard input, input assistance, alternative input methods), so it is confusing.

One of the primary use-cases that this SC was originally created to address was when developers used to use a select control to create a site navigation system, and they would make the action execute onchange, and as a result keyboard users had a barrier that prevented them from getting past the first item in the list. That would typically be outside of a form element, but I'd call that input.

[awkawk]

Given what has been said above, that this criterion was written 20+ years ago

I feel old enough already! The current form of the SC dates back to 2007 (https://www.w3.org/TR/2007/WD-WCAG20-20070517/#consistent-behavior) so almost 14 years but not 20+! :)

The implementations that I see in the real world are of the manual activation Tabs design pattern. Except that activating a tab control moves focus and I believe unexpectedly. The reason I believe that is because the manual activation APG pattern does not move focus on activation.

In the manual activation case, it would need to be 3.2.2 On Input that would come into play because focus is already moved before the user hits enter so we can't say that the change is due to the focus changing

[patrickhlauke]

@awkawk

In the manual activation case, it would need to be 3.2.2 On Input that would come into play because focus is already moved before the user hits enter so we can't say that the change is due to the focus changing

I believe you meant "In the automatic activation case" here, no?

[awkawk]

@patrickhlauke I don't think so, but see if my logic makes sense to you.

When you have a set of tabs (A | B | C) and tab A is focused and selected so that the content associated with A is in view, and then you hit the right arrow and the B tab is focused but not selected ("A" content is in view still), the onfocus moment is passed. Then when you hit enter or space to select tab B and the "B" content is in view that is on input. This sequence on its own is fine, but if when you hit enter to select B the focus jumps to the first form field in the "B" content area that is where there is a problem.

On the other hand, with automatic activation, focus and selection are moved at the same time, so 3.2.1 on Focus fits if the focus is moved to the first control within "B" when the "B" tab is focused.

[patrickhlauke]

Ah, right you are @awkawk, I read around it the wrong way. See what you mean now.

Though yes, I personally disagree on that necessarily failing 3.2.2 as making an active selection of "yes, I want to view/go to this tab in the tablist" does not seem to be disruptive the same way as the original/primary use case you mentioned (as users here with the manual activation tab still have to make an active choice/confirm that they want to open that particular tab before anything happens to their focus, so they're not blocked the same way that those classic "<select> with onchange that then loads a new page" cases were).

But I guess we can agree to disagree here...

[awkawk]

I do agree that the level of barrier is different between these, and maybe the manual activation example doesn't rise to the level of a failure. If there is a select with a list of pages or sections to view and a separate "go" button to trigger the action, so users need to check it out, so maybe it isn't an issue if the solution for 3.2.1 is the same as the problem in 3.2.2?