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".

[GreggVan]

@patrickhlauke

in your example - the second field has no label - so it is not an example of a bad label. it is a failure - for not having a label

Second - if you look at the request, it was for a real-world example of a label that is present but not descriptive.
Please provide a URL to one in the real world.

Third -- if you do find one -- be sure that it is not a problem for anyone except people with disabilities If it is not usable by everyone - that is not an accessibility issue, it is a bug.

Remember that an accessibility issue is one where it is usable by people without disabilities but not those with.

We are specifically barred from adding provisions against bad design in our guidelines - Only things that are barriers specific to having a disability - not to all users

best

[patrickhlauke]

@GreggVan

in your example

not my example(s), Gregg. it was @jared-w-smith 's example...

[patrickhlauke]

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

@JAWS-test but as i said, it's not a good example of - as I requested - showing a case where something something PASSES 3.3.2 and FAILS 2.4.6. as this case also already FAILS 3.3.2 without even having to decide on "does it have a label that is correct, just not descriptive enough" since one of those two inputs completely lacks a label...

[GreggVan]

Ah Apologies @patrickhlauke - for the misattribution

[davidofyork]

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

I don't think there necessarily needs to be a clear distinction between 'identification' and 'description', or even whether such a distinction is possible.

• Understanding SC 3.3.2 specifies "labels that identify the controls in a form so that users know what input data is expected."
• Understanding SC 2.4.6 states "Descriptive labels help users identify specific components within the content."

These are very similar objectives. You could perhaps make a case for 2.4.6 requiring more detailed, elaborate labels... but then the Understanding doc nixes this with "Labels and headings do not need to be lengthy."

So, there is inevitably going to be some overlap between the two. That's just how they have been written, unfortunately.

But, in my opinion, it's better to have some overlap/redundancy, than to neuter 3.3.2 in such a way that it fails to meet its objective.

[patrickhlauke]

I don't think there necessarily needs to be a clear distinction between 'identification' and 'description', or even whether such a distinction is possible.

so for auditors that come along and want to work out "should I fail this under this SC, or the other, or both?" we should continue just handwaving things...

anyway, i look forward to people here proposing actual tangible edits to the understanding docs for 3.3.2 and 2.4.6, to explain what their desired outcome here would be.

[davidofyork]

so for auditors that come along and want to work out "should I fail this under this SC, or the other, or both?" we should continue just handwaving things...

Both 3.3.2 and 2.4.6 require labels to be accurate so that users can identify controls. There's nothing handwavy or difficult to follow about that.

Its far easier for auditors to fail multiple criteria, than to follow the circuitous web of cross-references that currently exist between 1.3.1, 2.4.6, 3.3.2, and 4.1.2.

[patrickhlauke]

follow the circuitous web of cross-references that currently exist between 1.3.1, 2.4.6, 3.3.2, and 4.1.2

I look forward to your PR that neatly clarifies this for all SCs you mention

[ronsmantpg]

FWIW, I thought "clear and unambiguous" in 3.3.2 referred to the presence of the label, not the content - that it was clear that a label belonged to a specific field and not to another field. This does pertain to "accuracy". 2.4.6 is about the accuracy of the content, how well it describes what the user is expected to enter into that field. So, "FN" immediately to the left of a text field satisfies 3.3.2 (it's present, it's obvious and it's visibly associated with the text field) but not 2.4.6. (it doesn't adequately describe what input is expected - some people would guess that FN means First Name but many people, including those with a cognitive impairment, would not, so the content of the label needs to be clarified). I don't see that removing "clear and unambiguous" from 3.3.2 improves either SC.

[patrickhlauke]

@ronsmantpg 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

[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.