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.

I left out one example:
<label for=“fn”>First name</label><input required type=“text”
id=“fn”> — 1.3.1 ok, 3.3.2 issue


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

Let’s figure out G83 first.
AWK


>
>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:58:07 UTC