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

Allen,

I am 100% with you on this....<smile>



* katie *
 
Katie Haritos-Shea 
Senior Accessibility SME (WCAG/Section 508/ADA/AODA)
 
Cell: 703-371-5545 | ryladog@gmail.com | Oakton, VA | LinkedIn Profile | Office: 703-371-5545

-----Original Message-----
From: Hoffman, Allen [mailto:allen.hoffman@hq.dhs.gov] 
Sent: Wednesday, January 7, 2015 12:40 PM
To: Sailesh Panchang; 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]

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 18:24:34 UTC