Restore the need for accuracy/correctness to 3.3.2 Labels or Instructions

[davidofyork]

A recently published update to the Understanding document for 3.3.2 Labels or Instructions has made changes that effectively render the success criterion pointless.

In an attempt to disambiguate the slight overlap between 3.3.2 Labels or Instructions and 2.4.6 Headings and Labels, #1792 removed several references to the need for "clear and unambiguous" labels and instructions. The justification was that 2.4.6 concerns the quality of headings and labels, whereas 3.3.2 concerns the mere presence of labels or instructions (regardless of how good/comprehensive/accurate they are). This, I feel, was a misstep.

As others and I commented elsewhere, these changes go against the intent (if not the normative wording) of 3.3.2.

The normative text - "Labels or instructions are provided when content requires user input" - is unhelpfully terse.
However, the stated goal that "Users know what information to enter" and the intent "to have content authors present instructions or labels that identify the controls in a form so that users know what input data is expected" is more indicative of the intended purpose of 3.3.2.

By removing any need for clarity or quality or accuracy in 3.3.2, then what is the benefit of conforming to this SC?

(Also, if any requirement for clarity or descriptiveness is punted squarely to 2.4.6, why list G131: Providing descriptive labels as a sufficient technique?)

Picking up from #3795 (comment), 3.3.2 now effectively says that anything goes, as long as it looks like a label or instruction. How does that help users?

Without any requirement for accuracy or correctness...

• a nonsense label would pass 3.3.2: <label for="tel">XWPSWTLNMZ</label>
• an incorrect label would pass 3.3.2: <label for="tel">Name</label>
• an ambiguous label would pass 3.3.2: <label for="consent">I agree</label>

Now, you could argue that these examples impact everyone and therefore can be considered "bad UX" and beyond the scope of WCAG. But if that's the case, why have this success criterion at all? Who does the mere provision of labels or instructions actually benefit?

It would be like saying that 1.1.1 Non-text Content should only be about the presence of a text alternative, not about whether the text alternative accurately describes the content. Admittedly, 1.1.1 has the additional clause of "a text alternative that serves the equivalent purpose" and 1.1.1 also hasn't been split over two closely related success criteria, but that's where we are. In my opinion, 3.3.2 would greatly benefit from a similar qualifying clause, if not in the normative text then in the Understanding document.

At the very least, accuracy should be an explicit expectation of 3.3.2 (in that, the label or instruction must identify/explain what the control does). Whether it does that clearly or sufficiently descriptively is then a matter for 2.4.6 (although I accept that an accurate/correct label will likely be sufficiently descriptive for 2.4.6 in most cases).

In terms of specific actions, I wouldn't necessarily reverse the changes in #1792, but instead make an explicit expectation of accuracy. So, for example:

• What to do: Provide labels or instructions for inputs [that accurately describes what data is expected].
• "The intent of this Success Criterion is to have content authors present instructions or labels that [accurately] identify the controls in a form so that users know what input data is expected."
• "While this Success Criterion requires that controls and inputs have [accurate] labels or instructions, whether or not labels (if used) are sufficiently clear or descriptive is covered separately by 2.4.6: Headings and Labels."

And perhaps even an additional sentence to emphasize the need for accuracy:

• "Although WCAG 3.3.2 focuses primarily on ensuring that labels or instructions are provided, it is still essential that these labels or instructions are accurate."

[mbgower]

Draft Working Group Response

Thanks for flagging your concern, David.

the slight overlap between 3.3.2 Labels or Instructions and 2.4.6 Headings and Label

As you note, from a data modelling perspective, the two SCs are not ideally normalized, but there is clear pre-existing non-normative language establishing the division in the understanding document, such as:

whether or not these labels are sufficiently clear or descriptive is covered separately by 2.4.6: Headings and Labels.

It is consistent from both the normative language and from pre-exisiting understanding documents that 3.3.2 is about the presence of labels, and 2.4.6 covers the quality of them.

By removing any need for clarity or quality or accuracy in 3.3.2, then what is the benefit of conforming to this SC?

There are three basic factors concerning labels needed to improve the accessibility of form inputs: existence, quality, and programmatic indication.
Dividing these three factors across multiple success criteria is fairly common in WCAG (although not consistently). 3.3.2 requires the existence of labels or instructions for inputs. Once they visually exist, they then have a requirement to be programmatically linked to the inputs to meet 1.3.1 Info & Relationships. The quality of the actual text content in the labels is covered by 2.4.6.

This harkens back to the division of the guidelines into principles such as Perceivable and Understandable.

(Also, if any requirement for clarity or descriptiveness is punted squarely to 2.4.6, why list G131: Providing descriptive labels as a sufficient technique?)

G131 is listed as a sufficient technique for 3.3.2 only if it is combined with one of a number of other techniques. As the technique itself notes, it is "Sufficient using a more specific technique".

In my opinion, 3.3.2 would greatly benefit from a similar qualifying clause, if not in the normative text then in the Understanding document.

Whether it is better to shove qualitative and quantitative considerations into the same SC, as in 1.1.1 or to carve it up in some way, is an ongoing discussion in WCAG 3. From an automated testing perspective, it is typically easier to test for the existence of something than the quality of it. What we can say emphatically is that the WCAG 2 Task Force cannot change the normative text in any meaningful way. Further, while the Task Force has the ability to clarify and expand on the normative text in the Understanding documents and techniques, we do not have the ability to contradict or re-interpret it (much as it is tempting to do in many circumstances). Those kind of considerations are passed on to WCAG 3.

For this reaason, your requests to add the concept of 'accuracy' to an SC that does not specify it is out of scope of current work. It would also render 2.4.6 almost entirely redundant.

By the same token, it seems to be an unnecessary change, since there is the other SC which does have language that is much easier to argue indicates a need for accuracy, 2.4.6. Simply, if you do not feel that a label is accurate, you can already fail it against Headings and Labels.

[mbgower]

BTW, speaking personally, I think accuracy is an easier yardstick than describes, and I am working on getting that incorporated into WCAG 3 considerations. Have a look at my Outcome: Meaningful images have a text alternative

[davidofyork]

Thanks for your considered reply, Mike. However, I respectfully disagree with the thrust of your rebuttal.

There are three basic factors concerning labels needed to improve the accessibility of form inputs: existence, quality, and programmatic indication. Dividing these three factors across multiple success criteria is fairly common in WCAG (although not consistently).

I'm struggling to think of any other examples in WCAG where existence, quality, and programmatic indication are neatly spread across multiple success criteria...

• As mentioned previous, 1.1.1 Non-text Content conflates existence and quality into a single SC.
• 1.2.2 Captions (Prerecorded) seems to be squarely about the existence of captions, but one of the associated failures (F8) concerns the quality of captions, suggesting that the SC is also concerned with quality.
• 1.2.5 Audio Description (Prerecorded) also seems to be squarely about the existence of audio description, but there is no corresponding SC that covers the quality of audio description. Instead, the linked definition of audio description implies that it needs to be of sufficient quality "to describe important visual details that cannot be understood from the main soundtrack alone". So again, a single SC concerns both existence and quality. The same applies to sign language interpretation in 1.2.6.
• 2.4.2 Page Titled conflates existence and quality into a single SC.
• 4.1.2 Name, Role, Value focuses squarely on the existence / programmatic indication of accessible names, but there is no corresponding SC regarding the quality of accessible names, as discussed elsewhere.
• If we look at the other concern of 2.4.6 Headings and Labels, which is headings, there is a corresponding SC regarding programmatic indication (1.3.1) but no corresponding SC regarding the existence of headings. There's 2.4.10 Section Headings, which is AAA, but even that requires "headings that introduce [sections]" (a measure of quality).

There is no clear precedent for compartmentalizing the accessibility of labels in this way. As a result, I still maintain that, without any requirement for accuracy, 3.3.2 has been rendered pointless. Merely providing labels does not benefit anyone.

This harkens back to the division of the guidelines into principles such as Perceivable and Understandable.

In that case, the assertion that 3.3.2 concerns only the existence of labels is even more misguided.

3.3.2 Labels or Instructions falls under Guideline 3.3 Input Assistance, which states: "Help users avoid and correct mistakes". This, in turn, falls under Principle 3 Understandable, which states: "Information and the operation of the user interface must be understandable".

The mere existence of labels will neither help users avoid and correct mistakes nor contribute to an understandable user interface.

As a minimum, I would urge you to (re)consider adding the disclaimer I mentioned in my earlier post, along the lines of:
"Although 3.3.2: Labels or Instructions focuses primarily on ensuring that labels or instructions are provided, it is still essential that these labels or instructions are accurate."

However, if you are still reluctant to include any mention of accuracy into the Understanding document, how about following the lead of 1.2.2 and including a failure example of an inaccurate label? This would make it clear that accuracy is a requirement.

Failing that, how about following the lead of 1.2.5 and 1.2.6 and adjusting the definition of label to require a degree of accuracy? This would (indirectly) make it clear that accuracy is a requirement.

Any of these approaches would help to establish at least some benefit to following 3.3.2.

[JAWS-test]

If 3.3.2 only checks the existence, but not the correctness of labels and instructions, then 2.4.6 is problematic in that it only checks labels. This means that the instructions could be completely wrong and there would be no SC to evaluate this.

[electronicwoft]

I like the threefold split, but I'd argue that 'quality' is problematic in the same way 'describe' is in 2.4.6 ... that is, and forgive this use of language, they are 'qualatative'.

SC2.4.6 is likely ignored by most practitioners because they don't understand the term 'topic', or 'purpose' is ambiguous, so the presence of a heading and its programmatic headingness are ticked off, but not whether its meaning is relevant.

To determine whether a word or phrase is meaningful in the context in which it occurs is surprisingly difficult philosophically so without a bouncing ball likely impossible for most practitioners.

The recently addedd In Brief section does absolutely nothing in my view to improve one's understanding of the SC nor guide readers as to how they might evaluate this success criterion, and the existing content with a requirement for 'descriptive' doesn't either.

For any of the success criteria that deal with meaning, there needs to be a way for evaluators to determine whether text in this case refers to that which it references regardless of the language in which it is presented in ways that are not wholly dependent on the socio-cultural characteristics of an evaluator.

And this may require delving into semantics or grammar to provide a mechanistic procedure for determining whether a label or heading are appropriate.

[GreggVan]

@JAWS-test If we are talking about visible lables -- then having the wrong labels on things is not an accessibility violation. They are bad for everyone - not just people with disabilities -- so it does not meet the test of being an accessibility issue.

Now if the labels are understandable by people who do NOT have disabilities -- but not by people who DO -- then that is an accessibility issue.

Also note that a "good" lable text is like good "alt" text -- and is subjective. So

SO - agree that dividing it into "has a label" (objective - testable)
and "the label is good (subjective - not testable)
is good with us handling "label is good" via assertions or just recommendations. And as for Accuracy -- that is off our table.

[davidofyork]

Auditor convenience and a desire for taxonomical neatness should not take priority over actual benefit to people with disabilities. Yes, a threefold split between 3.3.2, 1.3.1, and 2.4.6 is tidy and convenient, but leaves 3.3.2 devoid of purpose.

@GreggVan - why is accuracy off the table?

Without accuracy, you cannot satisfy either the guideline or principle under which 3.3.2 falls:

• Guideline 3.3 Input Assistance: Help users avoid and correct mistakes.
• Principle 3 Understandable: Information and the operation of the user interface must be understandable.

The mere existence of labels (with no consideration of accuracy) will neither help users avoid and correct mistakes nor contribute to an understandable user interface.

[mraccess77]

SC 3.3.2 requires that labels or instructions be present - the definition of a label indicates that it is present for all users. So, the SC would seem to include requirements that apply to all users. If we say that the need for labels being being needed for everyone means that it's not a WCAG requirement then it seems we need to remove SC 3.3.2 which does not make sense to me.

[GreggVan]

No. Having labels IS a WCAG because there are many cases where the purpose is clear to the average user even if it does not have a label. But for people with cognitive disabilities - a label may be needed where it is not otherwise. So having a label is an accessibility issue.

HOWEVER -- once you have a label -- if it is wrong - that would keep everyone from using the element. So Accuracy is NOT an accessibility issue. Also accuracy is subjective - so not very testable. For the most part it is because people would never (except by mistake) but a wrong label on - because it would impair use by all users.

WCAG does not - (and has been specifically instructed not to ) include usability issues that apply to all users equally. It only covers things that don't apply to all users -- or that significantly impact people with disabilities but not significantly impact others -- and thus don't get done unless they are called out as accessibility issues.

[davidofyork]

But for people with cognitive disabilities - a label may be needed where it is not otherwise. So having a label is an accessibility issue.

Yes, a label may be needed specifically to benefit people with cognitive disabilities, but it still needs to be accurate! Otherwise, it isn't going to benefit anyone!

As I mentioned at the start of this thread, and what I think @mraccess77 is also getting at, is if you argue that inaccurate labels potentially impact everyone and are therefore beyond the scope of WCAG, then why have success criterion 3.3.2 at all? What does it leave? Who does the mere provision of labels or instructions (with no concern for accuracy) actually benefit?

For the most part it is because people would never (except by mistake) but a wrong label on - because it would impair use by all users.

One would hope authors would never purposely provide a wrong label, but you'd be surprised!

And if completely wrong labels are indeed unlikely, there are still many instances of imprecise labels - <label for="first_name">Name</label> - or ambiguous labels - <label for="consent">I agree</label> - that would now pass 3.3.2.

To discount any concern for accuracy because you can't imagine authors getting it wrong, is a very... optimistic stance to take.

[GreggVan]

Re-read my answer. I did not say that authors could not get it wrong. I said that if they had a label and it was wrong - it would be a problem for everyone - and thing that are problems for everyone are not accessibility issues.

Also I said that "accuracy" is subjective.

best
g

[electronicwoft]

@davidofyork ... the other aspects to the wording of this success criterion apart from its terseness is the disjunction 'or' which can either be interpreted as inclusive or exclusive ... that is, if input is required, either a label or an instruction may be present, but not necessarily both.

There is a sense in which instructions are little more than something within the HTML element.

As @JAWS-test points out, there's no SC covering the quality of instructions so that 'type your phone number' will pass this success criterion, and, while this may impact everyone, it likely affects people with certain disabilities more who cannot comprehend context etc.

Also, the 'required' is problematic because:

