W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > January to March 2019

Re: What is a failure of 1.3.5 Identify Input Purpose?

From: John Foliot <john.foliot@deque.com>
Date: Sat, 19 Jan 2019 12:32:41 -0600
Message-ID: <CAKdCpxxFNTHhacytHEtS+uFT=_MfJrp-F=xU4R0sMMX=_f-65Q@mail.gmail.com>
To: David MacDonald <david100@sympatico.ca>
Cc: Joshue O Connor - InterAccess <josh@interaccess.ie>, WCAG <w3c-wai-gl@w3.org>
David writes:

*But that is not WCAG, which requires that conforming techniques work with
the AT and the browsers which are depended upon for conformance.  *

Respectfully David, that is an extremely narrow definition of WCAG, and one
that (I think) flies in the face of logic. Which AT does Success Criterion
1.4.1 Use of Color depend on? SC 2.2.2 Pause, Stop, Hide? SC 3.2.1 On Focus?

I can find numerous examples of existing 2.0 AND 2.1 SC that do not depend
on Assistive Technology, and apply to more than just "browsers" (We have an
entire collection of Techniques for PDFs (that natively open in Acrobat
Reader, or in your browser *via an extension*); and WCAG - especially WCAG
2.1 - is being applied to "Native" Mobile Apps that may or may not require
a "browser"). The normative definition of Accessibility Supported is:

*Using a technology in a way that is accessibility supported means that it
works with assistive technologies (AT) and the accessibility features of
operating systems, browsers, and other user agents.*

...and...

*Note 2: Assistive technologies often communicate data and messages with
mainstream user agents by using and monitoring APIs.*

Additionally, I'll re-quote the statement you provided:

"... the Success Criteria require *that something be done in the Web
content* that would make it possible for assistive technologies to
successfully present the content's information to the user. "


NOT "...guarantee accommodation...", but rather, "...make it possible...".

Microdata <https://www.w3.org/TR/microdata/> (the example I provided) *IS*
a formally published W3C Recommendation, and it *DOES* have consuming
user-agents and the required API's.  From the Microdata Overview
<https://www.w3.org/TR/microdata/#overview>:

*For example, search engines can better identify page content using
schema.org <http://schema.org> annotations, and content management systems
can find and use information from documents, if it is marked up in a known
way. *


So, from a pure-play technical reading of the Recommendation, it *DOES*
meet all of the criteria, yet today it doesn't have a 'porting' mechanism
(perhaps a specialized CMS, or maybe a proxy web site interface that
ingests marked-up pages at one end, and outputs modified content at the
other) that actually aids end users (a point I also acknowledged). But
that's not because the technology eco-system is flawed, but rather not all
of the gaps have been filled.

Returning to my statement, I'd never "recommend" a page or other marked-up
content use this technique today (due to the lack of real support), but I'd
also come-up short in actually "failing" the page or content *IF* all of
the technical requirements are met, specifically: "The content is *implemented
*using technologies *with support for identifying the expected meaning* for
form input data. <https://www.w3.org/TR/WCAG21/#identify-input-purpose>"
Like it or not, Microdata, when implemented, *DOES* support the ability to
identify the expected meaning. Today, I will suggest, it's not just being
leveraged in a way that is consistently useful in our context of assisting
PwD, but I do not believe we could fail it (from a legal conformance
reporting perspective).

JF

On Sat, Jan 19, 2019 at 11:05 AM David MacDonald <david100@sympatico.ca>
wrote:

> > if an organization wanted to publicly publish the taxonomy in a more
> robust format (hello Schema.org), then there is no technical reason why
> using, say, Microdata to achieve the goal would not be conformant. It might
> not actually *DO* anything at this time (lack of tooling), but the fairly
> robust if 'wordy' Microdata syntax and mechanism would not be a fail - *IF
> it referenced a publicly published taxonomy library that matched the values
> in Section 7.*
>
> I would not pass something that is not accessibility supported.
> "... the Success Criteria require that something be done in the Web
> content that would make it possible for assistive technologies to
> successfully present the content's information to the user. "
>
> https://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-accessibility-support-head
>
> I understand in Silver there is a proposal to change this and to move to a
> more standards based approach where everybody builds to the standard and if
> the AT or Browsers don't do their part then it still passes. But that is
> not WCAG, which requires that conforming techniques work with the AT and
> the browsers which are depended upon for conformance. WCAG 2.0 requires
> real world current benefit to users rather than an aspirational hope that
> something will happen in the future with an SC. WCAG SCs for 2.0 were not
> created with the "build it and they will come" approach although this 2.1
> SC starts to hint in that direction.
>
> Cheers,
> David MacDonald
>
>
>
> *Can**Adapt* *Solutions Inc.*
>
> Tel:  613-806-9005
>
> LinkedIn
> <http://www.linkedin.com/in/davidmacdonald100>
>
> twitter.com/davidmacd
>
> GitHub <https://github.com/DavidMacDonald>
>
> www.Can-Adapt.com <http://www.can-adapt.com/>
>
>
>
> *  Adapting the web to all users*
> *            Including those with disabilities*
>
> If you are not the intended recipient, please review our privacy policy
> <http://www.davidmacd.com/disclaimer.html>
>
>
> On Fri, Jan 18, 2019 at 1:38 PM John Foliot <john.foliot@deque.com> wrote:
>
>> Ha, Part 2...
>>
>> I think Josh the answer is far more nuanced than that.
>>
>> A "Failure" would be a form - scoped to the *user *(and not, say to the
>> user's family[1], or work colleagues[2]) - that had inputs that correspond
>> to the values identified in the chart found in Section 7 of the WCAG 2.1
>> Recommendation <https://www.w3.org/TR/WCAG21/#input-purposes>.
>>
>> The failure is when any of the corresponding 'required' inputs do not
>> contain a *metadata taxonomy term *attached to the <input>... however
>> the *mechanism* by which that is accomplished cannot be specified in the
>> Recommendation (as you likely know), because 'techniques' are
>> non-normative, and WCAG leaves open the possibility of more than one
>> potential solution/technique.
>>
>> The testing technique then is dependent (today) on manual code
>> inspection, where you must examine each <input> (again, scoped exclusively
>> to the actual user, and on the list of required inputs found in Section 7)
>> to see if the taxonomy concept/term has been *programmatically attached.*
>> As I noted in my previous response, today the only fully 'robust' technique
>> would be to use @autocomplete, but if an organization wanted to publicly
>> publish the taxonomy in a more robust format (hello Schema.org), then there
>> is no technical reason why using, say, Microdata to achieve the goal would
>> not be conformant. It might not actually *DO* anything at this time (lack
>> of tooling), but the fairly robust if 'wordy' Microdata syntax and
>> mechanism would not be a fail - *IF it referenced a publicly published
>> taxonomy library that matched the values in Section 7.* (Part of being
>> machine-readable is that the machines might need to actually look up what
>> it is they are reading...)
>>
>> [1] A question was posed about *booking airline tickets for you and your
>> family*. In that instance, the only inputs that would require
>> the @autocomplete values (or other technique) would be those values
>> associated to *YOU* - and not to the other members of your family, for
>> while they may share many of the same 'responses' (i.e. family-name...
>> maybe, maybe-not: today's nuclear family taking so many different forms),
>> however those inputs are scoped to other members of the family, AND NOT THE
>> USER, so there is no need to tag those additional inputs.
>>
>>
>> [2] A similar scenario was queried, where *a "HR" form was collecting
>> multiple names and address* (i.e. there may be a total of 20 on-screen
>> inputs labeled "Name"), but again, because this SC is scoped to the *USER*,
>> then potentially only the input directly related to the user
>> (owner/completer of the form) would require the metadata, as all of the
>> other date inputs are scoped to "others".
>>
>>
>> And when you think about it from the "functionality of the @autocomplete
>> attribute", it's fairly safe to assume that most (not all) browser
>> configurations, *if the user has opted to store any personal data for
>> speedier form completion on their local user-agent in the first place*,
>> would liekly only store data relate to them, and not to their family
>> members, neighbors or work colleagues. (Currently neither Edge nor Internet
>> Explorer support the @autocomplete 'functionality' in any fashion, and in
>> fact the most robust tool supporting the @autocomplete tokens was the Last
>> Pass password management tool.)
>>
>> Additionally, I think it's fairly safe to presume that public terminals
>> WOULD NOT have this kind of personally identifying data stored locally on
>> those machines, so in that scenario, the "auto-filling" function would be
>> disabled (or at least, unable to deliver on the functionality, due to the
>> lack of stored local data). None-the-less, *OUR* *accessibility value*
>> is primarily that those form inputs are now tagged with extra metadata that
>> is machine-readable, and what and how we use that additional information is
>> now open to tooling (etc.)
>>
>> To be clear, while using the @autocomplete attribute solution extends
>> some real benefit for all users (including the target audience that
>> inspired this SC - COGA), the 'auto-filling' of those inputs is but one
>> function *facilitated by adding specific metadata terms to inputs*. And
>> while SC 1.3.5 is currently only for inputs, that isn't the end of the
>> story, it's but Chapter 1, and hopefully we'll get more and better tools
>> and methods to meet the much larger goal of allowing users to customize
>> their UI (How? when we know the purpose and intent of all of the visual
>> controls on the page, we can then "output them indifferent modalities" to
>> meet the needs of the end user - i.e. Personalization)
>>
>>
>>
>> *HTHJF*
>>
>> On Fri, Jan 18, 2019 at 5:22 AM Joshue O Connor - InterAccess <
>> josh@interaccess.ie> wrote:
>>
>>> Hi all,
>>>
>>> Are we saying that a well marked up form that does not have a HTML 5.2
>>> autocomplete attribute (or similar) is basically a fail of this SC? [1]
>>>
>>> Thanks
>>>
>>> [1]
>>> https://www.w3.org/WAI/WCAG21/Understanding/identify-input-purpose.html
>>> --
>>> Joshue O Connor
>>> Director | InterAccess.ie
>>>
>>
>>
>> --
>> *​John Foliot* | Principal Accessibility Strategist | W3C AC
>> Representative
>> Deque Systems - Accessibility for Good
>> deque.com
>>
>>

-- 
*​John Foliot* | Principal Accessibility Strategist | W3C AC Representative
Deque Systems - Accessibility for Good
deque.com
Received on Saturday, 19 January 2019 18:33:39 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 21:08:29 UTC