Need to change "Understanding SC 3.3.2" as it does not accurately reflect what the SC says.

[spanchang]

SC3-3-2Understanding.docx
See attached Word doc.
A pull request has been created on Feb 23, 2016 at
https://github.com/spanchang/RewriteUnderstanding_SC3-3-2.git

[joshueoconnor]

Hi @spanchang,

Sorry but you will need to resubmit this again. I can't figure out the details of the pull request. Please have a look at our 'Github pull request' on this page. [1]

Thanks

Josh

[1] https://www.w3.org/WAI/WCAG20/comments/Overview.html

[spanchang]

Hi Josh,
The Github pull request method does not seem to work with NVDA or JAWS. I did create a fork of the WCAG2, downloaded and installed githubSetup.ext but when I ran Github, neither screen reader seemed to work with it.
On attempting to work without cloning it on local machine as suggested, I was unable to find the XML content for the specific SC 3.3.2.
The pull request page suggests that one should simply create an issue in Gitthub if one is unable to create a pull request or determine where specific changes need to be done.
I sent a Word file with rationale and specific changes for SC 3.3.2 to Michael Cooper with request to create a pull request.
Would you like me to send the Word file to you and Andrew too by a separate email or create an issue and paste the text of the file in it?
Thanks,
Sailesh

[spanchang]

Josh,
I just attached the Word file here ... I noticed it can be done here. Thanks, SC3-3-2Understanding.docx

[joshueoconnor]

From Sailesh Panchang Feb 26, 2016

I. Title: Change “Understanding SC 3.3.2" as it does not accurately reflect what the SC says

