Re: Possible wording for 1.3.4?

The normative language for this SC feels too technology specific. One of 
the goals of WCAG 2.0 was to be technology agnostic, and the one time it 
notably failed (Guideline 2.1) has caused us no end of problems since 
touch emerged.

The tokens defined in HTML5.2 seem to fulfil the purpose, so I suggest 
we take them and make them part of WCAG2.1 itself. That way we can make 
the SC language technology agnostic, without losing any of the benefit 
derived from referencing the HTML tokens.



Léonie
On 15/01/2018 12:55, John Foliot 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 
> <mailto: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 <tel:(613)%20235-4902>
> 
>     LinkedIn
>     <http://www.linkedin.com/in/davidmacdonald100>
> 
>     twitter.com/davidmacd <http://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 <mailto:david100@sympatico.ca>> wrote:
> 
>         I could live with it
> 
>         Cheers,
>         David MacDonald
> 
>         *Can**Adapt**Solutions Inc.*
> 
>         Tel: 613.235.4902 <tel:(613)%20235-4902>
> 
>         LinkedIn
>         <http://www.linkedin.com/in/davidmacdonald100>
> 
>         twitter.com/davidmacd <http://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 <mailto: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 <mailto:john.foliot@deque.com>
> 
> Advancing the mission of digital accessibility and inclusion

-- 
@LeonieWatson @tink@toot.cafe Carpe diem

Received on Monday, 15 January 2018 13:45:11 UTC