Understanding Identify Common/Input Purpose

[awkawk]

The 1.3.4 Identify Common Purpose (AA) SC has draft Understanding content that can be viewed at Understanding Identify Common Purpose.

Please review the Understanding document and submit a comment on this issue for any changes that are needed to the content.

[alastc]

Comment for @chriscm2006 & @jake-abma:

You were both down for reviewing/updating the understanding doc, can I just check if that has been active?

Based on a thread on the WCAG list I did a complete re-write towards making it focused on auto-filling inputs in, rather than personalisation per-se:

Readable Preview of the new version.

Has there been any active work on this since we went into CR? Does someone want to run with this version, or is there reason to use the previous one?

[jake-abma]

Hi Alastair, The last version at: https://rawgit.com/w3c/wcag21/identify-common-purpose/understanding/21/identify-common-purpose.html was done by Lisa and from that moment we were not active/involved anymore on this Understanding doc. So no active work from us OR Lisa may have done more on this...(maybe ask her?) Your version though seems the most appropriate and for me fine to use instead of the older version. Cheers! Jake 2018-03-03 18:13 GMT+01:00 Alastair Campbell <notifications@github.com>:

…

Comment for @chriscm2006 <https://github.com/chriscm2006> & @jake-abma <https://github.com/jake-abma>: You were both down for <https://www.w3.org/WAI/GL/wiki/Accepted_WCAG_2.1_SC> reviewing/updating the understanding doc, can I just check if that has been active? Based on a thread on the WCAG list I did a complete re-write <https://github.com/alastc/wcag21/blob/identify-common-purpose/understanding/21/identify-common-purpose.html> towards making it focused on auto-filling inputs in, rather than personalisation per-se: Readable Preview <https://alastairc.ac/tmp/autocomplete.html> of the new version. Has there been any active work on this since we went into CR? Does someone want to run with this version, or is there reason to use the previous one? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#779 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGFpggFmMBGq-CqyjLR56w-pm3UbZ5oGks5tas8rgaJpZM4SZ9Ax> .

[Ryladog]

sooooo....which Understanding document link are we using to review. I would like to see Alastairs version used...

[alastc]

Hi @Ryladog,

I've balanced it out a bit more (including some limited personalization aspects), but the main change is removing the tables, hopefully this is easier to get through:
CR version of Understanding Identify common controls.

It matches the scope better. Not saying it's perfect, but I think an easier starting point for the new SC text.

[Ryladog]

Alastair, I am afraid that the personailzation demo doesn't appear to add any icons. What am I doing wrong? ** katie **

[alastc]

Hi Katie,

If you click the button the right it does add icons to the home, sitemap and submit buttons, but not the inputs.

The demo was created way before the new SC text, and doesn't use the autocomplete attributes which is why I introduced it as "In future a more robust set of personalization abilities should be available", rather than saying it worked now.

I can take it out, I was just casting around for concrete examples to show.

-Alastair

[johnfoliot]

