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 28, 2018 2:15AM

Hi Jared,

First, if my tone in my last posting digressed to being offensive, I
apologize to you directly. This discussion has spanned 3 evenings, and it
has been my desire to explain this SC, and to answer clarifying questions
you have posed in a factual, evidence-based discussion. While it is no
excuse, I do apologize if my frustration in still not "getting there"
resulted in my recent snark towards you or your knowledge. You and I have
had a long, collegial, and personal relationship that goes back a long way,
and I do respect and acknowledge the work that you and WebAIM have
contributed to the cause of Web Accessibility over the many years we've
known each other. Sorry man.

***************

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.

To be clear, I am not dismissing the direct benefit that auto-completed
form inputs provides to end-users.

My concern is that you are not acknowledging that across the myriad of
users-agents and internationalization issues, to meet the *programmatically
determinable* purpose of an input consistently requires a formally
published taxonomy to become a standardized way of delivering this benefit,
as opposed to the current ad-hoc heuristic approach that some tools are
taking. I provided an admittedly arcane example of how the heuristic
approach could fail when the lack of an English token identifier resulted
in the email field on that form for not being auto-filled. This SC seeks to
mitigate that failure risk by mandating a fixed value, derived from a
published taxonomy.

Additionally and importantly, this SC also seeks to re-purpose the taxonomy
originally defined as part of the @autocomplete spec in HTML 5 to do more,
such as page personalization by using those same declared definitions, so
this is about auto-filling AND MORE, which we will be able to do when we
can be assured of that fixed taxonomy is being used.

I've not heard you recognize that this SC will open up those other benefits
(specifically personalization) that the stricter mandate of a fixed
taxonomy will deliver, which was the over-arching goal of this SC in the
first place.


But, as you've repeatedly emphasized, this SC isn't about
end users anyway, so I understand why you dismiss this idea.

If I may, I'll split that. It's not an either / or proposition, but rather
that by standardizing the concepts as token values improves the
effectiveness to deliver on user-benefits (in your example, not hoping that
"*Credit Card*" will suffice, but rather *knowing* that *cc-number* will
ALWAYS work by standards-consuming tools). This SC hardens the requirement
for the fixed taxonomy, so that other tools can deliver the benefits (form
completion and more) consistently.


But what of the millions of forms where the
text-string heuristics are already performed "programmatically" - and
no less "programmatically" than @autocomplete?

OK, I'm hearing that.

This is what WCAG 2.1 normative text says to that concept:


*This section contains a listing of common user interface component input
purposes. The terms below are not keywords that must be used, but instead
represent purposes that must be captured in the taxonomy adopted by a
webpage. Where applicable, authors mark up controls with the chosen
taxonomy to indicate the semantic purpose.*

(source:
https://www.w3.org/TR/WCAG21/#input-purposes
)


One key requirement here is "the taxonomy" that captures the purpose.

If I am to hear your argument, common terms such as Name and Address have
an implied (community) 'taxonomy', at least in English
, and that currently that support for auto-filling the form fields (at
least for English content) is pretty good
. But

I believe
we both agree
this
breaks down when internationalization issues occur.

One reason why the Working Group did not advance this SC with the larger
list of common buttons and controls
<https://docs.google.com/spreadsheets/d/1N63TKXrUXSmF1OeZAgpy8iTnDyQ1nzVbrevq2lBDvos/edit?usp=sharing>
originally proposed was that we lacked a "formal taxonomy" for many of
those common button and control types, even if they too had a "commonly"
understood (community) taxonomic
understanding, for example buttons for "Sign In" and "Sign Out".
We likely all understand those concepts 'heuristically', but they have not
been formally defined in a taxonomy as yet, so we couldn't include them in
this SC.


As such, while I do understand your reasoning, I
believe
the WG has
previously
signaled that a common or community taxonomic understanding did not suffice
for the purposes of this SC
;
that a formal taxonomy was expected
. The attendant
Note
also states:



*The list of input type purposes is based on the control purposes defined
in the HTML 5.2 Autofill field section (*), but it is important to
understand that a different technology may have some or all of the same
concepts defined in its specification and only the concepts that are mapped
to the meanings below are required.*

*(* and not the values in the HTML5 autocomplete specification, even though
today those values are identical - JF)*


N
oting
here
that the concepts are required in a *defined specification*
I believe
further underscores the
mandate
for a formal taxonomy.


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?

As far as goals are concerned, we are on the same page: we want machines (a
handful of popular browsers and software programs) to do the heavy lifting.

