Restore the need for accuracy/correctness to 3.3.2 Labels or Instructions about wcag HOT 40 OPEN

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)?

from wcag.

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.

from wcag.

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.

from wcag.

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

from wcag.

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.

from wcag.

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

from wcag.

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.

from wcag.

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.

from wcag.

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.

from wcag.

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.

from wcag.

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.

from wcag.

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.

from wcag.

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.

from wcag.

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

from wcag.

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.

from wcag.

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.

from wcag.

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

from wcag.

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

from wcag.

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

from wcag.

+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

from wcag.

@GreggVan

So it has to have a label.

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

from wcag.

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)

from wcag.

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)

from wcag.

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)

from wcag.

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.

from wcag.

@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

from wcag.

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

from wcag.

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

from wcag.

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

from wcag.

@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

from wcag.

@GreggVan

in your example

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

from wcag.

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

from wcag.

Ah Apologies @patrickhlauke - for the misattribution

from wcag.

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.

from wcag.

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.

from wcag.

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.

from wcag.

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

from wcag.

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.

from wcag.

@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

from wcag.

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

from wcag.