Re: Identify Common Purpose - resolving issues

​Now if
 we
​want to address Jake's issue we could go with a variation of his text

“In content implemented using technologies with support for identifying the
expected meaning for elements, for each user-specific element that has a
purpose that maps to any of the [link]list of common input fields,  the
meaning of the element can be programmatically determined.”

Our list would only contain user-specific form elements. But that list
could expand in future versions. The downside of this is that it looses
some of its understandability when it is changed from "user specific input
field" to "element".

I'm not sure how much this would help us in the future. This space may be
changing quickly and its likely a future version would be worded
differently.

Even if we could keep this SC language in the future, both the SC text and
the definition are normative, so changing either would be a normative
change to the SC.

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 Wed, Jan 17, 2018 at 2:28 AM, Abma, J.D. (Jake) <Jake.Abma@ing.nl> wrote:

> Nice work but one thing is that I see a limitation in “for each
> user-specific input field” if we want to expand this SC to also apply to
> NON user-specific input fields (or even links / buttons)
>
>
>
> It would be a shame to create a SC just because we want something in but
> it serves as a disposable lighter and in near future we need to OR create
> new SC which serve exactly the same purpose or delete/replace this one (if
> that’s even possible)
>
>
>
> So first we undressed this SC to a bare minimum and now lock the scope
> making it very narrow.
>
>
>
> *From:* Alastair Campbell [mailto:acampbell@nomensa.com]
> *Sent:* woensdag 17 januari 2018 1:19
> *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
>
>
>
> 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.
>
> -----------------------------------------------------------------
> ATTENTION:
> The information in this e-mail is confidential and only meant for the intended recipient. If you are not the intended recipient, don't use or disclose it in any way. Please let the sender know and delete the message immediately.
> -----------------------------------------------------------------
>
>