WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Jonathan Cohn
Date: Jul 25, 2018 1:48PM

Interesting, so i believe you are suggesting that using the codes associated with auto-complete attributes gives a language / region independent way of indicating what a specific fields purpose is, and that this could be used to help with designing a personalization accessibility issue.

For individuals working a help desk / call center / data entry fields I would think using auto-complete attribute would attempt to find information from a local directory to fill in the field with auto complete information. But for these applications where 90% of the time one is entering information that will only ever be used for that session I would expect auto-complete would cause more issues than it resolves. Is there currently another attribute being suggested or provided that would resolve these conflicts?

Best Wishes,

Jonathan Cohn

> On Jul 25, 2018, at 1:28 PM, John Foliot < <EMAIL REMOVED> > wrote:
>
> 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
> > > >