- From: Joshue O Connor - InterAccess <josh@interaccess.ie>
- Date: Tue, 16 Jan 2018 10:34:07 +0000
- To: tink@tink.uk, "Andrew Kirkpatrick" <akirkpat@adobe.com>, "w3c-waI-gl@w3. org" <w3c-wai-gl@w3.org>
------ Original Message ------ From: "Léonie Watson" <tink@tink.uk> [...] >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? Thanks Leonie - My understanding is that the intent is (for now) authors to use the HTML tokens that come from the autofill values that can effectively map to a 'common purpose'. There have been many conversations about 'rolling your own' schema etc but for now to get the ball rolling we want to leverage/reference the HTML 5.2 autofill values to help developers portray the intent or purpose of their widgets. HTH Josh > > > > >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 >> >>http://twitter.com/awkawk >> >>*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> >> >>www.Can-Adapt.com >><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://caniuse.com/#search=autofil >> >><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 10:37:44 UTC