E-mail List Archives
Re: WCAG 2.1 - 1.3.5 - How to capture a violation?
From: Jared Smith
Date: Jul 27, 2018 10:32PM
- Next message: glen walker: "Re: When "Alt" is not the semantically-correct representation of an image"
- Previous message: Birkir R. Gunnarsson: "Re: When "Alt" is not the semantically-correct representation of an image"
- Next message in Thread: John Foliot: "Re: WCAG 2.1 - 1.3.5 - How to capture a violation?"
- Previous message in Thread: Katie Haritos-Shea: "Re: WCAG 2.1 - 1.3.5 - How to capture a violation?"
- View all messages in this Thread
John Foliot < <EMAIL REMOVED> > wrote:
>> These statements pretty much sum up my disappointment in all of this.
>> WCAG would now demand 100% non-ambiguous perfection for machines in
>> situations where the field purpose is already fully understood by and
>> accessible to end users.
>
> I'm sorry Jared, I fundamentally reject that assertion. You and I both know
> that for many users that is simply not the case - that no web page on the
> internet today is "fully" understood and accessible to all end users.
OK, my use of "fully" was overstating, but now you're just distorting
what I've written. What I'm saying (and you fail to acknowledge) is
that in cases where the software (form filler, icon generator,
translator, personalizationer, or whatever) treats a label of "Last
name" and autocomplete="family-name" EXACTLY the same, then there's no
ADDITIONAL benefit to end users if the required autocomplete attribute
is present. But, as you've repeatedly emphasized, this SC isn't about
end users anyway, so I understand why you dismiss this idea.
> As I've previously noted, many of the use-cases that informed this SC were
> based upon researched conducted and documented by the COGA Task Force.
John, you know that we've conducted a fair amount of research and
testing with users with cognitive and learning disabilities and have
written and published at length on the topic. Our article is the top
Google result for "cognitive disabilities". I don't appreciate your
repeated condescending suggestions that I'm ignorant of this audience
or their needs.
> The heuristics you are relying on to support that statement cannot
> be performed "programmatically", because the 'common' (Western/English-centric) text-string used
> for the heuristics is not
> present on this Icelandic-language page
Sure, though it's a rather obscure example. Because current programs
don't support the Icelandic labels, then autocomplete would certainly
be necessary here. But what of the millions of forms where the
text-string heuristics are already performed "programmatically" - and
no less "programmatically" than @autocomplete?
Additionally, there's little keeping user agents from
"programmatically" supporting new text-strings in any language. You
could contribute the Icelandic label texts from that web page to
LastPass (as one example) right now in a matter of minutes -
https://lastpass.com/trans.php?isocode=is-is&product=chrome&poname=chrome.
Once included, then these fields (and any others on the web with these
labels) would be treated no differently than if @autocomplete were
added to them.
> And how is that "accessibility supported" requirement achieved? By restricting
> the list of token values to a fixed list, so that the machines can do the
> look-up.
Which of the following do you think would be more likely and would
result in more far-reaching accessibility - that we get a handful of
popular browsers and software programs to properly parse additional
common label texts to accurately determine input purpose, or that we
get millions of web authors to add additional, new attributes to the
majority of forms on the web?
Of course the best of both worlds for users with cognitive and
learning disabilities having a more accessible form experience would
be for better label parsing in their software AND for authors to add
@autocomplete when it will improve accessibility for these users.
But you've made it abundantly clear that this success criterion isn't
intended to improve form accessibility for users with disabilities at
all, but "is completely about machine understanding". I'll reluctantly
accept this as the W3C's intent, as short-sighted as I believe it to
be, and will try to help authors understand that autocomplete is
currently required for conformance and to minimize legal risk, even in
cases where it doesn't make any difference for end user accessibility.
But more so, I'll continue to help authors understand the needs of
users with disabilities so they can focus their efforts on things that
actually make a difference.
Jared
- Next message: glen walker: "Re: When "Alt" is not the semantically-correct representation of an image"
- Previous message: Birkir R. Gunnarsson: "Re: When "Alt" is not the semantically-correct representation of an image"
- Next message in Thread: John Foliot: "Re: WCAG 2.1 - 1.3.5 - How to capture a violation?"
- Previous message in Thread: Katie Haritos-Shea: "Re: WCAG 2.1 - 1.3.5 - How to capture a violation?"
- View all messages in this Thread