II. Background:
As a screen reader user myself, I will never suggest something that will lead to a poorer accessibility experience for PWD or AT users.
As an accessibility auditor however, I have to go by what the relevant guideline or standard against which content is being evaluated mandates.
This note is the outcome of the discussion for "Re: Should G83: "Providing text descriptions to identify required fields that were not completed" reference 3.3.2?".
Andrew suggested that a pull request be created in the last email of this thread:
http://lists.w3.org/Archives/Public/w3c-wai-gl/2016JanMar/0180.html
My last email on that thread summarized my views:
http://lists.w3.org/Archives/Public/w3c-wai-gl/2016JanMar/0179.html
My interpretation of SC 3.3.2 below is made in the light of the statement, "guidelines are not testable, but provide the framework and overall objectives to help authors understand the success criteria".
III. Rationale:
Most of us will want to interpret "instruction" as used in SC 3.3.2 in its broadest sense to include all types of instructions, e.g. instructions that identify which field is mandatory, or specify data formats, valid data ranges, period within which a form needs to be submitted and so forth.
Yet, such a broad interpretation is constrained by normative WCAG 2.0:
• the first three words of the SC namely, "labels or instructions", and the conjunction, "or", and
• the word "label" as defined by WCAG2 as "text (or text equivalent) presented to a user to identify a component within Web content"
This means, that all instructions are not covered by the scope of this SC but only those that work like a label when a label is absent.
In other words, only those instruction that help to identify the input elements or form controls are useful to meet the SC. (See Example 3 below)
Consider an instruction followed by a row of 3 input fields as in Example #3 below:
“Enter first middle and last name for the first applicant in the next 3 fields:”
“Enter first middle and last name for the second applicant in the next 3 fields:”
Sure these will fail SC 4.1.2 if the labels do not have an accessible name (say with a title i.e. H65), but they pass SC 3.3.2 because the instruction identifies the fields and it meets the "label or instruction" requirement.
Maybe, this may not have been the intention and most will not find this palatable, but this is what the SC says today.
And so does the first statement in the Understanding doc for SC 3.3.2: "The intent of this success criterion is to have content authors place instructions or labels that identify the controls in a form so that users know what input data is expected".
An instruction that merely identifies the data format or has an asterisk or the word, "(required)" placed next to the control without any other identifiable text fails to convey "what input data is expected by the form control".
Such an instruction is not what is contemplated by SC 3.3.2's current wording.
Because SC 3.3.2 is part of "Guideline 3.3 Input Assistance: Help users avoid and correct mistakes", one cannot attribute more to an SC than what it actually says.
So when the Understanding doc states, "The goal is to make certain that enough information is provided for the user to accomplish the task without undue confusion or navigation", it stretches what the SC mandates.
Some portion of Understanding SC 3.3.2, is really addressed by two AAA Level SCs within the same guideline:
• For SC 3.3.6: The intent of this Success Criterion is to help users with disabilities avoid consequences that may result from making a mistake when submitting form data. (This is covered by SC 3.3.4 AA too).
• For SC 3.3.5: Context-sensitive help only needs to be provided when the label is not sufficient to describe all functionality.
Therefore, quite a bit of the content within Understanding SC 3.3.2 including benefits and examples need to be re-written.
The above only relates to SC 3.3.2 and is not concerned with meeting SC 1.3.1 or 4.1.2 or 3.3.1 etc.
I will like the above viewpoint to be disproved because it has been asserted that "there is room for interpretation here". If an alternative interpretation exists, it needs to be justified with specific normative wording within WCAG 2.0 as applicable to SC 3.3.2.
IV. What happens if the above viewpoint discussed under "Rationale" is accepted?
a. Understanding SC 3.3.2 will need to be re-written. (see proposal below)
b. H90 will need to reference SC 1.3.1 only and not SC 3.3.2
c. The reference to SC 3.3.2 will need to be de-linked from Technique G83. (Note: the email thread referenced above under "Background" suggests that referencing 3.3.2 in G83 is also inconsistent if one compares the SC references within related techniques like G85, SCR18 or ARIA2).
d. Consider linking SC 1.3.1 to G83, G85.
Proposed Change to Understanding SC 3.3.2,: Intent, Benefits and Examples
Intent:
The intent of this success criterion is to have content authors place instructions or labels that identify the controls in a form so that users know what input data is expected. In the absence of field-specific labels, an instruction that identifies individual field or fields within a group is also sufficient to meet this success criterion.
The phrase "when content requires user input" refers to elements such as form controls that accept user input as distinct from other elements on a page like hyperlinks or images.
When the form control and its label or instruction are in the same field of vision, users of screen magnification software are likely to be well served. In other words, placing the label or instruction logically in close proximity to the related form control makes their relationship to each other obvious by presentation.
Note: When labels are provided for input objects, the input object's relationship to the label (or to redundant text serving as the label) must be programmatically determinable or available in text per Understanding Success Criterion 1.3.1 Info and Relationships. The label or instruction can also serve as an accessible name as per SC 4.1.2 if marked up properly.
Supplementary instructions that indicate the expected data format or data range or whether input is mandatory for specific form controls do not by themselves identify what data is expected and are not covered by the term "instructions" as used in the success criterion. However, such instructions help users with disabilities avoid consequences that may result from making a mistake when submitting form data including unnecessary navigation. All visible instructions should be programmatically determinable in relation to the form control as per Success Criterion 1.3.1.
Specific Benefits of Success Criterion 3.3.2:
A visible label or instruction (e.g. "Last name" or "Departure date" or "Your question") enables users to determine what data needs to be entered into a specific text box. A label or instruction also serves to convey the specific purpose of other controls like radio buttons, checkboxes, drop down controls etc.
Examples:
Example 1:
A field for entering a given name is clearly labeled with "Given Name" and the field for family name is labeled "Family Name" to avoid confusion over which name is requested.
Marking up each label, "Given Name:" / "Family Name:" as a label and using the for-id method (H44) to associate it with the corresponding field is one method of also satisfying SC 4.1.2 and SC 1.3.1.

Example 2:
A U.S. phone number separates the area code, exchange, and number into three fields. Parentheses surround the area code field, and a dash separates the exchange and number fields. These fields are all arranged to the right of the label "Your phone number:".
Marking up the common label, "Your phone number:" as a legend, setting a title attribute to identify individual segments of the phone number and wrapping them all in a fieldset is one method of making the three controls satisfy SC 4.1.2 and SC 1.3.1 too.