​​Hi Alastair, Apologies for the delay in responding, I have been travelling since last week delivering training, and between lack of time and limited connectivity I've been struggling to keep up. I have reviewed your proposed Understanding document, and I must strongly disagree with the general thrust of your draft. Discussion around this SC has been unduly distracted by discussion around *one* technique that can be applied, whilst failing to properly recognize that other techniques exist or are emerging. The current SC does not *MANDATE* the use of @autocomplete (and based upon our long-standing policy of being Technique agnostic, should not do so). The SC simply states: The meaning of each input field collecting information about the user can be programmatically determined <https://www.w3.org/TR/2018/CR-WCAG21-20180130/#dfn-programmatically-determinable> when: - The input field has a meaning that maps to the HTML 5.2 Autofill field names <https://www.w3.org/TR/html52/sec-forms.html#sec-autofill>; and - The content is implemented using technologies with support for identifying the expected meaning for form input data. Yes, using @autocomplete has additional benefits for all users, and we used the token values derived from @autocomplete to identify which inputs we want 'enhanced', but the intent was, is and always has been to start attaching additional metadata to "Common" controls and inputs (and then reduced to just "inputs"). Any additional benefits derived are happy coincidences, and not part of the intent of this SC. (This is why, for example, some members are resisting moving this SC under 3.x.x, as doing so further confuses the intent of this SC.) I have taken the liberty of re-working your draft to re-shift the focus back to the original intent, and offer the following proposed editorial change below: *Intent* The intent of this success criteria is to help users ​ better recognize​ and understand ​ ​ the intention of form inputs, by attaching additional information (metadata) to the identified form inputs. This allows for additional machine-processing for personalization and other automation, such as identifying and applying familiar terms or symbols to the inputs, which are needed for users with cognitive disabilities to be able to use the web. When a user-agent (browser or Assistive Technology) knows what an input is expecting it can then provide the ability for page customization, such as applying familiar icons or standardized labels next to the input. Additionally, using techniques such as the autocomplete attribute (from HTML) will make completing forms easier for everyone, by reducing the overhead of typing in common information such as address and credit card numbers. This benefits all users, but has a much greater impact on people with cognitive impairments. The approach of adding metadata to indicate the purpose of elements is intended to be compatible with future work on personalization. Work done to implement this success criteria should continue to work when a wider range of personalization attributes are available in future. Although autocomplete provides a very limited scope for personalization, the mechanism for future work is similar which can be seen in the Personalization Semantics Content Module <https://w3c.github.io/personalization-semantics/content/>. This approach will initially seem similar to adding role information (as required by 4.2.1 @@@ link) but actually provides higher level information so the user can understand the intent or purpose of the input. For example, that a field is intended for your name, it is not just a text field. In the future a more robust set of personalization abilities should be available, such as this personalization demo <https://rawgit.com/ayelet-seeman/coga.personalisation/demo/conactUs.html> provides. In this demo, a user can load a set of preferred symbols that are appropriate for them. These symbols can help a people comprehend intent via a toolbar or browser extension which overlays the symbols onto the page. When the autocomplete attribute is used, browser's and browser extensions can also populate form fields on command (or automatically) so the user does not have to remember or transcribe the information. NOTE: with the autocomplete technique, the attribute should be used when the form is asking for the user's information and should *not* be used if the user is being asked to input other people's information. ​ (Should this comment be moved to the Technique page related to using @autocomplete?)​ Thoughts? JF

…

On Wed, Mar 7, 2018 at 4:53 AM, Alastair Campbell ***@***.***> wrote: Hi Katie, If you click the button the right it does add icons to the home, sitemap and submit buttons, but not the inputs. The demo was created way before the new SC text, and doesn't use the autocomplete attributes which is why I introduced it as "In future a more robust set of personalization abilities should be available", rather than saying it worked now. I can take it out, I was just casting around for concrete examples to show. -Alastair — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#779 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABK-c4zstYHx8TqQDDMOBZJS9xEkz_Flks5tb64rgaJpZM4SZ9Ax> .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com Advancing the mission of digital accessibility and inclusion

[alastc]

Discussion around this SC has been unduly distracted by discussion around one technique that can be applied, whilst failing to properly recognize that other techniques exist or are emerging. The current SC does not MANDATE the use of @autocomplete

It doesn't mandate autocomplete, which is good for future compatibility and work, but for an author reading this now, can you point to another technique that works?

but the intent was, is and always has been to start attaching additional metadata to "Common" controls and inputs (and then reduced to just "inputs").

From a COGA TF point of view this SC does not fulfil that any more. It is now the other way around: it helps with entering data, but there is not sufficient coverage (just inputs) for COGA to be interested in the personalisation aspects. (@lseeman please correct me if I'm over-stating that.)

Given that, anyone working on the user-agent side is likely to use the full personalisation spec and hopefully including autocomplete attributes with that.

I think there is still benefit to us (people like you and me) for starting the education process about this topic, but the scope is now so limited for personalisation it's hard to justify.

I have taken the liberty of re-working your draft...

Thank you, depending on how this discussion goes that will make updates easier :-)

Overall, my main concern is that the understanding doc be specific and relevant to the SC.

With the immediate focus on adding personalisation & icons, it seems misleading as that is not currently supported. Shouldn't we lead with what people can see and use now, and incraase the personalisation aspects over time?

