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 6:45PM

> 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

Fields in a help desk or accounting app that allowed people to enter information about other users would not fall into this SC as this SC was specifically scoped to the fields which take input about the current user and not information about other users for this very reason. Browsers also have settings that can assist with control of autocomplete information.

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 < <EMAIL REMOVED> > On Behalf Of Jonathan Cohn
Sent: Wednesday, July 25, 2018 3:48 PM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] WCAG 2.1 - 1.3.5 - How to capture a violation?

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
>> >> >> archives at http://webaim.org/discussion/archives
>> >> >> >> archives at http://webaim.org/discussion/archives
>> >>
>
>
>
> --
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> <EMAIL REMOVED>
>
> Advancing the mission of digital accessibility and inclusion
> > > archives at http://webaim.org/discussion/archives
>