Re: SC 1.3.4 - Understanding doc update

> this SC is no longer about Purpose of Controls, but about helping users 
with memory or cognitive issues input repetitive content into form fields 

I believe this is underselling the ability to programmatically indicate 
the purpose of the inputs, which is what the value of the autofill 
attribute can be leveraged to achieve.
The SC in its current form produces two requirements consistent with the 
tactic being pursued by personalization implementation:
an implementable attribute supported with existing user agents
predetermined values for the attribute associated with purpose/meaning 

A lack of support in the wild was one of key hills to overcome during 
various discussions on personalization. By creating an implementable toe 
hold in this space, groups can create ATs and browser plugins now  which 
build on the autofill attributes and values to provide immediate ways of 
supporting personalization in limited ways (such as by using symbols). 
With such things in place, everyone can begin to understand and see 
potential uses and benefits, which helps create momentum for a broader 
personalization adoption.

Might I suggest a compromise name, which is Identify Input Purpose (or 
Identify Common Input Purpose). This is what the authors are being asked 
to do: adopt the autofill attribute values in whatever technologies they 
can so that input purposes can be programmatically determined.

Michael Gower
IBM Accessibility
Research

1803 Douglas Street, Victoria, BC  V8T 5C3
gowerm@ca.ibm.com
voice: (250) 220-1146 * cel: (250) 661-0098 *  fax: (250) 220-8034



From:   Katie Haritos-Shea <ryladog@gmail.com>
To:     Andrew Kirkpatrick <akirkpat@adobe.com>
Cc:     Alastair Campbell <acampbell@nomensa.com>, Joshue O Connor - 
InterAccess <josh@interaccess.ie>, John Foliot <john.foliot@deque.com>, 
"W3c-Wai-Gl-Request@W3. Org" <w3c-wai-gl@w3.org>, "lisa.seeman@zoho.com" 
<lisa.seeman@zoho.com>
Date:   2018-02-28 09:26 AM
Subject:        Re: SC 1.3.4 - Understanding doc update



Andrew,

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. 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. 

Katie: The SC, in the stem sentence and both bullets talk about 'input 
field', or 'form input data'.....therefore I am unsure how you envision 
the requirements of this SC to ever cover anything other than form inputs, 
no matter what technology is used. As is, this SC is no longer about 
Purpose of Controls, but about helping users with memory or cognitive 
issues input repetitive content into form fields - and that is cognitive 
support I could get behind. (But we could also just suggest they use 
Autocomplete for this purpose without an SC)

(As an aside someone might be able to use a feature like this to try to 
implement some micro-amount of personalization by adding icons when such 
functionality exists - but that would be above and beyond the help of 
easing the task of filling in the form.). So, IMO, this SC should be 
decoupled from personalization and the Level AAA SC about Purpose and 
moved to reside under Guideline 3.3 Input Assistance.


Alastair:  Katie – I’m fairly sure the AI/heuristics aspects is a red 
herring for this purpose. 

Katie: For this purpose of identifying a purpose of a control, or the 
meaning of any element on the page via a personalized rendering - you are 
correct - right now - it is a red herring. I wasn't suggesting that we try 
that....:-)

But using AI to allow Accessibility (and other) metadata to be 
injected-into or utilized-by a web page is the probably 
a better route to address this problem overall, for the web. Because 
requiring authors to add markup to everything, which the personalization 
identified portion of this SC is trying to do (via tokens that match the 
autocomplete values), sets a precedent for sending personalization down 
that road. That, in my opinion, is not the best way to tackle this very 
complicated problem that the web has been trying to solve for some time.

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

* 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 | ryladog@gmail.com | 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 11:01 AM, Andrew Kirkpatrick <akirkpat@adobe.com> 
wrote:
(Do I need to say “Chair hat off” for these things now? If so, it’s off.) 
AWK: Ditto.
 
Does 1.3.4 support personalisation?
Katie picked up on Lisa’s response of “No” last week, and without wanting 
to put words in Lisa’s mouth, I think the nuanced answer is ‘not in a way 
that looks anything like what was hoped for’. 
 
AWK: That is good to hear and meshes more with my understanding of what 
this SC can promote.
 
Partly that is because these tokens would represent about 5-10% 
(rough-guess) of what would be provided by the personalisation spec, so in 
that way this SC does not represent personalisation.
 
AWK: Right, but it is a step in a positive direction. 
 
Technically yes, the attributes added could be used to add icons, however, 
today (for implementations) we don’t have two user-agents (or two sites) 
that add icons based on autocomplete  tokens.
 
AWK: The ally-resources.com site shows one example of this, but doesn’t 
cover all HTML autocomplete attribute values though.
 
My proposed update (initial draft) is here:
https://alastairc.ac/tmp/autocomplete.html 
(And in github: 
https://github.com/alastc/wcag21/blob/identify-common-purpose/understanding/21/identify-common-purpose.html 
)
 
AWK: Thanks for the work on this Alastair.
 
I agree with Katie that it should be moved to 3.3, and call it something 
else. Autocomplete, input assistance, I don’t have strong feelings about 
that.
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. 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.