-
Notifications
You must be signed in to change notification settings - Fork 55
"Common Purpose" names should be maintained by WCAG #803
Comments
Thank you for commenting. For more information about how the AG WG will process this issue, see the following:
|
[Official WG Response]
|
This should have no implication for CR, since it makes no difference at all to implementation requirements - the set of terms that implementations must recognise is exactly the same, and they have not been given a definitive machine-readable source. |
The WG decided on the above response, so we changed the text in the comment containing the proposed response to read "[Official WG Response]". Please confirm is you are satisfied with the response within 3 days. If we haven't heard a response by then we will regard the resolution as satisfactory. |
Confirming I am satisfied. Thanks |
The new success criterion 1.3.4 makes a lot of sense.
(Although "Common Purpose" in english generally means a shared goal, rather than a widely-recognised one. It might be useful to change the name of the Success Criterion to reflect that).
Rather than baking in the list of terms by reference to HTML 5.2, it would make more sense if they were managed as an appendix to WCAG itself, or a parallel Rec-rack document.
That list from autocomplete makes a useful starting point, but it seems likely that there will be a number of changes specific to the accessibility use which might not be so easily adopted for "autofill" - and almost certainly only by extensions rather than the bigger American browsers taking them on natively, so needing to go through an HTML update cycle seems like an unnecessary barrier, introducing an external timeline dependency in the pathway to updates.
Having the information as a part of WCAG allows for a simpler update path for what is basically a vocabulary. An alternative is to make a separate Recommendation - again to allow for simpler updates to suit the needs of WCAG.
The text was updated successfully, but these errors were encountered: