- From: Sailesh Panchang <sailesh.panchang@deque.com>
- Date: Thu, 21 Apr 2016 09:30:36 -0400
- 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>
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 Thursday, 21 April 2016 13:31:05 UTC