Example 3: Instruction to identify form controls:
<form starts>
Enter first middle and last name for the first applicant in the next 3 fields:
<input type="text" name="fn1" id="fn1" />
<input type="text" name="mn1" id="mn1" />
<input type="text" name="ln1" id="ln1" />
Enter first middle and last name for the second applicant in the next
3 fields:
<input type="text" name="fn2" id="fn2" />
<input type="text" name="mn2" id="mn2" />
<input type="text" name="ln2" id="ln2" />
</form ends>

Placing an off-screen legend, like, "First Applicant" / "Second
Applicant", a title attribute to identify first middle and last name
boxes and wrapping them all in a fieldset is one method of making the
above satisfy SC 4.1.2 and SC 1.3.1 also.

[joshueoconnor]

@spanchang I formatted the third example for you. It displays fine.

[awkawk]

Sailesh,
With this we are circling back to where we were before. I can't ask the working group to read and digest the complete justification you propose because it is very very long and what we really, really need is a writeup of just the specific changes that are proposed to the understanding document. Not the argument as to why it is needed, because I think that we have that on the list and above, just the specific line-by-line set of changes.

You can do that in a github comment by saying "second paragraph of the description on [URL] needs to change from X to Y" and then we can discuss it from there.

[spanchang]

Proposed Change to Understanding SC 3.3.2,: Intent, Benefits and Examples

Intent:

Present content at
https://www.w3.org/TR/UNDERSTANDING-WCAG20/minimize-error-cues.html#minimize-error-cues-intent-head
The first sentence and the note at the end are retained in the proposed write-up:
<start of proposed Intent>
The intent of this success criterion is to have content authors place instructions or labels that identify the controls in a form so that users know what input data is expected. In the absence of field-specific labels, an instruction that identifies individual field or fields within a group is also sufficient to meet this success criterion.
The phrase "when content requires user input" refers to elements such as form controls that accept user input as distinct from other elements on a page like hyperlinks or images.
When the form control and its label or instruction are in the same field of vision, users of screen magnification software are likely to be well served. In other words, placing the label or instruction logically in close proximity to the related form control makes their relationship to each other obvious by presentation.
Note: When labels are provided for input objects, the input object's relationship to the label (or to redundant text serving as the label) must be programmatically determinable or available in text per Understanding Success Criterion 1.3.1 Info and Relationships. The label or instruction can also serve as an accessible name as per SC 4.1.2 if marked up properly.
Supplementary instructions that indicate the expected data format or data range or whether input is mandatory for specific form controls do not by themselves identify what data is expected and are not covered by the term "instructions" as used in the success criterion. However, such instructions help users with disabilities avoid consequences that may result from making a mistake when submitting form data including unnecessary navigation. All visible instructions should be programmatically determinable in relation to the form control as per Success Criterion 1.3.1.
</end of proposed Intent>

Benefits:

Present Benefits for SC 3.3.2:
https://www.w3.org/TR/UNDERSTANDING-WCAG20/minimize-error-cues.html#minimize-error-cues-230-head
<start of proposed Benefits>
A visible label or instruction (e.g. "Last name" or "Departure date" or "Your question") enables users to determine what data needs to be entered into a specific text box.
A label or instruction also serves to convey the specific purpose of other controls like radio buttons, checkboxes, drop down controls etc.
</end of proposed Benefits>

Examples:

Present content at
https://www.w3.org/TR/UNDERSTANDING-WCAG20/minimize-error-cues.html#minimize-error-cues-examples-head
The proposal deletes example #1 and 2.
Example #3 and 4 become Example 1 and 2 in the proposal below. The explanatory text following the examples is added / changed in the proposal below.
A new example 3 illustrating use of an instruction to identify fields is proposed.
<start of proposed Examples>

Example 1:
A field for entering a given name is clearly labeled with "Given Name" and the field for family name is labeled "Family Name" to avoid confusion over which name is requested.
Marking up each visible label, "Given Name:" / "Family Name:" as a label and using the for-id method (H44) to associate it with the corresponding field is one method of also satisfying SC 4.1.2 and SC 1.3.1 besides SC 3.3.2.

Example 2:

