RE: SC 1.3.4 - Understanding doc update

I think we should examine the security arguments around autocomplete to see if they really are problematic for the SC. I’m not convinced that WCAG requiring it makes the situation any worse but it could promote sites to collect more information especially in optional fields than the user might not typically offer up data for.

1.     Autocomplete exists and can be used maliciously today – WCAG saying it must be used on input has no real impact in my opinion on the mis use of it.  By us requiring it doesn’t somehow promote sites to use it in appropriately.

2.    By require using of auto complete we are promoting sites to collect more information about the user than most sites might otherwise.  Yes, sites could collect it already through fields either optional, visible, required, or hidden.

3.    Due to security people will recommend not using it and that would put this SC contrary to that..  I see this as a user agent issue.  User agents can fix the issue and users can choose to turn it off altogether.  User agents should help protect the information that they enter by not entering information automatically or warning the user when content was entered in input fields.

4.    I agree that the goal of personalization would not have these potential issues and that auto filling content is separate from personalization but that autocomplete attribute values can be used to help with a small percent of personalization related issues.


From: Katie Haritos-Shea []
Sent: Wednesday, February 28, 2018 12:57 PM
To: Alastair Campbell
Cc: Andrew Kirkpatrick; W3c-Wai-Gl-Request@W3. Org;
Subject: Re: SC 1.3.4 - Understanding doc update


As I said before, you did a great job starting of this new Understanding content. As I wasn't sure we were going to go this route, I didn't suggest anything - but I'll take a look again. But it does seem that there is this security risk with autocomplete that may have us rethinking this SC again.....

* katie *

Katie Haritos-Shea
Principal ICT Accessibility Architect

WCAG/Section 508/ADA/AODA/QA/FinServ/FinTech/Privacy, IAAP CPACC+WAS = CPWA<>

Cell: 703-371-5545<tel:703-371-5545> |<> | Oakton, VA | LinkedIn Profile<>

People may forget exactly what it was that you said or did,
but people will never forget how you made them feel.......

Our scars remind us of where we have been........they do not have to dictate where we are going.

On Wed, Feb 28, 2018 at 12:47 PM, Alastair Campbell <<>> wrote:
AWK wrote:
The<> site shows one example of this, but doesn’t cover all HTML autocomplete attribute values though.

AC: I think it uses the coga or aui attribute though?  Not to be picky, but if the implementation sites we have use the autocomplete attribute, that won’t match the a11y-resources UA. It’s an easy(ish) change, but would need to be made soon, I assume?

AWK: I don’t agree on calling it “autocomplete” as that is tied to the attribute name for HTML and we hope to not only allow other attributes at some point in HTML but also other technologies.

AC: Fair enough, happy to change it.

AWK: I also am not thrilled with the idea of relegating this SC to “input assistance”, even though this is part of the benefit it isn’t everything, and it is paired with 1.3.5 which is not about input assistance at all.

AC: For the current SC, the input assistance is the primary thing, as it is the benefit we can show now.

Katie wrote:
But we could also just suggest they use Autocomplete for this purpose without an SC)

AC: Do you mean ‘they’, as-in: an education process for end-users to learn about autocomplete in the browser? That’s useful, but we would also need the sites to use it. If the authors don’t add the meta-data, the results are rather hit & miss. There still needs to be a requirement to use the attributes.

Katie: We will need to be explaining to people why we have this SC and who it is for.

Are there any additions you could suggest?



Received on Wednesday, 28 February 2018 18:14:59 UTC