RE: WCAG-ISSUE-43: ARIA2 and PDF5 do not apply to SC 3.3.3 [HTML & ARIA Techniques TF]

I don't know how to silence SR presently, but think such logic for reducing redundant output would be something SR manufacturers can and should be looking at.  Ideally the simple criteria I'd implement for SR would be if output from standard HTML mark up equals ARIA output, only output the difference.  Probably not said right but the idea is to only speak information once.  SR(s) don't tell the end-user where the information came from, so users would not be involved other than configuring how they want such treated as can be done to some extent in JAWS and other screen readers now for form fields and othe elements.


Allen Hoffman
Deputy Executive Director
The Office of Accessible Systems & Technology
Department of Homeland Security
202-447-0503 (voice)
allen.hoffman@hq.dhs.gov

DHS Accessibility Helpdesk
202-447-0440 (voice)
202-447-0582 (fax)
202-447-5857 (TTY)
accessibility@dhs.gov
 
This communication, along with any attachments, is covered by federal and state law governing electronic communications and may contain sensitive and legally privileged information. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, use or copying of this message is strictly prohibited.  If you have received this message in error, please reply immediately to the sender and delete this message.  Thank you.

-----Original Message-----
From: Sailesh Panchang [mailto:sailesh.panchang@deque.com] 
Sent: Wednesday, January 07, 2015 12:34 PM
To: Jonathan Avila; Hoffman, Allen
Cc: Web Content Accessibility Guidelines Working Group
Subject: Re: WCAG-ISSUE-43: ARIA2 and PDF5 do not apply to SC 3.3.3 [HTML & ARIA Techniques TF]

Hello Jonathan / Allen,

JDA: That sounds like an issue for all users if only two fields have
stars -- so I'm not sure that alone is a WCAG violation.  That's poor
design.
Sailesh: Only 2 fields have a star because only 2 fields are required!
Not sure why you say it is poor design.

JDA: I don't think that matters.   The suggestion is provided either
way -- there is nothing in WCAG that says the suggestion needs to
change.
Sailesh: Sure, WCAG 2 does not say so but the SR read "First name
required" before the form submission and again after errors are
detected. As a user, one does not see any distinction at all. The
label and "required"  did not ring a bell for the user the first time
so there's a chance it will not the second time around too. So in this
instance placing an aria-invalid=true will surely convey explicitly
that the field failed validation.
Example 1: http://mars.dequecloud.com/demo/Form-AriaLiveWithJQ.htm

This is sufficient for  3.3.1 because  now the field is identified by
its label and  is also marked as  not being valid i.e. error is
present.

JDA: Please enter a first name would be required under SC 3.3.1 IMO
because it identifies the field in error -- but not under 3.3.3
because the system
wouldn't actually tell if it was a real first name or not.
Sailesh: 'Please enter a first name' is saying how the error can be
fixed, so it will satisfy 3.3.3, and in so doing also satisfies 3.3.1.
SC 3.3.1 does not require the suggestion to be part of the message.
Identifying "real name" is not  assumed to be part of the validation
text here. Keep it simple let us focus only on presence / absence of
data as that's what aria-required or the star are intended for.

JDA: Invalid isn't specific enough to be helpful in most situations...
Sailesh: That was the challenge when I wrote up the aria-invalid
technique and examples . The question was "how can aria-invalid stand
on its own to satisfy 3.3.1?' And the description and the examples I
proposed(including one  above) support that.
Example 2: http://mars.dequecloud.com/demo/form-alert3.htm


JDA:  but I think it could be useful.  For example, you can meet SC
3.3.1 by listing all
of the fields at the top of the screen in error.  Then you could use
aria-invalid at the specific fields in error.  This would be helpful
to me because
I can read all of them at the top but then go through the form field
by field and know via aria-invalid which ones were invalid.
Sailesh: Please see example 1 and 2 for aria-invalid.
If the errors are listed up top,  maybe using aria-describedby will
help the user  with the specific message when focus is on the field.
Example 3: http://mars.dequecloud.com/demo/form-alert2.htm