A U.S. phone number separates the area code, exchange, and number into three fields. Parentheses surround the area code field, and a dash separates the exchange and number fields. These fields are all arranged to the right of the label "Your phone number:".
Marking up the common label, "Your phone number:" as a legend, setting a title attribute to identify individual segments of the phone number and wrapping them all in a fieldset is one method of making the three controls satisfy SC 4.1.2 and SC 1.3.1 too.

Example 3:

Instruction to identify form controls:
<form starts>
Enter first middle and last name for the first applicant in the next 3 fields:
<input type="text" name="fn1" id="fn1" />
<input type="text" name="mn1" id="mn1" />
<input type="text" name="ln1" id="ln1" />
Enter first middle and last name for the second applicant in the next
3 fields:
<input type="text" name="fn2" id="fn2" />
<input type="text" name="mn2" id="mn2" />
<input type="text" name="ln2" id="ln2" />
</form ends>
Placing an off-screen legend, like, "First Applicant" / "Second
Applicant", a title attribute to identify first middle and last name
boxes and wrapping them all in a fieldset is one method of making the
above satisfy SC 4.1.2 and SC 1.3.1 too.
</end of proposed Examples>

The rationale for the proposal is in the text reproduced by Josh in the message of Feb 29:
https://github.com/w3c/wcag/issues/164#issuecomment-190227962

Thanks,

[awkawk]

@spanchang OK, so I'm really trying to follow this and put in a pull request that implements the changes but I can't. You need to provide specific information. For example:

Intent section:
Paragraph one - stays the same
Paragraph two - replace the first sentence with X
Note - first paragraph stays the same but add a second paragraph that says X

In your intent section I can't tell what I'm supposed to do with sufficient certainty.

In the benefits section you provide 2 items - do these replace the existing 4 items or get added at the end?

The examples section changes are a little more clear but not enough. If there are changes to an example, don't make me figure our where they are - be specific.

I can finish the changes and put a pull request in for next week if we get the changes before noon today. Otherwise it'll be the following week.

[spanchang]

Andrew,

I sent you an email providing the clarifications you need.
I am happy to go over the changes on the phone too.
Thanks,
Sailesh

On 4/15/16, Andrew Kirkpatrick notifications@github.com wrote:

@spanchang OK, so I'm really trying to follow this and put in a pull request
that implements the changes but I can't. You need to provide specific
information. For example:

Intent section:
Paragraph one - stays the same
Paragraph two - replace the first sentence with X
Note - first paragraph stays the same but add a second paragraph that says
X

In your intent section I can't tell what I'm supposed to do with sufficient
certainty.

In the benefits section you provide 2 items - do these replace the existing
4 items or get added at the end?

The examples section changes are a little more clear but not enough. If
there are changes to an example, don't make me figure our where they are -
be specific.

I can finish the changes and put a pull request in for next week if we get
the changes before noon today. Otherwise it'll be the following week.

---

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#164 (comment)

[spanchang]

Feebback to comments in Survey results Apr 19, 2016:
Andrew: I'd like to suggest replacing the second changed paragraph in the pull request with:
"This success criteria uses the phrase "when content requires user input" to refer to elements such as form controls that accept user input and to indicate that it does not apply to content on a page such as hyperlinks or linked images which are interactive but are not user input controls."
Sailesh: Yes this is better. Fine by me.

Andrew: I'd like to remove the 3rd paragraph as I don't think it says anything that is needed
Sailesh: The 3rd para beginning with " When the form control and ..." is relevant because the placement / positioning of a label helps determine a form control's identity for users who do not rely on AT and programmatic association. This in fact reinforces one of the presently documented benefits.

Andrew: The fourth paragraph is likely to cause a problem.
Sailesh: I retained the "Note" from the original content because I was not sure of its purpose. If you wish to do away with the 4th para "Note: ... if marked up properly. ", I am ok with it.

Andrew: Some of the new examples don't meet the described requirement.
Sailesh: Example # 1 and 2 are the same as example # 3 and 4 from the present.
The explanatory text that follows them is new or altered.
I am ok with deletion of references to SC 4.1.2.
Example#3 is a deliberate one to illustrate how an instruction (as contemplated by SC 3.3.2) can identify fields without using field-specific labels. Surely I do not recommend it, but it will pass 3.3.2.
Imagine the instruction for the first applicant followed by a single row (layout table) with 3 fields.

