RE: Draft technique for input purposes

I agree with John that this technique goes against the grain of the purpose for the SC, which is to make input purpose programmatically determinable without the need for users to rely upon perceiving or properly interpreting the meaning of heading text or other contextual cues that aren’t programmatically determinable.

Brooks

From: John Foliot [mailto:john.foliot@deque.com]
Sent: Monday, November 12, 2018 2:59 PM
To: Alastair Campbell <acampbell@nomensa.com>
Cc: Detlev Fischer <detlev.fischer@testkreis.de>; w3c-wai-gl@w3.org
Subject: Re: Draft technique for input purposes

Hi All,

I am quite concerned that this Technique does not meet the explicit scoping requirements of SC 1.3.5, which is to scope the inputs *to the user*. From the Understanding Document:
For some input fields, the type attribute already offers a way to specify the purpose, for example, input type="tel", input type="email", or input type="password". However, these are only very broad categories, describing the type of input, but not necessarily its purpose, especially as it relates to user-specific input fields. As an example, type="email" indicates that the field is for an e-mail address but does not clarify if the purpose is for entering the user's e-mail address or some other person's e-mail.


To now come forward with a Technique that directly contradicts this Understanding is, to my mind, both confusing and counter-productive. (Additionally, claiming that "...Also, browser autocomplete features recognise type="password"..." misses the point of this SC, which is: "The purpose of each input field collecting information about the user can be programmatically determined." and NOT that form inputs are auto-completed (which is a tangible benefit of the programmatically determinable requirement scoped to the user, but not the primary reason for this SC).

As a reminder, not all browsers autocomplete form inputs *ever* (Internet Explorer, Edge), and for browsers in public locations (library, cafe, other public terminals) forms will not "autocomplete" in those instances either - yet the programmatically determinable aspect of using @autocomplete ensures that the SC has still been met.

My specific concern with this Techniques is as follows: Step 1 states:

"Step 1: Examine the page title and heading to confirm it is about the user"

...which kind of ignores the whole "programmatically determinable" requirement (if we need to manually examine the page), and so I personally reject this as a Technique for success - it's missing the key requirement of programmatically scoping the inputs to the end user.

JF


On Mon, Nov 12, 2018 at 9:47 AM, Alastair Campbell <acampbell@nomensa.com<mailto:acampbell@nomensa.com>> wrote:
Sure, added here:
https://github.com/w3c/wcag/pull/532<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_w3c_wcag_pull_532&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=W3VUihr49D2x8upR4FtjMIsy0FSGEnqb4ghTiQJMtRw&m=Vphxq5OoecK-2p4ElCuIxYjFoT0V1MnXNpw-NbZAhCs&s=mNgwjmoDCMaN5lsHl_awZraEaHoRl00VS8ZStsmOKQo&e=>

From: Detlev Fischer


Can we turn this into a pull request or create an issue for it to have one place for comments?



--
​John Foliot | Principal Accessibility Strategist | W3C AC Representative
Deque Systems - Accessibility for Good
deque.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__deque.com_&d=DwMFaQ&c=4ZIZThykDLcoWk-GVjSLmy8-1Cr1I4FWIvbLFebwKgY&r=W3VUihr49D2x8upR4FtjMIsy0FSGEnqb4ghTiQJMtRw&m=Vphxq5OoecK-2p4ElCuIxYjFoT0V1MnXNpw-NbZAhCs&s=qcsVAXOT23gviOM-6XmoglF_x2EJBxTDtMNaUWH-Fdo&e=>