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

Hello Andrew and Josh,
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.
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 Thursday, 18 February 2016 19:19:40 UTC