W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 2015

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

From: Hoffman, Allen <allen.hoffman@hq.dhs.gov>
Date: Wed, 7 Jan 2015 15:31:26 +0000
To: Jonathan Avila <jon.avila@ssbbartgroup.com>, Sailesh Panchang <sailesh.panchang@deque.com>
CC: Web Content Accessibility Guidelines Working Group <w3c-wai-gl@w3.org>
Message-ID: <F2EC405EEF0B414E8B1415742F1C8BEC6F3EB2D5@D2ASEPREA004>
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 15:32:28 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 21:07:57 UTC