Then the similar design for applicant#2.

For a background / summary or a rationale for this proposal to change understanding SC 3.3.2:
The title says it for the most part, "Need to change "Understanding SC 3.3.2" as it does not accurately reflect what the SC says".
This is an outcome of the discussion for
"Re: Should G83: "Providing text descriptions to identify required fields that were not completed" reference
3.3.2?".
https://lists.w3.org/Archives/Public/w3c-wai-gl/2016JanMar/0179.html

Andrew suggested I should propose changes to SC 3.3.2 Understanding doc as a first step.
https://lists.w3.org/Archives/Public/w3c-wai-gl/2016JanMar/0180.html
This background and rationale for changes is in the Github message dated at Feb 26, 2016:
#164 (comment)

[awkawk]

Sailesh, I am supposed to follow up with you as there was a lot of confusion on the call about this. Can you very briefly and concisely identify what problem this is all intended to address? I've read the long explanations and the word document and do not feel that I can represent this confidently.

(When I say short, I mean in about one sentence)

[spanchang]

Andrew,
Please refer to my message of Apr 20, 2016 on Github.
I have also provided responses for your survey comments.
If you wish I can call you if you give me a time and number to call.
Thanks,
Sailesh 703-225-0380 ext 105

[awkawk]

Sailesh, we need something that encapsulates the concept rather than pointing to an email discussion. I don't think that "need to change understanding 3.3.2 because it doesn't reflect the SC" really says what the problem is.

I'm sorry if this is frustrating, but the group was confused so I hope that you can understand that even though you feel like the information is there and is sufficiently clear that the many others on the group don't.

[spanchang]

Understanding SC 3.3.2: Need for change:

1. IMO the intent as documented now beginning with the 2nd sentence stretches the meaning of "instructions" as contemplated by SC 3.3.2.
   All instructions are not covered by the scope of this SC but only those that work like a label when a label is absent.
   Refer to the words "label OR instructions" and the definition of "label".
2. Need to clarify "content that requires user input", is a manner of referring to form controls as distinct from other elements that do not need input.
   Should not be confused with other interactive controls or interpreted to mean that all form controls are "required" in the sense of "mandatory".
3. Based on the above, clearly benefit WCAG Network Graph #3 and 4 are not covered; also 'clickability' of a label is regarded as a good thing or UA feature and not related to mere presence of label text but the manner a control is assigned a name.
4. Examples Text edit line 1837 remove quotation marks #1 and 2 are not covered based on this interpretation of "label or instruction". A new example WCAG Network Graph #3 is proposed which illustrates instructional text that serves as a label because it identifies form controls.

That's why the proposal [1] is an almost complete re-write of the intent, benefits and examples for SC 3.3.2.
[1] #164 (comment)

Thanks,
Sailesh

[awkawk]

Sailesh,
Thanks, that helps clarify things.

With this additional clarity I am having a hard time agreeing with parts of your appraisal. I don't think that the text of the SC is as clear as I would like, but from the text of the SC there is nothing that indicates that "only instructions that work like a label when a label is not present" can meet the SC.

Points on your numbered items:

1. I think that the understanding document is clear that this is referring to form controls that accept user input. I do agree that we could add something to indicate that this is not just talking about the controls which have been designated as required by the form author.
2. I think that benefits 3 and 4 are appropriate for SC3.3.2
3. I find example 1 confusing - I'm not sure what to visualize for that, so perhaps we agree. I think that the second example is ok. I think that your example is fine, but it is more of a conceptual description than a specific example. It also seems that you are suggesting multiple examples within that one.

Related to your example is that I think that example 4 in the understanding document is incorrect in that it says that you must use a fieldset. The fields helps satisfy 4.1.2/1.3.1 but isn't needed for 3.3.2. I don't think that we should avoid recommending a fields/legend as it is sufficient to meet 3.3.2, but we shouldn't say that the example described doesn't meet 3.3.2 without a fieldset, as I believe that it does.

