Re: Possible wording for 1.3.4?

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