RE: Proposing a Technique for 1.3.5 Identify Input Purpose

Hi David,

Thanks for adding that, but I thought this method had been dropped (as a proposal) a while back?

The primary reason was that it doesn’t provide what the SC is asking for – a clear mapping to a known purpose.

The tokens include hyphens, which I assume you are transposing to spaces. But in that case, the user-agent would need some rules in order to differentiate the 11 different items with ‘name’ in them.

Also, it would be pushing people to use less than ideal terms, such as bday, CC name, CC exp etc. To go down that route, I think you would need to add a complete token-to-english mapping, which feels like a normative addition.

Also, if you assumed that this worked from a user-agent point of view, then it makes no difference from the security point of view. If it were a clear enough mapping, any security concern would be the same because it is the act of auto-filling inputs that was the concern. (I don’t think those concerns are well founded, but if they were then the improvement didn’t make sense to me!)



From: David MacDonald <>
Sent: 24 June 2018 21:50
To: WCAG <>
Subject: Proposing a Technique for 1.3.5 Identify Input Purpose

I've created a proposed technique for 1.3.5 which would allow the ACCNAME to contain a (case insensitive) string identical to the HTML 5.2 corresponding autocomplete token (or a string which contains the entire token within its string).

I took the idea from our new SC Label in Name (2.5.3), where the ACCNAME contains the string of the label.

This will provide some flexibility for authors who are creating simple contact forms in English, without compromising programmatic determination for assistive technologies, it provides another means to meet the SC,  for those with security concerns associated with autocomplete.

David MacDonald

CanAdapt Solutions Inc.
Mobile:  613.806.9005



  Adapting the web to all users
            Including those with disabilities

If you are not the intended recipient, please review our privacy policy<>

Received on Sunday, 24 June 2018 23:19:23 UTC