[spanchang]

Andrew,
Not every instruction can identify the purpose of a field.
This is going back to the G83 discussion of 02/2016.
That's why you first suggested getting a proposal to amend Understanding SC 3.3.2 and getting it reviewed by the WG, right?
So the rationale for the change was submitted above on Apr 21.
You seemed to agree with the proposal on Apr 19 as did some others. I also provided responses to your comments.
Sailesh

[awkawk]

Sailesh,
The SC says "Labels or instructions are provided when content requires user input. (Level A)". It doesn't say anything about certain types of labels or certain types of instructions. We may wish that it was more specific, but it isn't.

I was not in complete agreement on the survey, was less so on the call, and after reading the more clear explanation you provided I'm even more unconvinced.

[spanchang]

Josh,
Andrew and I disagreed about the interpretation of "instructions" in SC 3.3.2 while discussing change to the applicability of some techniques including G83.
While the word "label" is defined, "instructions" is not.
I have explained with reasoning why the term "instruction" refers to only those that help to identify a form control's purpose ... like a label going by the normative SC 3.3.2 and the definition of "label".
Almost all WG survey respondents agreed to the proposal to change SC 3.3.2 : intent, benefits and examples on Apr 19.
Andrew deflected attention from G83 by suggesting that I should submit a proposal to change Understanding SC 3.3.2.
After doing so, again the same point is being debated: meaning of "instruction".
It is not me going in circles here. So I request that the issue be discussed and resolved.
What is at stake: testers flagging an issue against a wrong SC namely 3.3.2.

Rationale at: #164 (comment)
Proposal at: #164 (comment)

Thanks,
Sailesh

[mraccess77]

I agree with Sailesh that the term instructions in SC 3.3.2 is referring to instructions in place of labels and does not require instructions when a label is present.

[joshueoconnor]

@spanchang Thanks for your work on this. The group has discussed it on the call and the consensus was that the current proposal was unclear and was therefore not accepted. You can see this discussion in the minutes. [1]

[1] http://www.w3.org/2016/05/17-wai-wcag-minutes.html

[spanchang]

Josh,
Was the debate around, "Need to change "Understanding SC 3.3.2" as it
does not accurately reflect what the SC says. · Issue #164" on Github?
If yes, the title of the discussion during call on May 17 was different:
"Should G83: "Providing text descriptions to identify required fields
that were not completed" reference 3.3.2?"
So when the content that is referenced and discussed does not match
the topic name, it is likely some WG members are confused.

I am not clear how suddenly the WG has documented that this issue /
proposal has become unclear after it was surveyed and discussed last
month.
Here are the survey results and comments by Greg and Jonathan on use
of instructions in place of a label:

Four WG members voted to accept the proposal as proposed: Makoto Ueki,
Wayne Dick, Marc Johlic, Alastair Campbell
Andrew had a few comments with his response, "accept with changes" and
you seconded that. I responded to Andrew's comments too.
(Surely these individuals did not find the proposal unclear).

GV's explanation for "instructions":
"When you have an input element — there is a label for the element OR
there are instructions that describe what the purpose and/or how to
use the input element . The rationale was that in some technologies
there might be an input element but no concept of a “label” for it —
or a label may not make sense for that type of input element. In
that case — there had to be instructions".

Jonathan: "Gregg, this is how I read it as well.  This would mean

that you agree that visual required field indication is not required
under SC 3.3.2, right? ...I agree with Sailesh that the term
instructions in SC 3.3.2 is referring to instructions in place of
labels and does not require instructions when a label is present."

So for the record: I do not see the WG's real intent or reasoning for
marking this proposal as unclear and "unacceptable".

Thanks and regards,
Sailesh Panchang

On 5/17/16, joshueoconnor notifications@github.com wrote:

@spanchang Thanks for your work on this. The group has discussed it on the
call and the consensus was that the current proposal was unclear and was
therefore not accepted.

---

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#164 (comment)

[joshueoconnor]

Closing this as per working group decision http://www.w3.org/2016/05/17-wai-wcag-minutes.html