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

John Foliot 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 _*
Thats a lot of forms.
> (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>...
So whats I'm hearing (and I parsed your feedback below thanks) is a yes.
[...]
>
> 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.
I'm thinking of low capacity devs, or public sector bodies with limited 
a11y experience etc. They're not going to care about particular 
taxonomies they just want to know 'how do I pass'.

For most forms capturing 'user data' will this be a case of mapping the 
relevant form inputs defined here to the inputs in the form. Correct? [1]

I need to recommend a coping strategy for government. I don't think, for 
auditing purposes we can say the answer is actually nuanced here. It 
either is or it isn't conformant to WCAG and from my reading, a form 
that collects user data, without an autocomplete - and relevant 
appropriate tokens is a fail.

Thanks

Josh

[1] 
https://www.w3.org/TR/html52/sec-forms.html#autofilling-form-controls-the-autocomplete-attribute 


> 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)
> _
> HTH
>
> JF_
>
> On Fri, Jan 18, 2019 at 5:22 AM Joshue O Connor - InterAccess 
> <josh@interaccess.ie <mailto: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 <http://deque.com/>
>


-- 
Joshue O Connor
Director | InterAccess.ie

Received on Monday, 21 January 2019 09:12:30 UTC