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 7:25PM

Jared,

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.
Virtually all of the new SC that emerged in 2.1 came from addressing known
gaps in 2.0 in the areas of Cognitive disabilities, Low Vision users (see
1.4.10 Reflow), and "Mobile" (which got abstracted for the most part to
touch interfaces - see 2.5.5 Target Size)

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. That
user group is currently significantly under-served by WCAG, in part due to
the complexity of finding a scalable way of addressing the myriad needs of
that community. This is a "foot in the door" start, with a goal of
addressing partial needs for some COGA users: users with Dyslexia and users
with
Aphasia.

*Users with Dyslexia* (https://www.w3.org/TR/coga-user-research/#dyslexia)
often still struggle with forms. Specific to form inputs, issues include:
Memory

- Mistakes with routine information, e.g., providing age, phone number,
or ages of children.
- Inability to hold on to information without referring to notes.

Automatizing Skills


- People with dyslexia do not tend to automatize skills very well. A
high degree of mental effort is required in carrying out tasks that typical
individuals generally do not feel requires effort. This is particularly
true when the skill is composed of several sub-skills (e.g., reading,
writing, driving).

Information Processing.

- Difficulties with taking in information efficiently (could be written
or auditory).
- Slow speed of information processing, such as a 'penny dropping' delay
between hearing or reading something and understanding and responding to it.

Literacy

- If people are undiagnosed or diagnosed late, they may be illiterate or
barely literate.
- Where literacy has been mastered, problems continue, such as poor
spelling; difficulty extracting meaning from written material; difficulty
with unfamiliar words; and difficulty with scanning or skimming text
.

Organization, Sequencing

- Incorrect sequencing of strings of numbers and letters (passwords,
phone numbers)

*User Story:*

*Harry is a high school student with dyslexia. Although he can read, his
level is slow and he finds it difficult. Harry does not use a screen reader
because he is afraid it will stop him from reading and improving his
skills. Harry wishes that forms could *
*be personalized to **display icons instead of text, as he finds those
easier to recognize and understand*
*.*



Then there are
*users with Aphasia* (https://www.w3.org/TR/coga-user-research/#aphasia).
"
Communication difficulties may arise as the result of what is commonly
known as a stroke. The type of impairment that results is known as Aphasia
due to brain damage, which may cause receptive (comprehension) and
expressive (speech and language) difficulties, or dysarthria and dyspraxia
where words can become unintelligible, amongst other difficulties.
"
Again, specific to forms, issues might include:

*Memory*

- Receptive and Expressive Aphasia may result in impaired short term
memory which can impact on re-learning language as can the impairment of
auditory memory for relearning correct articulation *and visual memory
that affects reading and writing*.

*Reasoning*

- Where intellectual capacity is affected there may be issues with
reasoning, learning and thus remembering plus abstraction.

*Language*


- Aphasia can cause difficulties with word finding, the meanings of
words and sentences, grammar and comprehension affecting the ability to
communicate.

*Visual Perception*


- Not recognising letters and words impact on reading and even object
recognition can be affected.

*Knowledge*


- Aphasia does not necessarily impact on intelligence but knowledge will
be trapped within the brain if the individual cannot express their thoughts.


I'll stop here (there's plenty more research at the referenced W3C URL),
but suffice to say, based upon the above research, I will respectfully
suggest
Jared
perhaps typed that comment without fully thinking through what
he was
saying.


It favors the machine over the human, and does so by burdening human
authors.


While I respect that as a concern, how many times do we also here similar
arguments when it comes to adding aria attributes, or even (
in the past
) alt text? As previously noted, we're aware of this issue, which is why
we're also continuing to research alternative ways of applying or attaching
meta-data like this to, not only form inputs, but other critical page
controls. I previously referred you to this research (*Comparison of ways
to use vocabulary in content* -
https://github.com/w3c/personalization-semantics/wiki/Comparison-of-ways-to-use-vocabulary-in-content),

which includes
exploring ways of addressing this need
, including different methods of applying element level metadata, and
looking at mechanisms that work with
lower-level APIs. But yes, today, there is an authoring burden (although,
because the requirement is to attach one of a fixed number of token values,
this could be reasonably addressed in WYSIWYG editors via a drop-down or
similar feature).


But the same software that parses autocomplete="family-name" already
knows that <label>Last Name: <input type="text"></label> is the same
thing, and thus provides identical functionality when you request help
in completing this field?


Sorry once again my friend, I reject that as a far too Western-centric
comment. As an example of why I reject your claim, I encourage you to wheel
on over to here: http://www.sunnlenska.is/frettir/6025.html
(and yes, there are other accessibility concerns with that page, but for
the purpose of this discussion, let's just focus on the form)


Question, is your "form-filler" able to autocomplete the Form "Senda
frétt"? (right hand side - there is an icon of an envelope)

In my version of Firefox, despite the fact that the I've added the
appropriate text strings to support automatically filling in forms (i.e.,
my email address is remembered, as one example), that form will not be auto
-
completed - including the third field which *is* seeking your email address
(translated here:
https://translate.google.com/translate?hl=en&sl=is&tl=en&u=http%3A%2F%2Fwww.sunnlenska.is%2Ffrettir%2F6025.html
)

Why?
B
ecause nowhere in the source code related to that input is the string
"email". The heuristics you are relying on to support that statement cannot
be performed "programmat
i
cally", because the 'common' (Western/English-centric) text-string used
for the heuristics
is not
present on this Icelandic-language page
.


...though recognize that this would rely on authors
to
provide an equivalent label text that is "accessibility supported"
by form fillers (something much more difficult to define than the
blanket "autocomplete is required").

Let me re-state that slightly differently: "...provide an equivalent TOKEN
that is "accessibility supported"..."
, which is effectively what using the @autocomplete attribute delivers. 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.

Remember again that WCAG seeks to avoid being overly prescriptive, which is
why nowhere in the SC does it state "autocomplete is required" - which is
what some folks are interpreting this SC to mean, but that's a false
reading of the requirement (which I've previously tried to untangle in this
thread). The issue is that today, the only "accessibility supported"
technique available is to use @autocomplete.


I have considered the scenario where the input is for entering someone
else's last name. In this case, autocomplete would not be used, yet
the form filler would, if activated erroneously, fill it with the
user's last name.


Maybe, maybe not: it all depends on what token string is associated to the
label in the code. Besides, this SC is scoped to data related to the
individual user, and not to other potential names.

The form
fillers already use form labels in their heuristics if autocomplete
isn't present (and perhaps even if it is). The only way to avoid this
potential issue is for form fillers to ONLY respect @autocomplete...


Jared!!! This SC is NOT (I repeat, *NOT*) about the actual function of *filling
in the fields* (which would have made it an "Operable" SC - aka a 2.x.x
SC), or even that the Purpose is clear to the end user via on-screen or
audio labelling (an Understanding SC - aka 3.x.x) - it's about being able
to "Perceive" what the form input is for - its *Purpose - *and that the
purpose can be* programmatically determined*. That's it, nothing more than
that.

It's about facilitating Personalization, an entry-level SC that is leading
towards a far greater desire for page customizations or Personalizations.
It is completely about machine understanding - "Programmatic Determination"
- so that machines can do something with the authored content. Currently,
one such "doing something" (not necessarily a "purpose" outcome) is the
auto-completion of those forms (**if** you've stored the correct values,
*your* name, *your* email, etc. in the local user-agent).

Focusing on that function however completely misses the point of the SC,
which we should all remember is entitled "*Identify Input Purpose*" and not
"Facilitate Form Completion". I personally believe the root of confusion in
this thread is failing to read the title and requirement of the actual SC,
as too many authors are focusing on a (the?) technique instead.


Meanwhile, Jeremy wrote:

With a clearly defined taxonomy, you don't have to build any kind of AI to
guess at fields, so the programmatic use of these fields is open to a much
wider audience, which can be useful.

Exactly. One additional constraint we had to deal with was the fact that
our W3C charter did not permit us to create a new taxonomy, so we had to
find one that served the purpose. That taxonomy, the "look up table" that
is the list of tokens and definitions previously defined in HTML5 (as part
of *that* Working Group's output) met the basic need. It is not an accident
however that the list is re-published in WCAG, not as "autocomplete values"
but rather as *Section 7. Input Purposes for User Interface Components* (
https://www.w3.org/TR/WCAG21/#input-purposes
) - also part of the normative spec.

That section further states:

"

*This section contains a listing of common user interface component
<https://www.w3.org/TR/WCAG21/#dfn-user-interface-components> 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. This provides the potential for
user agents and assistive technologies to apply personalized presentations
that can enable more people to understand and use the content."(* although
that is not forbidden either - JF)*

However, today, the only "accessibility supported" means of attaching those
purposes is to use the keywords (tokens) and the @autocomplete attribute.
I've previously linked the ongoing work to find other attributes or
alternative mechanisms that could also meet this requirement (including
perhaps minting a new aria-purpose attribute, or by using Microdata, or
JSON LD, or RDFa, or...). The current problem however is even if we minted
a new aria-attribute tomorrow (which won't happen, it takes at least 2
years for things like that to happen at the W3C), we ALSO need to satisfy
the "accessibility supported" requirement that is also part of WCAG 2.0 and
2.1. Because @autocomplete is a valid attribute that shares the same
taxonomy terms and is accessibility supported today, we were able to
re-purpose the attribute to attach the metadata, and by using a normative
attribute that is already being used in the wild today.

That said, "autocomplete" feels very wrong for this purpose.


Well, I'd argue not "VERY" wrong, but it is doing some re-purposing that
may not be 100% clear (as witnessed by this thread). It is (and was) a
tricky needle to thread, but it meets the need.

I feel like this should be a new attribute, like aria-purpose or something.


Like I said, we're working on it
<https://github.com/w3c/personalization-semantics/wiki/Comparison-of-ways-to-use-vocabulary-in-content>
...

JF



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

> Jeremy -
>
> I absolutely agree. In cases where the purpose of the field is
> ambiguous, using autocomplete is incredibly helpful and should be
> required.
>
> But the same software that parses autocomplete="family-name" already
> knows that <label>Last Name: <input type="text"></label> is the same
> thing, and thus provides identical functionality when you request help
> in completing this field? Does it then make sense to require authors
> to add the autocomplete attribute if it provides no better
> accessibility?
>
> I'd think it worthwhile to examine this further as a possible
> sufficient technique, though recognize that this would rely on authors
> to provide an equivalent label text that is "accessibility supported"
> by form fillers (something much more difficult to define than the
> blanket "autocomplete is required").
>
> I have considered the scenario where the input is for entering someone
> else's last name. In this case, autocomplete would not be used, yet
> the form filler would, if activated erroneously, fill it with the
> user's last name. But this is the current reality anyway. The form
> fillers already use form labels in their heuristics if autocomplete
> isn't present (and perhaps even if it is). The only way to avoid this
> potential issue is for form fillers to ONLY respect @autocomplete, and
> that certainly is not going to happen - they'd stop working on nearly
> all web forms (including the ones that passed 2.0, but now fail 2.1
> without having changed).
>
> Thanks,
>
> Jared
> > > > >



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

Advancing the mission of digital accessibility and inclusion