1. optional data input can also enforce format and length restrictions.
2. it is most commonly interpreted as adding a dreaded asterisk without conveying information about format or length because 'required' is interpreted narrowly as 'mandatory'

There is also much confusion about what constitutes instruction and help, and entrenched orthodoxies about how input instructions are to be implemented.

In the update, "users know what information to enter" is at best ambiguous as my example above illustrates.

And the understanding document only cites 'data format' which is commonly and narrowly interpreted as 'dd/mm/yyyy' and little else, but there are data entry constraints other than format that are too often only revealed on error.

Ideally, the understanding document should make explicit the typeds of constraints applicable to data input and provide relevant examples of each of these which it currently does not, and make a distinction between what which identifies or describes the purpose of and that which instructs.

[davidofyork]

No. Having labels IS a WCAG because there are many cases where the purpose is clear to the average user even if it does not have a label. But for people with cognitive disabilities - a label may be needed where it is not otherwise. So having a label is an accessibility issue.

@GreggVan Okay, let me put it another way. What is the accessibility issue that you feel is being addressed by merely providing a label (with no concern for accuracy)?

[yatil]

Many SCs chicken-out when it comes to accuracy. 4.1.2, for example, says that a name can be programmatically determined, but it doesn’t say that it needs to be a name that describes or identifies the UI component accurately.

The Understanding, however, seems to imply correctness in the In Brief section (emphasis mine):

Goal
People using assistive technology understand all components.
What to do
Give components correct names, roles, states, and values.
Why it's important
Assistive technology only works well when code is done properly.

I don’t think we can have it both ways. Personally, I think that labels and names must be at least in the general vicinity of being correct to pass the success criterion.

The “if it is bad for everyone, it’s a general usability issue and not an accessibility issue” argument falls down when we understand that disabled people are part of general usability considerations and that people with disabilities are often more affected by general usability malpractices.

In lieu of changing the SC, I think being clear that correct labels are implied in the Understanding is the correct way to address this.

[detlevhfischer]

@yatil

Many SCs chicken-out when it comes to accuracy. 4.1.2

Since this started discussing 3.3.2 is this another or a new issue?
We had a discussion whether the correctness (once there is some accname) could not be better dealt with in 2.4.6.

[yatil]

@detlevhfischer It's an example of a related issue which can inform this issue.

[jared-w-smith]

I'm dismayed at these changes and the pedantic arguments for them. The normative WCAG definition for "label" is "text or other component with a text alternative that is presented to a user to identify a component." If the text does not actually "identify the component", but is instead gibberish, non-identifying, or inaccurate, then it does not meet the definition of what a label is, thus cannot reasonably be considered a label for meeting 3.3.2.

This SC is, after all, under the "Understandable" principle which makes it alarming that some are arguing that labels that are antithetical to making an input understandable are sufficient.

I said that if they had a label and it was wrong - it would be a problem for everyone - and thing that are problems for everyone are not accessibility issues.

It is correct that WCAG should focus on things that impact users with disabilities, but this does not mean that it should focus ONLY on things that impact ONLY users with disabilities. If this were the case, then most of WCAG would not exist. One can readily argue that inaccurate or non-descriptive text disproportionately impacts users with cognitive and learning disabilities and users with visual disabilities that may not be able to fully contextualize or understand that the text does not accurately label the thing the visual presentation and semantic relationships suggest it does.

[GreggVan]

+1 to @jared-w-smith

RE @davidofyork There are controls whose purpose is clear by their position to other controls or text on a page. But would not be clear to a screen reader or someone with low vision who is zoomed in on the control and cannot see the full layout or someone with a cognitive disability that does not see "the whole" so can't figure out the purpose of this one control. So it has to have a label. That is the accessibility issues. Best g

[davidofyork]

@GreggVan

So it has to have a label.

But if that label isn't accurate, it won't benefit anyone.

[patrickhlauke]

There are controls whose purpose is clear by their position to other controls or text on a page. But would not be clear to a screen reader or someone with low vision who is zoomed in on the control and cannot see the full layout or someone with a cognitive disability that does not see "the whole" so can't figure out the purpose of this one control. So it has to have a label

that is a completely separate discussion about the control needing to have a "name", not "label"

This whole conversation is twisting and turning itself into areas that are only marginally related, at best.

For what it's worth, the high-level view from my point of view is:

• WCAG has, for better or worse, always had weirdly and awkwardly overlapping SCs - this has led to inconsistencies and confusion
• 3.3.2 Labels or Instructions (A) normatively talks about the presence of labels or instructions
• 2.4.6 Headings and Labels (AA) normatively talks about the descriptiveness of headings and labels (in true WCAG fashion, what is or isn't "descriptive" is left rather vague...)

The original aim of the changes from a few months ago (which went through review of the AGWG) was to disentangle the apparent overlap of 3.3.2 and 2.4.6. From the discussion at the time, we settled on the idea that 3.3.2 didn't normatively mandate the accuracy/correctness of the label, but merely (from the normative wording) its presence, and that the accuracy/correctness would be what the "descriptive" requirement from 2.4.6 to try and define that a bit more clearly (rather than the big handwave it has).

• If we argue that 3.3.2 also includes an implicit notion of accuracy/correctness, then that makes the "labels" part of 2.4.6 redundant - because of course if labels are accurate/correct, then they're likely sufficiently descriptive (or are there examples where you'd say "yes, this label is correct, but not descriptive enough").

