Re: Possible wording for 1.3.4?

+1 to the technology agnostic version Jake, Alistair and David are getting
at....

On Jan 15, 2018 7:56 AM, "John Foliot" <john.foliot@deque.com> wrote:

> This has been an active thread. I have proposed previously:
>
>
>    1. either provide the "list" as part of the normative text for a new
>    SC, or, alternatively point to a "locked-down" or milestone release of an
>    external specification's list. [I'm ambivalent about which method we choose
>    - what is critical is that it is versioned or locked down, and not
>    connected to a "Living Standard". My preference would be to include the
>    list as part of our spec, to avoid any potential confusion.]
>
>    2. Missing from Jake's (and Alastair's) proposal is the caveat text I
>    had previously suggested (that David agreed with) that stated:
>
>    *From the HTML 5 Recommendation: *
>    *    "Some fields correspond to subparts of other fields; for example,
>    a credit card expiry date can be expressed as one field giving both the
>    month and year of expiry ("cc-exp"), or as two fields, one giving the month
>    ("cc-exp-month") and one the year ("cc-exp-year"). In such cases, the names
>    of the broader fields cover multiple rows, in which the narrower fields are
>    defined.*
>
> *     Generally, authors are encouraged to use the broader fields rather
>    than the narrower fields, as the narrower fields tend to expose Western
>    biases. For example, while it is common in some Western cultures to have a
>    given name and a family name, in that order (and thus often referred to as
>    a first name and a surname), many cultures put the family name first and
>    the given name second, and many others simply have one name (a mononym).
>    Having a single field is therefore more flexible."*
>
> *NOTE: Should authors decide to use more specific input field (e.g. using
>    first name and family name inputs), authors are required to use the
>    equivalent and corresponding values found in the HTML 5
>    specification: https://www.w3.org/TR/html52/sec-forms.html#sec-autofill
>    <https://www.w3.org/TR/html52/sec-forms.html#sec-autofill>*
>
>    The quoted text can certainly go into the Understanding document, but
>    the highlighted NOTE should be part of the normative text.
>
>    3. Jake wrote: "Conformance is at a particular date, so it’s the
>    standard at that time." - while I agree with this in principle, we need to
>    update our section on Conformance claims to include this point. While "the
>    standard of the time" will be WCAG 2.x (noted in the claim, per our
>    guidance), we currently do not also list dependencies (WCAG 2.x + ARAI 1.1
>    + HTML 5.2 + CSS 3 + SVG 1.1), and so Jake, which standard at what time?...
>
>    It is for this reason that I'd prefer to see us list the input tokens
>    directly, either in the SC, or as part of a Glossary entry (or equiv.), as
>    opposed to pointing elsewhere.
>
> JF
>
> On Sun, Jan 14, 2018 at 4:29 PM, David MacDonald <david100@sympatico.ca>
> wrote:
>
>> However, I would not say "types" because it can be confused wth the
>> "type" attribute if the <input>... in which case it might be something like
>> this.
>>
>> “For the *list of common input fields* that are supported by the
>> technology for specifying the purpose of specific fields, the purpose can
>> be programmatically determined.”
>>
>> Cheers,
>> David MacDonald
>>
>>
>>
>> *Can**Adapt* *Solutions Inc.*
>>
>> Tel:  613.235.4902 <(613)%20235-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 Sun, Jan 14, 2018 at 5:17 PM, David MacDonald <david100@sympatico.ca>
>> wrote:
>>
>>> I could live with it
>>>
>>> Cheers,
>>> David MacDonald
>>>
>>>
>>>
>>> *Can**Adapt* *Solutions Inc.*
>>>
>>> Tel:  613.235.4902 <(613)%20235-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 Sun, Jan 14, 2018 at 4:32 PM, Alastair Campbell <
>>> acampbell@nomensa.com> wrote:
>>>
>>>> Most of this thread happened after-hours for me, coming back and
>>>> reviewing the whole thing my preference would be Jake’s version because it
>>>> creates an Appropriate separation from the technology by using a listing of
>>>> purposes.
>>>>
>>>>
>>>>
>>>> If WCAG specifies the list of purposes rather than linking to HTML5.x
>>>> directly, it:
>>>>
>>>>    - Doesn’t have to include *all* of the HTML ones, minimising the
>>>>    author burden to the most relevant ones. Also, if HTML adds more of them,
>>>>    they would not be included automatically.
>>>>
>>>>    - Could add techniques for aria/coga personalisation at a later
>>>>    stage with less fuss, transitioning from or extending the HTML list more
>>>>    easily.
>>>>
>>>>    - Can put the ‘for this user’ aspect in the list rather than the SC
>>>>    text.  (In my mind the ‘purpose’ for most of the fields is to apply to the
>>>>    user of the website only, so shouldn’t apply when doing it on someone
>>>>    else’s behalf.)
>>>>
>>>>
>>>>
>>>> Cheers,
>>>>
>>>>
>>>>
>>>> -Alastair
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> *From:* Abma, J.D. (Jake)
>>>>
>>>>
>>>>
>>>> *My suggestion for "Support Common Input Fields":*
>>>>
>>>>
>>>>
>>>> “For the *list of common input fields* that are supported by the
>>>> technology for specifying the purpose of specific types, the purpose can be
>>>> programmatically determined.”
>>>>
>>>>
>>>>
>>>> Note: It is not expected that every technology supports the same list.
>>>> Content implemented using a technology that supports a subset are  excepted
>>>> for fields that are not supported while a technology that supports a
>>>> superset are encouraged to implement additional meanings.
>>>>
>>>
>>>
>>
>
>
> --
> John Foliot
> Principal Accessibility Strategist
> Deque Systems Inc.
> john.foliot@deque.com
>
> Advancing the mission of digital accessibility and inclusion
>