Success Criterion 1.3.4 Identify Common Purpose needs Understanding and Techniques

[carmacleod]

Success Criterion 1.3.4 "Identify Common Purpose" needs a well-written "Understanding" page, as well as some concrete example "Techniques" (ideally, before it went to wide review draft last week).

Because these are missing, I had to grok through open and closed issues, and ask other people, to figure out what this SC is really saying. I don't think the public can truly review this new SC until it is made clear what authors are going to have to do to meet the criterion.

The summary seems to be (correct me if I am wrong):

1. Form controls (particularly input, textarea, and select... note: not just input) can use autocomplete/autofill
2. Other types of contol would need to use some kind of structured data/microdata markup with some sort of common vocabulary/schema similar to what search engines look for.

I am just concerned that there is not enough time before Candidate Recommendation for a proper review of this new SC without clear authoring information.

[lseeman]

I think you have a good grasp, although you will also be able to use an aria vocabulary that is being produced. (https://w3c.github.io/personalization-semantics/content/index.html)
we have a draft understanding page at https://rawgit.com/w3c/wcag21/identify-common-purpose/understanding/21/identify-common-purpose.html. we have a bit more to add. I hope it will be published this week

Does that help?

[carmacleod]

Yes, it does help explain. But I still don't think this SC is ready to become a WCAG requirement.

The non-form-controls portion of this SC is based on unstable specifications and defacto standards.
Also, it's a "big ask" to get authors to add yet another layer of semantics to their controls, particularly as this new additional layer is highly subjective (for example, there's no way that I would ever call a Revert button an "undo button" - revert means to go back to the last saved state, and undo means to go back to the state that was present right before the last action was performed).
Are there any browser extensions, or AT, or testing tools?

The form-controls (autocomplete) portion of this SC is more stable, but has some potential security risks that need to be ironed out before requiring authors to implement it.

I think that once this SC is more stable and secure, it would make sense to include it in a future version of WCAG.

[alastc]

(Non-official response, discussion/questions).
In the security thread #590 (which I started) we came to the conclusion that it is a browser / user-agent implementation issue. I.e. the mitigation of the security concerns needs to be done by the user-agent so that there is some interaction before filling things in, and it doesn't fill in hidden fields.

There doesn't seem to be any sign of browsers dropping autofill, so it shouldn't affect this SC.

I'm unclear why you call the specs unstable? (Apart from this one maybe?) Autofill is part of HTML LS & 5.x, Microdata has been around for a long time and the basics of it (needed here) I remember trying out years ago. I think @johnfoliot spoke to some microdata folk recently, I wonder if he can chip in about the stability of that spec?

The subjectivity and 'ask' are new, but relatively small compared to 1.3.1/4.1.2, and given the audience size & need that seems easy to justify.

[carmacleod]

Please also see #672

[alastc]

That's about other standards relying on WCAG 2.1, rather than the standards WCAG 2.1 is relying on. It doesn't seem to continue this thread, or preceed it?

That issue will have it's own response, possibly something like: This SC will be required to have implementations before WCAG 2.1 leaves CR, it is at-risk until then.

[carmacleod]

Sorry, I meant that I agree with @MakotoUeki that it would be more reasonable to have SC 1.3.4 Identify Common Purpose at level AAA, and not at level AA, for the same reasons that he mentions.

[awkawk]

(Official wG response)
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, while 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.

While 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.

The SC text and list of purposes has been updated so only the input aspects are used.

[carmacleod]

Thank-you for reducing the scope to just the autocomplete part. I agree completely that this is now a stable and achievable SC that will prove helpful to many people.