Skip to content
This repository has been archived by the owner on Jun 30, 2018. It is now read-only.

Received comment on the the SC 1.3.4 Common Purposes for User Interface Components list #654

Closed
mapluke opened this issue Jan 4, 2018 · 1 comment

Comments

@mapluke
Copy link

mapluke commented Jan 4, 2018

In reviewing a draft of the European Standard that will include new WCAG 2.1 text we received this very relevant comment that raises a quite fundamental issue about the Common Purposes for User Interface Components list of purposes:
“I would not be surprised if this SC is altered or even abandoned, because right now it introduces a (probably well researched, but still) arbitrary set of semantics. If this list is statically included in the WCAG specification it is bound to become more and more outdated, but if instead it is maintained separately and more dynamic it will become more difficult to test conformance (and conformance will erode over time).”
I cannot see an easy way to avoid the dilemma of either having a fixed list that becomes outdated or a maintained list that will change and make reliable conformance testing impossible.

@awkawk
Copy link
Member

awkawk commented Jan 21, 2018

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

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.

@awkawk awkawk closed this as completed Jan 21, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

4 participants