Re: Should G83: "Providing text descriptions to identify required fields that were not completed" reference 3.3.2?

Hi 

the meaning/thoughts regarding “instruction” in 3.3.2 when the WCAG Working Group put it in there was basically as follows.

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 (in text it was assumed since all content had to have text equiv per 1.1.1) and it couldnt just be that “it was obvious (visually and cognitively) what a person should do” 


Does this help? 

gregg

> On Apr 26, 2016, at 9:27 AM, Sailesh Panchang <sailesh.panchang@deque.com> wrote:
> 
> 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" in
> the context of SC 3.3.2.
> Almost all WG survey respondents agreed to the proposal to change SC
> 3.3.2 : intent, benefits and examples
> Andrew deflected attention from G83 by suggesting that I should submit
> a proposal to change Understanding SC 3.3.2.
> I did 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: https://github.com/w3c/wcag/issues/164#issuecomment-213075041
> Proposal at: https://github.com/w3c/wcag/issues/164#issuecomment-205374107
> 
> Thanks,
> Sailesh
> 
> 
> 
> 
> On 4/21/16, josh@interaccess.ie <josh@interaccess.ie> wrote:
>> Sailiesh and all,
>> 
>> I think the confusion you refer to may have been around another
>> technique - but since you have broached the subject (and the following
>> is not just addressed to you btw). The problem here is partially one of
>> lack of brevity when reviewing an issue - rather than disagreement with
>> suggested changes. Especially when it comes to reviewing some of these
>> issues retrospectively. It seems the group will often struggle
>> recalling, with accuracy, what the problem is that a suggested solution
>> is trying to address. This is exacerbated when a issue thread really
>> gets long.
>> 
>> So, I urge all working group members to be as concise as possible with
>> their submissions via Github and to consider this especially in the
>> context of the group returning to review any given issue after some time
>> has passed. Quoting the specs is fine, but try to make sure it is as
>> specific as possible, else the thread will suffer from tl;dr, and
>> sometimes just become unmanageable.
>> 
>> Thanks
>> 
>> Josh
>> 
>> 
>> 
>> ------ Original Message ------
>> From: "Sailesh Panchang" <sailesh.panchang@deque.com>
>> To: "Andrew Kirkpatrick" <akirkpat@adobe.com>
>> Cc: "jon.avila@ssbbartgroup.com" <jon.avila@ssbbartgroup.com>; "Michael
>> Pluke" <Mike.Pluke@castle-consult.com>; "James Nurthen"
>> <james.nurthen@oracle.com>; "w3c-wai-gl@w3.org" <w3c-wai-gl@w3.org>
>> Sent: 21/04/2016 14:30:36
>> Subject: Re: Should G83: "Providing text descriptions to identify
>> required fields that were not completed" reference 3.3.2?
>> 
>>> Andrew,
>>> At least four WG survey respondents agreed to the change "as is".
>>> You and Josh agreed to it with some changes. I agreed to these mostly
>>> and responded to the other comments yesterday on Github.
>>> I do not see the confusion  in the recorded minutes of Apr 19 meeting
>>> ;  there  seems to be general consensus that  the understanding doc
>>> does not match the SC text.
>>> There is one  comment that  seemed to regard links as part of "content
>>> that required user input".  You clarified this point I believe.
>>> This change to Understanding 3.3.2  was motivated  by your specific
>>> direction in the email above that I should do this.  This will be the
>>> basis for correcting the SCs linked to the techniques referenced in my
>>> last email above.
>>> Thanks,
>>> Sailesh
>>> Reference:
>>> https://github.com/w3c/wcag/issues/164#issuecomment-190227962
>>> 
>>> 
>>> On 2/18/16, Andrew Kirkpatrick <akirkpat@adobe.com> wrote:
>>>> Sailesh,
>>>> 
>>>>> 1. Going by the normative SC requirement and definition of label, the
>>>>> presence of a label "First name" is sufficient to pass 3.3.2.
>>>> 
>>>> I think that there is room for interpretation here.  It would be
>>>> great to
>>>> clear it up in the future, but one could make an argument that being
>>>> required is part of the identity of a control.
>>>> 
>>>> Here’s how this needs to go from here, if you want to suggest
>>>> changes.
>>>> 1) Please do a pull request on the Working-Branch-for-Q3 branch with
>>>> the
>>>> exact changes that you think are needed to the techniques and
>>>> understanding
>>>> documents.  Certainly the part of the Understanding document for
>>>> 3.2.3 would
>>>> need to be changed to not expressly mention the text for required
>>>> controls.
>>>> 2) We can put that pull request up for review by the group.
>>>> 
>>>> I think that it would help immensely to see the specific changes in
>>>> the
>>>> code, rather than continuing to debate this on the list.
>>>> AWK
>>>> 
>>>> 
>>>>> 2. But not presenting the visible text label "First name" next to the
>>>>> label does cause it to fail 3.3.2.
>>>>> 3. Based on the normative definition of  "label", supplementary
>>>>> instructions  including cues for mandatory fields like an asterisk or
>>>>> "(required)" do not qualify as labels because they are not "text
>>>>> presented to a user to identify a component within Web content".
>>>>> 4. If the author chooses to present  more instructions, that's fine.
>>>>> 5. Doing so or not doing so does not cause the form control to   pass
>>>>> or fail 3.3.2.
>>>>> 6. If additional field specific instructions are present and
>>>>> visually
>>>>> appear to be connected with the field, not associating the
>>>>> instruction
>>>>> with the field will cause a 1.3.1 error and not a 3.3.2 error as you
>>>>> have acknowledged.
>>>>> 7. The normative SC requirement cannot be extended based on what is
>>>>> documented in the non-normative Understanding or Technique docs. As
>>>>> things stand now, a label, "First name" is sufficient to pass 3.3.2
>>>>> as
>>>>> the SC says "labels or instructions".
>>>>> 8. There is no debate about the usefulness of providing instructions
>>>>> for mandatory fields or data formats etc. As stated previously, this
>>>>> can be considered in an extension to make it an accessibility
>>>>> requirement in the future.
>>>>> 9. The Techniques doc published for guidance  clearly is inconsistent
>>>>> when G83 lists SC 3.3.2  as an applicable SC for one type of
>>>>> instructions, namely, "required or mandatory" fields but does not do
>>>>> so for G85 which deals with  other instructions like data formats or
>>>>> ranges.
>>>>> Other related SCs like SCR18 or ARIA2 too do not list SC 3.3.2 as
>>>>> applicable SCs.
>>>>> 10. Listing 3.3.2 as an applicable SC for G83 causes confusion for
>>>>> testers and developers who needlessly spend time understanding how an
>>>>> SC 3.3.2 failure is triggered. If the error text is not associated
>>>>> with the form control testers are prone to report this as an SC 3.3.2
>>>>> issue when it is clearly an SC 1.3.1 issue. SC 1.3.1 is not listed as
>>>>> an applicable SC for G83 or G85. Users of the evaluation report too
>>>>> end up getting confused or challenge the accuracy of the report.
>>>>> 11. Likewise, developers and users of evaluation report get confused
>>>>> when they see "SC 3.3.2" against a reported failure "The visually
>>>>> displayed "(required)" for required controls within a fieldset group
>>>>> lacks the markup for programmatic association" which you
>>>>> categorically
>>>>> agreed is not an SC 3.3.2 issue and yet is the only SC listed against
>>>>> Technique H90.
>>>>> 
>>>>> While I have provided responses to your questions, I am still waiting
>>>>> to understand  which of the above  listed points is not valid. I am
>>>>> basing my reasoning on normative WCAG2.0 text. So kindly help me
>>>>> understand what is incorrect in my reasoning.
>>>>> 
>>>>> The WG spends several minutes debating which SC  should be listed as
>>>>> applicable SC for any particular technique before publication. Surely
>>>>> these are not considered "minor" or non-technical" discussions?
>>>>> 
>>>>> Highlighting the above for your attention  is all I can do. I am
>>>>> sorry
>>>>> it took these many emails. Thankyou for graciously engaging in this
>>>>> debate but I hope  this is time well spent and these inconsistencies
>>>>> will be resolved sooner than later.
>>>>> 
>>>>> Kind regards,
>>>>> Sailesh Panchang
>>>>> 
>>>>> 
>>>>> On 2/18/16, Andrew Kirkpatrick <akirkpat@adobe.com> wrote:
>>>>>> Sailesh,
>>>>>> I find myself asking what is the real-world situation where having
>>>>>> G83
>>>>>> being
>>>>>> associated with 3.3.2 is causing a problem or confusion?  To be
>>>>>> more
>>>>>> clear,
>>>>>> I’m not talking about a code example, I’m talking about a
>>>>>> remediation
>>>>>> situation where this distinction is coming up.  Can you provide any
>>>>>> more
>>>>>> detail?
>>>>>> 
>>>>>> In Understanding 3.3.2 it provides the following as a specific
>>>>>> benefit:
>>>>>> “Clearly identifying required fields prevents a keyboard only user
>>>>>> from
>>>>>> submitting an incomplete form and having to navigate the
>>>>>> redisplayed form
>>>>>> to
>>>>>> find the uncompleted field and provide the missing information."
>>>>>> 
>>>>>> To me, that indicates quite clearly that the required nature of a
>>>>>> control
>>>>>> is
>>>>>> considered under 3.3.2.
>>>>>> 
>>>>>> Thanks,
>>>>>> AWK
>>>>>> 
>>>>>> Andrew Kirkpatrick
>>>>>> Group Product Manager, Accessibility
>>>>>> Adobe
>>>>>> 
>>>>>> akirkpat@adobe.com
>>>>>> http://twitter.com/awkawk
>>>>>> http://blogs.adobe.com/accessibility
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 2/17/16, 21:07, "Sailesh Panchang" <sailesh.panchang@deque.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> Hi Andrew,
>>>>>>> Let me try once more to state my case:
>>>>>>> SC 3.3.2 refers to "labels _or_ instructions" and the text label
>>>>>>> "First name" (even if not PD serves as a unique label to convey the
>>>>>>> field's purpose distinctly.
>>>>>>> The visible text "(required)" placed next to the field would fail
>>>>>>> to
>>>>>>> convey the field's purpose distinctly and cannot be regarded as a
>>>>>>> label.
>>>>>>> It is supplementary or instructional text just like password / date
>>>>>>> format rules.
>>>>>>> In
>>>>>>> <label for=“fn”>First name</label>(required)<input type=“text”
>>>>>>> id=“fn”>
>>>>>>> or
>>>>>>> <span>First name (required)</span><input type=“text”>"
>>>>>>> the field passes 3.3.2 simply based on"First name" i.e. label.
>>>>>>> The instruction "(required)" whether displayed visibly or not is no
>>>>>>> longer relevant for passing 3.3.2.
>>>>>>> If it is present on the screen it can only fail 1.3.1 if it is not
>>>>>>> PD.
>>>>>>> 
>>>>>>> The WCAG2 definition of label, "label is presented to all users"
>>>>>>> is
>>>>>>> very significant.
>>>>>>> If all fields on the form only had "required" next to them, the
>>>>>>> form
>>>>>>> would be unusable because no labels are present.
>>>>>>> But if the fields had "First name", "Last name, "Phone#" etc. these
>>>>>>> will be regarded as labels by one and all.
>>>>>>> Also, if the extra HTML5 "required" or aria-required=true were
>>>>>>> present, it is an instruction available to some users ... not all.
>>>>>>> So
>>>>>>> it does not fit the definition of a label.
>>>>>>> And if the label for-id method is used to associate the "required"
>>>>>>> with the field, it is only using H44 to satisfy 1.3.1 ... does not
>>>>>>> impact the pass / fail state of 3.3.2.
>>>>>>> 
>>>>>>> Does this help explain my position why 3.3.2 is inapplicable to G83
>>>>>>> or
>>>>>>> H90 and to support my appeal to de-link SC 3.3.2 from these
>>>>>>> techniques
>>>>>>> and replace it with SC 1.3.1?
>>>>>>> 
>>>>>>> Thanks and best regards,
>>>>>>> Sailesh Panchang
>>>>>>> 
>>>>>>> 
>>>>>>> On 2/16/16, Sailesh Panchang <sailesh.panchang@deque.com> wrote:
>>>>>>>> Hi Andrew,
>>>>>>>> I am confused by your  "This may be where we disagree.  I think
>>>>>>>> that
>>>>>>>> the visual presence of “required” is part of the passing of
>>>>>>>> 3.3.2"
>>>>>>>> following your example #1:
>>>>>>>> "<label for=“fn”>First name</label>(required)<input type=“text”
>>>>>>>> id=“fn”> — 1.3.1 issue, 3.3.2 ok"
>>>>>>>> and your statement:
>>>>>>>> "Yes, but to pass 3.3.2 you don’t necessarily need to have the
>>>>>>>> label
>>>>>>>> be programmatically associated with the control.  1.3.1 requires
>>>>>>>> that
>>>>>>>> the equivalent information be available programmatically, but If
>>>>>>>> I had
>>>>>>>> this, I believe it would pass 3.3.2 and fail 1.3.1:
>>>>>>>> <span>First name (required)</span><input type=“text”>"
>>>>>>>> 
>>>>>>>> Also, please can you also  respond  to my comments in the last
>>>>>>>> email
>>>>>>>> about:
>>>>>>>> - using only HTML5 "required"   or aria-required=true without a
>>>>>>>> visual
>>>>>>>> cue
>>>>>>>> - why other techniques like G85 or SCR18 or ARIA2 do not include
>>>>>>>> 3.3.2
>>>>>>>> as applicable SC and the need to make G83 consistent with those
>>>>>>>> techniques?
>>>>>>>> 
>>>>>>>> Thanks a lot,
>>>>>>>> Sailesh Panchang
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 2/16/16, Andrew Kirkpatrick <akirkpat@adobe.com> wrote:
>>>>>>>>>> I agree, this code passes 3.3.2 for "First name" and fails 1.3.1
>>>>>>>>>> for
>>>>>>>>>> "First name" and 1.3.1 also for "required".
>>>>>>>>> 
>>>>>>>>> This may be where we disagree.  I think that the visual presence
>>>>>>>>> of
>>>>>>>>> “required” is part of the passing of 3.3.2.
>>>>>>>>> 
>>>>>>>>> AWK
>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>> 
>>> 
>> 
>> 
>