Re: Possible wording for 1.3.4?

I also +1 the technology agnostic version Jake, Alistair, David, and Leonie
are getting at....

I greatly prefer this much easier to read SC text - and if we're building
the list to only include user related / autofill ones, we can address that
aspect in the list and/or the Understanding doc.

-Marc

On Mon, Jan 15, 2018 at 8:46 AM, Katie Haritos-Shea <ryladog@gmail.com>
wrote:

> +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
>>
>