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 27, 2018 5:31AM

Don't forget WCAG2.0 also has 2.4.6 headings and labels describe topic or purpose but unlike 1.3.5 doesn't require it to be programmatically determinable.

Jonathan

Sent from my iPhone

> On Jul 27, 2018, at 2:48 AM, John Foliot < <EMAIL REMOVED> > wrote:
>
> Hi Jared,
>
> It's rather difficult to
> explain that an associated label is "programmatically determined" to
> convey "information and relationships" for an input under 1.3.1, but
> is not "programmatically determined" to convey "purpose" for an input
> under 1.3.5.
>
> Quick check: we're not confusing "programmatically *associated*" with
> "programmatically *determined*" here, correct?
>
> An "associated label" (i.e. one that uses the <label> element) is but one
> way of labeling an input to convey information and relationships; we could
> also use @label or @labelledby to meet the requirements of SC 1.3.1. As
> long as a "label" (aka Accessible Name) is programmatically determinable,
> then the value string that is associated to the concept of "label" can also
> be programmatically determined, and presented in a different modality (for
> example, in audio via a screen reader).
>
> *WHAT* the value string is (i.e. the text or instructions to convey the
> purpose *to the human user*, in any language) is not covered by this SC,
> but rather by an "Understanding" SC: Success Criterion 3.3.2 Labels or
> Instructions (Level A): Labels or instructions are provided when content
> requires user input. It's both SC, working together, that allows for both
> Perceiveability and Understandability in this use-case.
>
> Succinctly: 1.3.1 ensures that machines and software (like screen readers)
> can determine that there is a label there, and further convey what the
> label's "value" is to different modalities, 3.3.2 ensures that the end user
> can actually understand the string and do something with it (i.e., interact
> with the input)
>
>
> (Quick related note - why is title attribute -
> https://www.w3.org/TR/WCAG20-TECHS/H65.html - sufficient to meet
> 1.3.1? This doesn't seem to meet your definition for "programmatically
> determined", right?)
>
> ah yes, @title. A three part answer:
>
> 1) It is important to again remember that SC 1.3.1 wants a programmatically
> determinable way of determining the the label for the input - a machine
> recognizable identifier (for example @label or @title) that will have a
> value string that, for the purposes of the accessibility API's need for an
> "Accessible Name", can be a random string that can be both seen visually,
> but also can be presented in a different modality (audio). Again the *value* of
> the string here is for human consumption and cognition (thus a string that
> still needs to be "understandable" to meet SC 3.3.2), but the "association"
> is programmatically 'determined' (aka identified and associated) using an
> attribute (fixed term) on the input element. (Remember too that it has to
> be a fixed term, so that the machine has a fixed text string to "look up"
> or pattern match against.)
>
> 2) Originally, the HTML Accessibility API Mappings 1.0 (
> https://www.w3.org/TR/html-aam-1.0/#input-type-text-input-type-password-input-type-search-input-type-tel-input-type-url-and-textarea-element)
> included @title as part of the Accessible Name calculation:
>
> 1. If the control has an aria-label
> <https://www.w3.org/TR/wai-aria-1.1/#aria-label> or an aria-labelledby
> <https://www.w3.org/TR/wai-aria-1.1/#aria-labelledby> attribute
> the accessible
> name <https://www.w3.org/TR/html-aam-1.0/#dfn-accessible-name> is to
> be calculated using the algorithm defined in Accessible Name and
> Description: Computation and API Mappings 1.1
> <https://w3c.github.io/accname/>.
> 2. Otherwise use the associated label element(s) accessible name
> <https://www.w3.org/TR/html-aam-1.0/#dfn-accessible-name>(s) - if
> more than one label is associated; concatenate by DOM order,
> delimited by spaces.
> 3. Otherwise use the title attribute
> 4. If none of the above yield a usable text string there is no accessible
> name <https://www.w3.org/TR/html-aam-1.0/#dfn-accessible-name>
>
> However, as we know, in practice this wasn't working - @title was *NOT*
> being conveyed by screen readers as the accessible name. (I'll note that
> this is the fault of the Screen Readers for not supporting the spec, but
> also necessitating a change in the specification). This has been addressed
> with the publishing of Accessible Name and Description Computation 1.1 (W3C
> Candidate Recommendation 19 June 2018) (
> https://www.w3.org/TR/accname-1.1/#mapping_additional_nd_te) which has
> removed @title from the calculation. As such it has negated that technique
> (note to self - action item two: more housekeeping)
>
> 3) We know that "technical conformance" does not equal "accessible", so the
> technique, while ineffective today (and I would recommend it be avoided)
> will none-the-less still meet the "technical conformance" that a legal
> reading of WCAG 2.0. conformance may mandate. (In other words, because it
> was an effective [sic] technique when 2.0 was published, we cannot un-ring
> the legislative bell that attached legal conformance to the technical
> specification.) It sucks, mostly because legislation demands a fixed
> published spec, while technology changes daily from under our feet, but
> that is the answer to your question. (On a more positive note, because
> Techniques are non-normative, it may be easier to remove them, so I think
> we'll be able to do so, but I cannot "guarantee" that - we may have to
> settle with a WARNING in that technique.)
>
>
> If a field maps to one of the defined "input purposes" and does not
> have the proper autocomplete attribute, is it a failure? In other
> words, is
> <label>Name <input type="text"></label>
> now a WCAG 2.1 failure?
>
> Well... it does not meed the requirement of SC 1.3.5, but it does still
> meet WCAG 2.1's SC 1.3.1 and SC 3.3.2. But broadly speaking, no, you could
> not claim 2.1 conformance with that code snippet, because the value, while
> in English in your example, can be any string text value in any language,
> so it cannot be "looked up" by a machine. Machines need fixed token strings
> to do that kind of functionality.
>
>
> I really need a clear answer to this question. You've stated several
> times that autocomplete is not the only way to meet this SC.
>
> No I haven't Jared, please re-read my responses.
>
> Today(!) the only *functioning technique* we have to meet this SC is to use
> @autocomplete, but what is important to understand (with relationship to
> the 'ask' of this SC) is what we needed to do: we needed a mechanism to
> attach a fixed token string (a taxonomy term) to the input element that
> could be machine interpreted for the purposes of output in different
> modalities.
>
> Initially, this SC had a lot more to it (common buttons and controls - see
> this for an *idea* of what we were looking at:
> https://docs.google.com/spreadsheets/d/1N63TKXrUXSmF1OeZAgpy8iTnDyQ1nzVbrevq2lBDvos/edit?usp=sharing
> )
> , but because we lacked the appropriate taxonomy, and creating a new
> taxonomy was out of scope for our Working Group, we had to 'settle' for a
> smaller
> existing
> taxonomy that was those token values initially defined in HTML5 for
> @autocomplete
> .
>
> However, while that taxonomy has yet to be ported to say, a Schema.org
> notation, I had also explored the ability to so, so that we could attach
> that token value to an element using Microdata (
> https://www.w3.org/TR/microdata/) - a technique put aside (due to the lack
> of an established taxonomy) but I hope to continue to expand upon.
>
> Additionally, and related to this discussion, the Personalization Task
> force is currently exploring other/different mechanisms to attach an
> extended taxonomy (under development) for other similar needs. (see:
> https://github.com/w3c/personalization-semantics/wiki/Comparison-of-ways-to-use-vocabulary-in-content
> )
>
>
> This was
> a primary factor in my misunderstanding this SC - I thought if
> @autocomplete isn't required, then certainly a descriptive label is
> therefore sufficient, because how else would they pass? Now, based on
> your explanations, I don't see how anything other than @autocomplete
> could be sufficient to meet this SC today.
>
> Well, once again, a descriptive label is for the human to compute, but we
> need a mechanism that also allows for a machine to compute the "Purpose" of
> the element. That mechanism has two parts, a means of attaching it that is
> "programmatically determinable" (i.e. an attribute), AS WELL AS a token
> value taken from the list of defined tokens that are the @autocomplete/WCAG
> 2.1 tokens as the value string of the attribute. (In the same way that
> @lang - the attribute, uses a fixed token - the country code values defined
> in the ISO specification, as the two parts required to meet the Language
> SC's: lang="en" passes, lang="english" fails)
>
>
> As a follow-up... what if the associated label uses language that is
> common and standard for that input purpose (e.g., "Name" or "Credit
> card"). I believe most (all?) common form fillers interpret these
> common label values to provide the needed form-fill functionality
> (otherwise they wouldn't work on forms that lack @autocomplete).
>
> Nope, because those are random text strings that, in your example, are in
> the same language as the token (English), but often won't be. Additionally
> and as an aside, "Credit Card" would not suffice, as the required token for
> that input is actually (presumably?) cc-number (but, because your visible,
> on-screen English label is actually too vague, could also be one of any of
> the other cc-* values, such as cc-name, cc-address, etc. See:
> http://john.foliot.ca/demos/autofill.php)
>
> As for form fillers, my limited testing (
> https://www.w3.org/WAI/GL/wiki/WCAG_2.1_Implementations/JF/research)
> suggests that those tools are currently doing heuristics against English
> token values, but they don't work very well if you aren't using the English
> token somewhere in the code, so their usefulness is significantly
> diminished in non-English locales. This is a poster child for why
> "standards" are so important: if those tools using heuristics today instead
> supported the @autocomplete spec as defined, they could extend their market
> reach, but, well, you know...
>
>
> Using
> @autocomplete would thus provide no additional benefit or
> functionality in this case. If the author deems these to be
> "accessibility supported", would this be sufficient to meet 1.3.5?
>
> Functionality to whom? More importantly, is the benefit understood? That
> what is being sought is not for the humans to consume directly, its for the
> machines: the goal of this SC is NOT to make forms easier to fill out, but
> rather for machines to understand, with zero ambiguity, what is being
> sought in the tagged <input>, using an attribute and a fixed token or
> taxonomy term, so that expressing that "purpose" or "label" can be further
> conveyed to different modalities (such as using an icon). Please stop
> thinking of this as a human-consumable requirement, it isn't, it's for
> machines to do something with.
>
>
> Your arguments about other languages seems a stretch here. Why would
> someone that only speaks Vietnamese need to know the purpose of an
> input on an English page they can't understand? But if their
> Vietnamese form filler knows that "Số thẻ tín dụng" is for credit card
> number on a Vietnamese page, then @autocomplete doesn't give them
> anything extra. If this is the case, then why require it to meet
> 1.3.5?
>
> Hopefully by now, the answer here is clear. The outcome of the Success
> Criteria is to take "languages" out of the equation: we're using a fixed
> token, written in English, as a value string for an attribute, also written
> in English, "programmatically" attached to the <input> element - none of
> which is shown on screen, but expressed in the DOM, so that machines now
> also understand (or at least can be programmed to understand) what is being
> sought. The fact that the only technique we can apply today also has (for
> purposes of this SC) the added benefit that browsers and other tools can
> also act on that metadata by, for example, supplying *your* data (localized
> text strings stored locally in the browser or password manager tools) when
> the machine understands what is being asked for in a form input is a bonus:
> that functionality is but one outcome achieved when you tag the input with
> a fixed token value, but not the goal of the SC (which, coming full circle,
> I acknowledge is less than clear in the Understanding document, which needs
> to be fixed).
>
>
> HTH
>
> JF
>
>> On Thu, Jul 26, 2018 at 10:10 AM, Jared Smith < <EMAIL REMOVED> > wrote:
>>
>> John -
>>
>> Thanks for taking the time to provide such a detailed explanation.
>> This really is very helpful and informative.
>>
>> I've always viewed programmatically determined as being adapted in a
>> way or "different modalities" that provides meaning and usefulness to
>> the user. But I can see based on your explanations that this
>> user-focused interpretation is too broad - it focuses instead only on
>> computer parsing.
>>
>> I won't belabor the discussion about the semantics and nuances of the
>> language and terms any more, except to restate that I do not believe
>> that we can expect web authors to understand the requirements of this
>> success criterion from the normative text. It's rather difficult to
>> explain that an associated label is "programmatically determined" to
>> convey "information and relationships" for an input under 1.3.1, but
>> is not "programmatically determined" to convey "purpose" for an input
>> under 1.3.5.
>>
>> (Quick related note - why is title attribute -
>> https://www.w3.org/TR/WCAG20-TECHS/H65.html - sufficient to meet
>> 1.3.1? This doesn't seem to meet your definition for "programmatically
>> determined", right?)
>>
>> But this language and the W3C's interpretation of it is not changing.
>> So it becomes incumbent upon us to try to explain it in ways that will
>> minimize confusion and potential liability for web authors. Which
>> brings me to a couple additional questions...
>>
>> If a field maps to one of the defined "input purposes" and does not
>> have the proper autocomplete attribute, is it a failure? In other
>> words, is
>> <label>Name <input type="text"></label>
>> now a WCAG 2.1 failure?
>>
>> I really need a clear answer to this question. You've stated several
>> times that autocomplete is not the only way to meet this SC. This was
>> a primary factor in my misunderstanding this SC - I thought if
>> @autocomplete isn't required, then certainly a descriptive label is
>> therefore sufficient, because how else would they pass? Now, based on
>> your explanations, I don't see how anything other than @autocomplete
>> could be sufficient to meet this SC today.
>>
>> As a follow-up... what if the associated label uses language that is
>> common and standard for that input purpose (e.g., "Name" or "Credit
>> card"). I believe most (all?) common form fillers interpret these
>> common label values to provide the needed form-fill functionality
>> (otherwise they wouldn't work on forms that lack @autocomplete). Using
>> @autocomplete would thus provide no additional benefit or
>> functionality in this case. If the author deems these to be
>> "accessibility supported", would this be sufficient to meet 1.3.5?
>>
>> Your arguments about other languages seems a stretch here. Why would
>> someone that only speaks Vietnamese need to know the purpose of an
>> input on an English page they can't understand? But if their
>> Vietnamese form filler knows that "Số thẻ tín dụng" is for credit card
>> number on a Vietnamese page, then @autocomplete doesn't give them
>> anything extra. If this is the case, then why require it to meet
>> 1.3.5?
>>
>> I really appreciate the dialogue! Thanks again!
>>
>> Jared
>> >> >> >> >>
>
>
>
> --
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> <EMAIL REMOVED>
>
> Advancing the mission of digital accessibility and inclusion
> > > >