I think we're diverging on means and methods (as well as derived outcomes):
you are indicating to me that you believe heuristics will get us there, I
am arguing that a fixed formal taxonomy has a better chance of ensuring we
get there, which was the intention of this SC. (I'll also note that this is
in alignment with the current thinking and work coming from the
Personalization TF, a COGA activity at the W3C:
https://www.w3.org/TR/personalization-semantics-1.0/).


In many ways, the autocomplete attribute emerged at HTML5 for very similar
reasons - the browser vendors at the W3C wanted a standardized means of
delivering on the auto-filling function
,
without having to apply heavy heuristics to account for not only minor
variants in English labeling (your "Credit Card" example) and
also avoiding
essentially the same Internationalization issues that I demonstrated in
that Icelandic page. Sure, heuristics are working relatively well
most of the time
with English content today, but the most efficient means of ensuring this is
will work across the board is
to have a standardized taxonomy
"programmatically determinable"
.

As I see it, those browsers have 2 choices:

-
*to properly parse additional common label texts*

in all it's variants and language permutations
,
browsers and other tools need to either compile a really big list of all
those variants (individually or a shared compiling exercise), or hope for
AI to parse all those variations accurately;

- or publish a list of fixed terms that they will then "promise" to
support.

Computationally, the second choice is far simpler
and faster
for the browsers to do
(and which they did for the @autocomplete attribute - so if current
implementation support from the browsers is any indication, they seem to
prefer fixed lists)
.

So to meet your
and my stated
goal
consistently
, we
would
need to collect all those variants and define them
in a formal taxonomy
, or accept
that
the fixed list that the browsers are already doing something with, which
conceptually align with other goals we seek to achieve
, meets that need
.



...
or that we

get millions of web authors to add additional, new attributes to the

majority of forms on the web?


I am extremely mindful of "attribute creep" in HTML5, and share similar
concerns. I'll note however that the WCAG WG has not defined any attribute
here or elsewhere that I am aware of. That generally happens in other
technical Working Groups within the W3C.

Additionally, at the risk of being pedantic, the preferred technique today
consists of using 1 new (actually "existing" HTML5) attribute coupled with
one of its fixed list of values to a limited set of text inputs. While it
does increase the author lift, I will suggest that the lift is relatively
light overall. As I noted earlier, getting support for this in WYSIWYG
editors (if not already added to some, because it is a HTML5 attribute)
should be fairly easy.


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".

Well, that's kind of extreme
. As I previously stated, it's not an either / or outcome, but rather by
facilitating the need for the machines to act on the Purpose of the input
in a easy-to-parse way, we can also meet other goals and needs more closely
or directly associated to the actual user, without depending on heuristics
and the risks associated with that.


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.

Yup, and this SC increases the likelihood that that we can achieve that
second part: that going forward, authors will explicitly tag their inputs
in such a way that the browsers can get better at parsing consistently.

Since this SC does not (CAN not) mandate "use autocomplete", but rather
"ensure the fixed concepts, formally defined in WCAG 2.1 (Section 7) be
"programmatically determinable" [sic]", the SC leaves the actual method to
the author. Today we have but one 'accessibility supported' method, but the
SC does allow for other mechanisms to co-exist with the @autocomplete
attribute technique (because SC do not mandate techniques). The SC is also
clear that you do not have to use the specific tokens as published in the
WCAG spec but rather that the concepts (defined in the WCAG 2.1 spec), if
mapped to another taxonomy schema, retains the same semantic.


But you've made it abundantly clear that this success criterion isn't
intended to improve form accessibility for users with disabilities at
all,


Jared, that's not fair. The primary intent (but not the sole intent) is for
supporting machines, machines which in turn will be able to support and
improve the accessibility of the end user. The improvement being sought is
greater than just filling out the form; its that we can
also provide "customization" (or
output in
different modalities) to benefit users in other ways - the Personalization
goal - without expecting a heuristic solution to address those other needs.


...and will try to help authors understand that autocomplete is currently
required for conformance and to minimize legal risk...

While in practice today that is the sole technique we can use, it is and
remains factually incorrect to state that adding @autocomplete is required
- it's not.

In plain English
:
the requirement
of this SC
is to tag specific inputs, those inputs that align to the any of the
purposes listed and defined in WCAG 2.1 Section 7, with a programmatically
determinable way of determining the purpose of the input
. Using the @autocomplete technique does just that, with the added benefit
of facilitating the filling of form inputs.

As such, I too will recommend using the @autocomplete Technique, but for
different reasons: attaching a predictable token to the input allows for
user-customization, AND ensures that automated form-filling will work more
robustly and accurately because the value is explicitly declared, versus
deduced via heuristics.

JF

On Fri, Jul 27, 2018 at 11:32 PM, Jared Smith < <EMAIL REMOVED> > wrote:

> 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
> > > > >



--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
<EMAIL REMOVED>

Advancing the mission of digital accessibility and inclusion