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

Hi Andrew,
Your 4th example:
"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"
===
Sailesh:
This is covered by scenario #2 in my email above. I did address this
when I stated, "When there is no visual cue, merely adding
aria-required=true will only help one group of users and not users
with cognitive impairments." I also suggested the "required" property
is a method of satisfying 1.3.1.

Sorry I do not agree example 4 poses  a 3.3.2 issue because  I believe
we agreed,  examples 1 to 3 pass 3.3.2 with only "First name" inside
the label. This is still the case with example 4.
Just as browsers expose  the "required" property to screen readers,
browsers need to provide a visual cue too. Until this happens, it is
the responsibility of developers to provide a visual cue especially
when they use "required" property.
Till then, all sighted users PWD or not are in the same boat.
Who knows, one can argue, the UI did not support a  visual cue (like
H65 - use title when visual label cannot be used). the  content author
/ developer only used the "required" property for its  other very
useful feature: placing focus on the field if it was empty on
submission ... and avoid doing some JS work to accomplish the same.
Also, I am guided by the later half of 3.3.2 intent in the
understanding doc that contains "... not to clutter..."
The required property can also be provided  by an accessible tooltip
when field gets focus in the manner other data formats / input rules
are  exposed sometimes. The label text "First name" is  the "enough
info" as determined by the author  when no visual cue is present.

Thanks,
Sailesh


On 2/12/16, Andrew Kirkpatrick <akirkpat@adobe.com> wrote:
>>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 18:17:03 UTC