WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: John Foliot
Date: Jul 25, 2018 11:28AM

As one of the "shepherds" of this SC in the WCAG WG, I will confirm that
both Patrick and Jon are correct. The nuanced difference is the use of a
fixed taxonomy added to the input, versus ensuring it has an accessible
name. The "gain" here is actually more visible in non-english content,
where the accessible name would be localized for the language of the page.

<label for="ThisInput">Почтовый индекс</label> <input type="text"
id="ThisInput" autocomplete="postal-code">


No matter what the language of the label text is, the "machine-readable"
bit is clearly "postal-code", which is unambiguously defined here:
https://www.w3.org/TR/WCAG21/#input-purposes

...and specifically: *"postal-code - Postal code, post code, ZIP code,
CEDEX code (if CEDEX, append "CEDEX", and the dissement, if relevant, to
the address-level2 field)"*

Currently, the "taxonomy list" being used is in fact that normative list of
values and definitions that *is* the autocomplete values, and as others
have noted, currently the 'best' technique is to use @autocomplete to
attach the meta-data term to the input field. Going forward, there are
other activities at the W3C (not yet mature enough for production) related
to "Personalization" that hopes/intends to leverage this initial taxonomy,
and provide additional mechanisms and methods for attaching the values to
the inputs.

HTH

JF

On Wed, Jul 25, 2018 at 11:38 AM, Jonathan Avila < <EMAIL REMOVED> >
wrote:

> > 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
> > > > > > > > >



--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
<EMAIL REMOVED>

Advancing the mission of digital accessibility and inclusion