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

Ø  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 .

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?  If a required field was not completed it would have to be indicated on error though under SC 3.3.1 and suggestions provided (when known) under SC 3.3.3.

If required fields are indicated visually then they need to be accessible – but indicating them on error would seem to be sufficient to meet the current WCAG 2.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group
jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>
703.637.8957 (Office)

Visit us online: Website<http://www.ssbbartgroup.com/> | Twitter<https://twitter.com/SSBBARTGroup> | Facebook<https://www.facebook.com/ssbbartgroup> | Linkedin<https://www.linkedin.com/company/355266?trk=tyah> | Blog<http://www.ssbbartgroup.com/blog/>
Check out our Digital Accessibility Webinars!<http://www.ssbbartgroup.com/webinars/>

From: Gregg Vanderheiden [mailto:gregg@raisingthefloor.org]
Sent: Tuesday, April 26, 2016 11:07 AM
To: Sailesh Panchang
Cc: Joshue O Connor; Andrew Kirkpatrick; Jonathan Avila; Mike Pluke; James Nurthen; GLWAI Guidelines WG org
Subject: 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<mailto: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<mailto:josh@interaccess.ie> <josh@interaccess.ie<mailto: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<mailto:sailesh.panchang@deque.com>>
To: "Andrew Kirkpatrick" <akirkpat@adobe.com<mailto:akirkpat@adobe.com>>
Cc: "jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>" <jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>>; "Michael
Pluke" <Mike.Pluke@castle-consult.com<mailto:Mike.Pluke@castle-consult.com>>; "James Nurthen"
<james.nurthen@oracle.com<mailto:james.nurthen@oracle.com>>; "w3c-wai-gl@w3.org<mailto:w3c-wai-gl@w3.org>" <w3c-wai-gl@w3.org<mailto: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<mailto: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<mailto: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<mailto:akirkpat@adobe.com>
http://twitter.com/awkawk

http://blogs.adobe.com/accessibility








On 2/17/16, 21:07, "Sailesh Panchang" <sailesh.panchang@deque.com<mailto: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<mailto: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<mailto: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