E-mail List Archives
Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
From: John Foliot
Date: Jul 25, 2018 11:28AM
- Next message: Jim Homme: "Re: Hidden headings with aria-labelledby or just aria-label best for for labelling landmark regions?"
- Previous message: Jared Smith: "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: Jared Smith: "Re: WCAG 2.1 - 1.3.5 - How to capture a violation?"
- View all messages in this Thread
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: Jim Homme: "Re: Hidden headings with aria-labelledby or just aria-label best for for labelling landmark regions?"
- Previous message: Jared Smith: "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: Jared Smith: "Re: WCAG 2.1 - 1.3.5 - How to capture a violation?"
- View all messages in this Thread