WebAIM - Web Accessibility In Mind

E-mail List Archives

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

for

From: Katie Haritos-Shea
Date: Jul 27, 2018 8:54PM

As someone who blatantly ridiculed the COGA people, task force and work, I
find this defense of an unbaked SC trying to make others seem 'uninformed'
and 'insensitive'' to COGA needs, nauseating.

On Fri, Jul 27, 2018, 9:25 PM John Foliot < <EMAIL REMOVED> > wrote:

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