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

Greg,
I do not think my view differs from yours at all. That's why I drafted
 a proposal to make Understanding SC 3.3.2 clearer.
IMO Andrew tends to give the word "instructions" a very wide berth
that is not intended by the SC or the definition of the term label.
I captured this in the rationale for the change and the proposal I drafted up:
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/26/16, Gregg Vanderheiden <gregg@raisingthefloor.org> wrote:
> 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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>

Received on Tuesday, 26 April 2016 20:56:22 UTC