WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Jared Smith
Date: Jul 26, 2018 9:10AM

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