Conflict between glossary definition of label and H65 sufficient technique for 3.3.2

[joshueoconnor]

From: Glenda Sims/DEQUE Summary of Issue: Conflict between glossary definition of label and H65 sufficient technique for 3.3.2 Comment (Including rationale for any proposed change): The Normative definition for label clearly says "Note 1: A label is presented to all users whereas the name may be hidden and only exposed by assistive technology. In many (but not all) cases the name and the label are the same." But there is a sufficient technique (H65) for 3.3.1 that allows title (or hidden labels) to be used. BUT..this is in direct conflict with the definition of label.

Proposed Change: Remove H65 as a sufficient technique because it does not allow you to pass 3.3.1 (because it does not provide the label information for all users (only provides it for screen reader users).

[joshueoconnor]

Related to https://github.com/w3c/wcag/issues/100

[joshueoconnor]

This definition of 'presented to all users' surely represents presentation in a modality that they need? Visually for sighted, maybe hidden for SR users. The user needs must be supported, the method is secondary to satisfying that need, right? If the technique covered other modalities better, would that be an improvement?

[joshueoconnor]

Any comments?

[joshueoconnor]

Suggestion Surveyed: https://www.w3.org/2002/09/wbs/35422/charter_policy_update_2015/

[joshueoconnor]

AWK: We should update the test procedure to H65.

[awkawk]

Updates suggested for 101 (but not for issue 100): https://github.com/w3c/wcag/commit/3065c37a42ee4abade75b17c335afc9cc86b7906?diff=split

[awkawk]

AWK will provide a proposed response.

[awkawk]

Propose to address with #627

[alastc]

The PR was merged, closing until someone objects...

[goetsu]

@alastc @awkawk even if I agree for the reason of removal, it will create a regression for compliance of many websites that are currently using that technique to comply with 3.3.2 (even w3.org use it for the search field) At least I think it deserve a clear announcement (blog post or clear indication inside "Understanding documents change Log" section if you want to keep it that way.

[innoticFR]

even w3.org use it for the search field

W3 is in fact failing due to using G167 : Using an adjacent button to label the purpose of a field technique, but still without a "clear text label" for the button as normally expected. The G167 might lack of an additional test in the procedure to check for a visible text.

H65 and (G167 or H71) are quite complementary for 3.3.2.

[patrickhlauke]

the "clear text label" bit in G167 isn't really the crucial part though. people need to really get to grips with the idea that these various techniques are only informative. it doesn't mean that if you don't do EXACTLY what one particular technique does/says, you're failing the SC that it was mentioned in...

a graphical search icon, in a control adjacent to a text input, is a pretty universally understood indicator that the field is a search field. there's no requirement to say that it must have a text label that says "Search" or it will fail.

[innoticFR]

Thanks for your feedback.

That was my first intuition and that makes sense. The key here is making voice navigation predictable, and a "universally understood indicator" like a search button seems acceptable in most of the cases as long as it's easy to guess (voice command for instance).

(regarding this search field, I was more concerned by the tabindex=3 attribute on the input making the button not directly adjacent in the tab order, but that's not the subject here)

[mraccess77]

An icon can be used to meet SC 3.3.2 - a visible text label is not needed. 1.3.1/4.1.2 would need a programmatic label and a title suffices for that. 2.5.3 would not apply since there is not a text label. The challenge is that the title attribute could be seen as acting like the text label - but since it's the programmatic label 2.5.3 would pass.

[goetsu]

another issue with this modification is that the 3.3.2 understanding still refer to some example using title

Visual labels for the fields (beyond the punctuation) cannot be provided in the design, so invisible labels are provided with the "title" attribute to each of the three fields. The value of this attribute for the three fields are, respectively, "Area Code", "Exchange", and "Number".

@mraccess77 if you consider alt of a icon used as submit button compliant with 3.3.2 I don't understand why a title would not be. title is even more "visible" than alt as at least it become visible on hover. Also other listed technique like aria-labelledby or aria-describedby would not necessary reference a "visible" label.

So if the working group want to limit 3.3.2 compliance to "visible" label then

• all associated techniques and understanding document need to be clear on this.
• Alt attribut of an icon can't be considered as compliant with 3.3.2
• title attribut will not be listed as sufficient technique

If working group don't want to limit 3.3.2 compliance to "visible" label then title need to be added back in the list of sufficient technique

[innoticFR]

Hello @goetsu ,

(I crosspost the answer I made to the same subject on the RGAA (french guidelines). : https://github.com/DISIC/RGAA/issues/55#issuecomment-655603420 (in french))

The important part of the same example paragraph is the previous sentence

To address this, the three fields are grouped in a fieldset with the legend "Phone number".

3.3.2 does authorize any mean of labelling the fields, so the criteria is satisfied as "The term label is not limited to the label element in HTML."

The problem in this Understanding part is that the term "invisible label" is used when "accessible name" is expected, and the term "legend" is used without saying "visible label". And that might be confusing. (see https://github.com/w3c/wcag/issues/755)

3.3.2 has always required a "visible" label and the following note is present since the 2007 Working Draft

Note 1: A label is presented to all users whereas the name may be hidden and only exposed by assistive technology.

For this success criteria, it's not the alt of the image button that made the label visible, but the icon itself ("universally understood indicator" to quote @patrickhlauke). 3.3.2 is not focusing on the accessible name, but on the visible label which is not required to be plain text if meaningful enough. For instance: a phone icon can be used for labelling a phone number

The label term is described in the Understanding as being:

text or other component with a text alternative

[goetsu]

The problem in this Understanding part is that the term "invisible label" is used when "accessible name" is expected, and the term "legend" is used without saying "visible label". And that might be confusing.

even with that the legend can be considered as a visible label for each individual fields in the fieldset

The label term is described in the Understanding as being: text or other component with a text alternative

yes and it's problematic as there is no reference to the "universally understood indicator" you mentioned in this definition (subject to interpretation in my opinion)

So as said before removing the title technique ins't sufficient to solve this "visible" / "invisible" / "partially visible" situation and have no justification if we keep other techniques and understanding document as they are today

[innoticFR]

Even if I personally find the the Intent paragraph of this SC is one of the clearest, I agree that if that subject still needs to be discussed here on Github, it's that the understanding document is not explicit enough and should be reviewed (if only to avoid having to justify this point to others).

@goetsu : The "universally undestood indicator" is not part of the definition, just a (partial) quote from patrickhlauke's answer. I think the sole (but obvious) requirement is to have an understandable label (text or iconic).

[mraccess77]

@goetsu the programmatic name for the button is not relevant for SC 3.3.2 as 3.3.2 is aimed at the visible label. To clarify - I was not suggest alt be used although alt would pass 1.3.1/4.1.2 for images if it provided an equivalent.

[goetsu]

@mraccess77 so as said in case of the search bar on w3c website (and many other websites), is not compliant anymore with 3.3.2 (as for me an icon without any text can't be considered as a visible label and title not accepted as a possible solution for 3.3.2).

Once again, i'm ok to remove title technique but then other techniques and understanding need to be made more explicit on the fact that label need to be visible and then this need to be announced officially as this is subject to change compliance of websites that have considered title as a possible technique to use since a long time.

[awkawk]

@mraccess77 so as said in case of the search bar on w3c website (and many other websites), is not compliant anymore with 3.3.2 (as for me an icon without any text can't be considered as a visible label and title not accepted as a possible solution for 3.3.2).

This isn't accurate. The W3C's search feature meets 3.3.2 as is.

[patrickhlauke]

as for me an icon without any text can't be considered as a visible label

and that's where the disagreement seems to be. I, and i think most others here, say an icon on its own works as a visible label. the label does not need to be text. the fact that H65 talks about there being a clear text label is coincidental and not an actual requirement.

[mraccess77]

@goetsu there is no WCAG requirement for visual text labels - only visible labels.

[goetsu]

@mraccess77 @patrickhlauke so you will rely on G167 but G167 don't ask for a descriptive label as not associated with G131 as H65 was. So unless G167 moved in sublist of G131 as other techniques it mean that we can use any image even if not makings the component's purpose clear.

[awkawk]

@goetsu You can conform to 3.3.2 without relying on G167

[goetsu]

@awkawk you mean that you consider that the current w3c search bar use a non existing technique to conform to 3.3.2 ?

if yes fine but it's not my point anyway as :

• G167 will still need to be moved in G131 sublist,
• "Visual labels for the fields (beyond the punctuation) cannot be provided in the design, so invisible labels are provided with the "title" attribute to each of the three fields." still need to be removed and corresponding example modified
• all associated techniques and understanding still need to be made more clear that label need to be visible
• a more wide communication still need to be made on removal of title technique as sites using this technique are now made not compliant anymore

[alastc]

I'm trying to work out if there's an issue to resolve, @goetsu, you wrote:

If working group don't want to limit 3.3.2 compliance to "visible" label then title need to be added back in the list of sufficient technique

But you didn't seem to consider that an icon (for example) can be a visible label, at least for the purpose of 3.3.2.

Maybe we add an icon as an example to G131? And possibly G167

G167 will still need to be moved in G131 sublist,

They have slightly different procedures, and I think whether an icon is used is separate from whether it is a label or adjacent button.

"Visual labels for the fields (beyond the punctuation) cannot be provided in the design, so invisible labels are provided with the "title" attribute to each of the three fields." still need to be removed and corresponding example modified

I think the example overall is valid, perhaps with a small adjustment, something like:

The single "Phone number" label also cannot label all three fields. To address this, the three fields are grouped in a fieldset with the legend "Phone number". Visual labels for the fields (beyond the punctuation) cannot be provided in the design, and all three fields are considered to be visually labeled by the legend. To meet other criteria, each field would also need to have an accessible name set, for example by using the title or aria-label attribute.

all associated techniques and understanding still need to be made more clear that label need to be visible

The top of the understanding document for 3.3.2 is clear to me (which doesn't mean it's clear to everyone of course), I'm still trying to understand what has changed that makes you think it isn't clear anymore?

a more wide communication still need to be made on removal of title technique as sites using this technique are now made not compliant anymore

Again, what changed? The title technique is valid if there is also a visible label (in the general sense) for the control. H65 isn't listed for 3.3.2, it's for 1.1.1/1.3.1/4.1.2

[innoticFR]

I think that this small adjustment is necessary as it answers the still opened https://github.com/w3c/wcag/issues/755 issue

[patrickhlauke]

use a non existing technique to conform

techniques are not exhaustive. sufficient/recommended techniques are not the only way to satisfy an SC. they're informative, they give examples of one way of achieving conformance to an SC. nothing more.

(and again, this tied back to a separate discussion about techniques we had...elsewhere here...how people seem to misinterpret techniques?)

[awkawk]

@awkawk you mean that you consider that the current w3c search bar use a non existing technique to conform to 3.3.2 ?

I would need to look to see if it uses an existing or non-existing technique, but either way I regard that search functionality as meeting 3.3.2.

if yes fine but it's not my point anyway as

OK, but you said that it wasn't compliant with 3.3.2 which is what I was responding to.

[alastc]

Thanks @innoticFR, as that's an open issue I'll post the suggest there.

If adding an icon example to G131 is deemed useful, we can re-open this issue and make that task the focus.

[goetsu]

@alastc

Maybe we add an icon as an example to G131? And possibly G167

yes would be good idea

They have slightly different procedures, and I think whether an icon is used is separate from whether it is a label or adjacent button.

my point is that the image/icon need to make the purpose of the field clear otherwise it can't be considered as label so if not by moving G167 inside G131 sublist then at least by changing G167 to add a third condition like "Check that the button make the purpose of the field clear"

"all three fields are considered to be visually labeled by the legend."

as legend doesn't make purpose of each field clear for me the legend can't serve as visible label for each field unless H71 changed to ask for visible legend and descriptif enough content like "Phone number (Area Code, Exchange and Number)"

the top of the understanding document for 3.3.2 is clear to me

maybe change it to something like "The intent of this Success Criterion is to have content authors present visible instructions or labels that identify the controls in a form so that users know what input data is expected. and change G131 to "Providing visible descriptive labels"

Again, what changed? The title technique is valid if there is also a visible label

before the modification title was valid even without any other visible label as it was a technique listed for 3.3.2 and not the case anymore

[innoticFR]

before the modification title was valid even without any other visible label as it was a technique listed for 3.3.2 and not the case anymore

The misunderstanding is that H65 addresses elements without a label element (Identify each form control that is not associated with a label element), but not elements without a visible label. All examples in H65 already showed a visible label as expected by this SC (associated field, button, legend, or table headers).

This H65 technique was sufficient only because a visible label was already present. The changes made to H65 make it now clearer that H65 does, in fact, require 3.3.2 to be already satisfied.

[goetsu]

@innoticFR as said just before in that case G131 need to be modified to "Providing visible descriptive labels" otherwise many other techniques to be perform in addition to G131 may not be compliant as for example aria-describedby or aria-labelledby can refer to hidden element

[alastc]

as legend doesn't make purpose of each field clear for me the legend can't serve as visible label for each field

I think that's too blanket a statement. If you see 4 short fields with a legend of "Credit card number", I think that is quite clear. For phone numbers, there are conventions depending on your local. Fulfilling 3.3.2 does have relatively high subjectivity (e.g. compared to language of page), and that's necessary for something that's asking to be descriptive.

the legend can't serve as visible label for each field unless H71 changed to ask for visible legend and descriptive enough content

We don't have to change H71 for this purpose. It is a technique demonstrating how to meet the guidelines in a particular way, in that case for fields with labels. The procedure starts with "where the individual labels for each control do not provide a sufficient description, and an additional group level description is needed,", i.e. the controls do have labels, but not enough.

Whilst we'd like to, we'll never have a technique for every scenario, there are just too many scenarios. There is an example in the 3.3.2 understanding that covers it. We could create a new technique (if someone steps forward) to cover that scenario.

We also have to remember 3.3.2 has a 'or' statement, so an input is allowed to have no visible label if there are instructions.

[alastc]

I've also created a PR to cover the things mentioned above, in #1205

[patrickhlauke]

Whilst we'd like to, we'll never have a technique for every scenario, there are just too many scenarios.

as said before, to me this is once more an example of a misunderstanding of techniques. i often see cases where authors and auditors talk about "failing" a particular sufficient technique, or thinking that techniques are comprehensive and provide all the possible tests that need to be performed to then determine if an SC is passed or not. maybe i'm misreading it, but that's the impression i'm getting here.

[goetsu]

@patrickhlauke I know perfectly that techniques aren't only way to comply and that not conforming to a specific technique doesn't necessary mean that you not compliant. But regarding 3.3.2

• the SC wording itself in my opinion is subject to interpretation regarding the need labels or instruction being "visible" specially as for "instructions" there is no normatives associated definition as there is for "labels" where there is the note "A label is presented to all users ... " that can help to understand that
• existing techniques neither explicitly mentioned the need of having a "visible" label / instructions
• there is very few failures to make more easy to understand what will be a failure and what will not be a failure

In my opinion understanding document, techniques and failures even if not normative are here help to better understand the SC intent and make clear that the label / instructions need to be visible.

One last example where I would like to have opinion of the group https://codepen.io/goetsubis/pen/rNxKOdy would you consider both cases compliant with 3.3.2 or just case 1 or none and if just case 1 or none why that ?

[innoticFR]

@goetsu I think that @alastc PR addresses your request (3.3.2 + G131 + G167)

[goetsu]

@innoticFR yes they do but still interested to have opinion of the group on the last example I provide specially if answer is not compliant for one or both examples

[innoticFR]

Those examples are interesting. And to illustrate this, there is a common use case, for instance, when selecting a date with 3 dropdown lists (day, month, year) with a unique label "Date".

Not required for 3.3.2, but I would suggest using H71: Providing a description for groups of form controls using fieldset and legend elements

In your examples, each select element first option contains the label ("color", "size") but that label is not visible once an option has been selected (manually or by some browser autofill feature), and has to be discarded for evaluating 3.3.2. Note: for better accessibility, imho, this option should be marked as <option disabled selected>.

Regarding the accessible name (which is not part of 3.3.2), title is still useful for screen magnifier, or mouse users, while aria-label is preferred for assistive technologies. Using both will help more people.

Is the purpose of each field clear when the individual label is not visible? It depends on what you are searching for. If you're searching for fruits varieties, and one dropdown contains colors (e.g. red, orange, ...), and another one contains families (e.g. strawberry, orange, ...) then once "orange" has been selected, the remaining visible label "Filters" does not let you understand the purpose of the field. Are we filtering by color or by fruit family? Of course, that was not your example, but that's just to say that each case might be different.

If you apply the same reasoning for dates (which is more common), then having the month expressed in text rather than in number might remove confusion between the month and the day number, and a "Date" legend would be sufficient only in the former case (to avoid dd/mm/yyyy and mm/dd/yyyy confusion)

TL;DR: I personally make no distinction between your two examples in 3.3.2, and in some context, I think the "Filters" legend could be enough to indicate the purpose of the fields for 3.3.2.

That being said, that's only my own analyze and I'm also interested in the group opinion