Allen, please tell me how to silence the SR from announcing 'invalid
entry' for aria-invalid=true?
On a website using it  may be quite useful as in example 1 and 2 but
redundant as in example 3. So will a user on a website know when to
turn it on/off?
Thanks,
Sailesh Panchang

Thanks,
Sailesh Panchang


On 1/7/15, Hoffman, Allen <allen.hoffman@hq.dhs.gov> wrote:
> How do we codify that folks need to do basic HTML coding, and can then
> optionally add ARIA on, but should rarely replace standard HTML coding with
> ARIA only.  This seems to be an almost religious argument within our
> community, but for broadest accessibility doing foundational coding, and
> adding ARIA as supplement, rather than replacement solution is the most
> effective path forward today in my opinion.  If, adding ARIA increases noise
> level for some situations that is easily a configurable option for the
> assistive technology on what to read in what priority and what can be
> ignored.  For example, if ARIA duplicates previously coded information why
> would the screen reader duplicate the reading, other than due to not
> including such a check in the screen reader itself.  On the other hand if
> the ARIA gets dropped because of older environment, the foundational coding
> will take care of the gap.  I don't believe standard HTML syntax supporting
> accessibility is deprecated, so replacing with less supported ARIA to me
> seems like putting the cart before the horse.
>
>
>
>
> Allen Hoffman
> Deputy Executive Director
> The Office of Accessible Systems & Technology
> Department of Homeland Security
> 202-447-0503 (voice)
> allen.hoffman@hq.dhs.gov
>
> DHS Accessibility Helpdesk
> 202-447-0440 (voice)
> 202-447-0582 (fax)
> 202-447-5857 (TTY)
> accessibility@dhs.gov
>
> This communication, along with any attachments, is covered by federal and
> state law governing electronic communications and may contain sensitive and
> legally privileged information. If the reader of this message is not the
> intended recipient, you are hereby notified that any dissemination,
> distribution, use or copying of this message is strictly prohibited.  If you
> have received this message in error, please reply immediately to the sender
> and delete this message.  Thank you.
>
> -----Original Message-----
> From: Jonathan Avila [mailto:jon.avila@ssbbartgroup.com]
> Sent: Wednesday, January 07, 2015 10:03 AM
> To: Sailesh Panchang
> Cc: Web Content Accessibility Guidelines Working Group
> Subject: RE: WCAG-ISSUE-43: ARIA2 and PDF5 do not apply to SC 3.3.3 [HTML &
> ARIA Techniques TF]
>
> Sailesh, see my comments below as jda.
>
> Consider  a case where there is an asterisk next to  first and last name
> fields (not part of field's label). And there is a middle name field without
> the star. One  could bring the star within the label to
> make it PD. Or one could place aria-required=true.   The star does not
> go away when when one enters data into the fields. Are you suggesting one
> should remove the star and aria-required or set it to false when one enters
> data into the fields?
>
> JDA: No
>
> The aria-required serves the same purpose as the star and it can be PD. If I
> choose to review the form before submitting it  I'll not know that I need
> not have entered a middle name. This is misleading when a star is displayed
> only for 2 of the 3 fields.
>
> JDA: That sounds like an issue for all users if only two fields have stars
> -- so I'm not sure that alone is a WCAG violation.  That's poor design.
>
> When form submission fails,  it is not good enough for SC 3.3.3 if the PD
> text for first name simply reads the label and the word required.
>
> JDA:  If the field is only checked to see if it is empty or not -- then why
> isn't required enough to meet SC 3.3.3.  The suggestion is to put data into
> the field.  G83 could be read that this is acceptable to indicate required
> as a way to meet 3.3.3
>
> That was read even before the form was submitted.
> JDA: I don't think that matters.   The suggestion is provided either way --
> there is nothing in WCAG that says the suggestion needs to change.
>
> The suggestion should say something like "Please enter a first name"  for SC
> 3.3.3 compliance. And if this is done, do you not agree that aria-invalid
> simply creates more noise for the end user? Refer to examples for
> aria-invalid.
>
> JDA: Please enter a first name would be required under SC 3.3.1 IMO because
> it identifies the field in error -- but not under 3.3.3 because the system
> wouldn't actually tell if it was a real first name or not.
>
> do you not agree that aria-invalid simply creates more noise for the end
> user? Refer to examples for aria-invalid.
>
> JDA: Invalid isn't specific enough to be helpful in most situations but I
> think it could be useful.  For example, you can meet SC 3.3.1 by listing all
> of the fields at the top of the screen in error.  Then you could use
> aria-invalid at the specific fields in error.  This would be helpful to me
> because I can read all of them at the top but then go through the form field
> by field and know via aria-invalid which ones were invalid.
>
> Thanks,
>
> -----Original Message-----
> From: Sailesh Panchang [mailto:sailesh.panchang@deque.com]
> Sent: Tuesday, December 16, 2014 11:26 AM
> To: Jonathan Avila
> Cc: Web Content Accessibility Guidelines Working Group
> Subject: Re: WCAG-ISSUE-43: ARIA2 and PDF5 do not apply to SC 3.3.3 [HTML &
> ARIA Techniques TF]
>
> Hi Jonathan,
> Consider  a case where there is an asterisk next to  first and last name
> fields (not part of field's label). And there is a middle name field without
> the star. One  could bring the star within the label to
> make it PD. Or one could place aria-required=true.   The star does not
> go away when when one enters data into the fields. Are you suggesting one
> should remove the star and aria-required or set it to false when one enters
> data into the fields? The aria-required serves the same purpose as the star
> and it can be PD. If I choose to review the form before submitting it  I'll
> not know that I need not have entered a middle name. This is misleading when
> a star is displayed only for 2 of the 3 fields.
> When form submission fails,  it is not good enough for SC 3.3.3 if the PD
> text for first name simply reads the label and the word required.
> That was read even before the form was submitted. The suggestion should say
> something like "Please enter a first name"  for SC 3.3.3 compliance. And if
> this is done, do you not agree that aria-invalid simply creates more noise
> for the end user? Refer to examples for aria-invalid.
> Thanks,
> Sailesh
>
>
>
>
> On 12/16/14, Jonathan Avila <jon.avila@ssbbartgroup.com> wrote:
>>> ARIA2  nor PDF5 do not apply to SC 3.3.3. Simply placing
>>> aria-required=true by itself does not help to say how an
>>
>> I see this as a layered approach.  ARIA2 can only be used if the field
>> is empty.  Once the field contains data then you would need different
>> suggestion of the field is still in error and the field is
>> automatically detected.
>>
>> Jonathan
>>
>> -----Original Message-----
>> From: Web Content Accessibility Guidelines Working Group Issue Tracker
>> [mailto:sysbot+tracker@w3.org]
>> Sent: Tuesday, December 16, 2014 10:32 AM
>> To: w3c-wai-gl@w3.org
>> Subject: WCAG-ISSUE-43: ARIA2 and PDF5 do not apply to SC 3.3.3 [HTML
>> & ARIA Techniques TF]
>>
>> WCAG-ISSUE-43: ARIA2 and PDF5 do not apply to SC 3.3.3 [HTML & ARIA
>> Techniques TF]
>>
>> http://www.w3.org/WAI/GL/track/issues/43

>>
>> Raised by: Sailesh Panchang
>> On product: HTML & ARIA Techniques TF
>>
>> ARIA2  nor PDF5 do not apply to SC 3.3.3. Simply placing
>> aria-required=true by itself does not help to say how an input error may
>> be fixed.
>> The attribute is seldom added after form submission when input errors
>> are detected.
>> When it is used, generally, is exposed before form submission.
>> So I do not see how ARIA2 / PDF5 apply to SC 3.3.3.
>>
>>
>>
>>
>>
>

Received on Wednesday, 7 January 2015 17:40:53 UTC