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

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