Re: Identify Common Purpose - resolving issues

+1 to last ditch attempt (although I cannot help saying that this SC title must be the most unwieldy ever - it is somewhat ironic that this seem necessary for a coga SC).
I am impressed at effort you have put in to push this across the line.
Detlev

Sent from phone

> Am 17.01.2018 um 01:18 schrieb Alastair Campbell <acampbell@nomensa.com>:
> 
> 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-ict.com/personlization.shtml
> Script: https://github.com/ayelet-seeman/coga.personalisation
> Website based implementation: https://a11y-resources.com/developer/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.