• If we argue that 3.3.2 does not include this notion of accuracy/correctness, a nonsense label like XYZ would pass 3.3.2 but fail 2.4.6. So in the end it would still fail (assuming you're doing a AA audit, rather than just a single A one).

There are still cases where a control lacks an actual visible label - for instance, filter or search fields that haven't been given any visible label, or where they use placeholder (which fails the test of having a label when the placeholder text disappears on focus or is overwritten by an actual value), so it's not "redundant". Just that the cases for then failing 3.3.2 are less common (and mostly the failures would fall under 2.4.6).

Regarding the definition of "label" ... in the mentioned discussion of 4.1.2 Name, Role, Value (when we tried to work out if "Name" means "correct name" or just "any name"), we did end up in a discussion about what "identify a component" means ... and whether it meant "knowing what it is/that it has the correct name" or "having a unique way of referring to/identifying something (so even a nonsense alphanumeric string would count as being something that 'identifies' a component)", and we leaned begrudgingly towards the latter because otherwise if accuracy of "Name" was included in 4.1.2, then it would have made 3.3.2 partially redundant ... and again, we're back in the "this is because WCAG SCs are oddly overlapping").

So, long story short, the decision needs to be whether or not 3.3.2 had an implicit understanding that labels (or instructions) need to be correct or not, and whether or not a label/instruction that is blatantly incorrect (for everybody) also fails 3.3.2. And if so, we need to partially neuter 2.4.6 or at least explain that in most cases, a pass of 3.3.2 will mean a pass of 2.4.6 for labels, making the latter mostly redundant (unless we can come to a good example where a label is correct enough to pass 3.3.2 but not descriptive enough to also pass 2.4.6).

And then once that question is answered, we then need to further decide if the fact that a form field is "required" or not ... falls under "correct/accurate" label, or "descriptive" label... the follow-up battle.

And yes, overlapping SCs are fun. (and I hope we don't now drag back in the 4.1.2 Name... aspect, or even the 1.3.1 Info and Relationship part of something being programmatically marked up as an actual <label> or similar)

[patrickhlauke]

But if that label isn't accurate, it won't benefit anyone.

Which is why in the current division between the SCs, it would still fail (2.4.6 though, not 3.3.2)

[patrickhlauke]

as an aside, in the aforementioned discussion around 4.1.2 Name, Role, Value, we did in the end concede that "Role" mean to mean "appropriate role" (a change that @scottaohara then pushed), but that was mainly because there was no other equivalent SC that would have covered this aspect already (whereas for "Name" we argued that the correctness/appropriateness of the name was covered to an extent by 3.3.2 in combination with 2.5.3 Label in Name ... oh, tangled world wide webs we weave)

[davidofyork]

But if that label isn't accurate, it won't benefit anyone.

Which is why in the current division between the SCs, it would still fail (2.4.6 though, not 3.3.2)

Sure. But @GreggVan was claiming that the mere presence of a label (currently 3.3.2's only requirement) would benefit screen reader users, low vision users, people with cognitive disabilities. That's not the case.

If we argue that 3.3.2 also includes an implicit notion of accuracy/correctness, then that makes the "labels" part of 2.4.6 redundant - because of course if labels are accurate/correct, then they're likely sufficiently descriptive (or are there examples where you'd say "yes, this label is correct, but not descriptive enough").

What's wrong with a bit of redundancy? I'd rather an inaccurate label fail both 3.3.2 (on accuracy/correctness) AND 2.4.6 (on descriptiveness), than have it pass 3.3.2 (due to merely existing) and fail 2.4.6 (on accuracy/correctness). It would also ensure that accuracy is addressed in the edge case of someone performing a single A audit.

As @jared-w-smith pointed out, a label, by WCAG's own definition, has to identify a component. And no, that doesn't mean a unique but nonsense alphanumeric string. That may have sufficed for the programmatically determinable aspect of 4.1.2, but 3.3.2 falls under the more human-oriented Guideline 3.3 Input Assistance: Help users avoid and correct mistakes, and Principle 3 Understandable. Inaccurate, imprecise, or nonsense labels will simply not achieve that.

[jared-w-smith]

or are there examples where you'd say "yes, this label is correct, but not descriptive enough"

I believe this is precisely the case.

3.3.2 requires a label, and a label is (by normative definition) to allow "a user to identify a component". A user can't "identify a component" if the label text is entirely inaccurate. This is reflected in the Understanding document's goal: "Users know what information to enter."

2.4.6 at AA additionally requires that those label texts "describe topic or purpose".

A focus on "identify" for 3.3.2 and "describe" for 2.4.6 is the key. Minimally descriptive, yet accurate, label text is necessary to "identify" components in 3.3.2, but additional description of topic or purpose may be necessary to meet 2.4.6.

[patrickhlauke]

@jared-w-smith give me a real-world example then of a label that is correct, but not descriptive enough...

as in, if we're saying 3.3.2 is identify (correctly), 2.4.6 is describe, let's draw the line here (or at least start roughly working towards it) where we move from one to the other

[patrickhlauke]

As @jared-w-smith pointed out, a label, by WCAG's own definition, has to identify a component. And no, that doesn't mean a unique but nonsense alphanumeric string.

well, that's not what the group came to decide when it came to "Name" for the same type of question. I can "identify" a control by saying "The form field with the XYZ label" even if XYZ doesn't mean anything to me. identify vs understand.

What's wrong with a bit of redundancy?

nothing as long as it's documented specifically, so that you don't end up with one auditor failing something under 2.4.6, another under 3.3.2, and a third failing it under both...

but of course, if you then have the same thing failing both, people may rightly ask "so why the hell are there two separate SCs that cover the exact same thing?"

to be clear, if i had my own way, i'd completely deprecate or modify the AA one to not have an awkward overlap/appear to cover the exact same thing for labels, but here we are trying to at least bring some consistency in how the two SCs interoperate

[jared-w-smith]

give me a real-world example then of a label that is correct, but not descriptive enough...

Here are a few ideas with very minimal markup provided...

These inputs have a label to identify them, but does not adequately describe the purpose of each field.

Name:
<input type=text id=firstname> <input type=text id=lastname>

as opposed to

First name:
<input type=text id=firstname>
Last name:
<input type=text id=lastname>

A checkbox with a generic identifying label text as opposed to one that describes the topic/purpose:

<input type=checkbox> Agree

compared to

<input type=checkbox> Agree to our 47 page terms of use that requires the sacrifice of your firstborn

Or an input that identifies the type of content required, but does not describe the actual topic of the content required:

Maiden name:
<input type=text>

compared to

Your mother's maiden name (required):
<input type=text>

I can "identify" a control by saying "The form field with the XYZ label" even if XYZ doesn't mean anything to me. identify vs understand.

But you can also "identify" the presence of the input field in absence of label text at all, so why have this SC at all? If the intent is indeed to make the input "understandable" as opposed to merely "perceivable", then a reasonable level of accuracy is necessary.

[patrickhlauke]

These inputs have a label to identify them, but does not adequately describe the purpose of each field.

Name:
<input type=text id=firstname> <input type=text id=lastname>

That already fails identify (even the wider definition, without accuracy/correctness involved) - I see one label and two fields. so at least one of them has no label at all. So not a good example for this...

But you can also "identify" the presence of the input field in absence of label text at all

By saying what? "the 23rd generic text input on the page"?

so why have this SC at all?

well yes, that is the fundamental dilemma we've been having with some of the old SCs (and heck, even the new ones) and their awkward overlaps

(coupled with the "ethos" of "if it's a problem for everybody, not just PWDs, then it's not a WCAG problem")

[JAWS-test]

@patrickhlauke

That already fails identify (even the wider definition, without accuracy/correctness involved) - I see one label and two fields. so at least one of them has no label at all. So not a good example for this...

I, on the other hand, think that's a very good example. Many people will realize what the meaning of the two fields is, but not everyone will. Analogous to a field for the telephone number, where I can have 2 to 4 fields for the country code, the city, the number and the extension. Or 3 input fields for a date.

In SC 2.4.6, the example with the name is even explicitly mentioned:

A form asks for the name of the user. It consists of two input fields to ask for the first and last name. The first field is labeled "First name", the second is labeled "Last name".

[davidofyork]

@ronsmantpg

FWIW, I thought "clear and unambiguous" in 3.3.2 referred to the presence of the label, not the content

If that were the case, it wouldn’t serve the stated goal and intention of the SC, not to mention the Guideline and Principle it falls under.

@patrickhlauke

the problem, it seems, is that "clear and unambiguous" was - paradoxically - an ambiguous statement which led many to also interpret it as meaning "correct/descriptive", and is what started the debate in the first place

I don’t think it was “clear and unambiguous” that led to that interpretation (and I wouldn’t necessarily argue to reinstate those exact words) but they certainly helped support the notion that this is about helping users identify and understand components.

[alastc]

WCAG has, for better or worse, always had weirdly and awkwardly overlapping SCs - this has led to inconsistencies and confusion

Given the multiple requirements for single elements (e.g. labels), you either try and rationalise somewhat (and end up with some odd overlaps), or you have a lot of redundancy where the same requirements are repeated in different places.

FWIW the "what is the thing in the interface" categorisation of WCAG 3 should reduce overlap, we'll have to keep an eye on redundancy.

Overall (and chair-hat-off), when you combine the requirement for a label to exist with a natural tendency to put something logical into the label, it's generally going to work.

You could get some odd 'malicious compliance' examples, but it is likely to stray into the area of "terrible for everyone", rather than an accessibility issue. Therefore I support Mike's reply above.

[electronicwoft]

BCNF aside, the advance into and retreat from The Informative to support success criteria is primarily now the problem here and elsewhere with WCAG 2.x.

And, while the purported overlap and/or redundancy might be an issue for some, the more pressing issue for practitioners is "how do I determine whether this label is appropriate for that thing consistently".

The subject of this issue is about restoring the appropriateness of referant and reference, and, for my money, 'identify' is preferred because - as stated above - it is already in the normative definition of 'label'.

So, rather than endlessly tinkering with the understanding documents, what about defining 'describe' and 'descriptive' - quelle horreure) - in the normative glossary for WCAG 2.3.

As it stands, 'describes' is problematic because in English it carries the connotation of 'catalogue the characteristics of' which is undesirable, but it is consistent with 'being supplementary to' which is a connotation used elsewhere in W3 documentation.

So, following Patrick's distinction above, a label identifies in 3.3.2 and describes in 2.4.6, but 'describes is normatively defined in the glossary as supplementing that which identifies for cases in which context may be required for people with given impairments.

This does not make 'label' ambiguous - it gives pointers to how best it might be interpreted and applied.

(yes, but this does introduce an inconsistency for 1.1.1 bulletpoint 1 ...)

WCAG 3.0 is years away and - in my view - requires some pretty significant surgery before it can be released into the wild, so let's have a WCAG 2.3 that cleans up some of these ambiguities lest WCAG 2.x is superseded by orthodoxies in practice.

[davidofyork]

@alastc
Given the multiple requirements for single elements (e.g. labels), you either try and rationalise somewhat (and end up with some odd overlaps), or you have a lot of redundancy where the same requirements are repeated in different places.

But this attempt at rationalization has neutered 3.3.2 in such a way that it serves no purpose other than as a prerequisite for 2.4.6. This is not the function that success criteria are meant to have. As I keep pointing out, the mere presence of a label (with no concern for accuracy) benefits no one.

Overall (and chair-hat-off), when you combine the requirement for a label to exist with a natural tendency to put something logical into the label, it's generally going to work.

We're seemingly reluctant to allow for duplication and redundancy across SCs because developers might get confused or maliciously comply, but at the same we're suggesting that an explicit requirement of accuracy is unnecessary because developers have a natural tendency to do the right thing.

[GreggVan]

Sorry but

1. you can't require what you can't objectively test. And "accurate" and "correct" are value judgements.

2. if the labels are there -- they

• ETHER
  • will be accurate (because why would anyone put a label on that would be inaccurate for every user with and without disabilities )
• OR
  • they will be inaccurate -- in which case it is not an accessibility issue because it is inaccurate for everyone - not just people with disabilities

Since it is highly unlikely that people will deliberately create labels that are inaccurate (for everyone) AND they clearly think the label is accurate (even if it is bad), requiring it to be accurate won't change it because they already thought it was. And if you say - well, third-party evaluators may disagree -- then you made my point - that it is a judgment and not something that is true or false.

Thus we should not (because we don't have grounds to and can't) add a judgment item like 'accurate' to the requirement.

[davidofyork]

@GreggVan
Sorry but
1. you can't require what you can't objectively test. And "accurate" and "correct" are value judgements.

Sorry, but "clear" and "descriptive" are also value judgements. We require those and objectively test for those under 2.4.6 Headings and Labels. It can be done.

[electronicwoft]

"1. you can't require what you can't objectively test. And "accurate" and "correct" are value judgements."

'describe', 'descriptive', 'equivalent', similarly require ''judgment' to assess either by designer, developer, or evaluator ...

I'd argue that 2.4.6 is largely ignored or given scant attention precisely because there is no mechanistic or repeatible way of determining whether this or that 'describes topic or purpose' because the meaning of 'describe' (in English) simply means 'to put into words'. But which words? One or many? Direct or indirect?

[GreggVan]

@davidofyork
Pointing to one error in the guidelines - is not justification for another. "Clear" and "Descriptive" are also subjective and should be in notes and not requirements.

IN WCAG 3 we are looking for ways to include subjective guidance -- but it is not testable reliably except if you are nowhere near the boundaries.

[davidofyork]

@GreggVan
Pointing to one error in the guidelines - is not justification for another. "Clear" and "Descriptive" are also subjective and should be in notes and not requirements.

The entire normative requirement of 2.4.6 is that headings and labels describe topic or purpose. Are you suggesting that's an error? And if so, should we instead be looking to deprecate 2.4.6 entirely?

[chaals]

it is not testable reliably except if you are nowhere near the boundaries.

Which is likely to mean that in the vast majority of cases, it's pretty easy to judge.

If 8/10 people would agree on 8/10 cases, then on balance that means about 2/3 of the time the guidance is useful in determining what to do.

"test objectively" is a theoretical aim that's noble. However, letting it be the enemy of providing useful guidance that in practical terms actually mostly works seems like a bad idea.

There is a difference between "nobody can work out what this means", and "I can construct a plausible argument that is counter to most people's assumption". The former is an indicator that "this" is not helpful. The latter is a recognition that people are very creative, but doesn't mean we should be ditching something that overall helps achieve the goal of providing actionable guidance to help make content more accessible.

(Note: Actionable means "people can generally use it effectively" not "it's impossible to argue a case that it is poor guidance".)

[GreggVan]

I think you are confusing

• not reliable at the boundaries
  and
• not reliable unless it is nowhere near the boundaries.

The first is true of every measurement. Even metrics. Even if measured in angstroms.

This is why we talk about “high inter-rater reliability”

But you can argue that just because everything is a bit ambiguous right at the boundaries, we should pass laws or regulations or standards that are “not reliable unless it is nowhere near the boundaries”

• speed limit is “not too fast”
• stairs should support “a lot of full sized adults on them at the same time”

We can't put things in as requirement if we don't have a pass/fail criterion that has a high inter-rater agreement when you are not at or very near a boundary condition.

[electronicwoft]

• speed limit is “not too fast”
• stairs should support “a lot of full sized adults on them at the same time”

We can't put things in as requirement if we don't have a pass/fail criterion that has a high inter-rater agreement when you are not at or very near a boundary condition.

The numeric threshholds you replace with comparatives in your examples is a false equivalence and a rhetorical distraction.

[GreggVan]

re @electronicwoft
???? false equivalence and a rhetorical distraction. ???

How is it a false equivalency.. It was demonstrating quite clearly that regulations need to have measuerable numbers even if arbitrary. (why is 60 mph so much safer than 63 that we set it at 60. It isn't. but it is a definite threshold that everyone can basically agree on (however - also as I pointed out - when you get near the boundary (near 60), you will get lots of people measuring a car's speed as different around that. (One reason they don't ENFORCE violations near 60. You must be going enough faster that everyone would agree that you were "more than 60 by some bit) before the enforce. )

So how it is a false equivalency when I am saying they are not equivalent?

Also what was rhetorical about i?

Please, let's stick to making points and counterpoints and not dismissing other people's comments as a distraction.

[TestPartners]

We make subjective judgements all the time and it's rarely a problem. It's required by the normative text of numerous WCAG success criteria, such as:

SC 1.1.1: "text alternative that serves the equivalent purpose". In many cases, we have no idea what the author's purpose was. Increasingly, the text alternative came from a digital asset management system, so there was no "purpose" when it was created. The tester has to decide what they think the purpose is.

SC 1.2.1, 1.2.2 and 1.2.3: "except when the audio or video is a media alternative for text and is clearly labeled as such". How would you define "clearly labelled" in objective terms that are measurable?

SC 1.2.5: "Audio description is provided for all prerecorded video content in synchronized media." In practice, it is rare for audio description to be provided for all content, even when using extended audio description. In many cases, it would be a really bad user experience. In some cases, it wouldn't even be possible to create audio description for all content. Instead, we create audio descriptions containing the important visual content, not all of it.

SC 3.1.3: "phrases used in an unusual or restricted way, including idioms and jargon".

Maybe the root of this argument is that some people advocate a de-skilled and automatable process that gives 100% repeatable results, while others advocate a skill-based process that is capable of producing better results but is subject to greater variability. The former sounds attractive, but you only have to look at the awful results produced by the Trusted Tester methodology to see how badly it can work. Removing subjective criteria hides the issue rather than solving it. In a fuzzy world, there isn't going to be a "right" answer and we're not all going to agree.

[electronicwoft]

@GreggVan

Linguistic comparatives are not equivalent to numeric absolutes hence it being a false equivalency.

I thought that was self-evident hence the rhetorical distraction - apoligies.

Success criteria are not numerical expressions and most of them would be utterly worthless if they were formulated as such.

It's time to accept that a little bit of ambiguity is inevitable.

The question then becomes how best to minimise the effects of that ambiguity without forcing evry success criterion to be logically consistent or formulaic even though there object cannot be effectively quantised or absolutised.

Not every success criterion can be 1.4.3 nor should they be.

Nor do success criteria require absolutes to be reliably, consistently, and successfully tested.

As stated above, the best way to minimise the effects of ambiguity is to provide definitions and preferrably normative ones to guide practitioners towards achieving outcomes as consistently as possible.

So let's get back to how best to disambiguate 2.x?

[bruce-usab]

Related is #4036

[mbgower]

When any topic reaches a certain number of comments, I find it becomes so weighted down with side comments that it becomes difficult to resolve. I believe this has occurred here.

In an effort to address (and possibly resolve?) this issue, I will attempt to list what I'm hoping are guiding facts, which everyone can agree on:

1. The change that triggered this issue was a published update to the language in the understanding document of 3.3.2.
2. The update went through a process of scrutiny by the WCAG 2 Task Force, whereby the task force reached consensus on the proposed changes.
3. The outcome of that task force scrutiny was that the PR with those changes was sent to the AGWG for a review process last December.
4. The outcome of that AGWG review was that those changes received positive and wide support (11 members gave thumbs up to the PR; for context, unless there are concerns raised, we only look for 4 thumbs up, even for normative changes).
5. A second issue about 3.3.2, specifically about the meaning of "required" (which has been a side-topic in this issue), was addressed by a working group response that went through a similar process of review and adoption.

In other words, these changes were well scrutinized and supported.

---

While this is a more subjective statement, it's also worth pointing out that the wording changes in the PR were not large-scale nor did they introduce new concepts in the Understanding document.

Finally, I challenge the narrative there was a pre-existing accuracy/correctness factor to this SC that was substantively altered by this change and needs to be "restored". Such language clearly does not exist in the normative text. A careful scrutiny of the PR challenges the assertion that it existed within the understanding document. The phrase "clear and unambiguous" was removed in two of the benefit examples which I suspect is at the heart of this issue. Yet it is debatable whether this phrase is referring to the content of a label or its placement/affiliation. Hopefully it's obvious that sufficient techniques like G162: Positioning labels to maximize predictability of relationships and G167: Using an adjacent button to label the purpose of a field challenge the interpretation that this (or the word "identify" in the definition of label) is mainly or solely about semantics/language.

---

This issue is proposing altering the normative text of 3.3.2 to "make an explicit expectation of accuracy".
Put simply, we cannot do this. The task force is prevented from proposing any normative changes that alter the requirements of the published standards.

Further, I believe it has been demonstrated that such a change is unnecessary. Any lack of accuracy or clarity in a label can be failed against 2.4.6. That is not new guidance. It is clearly stated in the last line of the pre-existing Intent section in the 3.3.2 Understanding document (as well as elsewhere), which I quoted in my draft working group response.

Beyond proposing this normative change, the issue argues that if there is no qualitative measure for 3.3.2, there is no point to it:

By removing any need for clarity or quality or accuracy in 3.3.2, then what is the benefit of conforming to this SC?

However, it is clearly illustrated in both language, examples and techniques that the presence of a label allows a number of other considerations to take place, namely:

1. Is the label accurate and descriptive? (2.4.6)
2. Is the label programmatically associated with the input? (1.3.1)

A missing input label can clearly be failed against 3.3.2. A missing label cannot easily be failed against the language of either 2.4.6 (whose sole technique has a test that only applies "For each interface with a label") or 1.3.1 (which relies on a label existing in the presentation in order to enforce a programmatic relationship).

As in my draft response, I acknowledge that any task force work is constrained not just by its work statement, but by the reality of an imperfect standard made more imperfect by a lot of historical authors writing inconsistent non-normative guidance over more than a decade. In my opinion, these adopted changes to the 3.3.2 Understanding document lead to more consistent inter rater reliability: Inaccurate or poorly described labels are reported against 2.4.6; missing labels are reported against 3.3.2.

If after taking in this response, @davidofyork or anyone else still feels a change is needed, I encourage them to create a PR, which can then enter into the same WCAG 2 process I outlined above.

Alternatively, as I've already noted, I strongly agree with the tactic of using accuracy as a measure in WCAG 3, and I also encourage you to become more involved in helping bring that to fruition.

[davidofyork]

Thanks for the comprehensive summary, @mbgower! I agree, with a discussion of this length, not to mention the numerous distractions, it’s easy to lose focus.

---

What you and others still seem to be overlooking is the specific role and intended purpose of SC 3.3.2 within the overall framework of WCAG.

As I’ve pointed out several times in this thread, 3.3.2 falls under:

• Guideline 3.3 Input Assistance: Help users avoid and correct mistakes.
  and
• Principle 3 Understandable: Information and the operation of the user interface must be understandable.

SC 3.3.2 was designed with a purpose, an intention.

This was captured in the stated goal that "Users know what information to enter" and the intent "to have content authors present instructions or labels that identify the controls in a form so that users know what input data is expected." Presumably those words were well scrutinized and supported too?

Suggesting that the excised phrase “clear and unambiguous” or the word “identify” in the WCAG definition of a label referred not to the content of a label but to its placement/affiliation is a spurious claim that, again, is at odds with the stated goal and intention of 3.3.2.

SC 3.3.2 has a job to do – to help users avoid and correct mistakes within the context of an understandable interface.

It certainly wasn’t designed to be a mere prerequisite to other SCs.

---

As for what should be done about this, there are various options. In no particular order:

Alter the normative text of 3.3.2 to make an explicit expectation of accuracy

This issue doesn’t actually propose altering the normative text, it concerns revisions to the non-normative Understanding document. I understand the normative text is written in stone and cannot be adjusted.

Update the non-normative Understanding SC 3.3.2 document to make an explicit expectation of accuracy

This certainly is possible and #4056 proposes how it could be achieved. It would result in some overlap between 3.3.2 and 2.4.6, which I know some members are concerned about, but personally I don’t think it would be as confusing as people fear. A failure of 3.3.2 due to an inaccurate label would result in an automatic failure of 2.4.6.

Update the normative WCAG definition of ‘label’ to make an explicit expectation of accuracy

The current definition of ‘label’ states: “text or other component with a text alternative that is presented to a user to identify a component within Web content.” As @jared-w-smith pointed out, the need to “identify a component” should be enough to make the case for accurate labels, but I’m aware some will claim that a component can still be identified from a meaningless ID number (or proximity to a label). So perhaps the definition could be tweaked to reflect a need for accuracy?
Note: This is the approach taken with 1.2.5 Audio Description (Prerecorded), which concerns the existence of audio description but includes a linked definition of audio description that implies a need for quality.

Update the non-normative Understanding SC 2.4.6 document to downplay the focus on labels

This would be difficult to achieve within the constraint of the normative text. I did consider whether 2.4.6 could focus on more elaborate, descriptive headings and labels but that is challenged by the statement “Labels and headings do not need to be lengthy.”

Deprecate SC 2.4.6

Having heard members’ concerns about the subjectivity and value judgements required by 2.4.6, with one member implying that the SC was a mistake, I mooted whether 2.4.6 should be deprecated in the manner of 4.1.1. However, I understand this would be highly unlikely to gain traction and it's doubtful we'll see another 2.x version of WCAG.

Include a failure example demonstrating how an inaccurate label represents a failure of 3.3.2

This is a very subtle but achievable solution. A similar approach is taken in 1.2.2 Captions (Prerecorded), where the normative/non-normative text is concerned only with the existence of captions. However, one of its associated failures (F8) concerns the quality of captions, suggesting that the SC is also concerned with quality.

Update the non-normative Understanding SC 3.3.2 document to include a note emphasizing the need for accuracy

As I suggested in #4056, this could be something along the lines of:
“While this Success Criterion requires that controls and inputs have labels or instructions, it is crucial that these labels or instructions are not only present but also accurate.”

This is the least disruptive approach but the easiest to achieve. It wouldn’t enforce accuracy but it would at least acknowledge and restate the goal and intent of 3.3.2.

---

I urge members to evaluate these options now rather than postponing the consideration of accuracy to future guideline versions. With WCAG 3 still far off, the issues we face today will continue to affect us for some time.

[mbgower]

It certainly wasn’t designed to be a mere prerequisite to other SCs.

What's wrong with an SC being a prereq for another? That's how many work. We are all agreeing there is overlap. A decision was made to implement minor tweaks in guidance to reduce that overlap.

In my prior comment I outlined where a tester/assessor would record various failings of label, be they due to absence, language, or programmatic connection (and the understanding document already does that as well). What is the actual negative outcome of that current guidance on an end-user's experience? What is negative from a tester or reporting perspective?

You seem to be concerned that more things will be reported under 2.4.6 and less under 3.3.2, but in what way is that actually a problem? Several of your proposed options include just reversing this relative emphasis -- or even completely eliminating 3.3.2. How is that any better?

Suggesting that the excised phrase “clear and unambiguous” or the word “identify” in the WCAG definition of a label referred not to the content of a label but to its placement/affiliation is a spurious claim that, again, is at odds with the stated goal and intention of 3.3.2

It is not a spurious claim to say there is ambiguity; there are aspects of this SC concerned with visual identification and presentation. How else to explain sufficient techniques like Positioning labels to maximize predictability of relationships?

Thank your for the PR. I have associated it with this issue and added it to the TF process.

[davidofyork]

@mbgower
What's wrong with an SC being a prereq for another? That's how many work.

Really? Which ones?

• 1.1.1 Non-text Content concerns the provision of text alternatives, but also includes the "that serves the equivalent purpose" clause, making it quality-related...
• 2.4.2 Page Titled conflates existence and quality into a single SC.
• 3.3.1 Error Identification concerns the provision of error messages, but includes the "error is described to the user in text" clause, making it quality-related...
• As previously mentioned, the time-based media SCs concern the provision of captions and audio description, but include failures or rely on definitions that make them quality-related...

I'm not aware of any SCs that serve no other purpose than to tee up a different SC.

You seem to be concerned that more things will be reported under 2.4.6 and less under 3.3.2, but in what way is that actually a problem? Several of your proposed options include just reversing this relative emphasis -- or even completely eliminating 3.3.2. How is that any better?

No, my intention (and the motivation behind my proposed options) is to ensure that SC 3.3.2 honors its parent guideline, 3.3 Input Assistance, by helping users avoid and correct mistakes, and supports its parent principle, by ensuring that information and the operation of the user interface is understandable. By making 3.3.2 about the mere provision of labels, it supports neither the guideline nor the principle.

Honestly, why is this so objectionable? I assume the WCAG framework of principles and guidelines was created for a purpose and that SC were allocated accordingly. So why wouldn't you want to uphold this?

I have no concerns about things being reported under one SC more than the other and I certainly haven't suggested eliminating 3.3.2.

Suggesting that the excised phrase “clear and unambiguous” or the word “identify” in the WCAG definition of a label referred not to the content of a label but to its placement/affiliation is a spurious claim that, again, is at odds with the stated goal and intention of 3.3.2

It is not a spurious claim to say there is ambiguity; there are aspects of this SC concerned with visual identification and presentation. How else to explain sufficient techniques like ?

Oh, there's no doubt that sufficient techniques like Positioning labels to maximize predictability of relationships will support identification of form controls (although note that G162 is only sufficient when used with G131: Providing descriptive labels). But my point was that the excised phrase “clear and unambiguous” or the word “identify” is concerned more with the content of a label. A logically positioned label will not alone identity a form control.

Thank your for the PR. I have associated it with this issue and added it to the TF process.

As stated above, at the very least I think the Understanding SC 3.3.2 document should include a note emphasizing the need for accuracy. It wouldn’t enforce accuracy, it shouldn't impact your attempt at addressing the overlap with 2.4.6, but it would at least acknowledge and restate the goal and intent of 3.3.2.

[stevefaulkner]

As stated above, at the very least I think the Understanding SC 3.3.2 document should include a note emphasizing the need for accuracy. It wouldn’t enforce accuracy, it shouldn't impact your attempt at addressing the overlap with 2.4.6, but it would at least acknowledge and restate the goal and intent of 3.3.2.

Bravo!

[mbgower]

I'm not aware of any SCs that serve no other purpose than to tee up a different SC.

Just because you keep saying 3.3.2 serves no other purpose doesn't make it true. I and others have shown what its purpose is and how it can be used with the guidance as it now reads, and why the existence of a label is a critical thing. 3.3.2 can serve a purpose and serve as a prereq to something else. They are not exclusive. Much of the A > AA > AAA structure is constructed on a prereq model.

I assume the WCAG framework of principles and guidelines was created for a purpose and that SC were allocated accordingly. So why wouldn't you want to uphold this?

I believe the POUR model was conceived to make WCAG a neater package. Unfortunately, the allocation of SCs into a poorly normalized POUR model (in the data modelling sense) is often flakey. 2.4.6, "Headings and labels describe topic or purpose," can serve as an immediate example. It's located under Operable! That's why the focus of discussion is on the normative text of the requirements (which is challenging enough).

---

I get the sense from a few comments that I'm viewed as some solitary recalcitrant blocker in the way of progress. Yes, I classified this as a response-only issue back when it appeared back in July. I offered a draft response explaining why, and then I stepped aside for over two months and let other participants offer more than 50 comments. There are people who support what you are saying, and there are people disagreeing with you. Now that we have a PR, folks can try to iterate to something that gets traction.

Both the Understanding documents are absent any occurrence of the word "accuracy". As I said before, I think it is a measurement that can garner inter rater reliability, and I've been heavily advocating for its use in WCAG 3. I get that there are notions of 'appropriateness' in the 3.3.2 understanding document. But ultimately, my position is that alterations in the Understanding document must be based on the normative language, and the basis just doesn't seem to be there to me.

One approach, which I assume you won't like, is to add accuracy to 2.4.6. For instance, the final paragraph of 3.3.2's Intent section could read:

While this Success Criterion requires that controls and inputs have labels or instructions, whether or not labels (if used) are accurate, sufficiently clear, or descriptive is covered separately by 2.4.6: Headings and Labels.

2.4.6 does have normative language that can supports this addition, if one can be persuaded that "descriptive" includes such a notion. To me it is defensible to point to a sentence like this and argue it includes a notion of accuracy:

Conversely, it is also possible for content to pass Success Criterion 1.3.1 (with headings or labels correctly marked up or identified), while failing this Success Criterion (if those headings or labels are not sufficiently clear or descriptive).

[electronicwoft]

it's very disappointing that changes to the normative component - even the glossary - are forbidden until WCAG 3.0 ... As I have experienced, much of WCAG 2.x has taken on a life of it's own in practice, and its letter is given scant attention.

So I wonder whether changing a handful of words in the non-normative text of any success criterion really has any impact given the messaging about the value of the informative components of WCAG 2.x in determining conformance.

And, with thisI say adieu to this issue ...

[davidofyork]

I'm not aware of any SCs that serve no other purpose than to tee up a different SC.

Just because you keep saying 3.3.2 serves no other purpose doesn't make it true.

Then, by all means, Mike, please show me!

I and others have shown what its purpose is and how it can be used with the guidance as it now reads, and why the existence of a label is a critical thing.

The only thing you have demonstrated is how (in your words) “the presence of a label allows a number of other considerations to take place”, namely SCs 2.4.6 and 1.3.1.

Gregg attempted to justify the mere existence of labels as benefiting people with cognitive disabilities, but as I pointed out, the label still needs to be accurate.

3.3.2 can serve a purpose and serve as a prereq to something else. They are not exclusive. Much of the A > AA > AAA structure is constructed on a prereq model.

Again, could you give me an example of an SC that exists purely as a prerequisite for another SC while serving no other purpose?

I assume the WCAG framework of principles and guidelines was created for a purpose and that SC were allocated accordingly. So why wouldn't you want to uphold this?

I believe the POUR model was conceived to make WCAG a neater package. Unfortunately, the allocation of SCs into a poorly normalized POUR model (in the data modelling sense) is often flakey. 2.4.6, "Headings and labels describe topic or purpose," can serve as an immediate example. It's located under Operable! That's why the focus of discussion is on the normative text of the requirements (which is challenging enough).

This is what I find so frustrating. On the one hand, WCAG is this untouchable monolith and we must work carefully within the constraints of its normative text. But on the other hand, we can be all loosey-goosey about what goes where, with principle/guidelines seemingly having no bearing on their associated SCs. The principles and guidelines are just as normative as the success criteria, and should be upheld just as rigorously.

(For the record, Principle 2: Operable states: “User interface components and navigation must be operable.” Within that, Guideline 2.4 Navigable states: “Provide ways to help users navigate, find content, and determine where they are.” And 2.4.6 concerns the provision of descriptive headings and labels to support navigation. Its categorization is not as illogical as you are implying. And I suspect that, given the relative importance of headings when it comes to navigation, labels did not figure as prominently in the formation of this SC. But that’s by the by.)

One approach, which I assume you won't like, is to add accuracy to 2.4.6.

Actually, I have no objection to adding accuracy to 2.4.6 - just not at the expense of adding it to 3.3.2. 😄

[bruce-usab]

Issue (and related PR) discussed on TF call today. Consensus on call is that this issue is best addressed by updating Understanding 2.4.6. @mbgower volunteered to review and propose something.

[mbgower]

Then, by all means, Mike, please show me!

I run across a lack of labels frequently. Here's one I encountered while trying out a tool this week.

Two dropdowns without labels. Without 3.3.2, where would you fail this?

Again, could you give me an example of an SC that exists purely as a prerequisite for another SC while serving no other purpose?

I have now shown you an example of how 3.3.2 does serve a purpose. I have never said there are SCs that exist purely as a prereq and serve no other purpose. Those are your words.

Its categorization is not as illogical as you are implying.

I never stated it was illogical. I said "flakey". I stated the data model was not normalized, so that the categories overlap. Do you not think a strong case could be made to put 2.4.6 under the Understanding principle? It's not difficult to construct a narrative to put numerous SCs into different principles. One ends up with many:many relationships all over the place.

This is what I find so frustrating. On the one hand, WCAG is this untouchable monolith and we must work carefully within the constraints of its normative text. But on the other hand, we can be all loosey-goosey about what goes where, with principle/guidelines seemingly having no bearing on their associated SCs. The principles and guidelines are just as normative as the success criteria, and should be upheld just as rigorously.

You are not alone in being frustrated by the constraints under which anyone trying to improve WCAG 2 has to operate. I said as much in my draft response. But the task force has clear constraints, and my responses have attempted to make those explicit. It's also worth noting that over 200 issues have been address in less than a year. There are improvements being made.

In regard to your comments about the principle and guidelines, the reality is that those are not used for testing. (In the words of the technical document, "The guidelines are not testable, but provide the framework and overall objectives to help authors understand the success criteria and better implement the techniques.") The normative text of the success critieria forms the nucleus of comformance statements, and it is the SC text against which the ACT rules are applied. I don't think it's a coincidence that the European model stripped out all the content at the principle and guideline levels, and used POUR strictly as heading structures.

[davidofyork]

@mbgower
Two dropdowns without labels. Without 3.3.2, where would you fail this?

You would satisfy 3.3.2 by providing labels for the two dropdowns, but those labels wouldn't have to identify the dropdowns in a meaningful way. For example, the labels could say: "Please select".

As I have stated so many times in this discussion, merely providing labels (with no concern for accuracy) does not benefit anyone.

It doesn't meet the stated goal that "Users know what information to enter", nor does it meet the stated intent "to have content authors present instructions or labels that identify the controls in a form so that users know what input data is expected."

And yes, I'm sure you would punt this over to 2.4.6 and fail it there instead.

But this demonstrates how 3.3.2 now exists purely as a prerequisite for another SC while serving no other purpose.

I don't think I can restate this any clearer. And sadly, it's clear from the group's response that it's not going to gain any traction.