WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: WCAG 2.1 - 1.3.5 - How to capture a violation?

for

From: John Foliot
Date: Jul 27, 2018 12:47AM

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