Understanding 2.4.6 and 3.3.2 list benefits more related to 1.3.1 (and some benefits that seem unrelated altogether)

[patrickhlauke]

2.4.6: Headings and Labels and 3.3.2: Labels or Instructions are, at least to my mind, about identifying that pages have appropriate text acting as headings/labels/instructions. They are not about whether or not headings/labels/instructions are correctly marked up or associated with their relevant controls.

My take has been that it's perfectly possible for a page to pass 2.4.6 and 3.3.2, but fail 1.3.1 - if there is text acting as a label or instruction, for instance, and it is appropriate, i'd mark it as a pass under 2.4.6 and 3.3.2, regardless of whether or not it's using an appropriate <label for="..."> markup and association or similar.

Both understanding documents rightly point back to 1.3.1 in a note. However, they then seem to proceed to list benefits under the explicit assumption that the markup itself is correct, leading to confusion.

In https://www.w3.org/WAI/WCAG21/Understanding/headings-and-labels.html under Benefits:

• People who have difficulty using their hands or who experience pain when doing so will benefit from techniques that reduce the number of keystrokes required to reach the content they need.

This benefit isn't quite clearly explained. Even assuming that 1.3.1 is also followed here, I'm not clear what that's got to do with the number of keystrokes needed?

• This Success Criterion helps people who use screen readers by ensuring that labels and headings are meaningful when read out of context, for example, in a Table of Contents, or when jumping from heading to heading within a page.

It would be good to note that this benefit is explicitly about headings/labels that also pass 1.3.1.

This Success Criterion may also help users with low vision who can see only a few words at a time.

(is this supposed to be another bullet point? or is it part of the previous bullet point?)

It's not quite clear here how having descriptive headings/labels can help low vision users? Particularly as this SC doesn't mandate the use of headings/labels, but it does mandate that where present, they must be descriptive. I could understand if the original idea was that having headings in a large document helps visually structure documents more clearly, meaning that LV users can more easily skim over a document to find the correct section...but the SC doesn't actually mandate those. Is the benefit here along these lines, but ensuring that (under the assumption headings are already being used) these headings make sense/help LV users know that this is the correct section they're likely to find what they're looking for when skimming?

In https://www.w3.org/WAI/WCAG21/Understanding/labels-or-instructions.html under Benefits:

• When label elements are associated with input elements the label is spoken by screen readers when the field receives focus and users with impaired motor control are helped by a larger clickable area for the control, since clicking on the label or the control will activate the control.

This feels far more like a benefit of 1.3.1 (and to an extent 4.1.2, for the screen reader aspect) than 3.3.2.

• Field labels located in close proximity to the associated field assist users of screen magnifiers because the field and label are more likely to visible within the magnified area of the page.

This benefit is about the proximity of text acting as a label. The SC does not actually touch on this aspect of proximity? i.e. it's arguably possible to pass 3.3.2 if the author IS providing a label, but the label isn't directly adjacent/close (for whatever wooly non-normative definition of "close proximity", which is not defined anywhere)

• Clearly identifying required fields prevents a keyboard only user from submitting an incomplete form and having to navigate the redisplayed form to find the uncompleted field and provide the missing information.

arguably, it may be worth stressing first that it benefits all users (also including blind/LV/COGA users in particular). Then perhaps focus on the case of keyboard users not having to navigate through the whole form again laboriously until they reach the fields they missed out. (and also, not just required fields, but any fields that have particular requirements that aren't explained)

[awkawk]

@patrickhlauke I think that you are pointing out some issues that we should address. Would you like to submit a pull request with recommended changes?

[patrickhlauke]

i'd first like to get an idea if my interpretation is correct? probably, to put another way: are 2.4.6 and 3.3.2 independent of 1.3.1? or is a failure of 1.3.1 (for, e.g., headings not marked up as actual <h1>-<h6> headings, or <label> elements not being used or not associated correctly, etc) an automatic failure of 2.4.6 / 3.3.2? I tend towards them being independent (but of course related).

if that's the consensus, then sure, happy to submit a PR :)

[awkawk]

I believe that your interpretation is correct, but I'll add it to a survey to get more of a group opinion.

[mraccess77]

@patrickhlauke your understanding is correct that 2.4.6, 2.4.10 and 3.3.2 do not require programmatic association.

[detlevhfischer]

@patrickhlauke exactly as I see it, Patrick.

[patrickhlauke]

@awkawk PR submitted #612

[edit: having mulled this over some more, pushed further changes to the PR - admittedly, it's now quite verbose in terms of notes, but I think it now covers more of the nuances and cross-connections between the 2.4.6, 3.3.2 and related concepts in 1.3.1 and 4.1.2]

[mbgower]

@patrickhlauke

I think it now covers more of the nuances and cross-connections between the 2.4.6, 3.3.2 and related concepts in 1.3.1 and 4.1.2

just wait until you get Label in Name in the mix! :)

[patrickhlauke]

I'll leave that addition up to you @mbgower ;)

[awkawk]

@patrickhlauke The WG approves the direction, although @mbgower will have some input on the pull request. :)

[patrickhlauke]

Just picking up on some of the comments from the minutes https://www.w3.org/2019/02/12-ag-minutes.html#item10

From a development perspective, you determine the label from the label. From the non developer perspective, its a visual determination. "label" has a lot of nuanced meanings. can be label element or text visually related to input. I think we end up into issues because of this.

As we seem to agree that the SC is not dependent on 1.3.1 (or 4.1.2), I'd argue that it's the latter (the non developer/visual determination) that is needed here. Same for "headings" not strictly being just those marked up as <h1>-<h6>.

Also, as WCAG is meant to go beyond just HTML, just thinking about <label> is probably not the right approach.

One distinction I've used in discussions internally about this is the slightly more verbose "content that acts as a heading or label", with additional clarification that this is distinct from content that is marked up as a heading or label.

But yes, agree that then "headings" and "labels" that only work for, say, AT users are an additional point of confusion.

[patrickhlauke]

And yes

This change is removing text about labels that has existed for years.

however, this text has caused confusion ever since for auditors (from speaking to various auditors and what they do/don't consider these SCs to be about)

[awkawk]

Closing this issue as we are reviewing Pull Request 612 next week.