WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: WCAG 2.1 - 1.3.5 - How to capture a violation?

for

From: Jonathan Avila
Date: Jul 25, 2018 10:38AM


> I'm still really confused by what you are suggesting. Again, where does this success criterion state or suggest that accessible name (e.g., <label>, aria-label, etc.) cannot be used to convey the purpose?

From what I understand the goal of the criterion was to ensure that there was a machine readable way to know exactly what the purpose of the field was and therefore allow a user agent, assistive technology, or other tool provide an icon, or other identifier to help users with cognitive and learning disabilities know what content to put in the field. The actual autocompleting of the form field is a side benefit but was not the original intent of the criterion. The name of a field and the purpose can and often will be different for various reasons.

I'd suggest that you log an issue on the github repository for WCAG with what you think would help clarify this in the understanding documents of WCAG 2.1

Best Regards,

Jonathan

Jonathan Avila
Chief Accessibility Officer
Level Access
<EMAIL REMOVED>
703.637.8957 office

Visit us online:
Website | Twitter | Facebook | LinkedIn | Blog

Looking to boost your accessibility knowledge? Check out our free webinars!

The information contained in this transmission may be attorney privileged and/or confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is strictly prohibited.

-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Jared Smith
Sent: Wednesday, July 25, 2018 10:15 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] WCAG 2.1 - 1.3.5 - How to capture a violation?

I'm still really confused by what you are suggesting. Again, where
does this success criterion state or suggest that accessible name
(e.g., <label>, aria-label, etc.) cannot be used to convey the
purpose?

1.3.1 allows (or nearly requires) that accessible name be used to
ensure that "information, structure, and relationships... can be
programmatically determined", so I can't see how 1.3.5, which requires
that "the purpose... can be programmatically determined" (nearly
identical wording), would prohibit this technique. "Programmatically
determined" can't mean two entirely different things for different
success criteria.

> The accessible name is generally not seen to fall into that category because of localization and other issues make prevent it from clearly aligning without ambiguity.

Where does the success criterion indicate or suggest that the purpose
has to be determined independent of localization or unambiguously? If
programmatically determined means "determined independent of
language", then it must also mean this in 1.3.1 (and elsewhere), which
would mean that all accessible names (if this was the chosen technique
for 1.3.1) would have to be language independent.

If the intent of this SC is to ensure that the purpose be identified
universally and unambiguously in all languages via some mechanism
other than accessible name, then it needs to be significantly edited
to indicate this. As is stands now, I see no way in which an
accessible name that conveys the purpose of the field would not be
sufficient to meet the normative text. If I'm wrong, I'm going to need
a much clearer explanation of how "programmatically determined" means
something different here than for the rest of WCAG.

Jared