Re: Finding agreement on common purpose

I am not agreeing to remove any content unless I understand why.It makes no sense to me. we have had a lot of positive comments, we can easily answer any negative comments  and are getting very close to flying though CR


In any case , having the Sc labelled at risk means that we can remove any item that does not have enough AT support im march.
All we should be doing is clearly setting what the bar is for At support before the end of CS.

All the best

Lisa Seeman

LinkedIn, Twitter





---- On Mon, 15 Jan 2018 19:59:17 +0200 Andrew Kirkpatrick<akirkpat@adobe.com> wrote ---- 

      Sure, “general agreement” isn’t unanimity. If we were unanimous we’d be done now. ☺
  
   Thanks,
 
  AWK
 
   
 
  Andrew Kirkpatrick
 
  Group Product Manager, Accessibility
 
  Adobe 
 
   
 
  akirkpat@adobe.com
 
 
 http://twitter.com/awkawk
  
  From: "White, Jason J" <jjwhite@ets.org>
 Date: Monday, January 15, 2018 at 12:52
 To: Andrew Kirkpatrick <akirkpat@adobe.com>, WCAG <w3c-wai-gl@w3.org>
 Subject: RE: Finding agreement on common purpose
 
   
 
 I’m not party to any “general agreement” on there being a normative list, including one derived from HTML 5.2.
  
   From: Andrew Kirkpatrick [mailto:akirkpat@adobe.com] 
 Sent: Monday, January 15, 2018 12:50 PM
 To: w3c-waI-gl@w3. org <w3c-wai-gl@w3.org>
 Subject: Finding agreement on common purpose
 Importance: High
 
 
  
 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:
  Not limited to any technology, as technologies like PDF and mobile frameworks and software evolve this can still be applied.
Same as #1 above
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.
“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%7C779aef00d4c0440539de08d55c40cd0c%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636516355755382876&sdata=gnhIza5y36fLFn0wI0%2BAaTa3nEKeNCRzk4PAcp%2FfiCI%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
  
 CanAdapt Solutions Inc.
 Tel:  613.235.4902
 LinkedIn 
 
 twitter.com/davidmacd
 GitHub
 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
 
 
 
 
 
 
 
  
  On Mon, Jan 15, 2018 at 4:41 AM, Alastair Campbell <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%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
 
 
 
 
  
  
 
  
   
 This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited.
  
 Thank you for your compliance.