I believe the Understanding docs should be quicker to update from 2.1, so it would be (relatively) easy to update this doc later.

[alastc]

Hi @johnfoliot I've updated that doc as per your edits.

[johnfoliot]

Hi Alastair,

Thanks for the edits.

I remain concerned about the readability of the attached table in that document - can we reinstate the borders on the individual TDs in the Section: "Meeting the success criteria"? Additionally, that section includes page controls no longer covered by this SC, i.e. the entire section "Providing purpose of controls for buttons and links", which should be removed.

[alastc]

Hi John,

Are we looking at the same one? There isn't a table in the new version (which is also linked from the description at the top of this page):
https://rawgit.com/w3c/wcag21/identify-common-purpose/understanding/21/identify-common-purpose.html

[johnfoliot]

Hi Alastair, I was looking at the resource linked from the Draft 2.1 Spec ( https://www.w3.org/WAI/WCAG21/Understanding/identify-purpose.html) which also seems to have been modified/edited. Keeping track of which version is which has been tricky to follow, as we have multiple documents scattered around everywhere. However, I have reviewed https://rawgit.com/w3c/wcag21/ identify-common-purpose/understanding/21/identify-common-purpose.html this morning, and I'm good with that version. JF

…

On Wed, Mar 14, 2018 at 4:05 AM, Alastair Campbell ***@***.*** > wrote: Hi John, Are we looking at the same one? There isn't a table in the new version (which is also linked from the description at the top of this page): https://rawgit.com/w3c/wcag21/identify-common-purpose/ understanding/21/identify-common-purpose.html — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#779 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABK-c7hiFDLwAtEs6ljsUxsvIKAKaUyrks5teM9ZgaJpZM4SZ9Ax> .

-- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com Advancing the mission of digital accessibility and inclusion

[alastc]

Ok, thanks.

It is tricky keeping the different versions lined up, but I think we only have two:

1. The docs linked to from the CR spec are in 'master', which need to be approved.
2. The ones on each 'working branch' are linked to from each of these github issues.

The survey points to these pages, so hopefully everyone can just follow those links to here, and get the right ones.

Cheers,

-Alastair

[johnfoliot]

The Draft Specification at https://www.w3.org/TR/WCAG21/#identify-common-purpose is still pointing to the wrong (outdated) Understanding document. Can we get this resolved?

[alastc]

Pull request created, I think Michael/Andrew can merge.

[marcjohlic]

There isn't a place to add comments on the current survey, so I'm just dropping it in here. I read and approved the updated Understanding doc from Alastair (https://rawgit.com/w3c/wcag21/identify-common-purpose/understanding/21/identify-common-purpose.html) BUT I think that all of the missing links under Intent, Benefits, and Resources should be filled in before this is Accepted and Published.

[alastc]

Hi Marc,

The locations of those resources are going to change fairly soon anyway, I'd rather have something in that screams update, that something that works now and becomes a 404 later.

[michael-n-cooper]

Understanding content for this issue should address the change agreed to by the WG in issue #755.

[alastc]

Comments from @johnfoliot on the list:

1. the current Understanding document incorrectly identifies this as Understanding Identify Common > Purpose, yet we've change the name of this SC to Identify Input Purpose, so an editorial change is required there.

2. Under Examples it states:

The list of values that should be used are available in the HTML5 specification: autocomplete values from HTML5.2.

While this is factually correct, did we not decide to also include that list directly in the WCAG 2.1 spec as an Appendix? Should we not also indicate that here (and perhaps stop pointing to the HTML 5.2 spec)?

Also:

• Typo for 4.2.1 instead of 4.1.2
• Where will the proposed links go in the techniques section?

Everything else appeared fine.

[alastc]

Comments from the AGWG call on updating this:

• From @mbgower - Understanding docs should be compared for the amount and type of content in sections (e.g., Intent), and an attempt made to align style and volume. The editorial pass should also consider adding subheadings or moving content to make the Understanding documents more consistent.
• Replace the password/new-password example (@johnfoliot )

[michael-n-cooper]

This issue was moved to w3c/wcag#343