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

Andrew,
Thanks for your time and responding to this thread.
Actually  your examples are reinforcing my argument, that conveying
the mandatory nature of the field is only a 1.3.1 issue and not 3.3.2
issue.
<label for=“fn”>First name</label>(required)<input type=“text”
id=“fn”> — 1.3.1 issue, 3.3.2 ok
 <label for=“fn”>First name (required)</label><input type=“text”
id=“fn”> — 1.3.1 and 3.3.2 ok
 <label for=“fn”>First name</label>(required)<input
aria-required=“true” type=“text” id=“fn”> — 1.3.1 and 3.3.2 ok

In all the 3 above 3.3.2 is ok because the LABEL tag contains "First name".
Eexample #1 passes 3.3.2 and fails 1.3.1 because "required" is not PD.

In example #2, the label for-id method is additionally being used to
provide programmatic association and meet SC 1.3.1 by including
"required" within the label.
Without "required" in the label it still passes 3.3.2.

In example #3, aria-required is being used to satisfy 1.3.1 ... the
label is the same as in example #1. So without the aria-required, this
only fails 1.3.1.

In other words, the label element for-id method or aria-required or
required properties can be used to provide programmatic association to
convey field is mandatory and thus satisfy 1.3.1. Doing so does not
alter the  "pass" state of 3.3.2 in above examples.

That's why I am suggesting  that 3.3.2 should be de-linked from  G83
and H90 and 1.3.1 should be added to H90.
They  will be in sync with  ARIA2 that is written most recently.

I agree, in Scenario 1B, the instructional statement above the  form
can be strengthened at field level by using aria-required=true.
Maybe I was not clear in the previous email ... I meant it is not
practical to associate that complete line of instruction
programmatically at individual field level.

Sorry, I am not sure how you reached the conclusion that I consider
3.3.2 as unnecessary. That is not my view. In all the three code
examples above, the label "first name" is necessary to pass 3.3.2.

Thanks and kind regards,
Sailesh


On 2/12/16, Andrew Kirkpatrick <akirkpat@adobe.com> wrote:
>>There are two scenarios here:
>>Scenario 1:
>>a. The mandatory nature of the field is  visually available next to  the
>> field or its label (astterisk, "-required" text or the like):
>>This may be included within the label along with the field's text label or
>> by using required / aria-required. This essentially meets SC 1.3.1.
>>Often it is convenient to include the visible asterisk or "- required" like
>> text  within the label  and thereby  make it PD.
>>Failing to associate such a visual cue  only leads to a failure of 1.3.1 at
>> best and not 3.3.2 I believe.
>
> I agree that if there is a visual cue and the visual cue is not paired with
> some manner of programmatic indication that conveys that the field is
> required, then there is a 1.3.1 issue.  That scenario passes 3.3.2 as there
> are “labels or instructions”.
>
> This would mean:
>
> <label for=“fn”>First name</label>(required)<input type=“text” id=“fn”> —
> 1.3.1 issue, 3.3.2 ok
> <label for=“fn”>First name (required)</label><input type=“text” id=“fn”> —
> 1.3.1 and 3.3.2 ok
> <label for=“fn”>First name</label>(required)<input aria-required=“true”
> type=“text” id=“fn”> — 1.3.1 and 3.3.2 ok
>
>
>
>>b. There is an instruction before the form like "all fields are mandatory
>> unless indicated as optional".
>>This then is not associated with individual fields and it is not practical
>> to do so.
>
> OK, so that would provide the instructions (labels would still be associated
> with each control) and each control would also need to have programmatic
> indication that the field is required.
>
>>Scenario 2:
>>There is no visual cue or instruction to incicate that certain fields are
>> mandatory.
>>
>>Today, SC 3.3.2 only requires a label or instruction. Refer: the first
>> sentence under intent of the understanding doc. So a label that says
>> "Name" when it should have been "First name" still passes 3.3.2 but may
>> fail 2.4.6. (The next field may correctly have "Last name" as its label).
>>
>
> I don’t agree with your conclusion from the first sentence of the 3.3.2
> understanding intent.  The sentence: "The intent of this success criterion
> is to have content authors place instructions or labels that identify the
> controls in a form so that users know what input data is expected” suggests
> to me that “name” as the label when “first name” is requested would be an
> issue (albeit a somewhat middling one).
>
>>
>>When mandatory nature of fields or  format requirements are  not available
>> to any user group, everyone is disadvantaged.
>>Everyone has to navigate through the form again and re-submit the form. The
>> manner in which  SC 3.3.1 and 3.3.3 are met is significant here and can
>> make a difference.
>
> This argument suggests that 3.3.2 should be removed entirely.  If a visual
> label isn’t provided it is a general usability issue and not a WCAG issue is
> how the argument goes.  I don’t like being on the slippery slope but I do
> think that we should keep 3.3.2 and that people with disabilities would be
> more affected.
>
>>So, requiring the mandatory nature of some fields or data format
>> instructions be included  as part of the label text or as a visual cue
>> can be added as a future SC 3.3.2 extension requirement. But this may
>> violate content author's freedom.
>
> In my opinion, if the form control is known to be required, there needs to
> be visual labeling and programmatic indication of the required state.  The
> visual rolls up to 3.3.2 and the programmatic rolls up to 1.3.1.
>
> Given that, and everything else the group has to do, I’m not seeing a
> compelling need to change this.
>
> AWK
>

Received on Friday, 12 February 2016 16:35:12 UTC