Re: Finding agreement on common purpose

Leonie,
The purpose is to use the autofill values as a reference for the types of purposes. For HTML the mapping is automatic of course, but for other technologies authors will need to ask whether there is any way specified to convey equivalent meanings.

So, if the HTML list has  purposes B, C, D
And in technology X the list has C, D
And in technology Y the list has A, B, C, E
And in technology Z the list has nothing

In HTML: Use BCD
In technology X: use CD
In technology Y, use BC
In technology Z, use nothing

In each technology, what the purpose is named doesn’t matter. What matters is whether they map or not. It would be great if “cc-name” in HTML was “cc-name” in another technology, but it could be called “credCardName” as long as it was understood from the spec that cc-name was the same as credCardName.

I expect that we will develop techniques to clarify how to meet 1.3.4 in other technologies, and clarify the mappings.

Thanks,
AWK

Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe 

akirkpat@adobe.com
http://twitter.com/awkawk


On 1/16/18, 05:20, "Léonie Watson" <tink@tink.uk> wrote:

    Is the intent of this SC for authors to use one (or more) of the HTML 
    tokens exactly as defined, or for authors to use any token that maps to 
    one of the tokens defined in HTML?
    
    
    
    On 15/01/2018 17:50, Andrew Kirkpatrick wrote:
    > What I’m hearing is that we are in general agreement that:
    > 
    >   * The HTML 5.2 autofill values for the common input purposes are ok
    >     and we will not include the purposes that are not input-related
    >   * The list can’t change over time
    >   * The purposes need to relate to the user directly, not inputs related
    >     to someone else
    > 
    > Other points that we don’t have general agreement on:
    > 
    >   * Limit this to markup
    >   * Limit this to HTML
    >   * Put the list into WCAG 2.1 vs referencing the list in a
    >     date-specific HTML version (e.g. 5.2)
    >   * Include the “for the user” aspect in the SC text vs the list
    > 
    > My best attempt on this this that I like is:
    > 
    > In content implemented using technologies with support for identifying 
    > the expected meaning for form input data, for each user-specific input 
    > field that has a purpose that maps to any of the [link]HTML 5.2 Autofill 
    > field names,  the meaning of the input field can be programmatically 
    > determined.
    > 
    > The reasons I like this relate to the items that we don’t have general 
    > agreement on:
    > 
    >  1. Not limited to any technology, as technologies like PDF and mobile
    >     frameworks and software evolve this can still be applied.
    >  2. Same as #1 above
    >  3. If we put it into our spec, we are adding to our localization
    >     burden, understanding burden, editorial burden, and will deal with
    >     the “add this to WCAG’s list” questions. Referencing the external
    >     list, stable and date-bound, makes sense to me. External standards
    >     (read EN 301 549) that incorporate WCAG 2.1 SC won’t need to worry
    >     about also adding the list because it is referenced.
    >  4. “the user” is part of the SC and it is not going to get lost as part
    >     of a separate list. And, since I’m linking to the external list, we
    >     need to add it.
    > 
    > Thanks,
    > 
    > AWK
    > 
    > Andrew Kirkpatrick
    > 
    > Group Product Manager, Accessibility
    > 
    > Adobe
    > 
    > akirkpat@adobe.com
    > 
    > https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftwitter.com%2Fawkawk&data=02%7C01%7Cakirkpat%40adobe.com%7Cb6b4b41a7e444623d2b808d55ccacc1d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636516948436877526&sdata=E8cpzMe5O11wwB0BFZpwduDktDUhbBvEAOZwQaa%2Fa%2BQ%3D&reserved=0

    > 
    > *From: *David MacDonald <david100@sympatico.ca>
    > *Date: *Monday, January 15, 2018 at 12:25
    > *To: *Alastair Campbell <acampbell@nomensa.com>
    > *Cc: *CAE-Vanderhe <gregg@raisingthefloor.org>, "Abma, J.D. (Jake)" 
    > <Jake.Abma@ing.nl>, Andrew Kirkpatrick <akirkpat@adobe.com>, 
    > "lisa.seeman@zoho.com" <lisa.seeman@zoho.com>, WCAG <w3c-wai-gl@w3.org>, 
    > Amihai Miron <amihai@user1st.com>
    > *Subject: *Re: Dealy in "Common Purposes"
    > 
    > Hi Alastair
    > 
    >  > With it focusing on HTML’s autofill attributes, there has been 
    > widespread browser support for years
    > 
    > Yes absolutely... further in
    > 
    > ​my
    > 
    >   email I suggested that we consider limiting the SC to HTML.
    > 
    > ​With each of Gregg's questions the only clear answer I was able to come 
    > up with was HTML autofill.​ However, Léonie is making a good case 
    > against referencing HTML directly and sticking with our list in the 
    > spec... I think Lisa would rather also prefer our list instead of 
    > referencing HMTL 5.2 ... so ...
    > 
    > Lisa
    > 
    > I would like to see a more robust answer to Gregg's questions other than 
    > implementations are in place and coming... so far I haven't seen an 
    > explanation of how this will work, and the implementations I've seen 
    > seem to be general personalization widgets rather than an implementation 
    > of a set of form fields with a mapping functionality back to our common 
    > purposes...
    > 
    > Here are Gregg's questions:
    > 
    > =====
    > 
    >   how are different languages and different taxonomies being handled?
    > 
    > how does the AT find the mapping of new terms back to the definitions in 
    > WCAG?
    > 
    > ·how does AT know the format of the map?
    > 
    > ·it is machine readable?
    > 
    > ·how does the AT find that map?
    > 
    > =====
    > 
    > Are you saying
    > 
    > schema
    > 
    > ​,​
    > 
    > microdata
    > 
    > ​,​
    > 
    >   COGA attributes will all map back to our numbered list
    > 
    > ​ in these mapping documents that sit in the AT? If there are currently 
    > no implementations of this, is it reasonable to at least provide a step 
    > by step description of how it will work once implemented.
    > 
    > 
    > Cheers,
    > David MacDonald
    > 
    > *Can**Adapt**Solutions Inc.*
    > 
    > Tel:  613.235.4902
    > 
    > LinkedIn
    > <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.linkedin.com%2Fin%2Fdavidmacdonald100&data=02%7C01%7Cakirkpat%40adobe.com%7C0592f609a08942953cf808d55c3ceb76%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636516339077263984&sdata=WRXOBqloqBrswc94U1ONt5%2F49bvn20rHHYAaBT3Mkio%3D&reserved=0>
    > 
    > twitter.com/davidmacd 
    > <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftwitter.com%2Fdavidmacd&data=02%7C01%7Cakirkpat%40adobe.com%7C0592f609a08942953cf808d55c3ceb76%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636516339077263984&sdata=kC9KmcGh6IRtN5wVoLzpX6miG5rId7I8lN1u7BdVLtg%3D&reserved=0>
    > 
    > GitHub 
    > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FDavidMacDonald&data=02%7C01%7Cakirkpat%40adobe.com%7C0592f609a08942953cf808d55c3ceb76%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636516339077263984&sdata=I1Uxffq2csz%2FQbYD%2B6iskRfkZkJWvu2EYN1llqtlbRA%3D&reserved=0>
    > 
    > https://na01.safelinks.protection.outlook.com/?url=www.Can-Adapt.com&data=02%7C01%7Cakirkpat%40adobe.com%7Cb6b4b41a7e444623d2b808d55ccacc1d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636516948436877526&sdata=Ons1duKRWwmpOkdsbNX2%2BKL1VC3RrULP1XuSFXZghyo%3D&reserved=0 
    > <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.can-adapt.com%2F&data=02%7C01%7Cakirkpat%40adobe.com%7C0592f609a08942953cf808d55c3ceb76%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636516339077263984&sdata=xUstg6t4u63kO9B5u3jxA9PjzgLWPOuBrO6R2LDI%2BXE%3D&reserved=0>
    > 
    > /  Adapting the web to *all* users/
    > 
    > /            Including those with disabilities/
    > 
    > If you are not the intended recipient, please review our privacy policy 
    > <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.davidmacd.com%2Fdisclaimer.html&data=02%7C01%7Cakirkpat%40adobe.com%7C0592f609a08942953cf808d55c3ceb76%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636516339077263984&sdata=Yfel9lmu92Kav5LOuwSxD410uDtvAJGbku%2F%2FuLM2tIg%3D&reserved=0>
    > 
    > On Mon, Jan 15, 2018 at 4:41 AM, Alastair Campbell 
    > <acampbell@nomensa.com <mailto:acampbell@nomensa.com>> wrote:
    > 
    >     *> *I share Gregg's concerns about the speculative nature of an SC
    >     that has no existing AT to make use of it
    > 
    >     Huh? With it focusing on HTML’s autofill attributes, there has been
    >     widespread browser support for years:
    > 
    >     https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcaniuse.com%2F%23search%3Dautofil&data=02%7C01%7Cakirkpat%40adobe.com%7Cb6b4b41a7e444623d2b808d55ccacc1d%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636516948436877526&sdata=ZprjQGXJeuy44gABgCCpVMvWV4af%2F5VfBZ0v75Vpf54%3D&reserved=0

    >     <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcaniuse.com%2F%23search%3Dautofil&data=02%7C01%7Cakirkpat%40adobe.com%7C0592f609a08942953cf808d55c3ceb76%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636516339077263984&sdata=moiMm4vKZuW73WknjxWdn56CFeE5TMtT1V4v6WJ0VGA%3D&reserved=0>
    > 
    > 
    >     Lisa also posted about a couple user-agent side implementations of
    >     the meta-data aspects, and 5 sites that are or will be using the
    >     more extended set now.
    > 
    >     Microdata is also standardised, but we seem to have dropped the
    >     non-autofil purposes, so I’ll stop there.
    > 
    >     -Alastair
    > 
    
    -- 
    @LeonieWatson @tink@toot.cafe Carpe diem

Received on Tuesday, 16 January 2018 13:45:51 UTC