Re: Identify Common Purpose - resolving issues

> External standards like EN301549 and others will be able to just
reference the SC text and not worry about integrating the list since it is
a reference.

I don't this the EN would link to ANY standard external. They copy and
paste into theirs. You can check with Mike Pluke (copied on this email)
about this perhaps.

See the ISO paper Using and referencing ISO and IEC Standards to support
public policy
<http://www.iso.org/sites/policy/documents/Using%20and%20referencing%20ISO%20and%20IEC%20standards%20to%20support%20public%20policy%20-%20EN.pdf>

I'm fine with importing the list
​ into our document ​
...
​as per Alastair's proposal​



Cheers,
David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

LinkedIn
<http://www.linkedin.com/in/davidmacdonald100>

twitter.com/davidmacd

GitHub <https://github.com/DavidMacDonald>

www.Can-Adapt.com <http://www.can-adapt.com/>



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>

On Tue, Jan 16, 2018 at 8:22 PM, Andrew Kirkpatrick <akirkpat@adobe.com>
wrote:

> OK, so what we have now are two options, one with the list in the WCAG
> document and one which references the list in HTML. Discuss.
>
>
>
> The pros/cons on the in the spec/outside the spec list choice seem to be:
>
>
>
>    - Concerned about referencing an external spec (pro for internal list)
>    - Responds to comments requesting that we reference an external list
>    and provides justification for the choices on specific tokens (pro for
>    external reference)
>    - Adding to Understanding burden (con for internal list – probably
>    minor)
>    - Adding to our editorial and localization burden (con for internal
>    list)
>    - External standards like EN301549 and others will be able to just
>    reference the SC text and not worry about integrating the list since it is
>    a reference.
>
>
>
> If others have points pro or con, please make them. I know which way I
> prefer but want to hear from others.
>
>
>
> Thanks,
>
> AWK
>
>
>
> Andrew Kirkpatrick
>
> Group Product Manager, Accessibility
>
> Adobe
>
>
>
> akirkpat@adobe.com
>
> http://twitter.com/awkawk
>
>
>
> *From: *Alastair Campbell <acampbell@nomensa.com>
> *Date: *Tuesday, January 16, 2018 at 19:18
> *To: *Andrew Kirkpatrick <akirkpat@adobe.com>, WCAG <w3c-wai-gl@w3.org>
> *Subject: *RE: Identify Common Purpose - resolving issues
>
>
>
> 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
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2F2017%2FWD-WCAG21-20171207%2F%23input-control-purposes&data=02%7C01%7Cakirkpat%40adobe.com%7C54a6e43dcd0b45082f1408d55d3fe42f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636517451353625590&sdata=U%2BB%2FzHRgdP7t4JPEgkeYFrWLuNHM9v6zv01N5jziPXQ%3D&reserved=0>
>
>
>
> 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
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fhtml51%2Fsec-forms.html%23autofilling-form-controls-the-autocomplete-attribute&data=02%7C01%7Cakirkpat%40adobe.com%7C54a6e43dcd0b45082f1408d55d3fe42f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636517451353781852&sdata=7JTOU1mo8sSIcLpudpYd%2BPsTNj0zMMGkNFRtzItC%2FjI%3D&reserved=0>
>
>
>
> 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
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcaniuse.com%2F%23feat%3Dinput-autocomplete-onoff&data=02%7C01%7Cakirkpat%40adobe.com%7C54a6e43dcd0b45082f1408d55d3fe42f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636517451353781852&sdata=x05v38cmVuP8MsKM1awr9ivHQOq8XFN5eObac4Qhnzw%3D&reserved=0>
>
> (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
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Faccessibility.athena-ict.com%2Fpersonlization.shtml&data=02%7C01%7Cakirkpat%40adobe.com%7C54a6e43dcd0b45082f1408d55d3fe42f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636517451353781852&sdata=jIYDitaTXpT%2FBscBuCkB5bAgoGGbhMPC2GJXf2VED00%3D&reserved=0>
>
> Script: https://github.com/ayelet-seeman/coga.personalisation
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fayelet-seeman%2Fcoga.personalisation&data=02%7C01%7Cakirkpat%40adobe.com%7C54a6e43dcd0b45082f1408d55d3fe42f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636517451353781852&sdata=%2BiUQjamzLdLJPbtxuMTrc7%2FxRW7oahS7C4YPuaH7hLE%3D&reserved=0>
>
> Website based implementation: https://a11y-resources.com/
> developer/coga-personalisation
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fa11y-resources.com%2Fdeveloper%2Fcoga-personalisation&data=02%7C01%7Cakirkpat%40adobe.com%7C54a6e43dcd0b45082f1408d55d3fe42f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636517451353781852&sdata=Z7BOfeGS1q9XBa3Y%2BODGlBECLimP8fNr0gMJtXgtmYg%3D&reserved=0>
>
>
>
> 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
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwcag21%2Fissues%2F672&data=02%7C01%7Cakirkpat%40adobe.com%7C54a6e43dcd0b45082f1408d55d3fe42f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636517451353781852&sdata=rbHe190dsJFLy%2B87xMDximdDLJPg2d6Ar6dmvcmLaoM%3D&reserved=0>:
> 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
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwcag21%2Fissues%2F665&data=02%7C01%7Cakirkpat%40adobe.com%7C54a6e43dcd0b45082f1408d55d3fe42f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636517451353781852&sdata=dIU%2B2IwILLoVgSVHxfKjdymLy%2Fo0hcsqYwRXGdQce6w%3D&reserved=0>:
> Proposes sentence structure change (minor)
>
> The wording has been significantly updated, we think this addresses the
> issue.
>
>
>
> https://github.com/w3c/wcag21/issues/661
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwcag21%2Fissues%2F661&data=02%7C01%7Cakirkpat%40adobe.com%7C54a6e43dcd0b45082f1408d55d3fe42f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636517451353781852&sdata=3jDDsjWtkT8bKTwq%2FDbKrN1stGeXcdqylaFtJOGjVBI%3D&reserved=0>:
> 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
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwcag21%2Fissues%2F654&data=02%7C01%7Cakirkpat%40adobe.com%7C54a6e43dcd0b45082f1408d55d3fe42f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636517451353781852&sdata=muXbzuBv7SJy2t%2BvpqyXPP5ZmSA9WJvQ8ZROVG6xKHM%3D&reserved=0>:
> 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
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwcag21%2Fissues%2F653&data=02%7C01%7Cakirkpat%40adobe.com%7C54a6e43dcd0b45082f1408d55d3fe42f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636517451353781852&sdata=8%2FvcNJ68aZTM9yKNYjxatq%2FRePxiBvcbs67Ve2V2gZw%3D&reserved=0>:
> 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
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwcag21%2Fissues%2F651&data=02%7C01%7Cakirkpat%40adobe.com%7C54a6e43dcd0b45082f1408d55d3fe42f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636517451353781852&sdata=EQXnkr3lzq4dOah5OcNj9r0PWais311%2BokEiDF2fW7A%3D&reserved=0>:
> 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
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwcag21%2Fissues%2F635&data=02%7C01%7Cakirkpat%40adobe.com%7C54a6e43dcd0b45082f1408d55d3fe42f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636517451353781852&sdata=dK%2F3JLwdysLpdyl7pyVFxSlUGP1h%2FS1rG0O69Pd2vik%3D&reserved=0>:
> 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
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwcag21%2Fissues%2F629&data=02%7C01%7Cakirkpat%40adobe.com%7C54a6e43dcd0b45082f1408d55d3fe42f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636517451353781852&sdata=NCWSumibueI5DzLBcMxMXLCCL9BuUB%2FBJJMwNCnfKcs%3D&reserved=0>:
> 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
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwcag21%2Fissues%2F624&data=02%7C01%7Cakirkpat%40adobe.com%7C54a6e43dcd0b45082f1408d55d3fe42f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636517451353781852&sdata=9SLio7TI4Vj4%2FTktd1nXc8gNlMQm9MoXoJqXOUXGc68%3D&reserved=0>:
> “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
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwcag21%2Fissues%2F602&data=02%7C01%7Cakirkpat%40adobe.com%7C54a6e43dcd0b45082f1408d55d3fe42f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636517451353781852&sdata=N5YnAmcrRy%2Bio5lxTEqNeka7ggnGoRXqnNXWkhiPOPs%3D&reserved=0>:
> similar to 635 (closed as duplicate)
>
>
>
> https://github.com/w3c/wcag21/issues/590
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwcag21%2Fissues%2F590&data=02%7C01%7Cakirkpat%40adobe.com%7C54a6e43dcd0b45082f1408d55d3fe42f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636517451353781852&sdata=encdv1aTuL6ldlLxx8eoRi%2FlnrTQgDoP7q7E4lKmE1g%3D&reserved=0>:
> 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
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fw3c%2Fwcag21%2Fissues%2F586&data=02%7C01%7Cakirkpat%40adobe.com%7C54a6e43dcd0b45082f1408d55d3fe42f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C636517451353781852&sdata=LVbEEzc8uT0xHPeFVKhsCDBCe8M0YpvnH%2BztedvPrJ4%3D&reserved=0>:
> 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.
>