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

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