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

>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 15:01:11 UTC