E-mail List Archives
Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
From: Jonathan Cohn
Date: Jul 25, 2018 1:48PM
- Next message: Jared Smith: "Re: WCAG 2.1 - 1.3.5 - How to capture a violation?"
- Previous message: John Foliot: "Re: WCAG 2.1 - 1.3.5 - How to capture a violation?"
- Next message in Thread: Jared Smith: "Re: WCAG 2.1 - 1.3.5 - How to capture a violation?"
- Previous message in Thread: John Foliot: "Re: WCAG 2.1 - 1.3.5 - How to capture a violation?"
- View all messages in this Thread
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.
>>
>>
- Next message: Jared Smith: "Re: WCAG 2.1 - 1.3.5 - How to capture a violation?"
- Previous message: John Foliot: "Re: WCAG 2.1 - 1.3.5 - How to capture a violation?"
- Next message in Thread: Jared Smith: "Re: WCAG 2.1 - 1.3.5 - How to capture a violation?"
- Previous message in Thread: John Foliot: "Re: WCAG 2.1 - 1.3.5 - How to capture a violation?"
- View all messages in this Thread