Re: Possible wording for 1.3.4?

I'm ok with the premise

I think we may need a normative definition of

"meaning of each user interface component"

or

"meaning"

In oxford Dictionary the definition is "Important or worthwhile quality;
purpose."
https://en.oxforddictionaries.com/definition/meaning


The previous SC used the word "purpose"
Definition
"The reason for which something is done or created or for which something
exists"
https://en.oxforddictionaries.com/definition/purpose


It seems "purpose" is more accurate than "meaning" ... no?



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 Fri, Jan 12, 2018 at 9:47 AM, Andrew Kirkpatrick <akirkpat@adobe.com>
wrote:

> OK, so here’s a new attempt at language for 1.3.4.
>
>
>
> This language is below. Several concerns are addressed:
>
>    - Uses a small and already-established list of values, based on the
>    values in HTML5.2, but only imposes those values on other technologies if
>    those technologies share the same values.
>    - Well-established browser support for input autofill, and provides a
>    pathway for cognitive AT innovation.
>    - Addresses a need established by the COGA group related to difficulty
>    filling out forms as well as providing the personalization enhancements
>    development pathway.
>    - WCAG doesn’t need to provide a specific list of inputs by
>    referencing the HTML list, but that list is versioned with HTML so the
>    level of testability doesn’t change until we update the reference in WCAG
>    2.2 (or silver) to either an updated HTML or COGA/ARIA spec.
>    - Specifically targeted to the user, so this isn’t for EVERY input
>    control, just a handful in the HTML spec (~40) that relate to common user
>    information (name, address, phone, credit card).
>
>
>
> Title: Support Common Input Fields
>
> SC Text:
>
> In content implemented using technologies with support for autofilling
> form inputs, the meaning of each user interface component that accepts user
> input corresponding to the user can be programmatically determined; inputs
> matching a meaning provided in the HTML 5.2 Autofill field names
> <https://www.w3.org/TR/html52/sec-forms.html#autofill-field> must expose
> that meaning except if the technology being used does not support a
> corresponding autofill meaning.
>
>
>
> Note:
>
> The set of meanings for inputs is based on HTML 5.2. It is not expected
> that every technology supports the same set, so content implemented using a
> technology that supports a subset of the HTML 5.2 autofill meanings is not
> required to provide support for meanings that are not supported by that
> technology.
>
>
>
> Note:
>
> Some technologies are expected to provide a list of meanings that is a
> superset of the HTML 5.2 set; authors are encouraged to implement support
> for additional meanings in their content in order to provide a better
> experience for users.
>
>
>
> http://rawgit.com/w3c/wcag21/1.3.4_autofill/guidelines/
> index.html#identify-common-purpose
>
>
>
> If you like it, or don’t like it, please speak up ASAP!
>
>
>
> Thanks,
>
> AWK
>
>
>
> Andrew Kirkpatrick
>
> Group Product Manager, Accessibility
>
> Adobe
>
>
>
> akirkpat@adobe.com
>
> http://twitter.com/awkawk
>