E-mail List Archives
Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
From: Patrick H. Lauke
Date: Jul 25, 2018 10:14AM
- Next message: Jonathan Avila: "Re: WCAG 2.1 - 1.3.5 - How to capture a violation?"
- Previous message: Jared Smith: "Re: WCAG 2.1 - 1.3.5 - How to capture a violation?"
- Next message in Thread: Jonathan Avila: "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
This has been the crux of the problem around 1.3.5. It really means "machine-readable", i.e. it needs to be part of a defined taxinomy that tools can use to determine the purpose of a control (and potentially offer useful behaviour, such as autofilling form fields). But in the context of 1.3.1 it's also about using semantically correct markup...you couldn't just rely on a set of spans and then give them a label of "list item" and call it good.
> On 25 Jul 2018, at 15:15, Jared Smith < <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?
>
> 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
> > > >
- Next message: Jonathan Avila: "Re: WCAG 2.1 - 1.3.5 - How to capture a violation?"
- Previous message: Jared Smith: "Re: WCAG 2.1 - 1.3.5 - How to capture a violation?"
- Next message in Thread: Jonathan Avila: "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