Re: Identify Common Purpose - resolving issues

+1 to Alastair's proposed language (I too thank you!).

And to Andrew question, including that short list with the SC internally.

There is no shame in us getting individual solid requirements into this
spec, we do need to work on the other requirements, clear piece - by clear
piece. That is why to me, the number of SCs should not be such a concern.
Getting good solid SCs is more important than the number.

** katie **

Katie Haritos-Shea

Senior Accessibility SME (WCAG/Section 508/ADA)

703-371-5545

ryladog@gmail.com

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 Tue, Jan 16, 2018 at 8:26 PM, John Foliot <john.foliot@deque.com> wrote:

> Thanks Alastair, I personally think you covered this to a "T", and I'll +1
> your proposal here.
>
> It's unfortunate that the other half of the original proposal didn't get
> the traction I'd hoped it would, but at least with this we ARE moving the
> ball forward, just not as far as we had hoped. Still, a partial win is
> better than a loss, in my books at least.
>
> JF
>
> On Jan 16, 2018 7:20 PM, "Alastair Campbell" <acampbell@nomensa.com>
> wrote:
>
>> Hi everyone,
>>
>>
>>
>> Here’s my last ditch attempt, basically a small tweak to Andrew’s
>> version, but more importantly collating reasonable answers to the issues &
>> comments.
>>
>>
>>
>> So the text I’d suggest is:
>>
>> “In content implemented using technologies with support for identifying
>> the expected meaning for form input data, for each user-specific input
>> field that has a purpose that maps to any of the [link]list of common input
>> fields,  the meaning of the input field can be programmatically determined.”
>>
>>
>>
>> I.e. the same as Andrew’s last version with one tweak, moving the list of
>> fields into the end of WCAG. That would be what is here:
>>
>> https://www.w3.org/TR/2017/WD-WCAG21-20171207/#input-control-purposes
>>
>>
>>
>> BUT, only the input options, and I propose to line that up *exactly*
>> with the HTML 5.2 token list, or at most a sub-set of those.
>>
>> https://www.w3.org/TR/html51/sec-forms.html#autofilling-form
>> -controls-the-autocomplete-attribute
>>
>>
>>
>> That takes care of my objection, which was that we would be directly
>> referencing a technology-specific spec.
>>
>>
>>
>> This is not a very good response to the user need. However, I see it as
>> very small wedge, and we need to expand on it in the next version.
>>
>>
>>
>> Tackling the other objections, I’ll try to use official response type
>> language:
>>
>>
>>
>>
>>
>> *1)           No implementations, move to AAA (Issues 672, 661, 653, 651)*
>>
>>
>>
>> The SC has been changed to focus on currently supported attributes, so
>> browsers support this across the board:
>>
>> https://caniuse.com/#feat=input-autocomplete-onoff
>>
>> (There are some issues with browser implementations, but they do not
>> appear to affect the autofill part of autocomplete.)
>>
>>
>>
>> This aspect alone is very helpful to some people with cognitive issues.
>>
>>
>>
>> For the aspect of adding icons for users (another goal of the SC) It is
>> also worth noting that there are several implementations already:
>>
>> Chrome extension: http://accessibility.athena-ic
>> t.com/personlization.shtml
>>
>> Script: https://github.com/ayelet-seeman/coga.personalisation
>>
>> Website based implementation: https://a11y-resources.com/dev
>> eloper/coga-personalisation
>>
>>
>>
>> These are at early stages and have been using the COGA semantics spec,
>> but these can be updated to cover the autofill attributes as well, whilst
>> the other aspects mature.
>>
>>
>>
>> Overall, there is basic support for the proposal already, and people
>> committed to expanding the functionality during the CR stage.
>>
>>
>>
>> Given the user-need, and that this new version is far easier to
>> implement, there does not seem to be an issue with including this SC at
>> level AA.
>>
>>
>>
>>
>>
>> *2)           Making the list – how it was determined, whether we add
>> more, remove some, reference externally, or what (Issues 654, 651, )*
>>
>>
>>
>> The SC has been updated to use what browsers currently implement, and
>> there was already a great deal of overlap between what was required for
>> inputs, and the HTML list.
>>
>>
>>
>> Once implemented, it seems unlikely that the browsers (and therefore the
>> HTML spec) would reduce the list, unless there is a security issue with
>> particular items.
>>
>> The advantage of maintaining the list in WCAG is that items added to HTML
>> are not automatically required by WCAG.
>>
>> In future iterations that expand this requirement, the working group
>> hopes there will be a stable specification to directly reference for that
>> purpose, but this seems to be a reasonable starting point.
>>
>>
>>
>>
>>
>> *3)           Security concerns/conflicts (629, 590)*
>>
>>
>>
>> (NB: As the person that raised the issue in the first place, I feel I can
>> speak to this one!)
>>
>>
>>
>> Whilst there are some privacy and security concerns with automatically
>> filling in inputs (without the user wanting to), this is ultimately a
>> user-agent/browser issue.
>>
>> The way to solve the issue is to make sure the user agrees to fields
>> being populated (e.g. clicks a button in the browser interface), and avoid
>> filling in hidden inputs.
>>
>> We can note the concern in the understanding document, but if change is
>> needed it is up to the browsers and Web Platform working group to resolve.
>>
>>
>>
>> Sorry, I didn’t quite make evening (just past midnight), but hopefully
>> this will help.
>>
>>
>>
>> Cheers,
>>
>>
>>
>> -Alastair
>>
>>
>>
>>
>>
>> *Individual responses*
>>
>>
>>
>> https://github.com/w3c/wcag21/issues/672: Suggests moving to AAA due to
>> lack of implementations and required support if 2.1 takes ISO path. Problem
>> in Japan. (major)
>>
>> Use comment from (1)
>>
>>
>>
>> https://github.com/w3c/wcag21/issues/665: Proposes sentence structure
>> change (minor)
>>
>> The wording has been significantly updated, we think this addresses the
>> issue.
>>
>>
>>
>> https://github.com/w3c/wcag21/issues/661: Presently there are no add-ons
>> or AT supporting the SC, change to AAA (major)
>>
>> Use comment from (1)
>>
>>
>>
>> https://github.com/w3c/wcag21/issues/654: Concerned about the dilemma of
>> a fixed list of purposes vs. an untestable (moving target) maintained list.
>> (major)
>>
>> Use comment from (1), also:
>>
>> In the current proposal the list is based on something that browsers have
>> already implemented, in future iterations of WCAG it is possible this will
>> be separated.
>>
>>
>>
>> https://github.com/w3c/wcag21/issues/653: Suggests waiting for
>> browsers/UA to possibly pick up schema.org data and then it will be time
>> to ask developers to support it. (major)
>>
>> Use comment from (1)
>>
>>
>>
>> https://github.com/w3c/wcag21/issues/651: Suggests a reference to the
>> HTML autofill list, or at least clarifying in understanding that the list
>> will become out of date with the source. Thinks should be for HTML only
>> also. (major)
>>
>> Use comment from (2), also:
>>
>> The SC text has been updated to show that it should only be used in
>> technologies that support it, and the understanding and techniques will
>> clarify that.
>>
>>
>>
>> https://github.com/w3c/wcag21/issues/635: Concerned that the purposes
>> need to be uniquely identifiable and referenceable. (seems solved)
>>
>> The new SC text has resolved this issue.
>>
>>
>>
>> https://github.com/w3c/wcag21/issues/629: Wants more and better
>> understanding content. Raises potential security risks. (major)
>>
>> Use comment from (1, 3), also:
>>
>> The SC text and list of purposes has been updated so only the input
>> aspects are used.
>>
>>
>>
>>
>>
>> https://github.com/w3c/wcag21/issues/624: “compose” / “new” question
>> related to a specific metadata item in the list.
>>
>> The wording has been significantly updated, we think this addresses the
>> issue, it no longer includes the buttons aspect.
>>
>>
>>
>> https://github.com/w3c/wcag21/issues/602: similar to 635 (closed as
>> duplicate)
>>
>>
>>
>> https://github.com/w3c/wcag21/issues/590: comment that raises possible
>> concerns and conflicts with security requirements for sites (major –
>> solved?)
>>
>> Use comment from (3). But it’s to me, so don’t worry about it.
>>
>>
>>
>> https://github.com/w3c/wcag21/issues/586: List of purposes needs more
>> terms (minor/major)
>>
>> Unfortunately, due to issues around the implementation and feasibility
>> the purposes related to links and buttons have been removed.
>>
>> We do intend to expand on this work in future, and would like to defer
>> this comment for future work.
>>
>