- From: David MacDonald <david100@sympatico.ca>
- Date: Mon, 15 Jan 2018 16:50:04 -0500
- To: Andrew Kirkpatrick <akirkpat@adobe.com>, "lisa.seeman" <lisa.seeman@zoho.com>
- Cc: Marc Johlic <marc.johlic@gmail.com>, "w3c-waI-gl@w3. org" <w3c-wai-gl@w3.org>
- Message-ID: <CAAdDpDYcmhzKHtWUhfvkNJ_A0u0TxFhd4XNHDSQ+P+X3=a+RpA@mail.gmail.com>
following up on that ... I thought a PDF form with a tooltip (accessible name) of First Name would meet this. Cheers, David MacDonald *Can**Adapt* *Solutions Inc.* Tel: 613.235.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 Mon, Jan 15, 2018 at 4:47 PM, David MacDonald <david100@sympatico.ca> wrote: > > I’m using a PDF form with “first name” as the meaning, I won’t have a > way to include the meaning since there is no analog to the autofill > properties. > > I have to admit I'm confused at the different ways to meet this SC... I > understood from calls with Lisa and John when we were on the sub group for > this SC that having an Accessible Name that mapped to the purpose, would > pass... > > In other words. > > <label for="p1">First Name</label> > <input ... id="p1"> > > would pass this because it had a programmatically determinable purpose > even though that purpose was found in the ACCNAME and not using the > autofill properties. > > 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 Mon, Jan 15, 2018 at 4:16 PM, Andrew Kirkpatrick <akirkpat@adobe.com> > wrote: > >> I’m worried about people feeling that this says that all technologies >> need to have all of these properties. >> >> >> >> If I’m using a PDF form with “first name” as the meaning, I won’t have a >> way to include the meaning since there is no analog to the autofill >> properties. That’s the reason for the “In content implemented using >> technologies with support for identifying the expected meaning for form >> input data”. >> >> >> >> Thanks, >> >> AWK >> >> >> >> Andrew Kirkpatrick >> >> Group Product Manager, Accessibility >> >> Adobe >> >> >> >> akirkpat@adobe.com >> >> http://twitter.com/awkawk >> >> >> >> *From: *Marc Johlic <marc.johlic@gmail.com> >> *Date: *Monday, January 15, 2018 at 15:14 >> *To: *Andrew Kirkpatrick <akirkpat@adobe.com> >> *Cc: *WCAG <w3c-wai-gl@w3.org> >> *Subject: *Re: Finding agreement on common purpose >> >> >> >> Hi Andrew, >> >> >> >> OK, I could +1 this - and your bullet #3 makes sense. But if possible I >> would still like to be able to simplify the language and get it somewhere >> closer to what Jake was proposing. Would something like this be possible, >> or do you think too much is lost by dropping the extra wording? >> >> >> >> *Proposed*: The meaning of user-specific input fields that map to any >> of the [link]HTML 5.2 Autofill field names can be programmatically >> determined. >> >> >> >> >> >> I think any questions around technologies that support identifying >> meaning could be sorted out in the Understanding doc. I would just like >> the SC(s) to be as easy to parse as possible. >> >> >> >> -Marc >> >> >> >> On Mon, Jan 15, 2018 at 12:50 PM, Andrew Kirkpatrick <akirkpat@adobe.com> >> 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 >> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftwitter.com%2Fawkawk&data=02%7C01%7Cakirkpat%40adobe.com%7Ce0c6ec5f88a14ff9b2e508d55c54a528%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636516440983980792&sdata=9mYQv1d6UYDw190Qz8j06SsGRzJ4eoFotbfv3y0bx7g%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 <(613)%20235-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> >> 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 >> >> >> >> >> > >
Received on Monday, 15 January 2018 21:50:29 UTC