- From: John Foliot <john.foliot@deque.com>
- Date: Fri, 12 Jan 2018 15:56:31 -0600
- To: Michael Gower <michael.gower@ca.ibm.com>
- Cc: Andrew Kirkpatrick <akirkpat@adobe.com>, "Abma, J.D. (Jake)" <Jake.Abma@ing.nl>, "White, Jason J" <jjwhite@ets.org>, Marc Johlic <marc.johlic@gmail.com>, WCAG <w3c-wai-gl@w3.org>
- Message-ID: <CAKdCpxzkz-J1epv8oiYvnOBZj7JWPqqGVu5yw=pEg29cvtFSWg@mail.gmail.com>
> John, the testing is determined at the technique level, right? Well, I know a lot of entities approach it like that, but I'd push back and say that testing is done at the "Functional Outcomes" level, as it clearly states that Techniques (themselves non-normative) are but *common* ways of meeting success or failure, but not the definitive way of doing so (nor are the techniques "complete", and in fact the WG welcomes new Technique submissions as part of our charter). Here at Deque, we have an internal methodology we call the Deque Way, which uses a mix of pattern matching & 'Techniques testing' (both mechanically via aXe, as well as via human testing), as well as a "Sanity Check" piece-part that effectively asks the evaluator "Can the user accomplish what needs to be accomplished on this page? Has the functional requirement been met?" Our testing methodology presumes we've covered all the bases as far as techniques are concerned, but always ends by asking - "yes, but does it work for the user?" (I'll spin you a strawman: currently EXIF data does not have a field for text alternative, but say that spec changed, and started allowing that. A website *could* use a scripted method of surfacing that value and exposing it to the end user/Accessibility API, all the while not *mandating the author* to use either "@aria-label, @aria-labelledby, @alt, or @title + a text value" in their authored code: they use the scripted solution instead, and the script pipes the value directly to the AAPI - it's a stretch, I know, but hopefully you get the point: it's the functional outcome that counts, not the Technique.) > So if someone is using a sufficient technique that specifies html5 autofill, the testing is going to be based on that. Well, the first test would likely look for the presence of autofill tokens, sure, but if those tokens weren't there, but the website had a different method of achieving the functional outcome, our testing methodology would catch and note that too, and so *potentially* a page could conform to this requirement even if it *didn't* use the autofill tokens. That's because we don't just test for Techniques specifically, we test for outcomes. > Other technologies may have a different range of specified values and they would similarly have testing based on that technique. So the technology, through the Sufficient Techniques, will determine the scope for testing. I disagree: you seem to be assuming that the Sufficient Techniques would be complete, and address all potential solutions, which is factually incorrect, and even the Techniques document warns as much: Techniques are informative—that means they are not required. The basis for determining conformance to WCAG 2.0 is the success criteria from the WCAG 2.0 standard <http://www.w3.org/TR/WCAG20/>—not the techniques.. *Note: *W3C cautions against requiring W3C's sufficient techniques. The only thing that should be required is meeting the WCAG 2.0 success criteria. (source: https://www.w3.org/TR/WCAG20-TECHS/intro.html ) Specific to this SC, the suggestion is to point to the autofill values "list" as the starting point of input fields that require support, with an exception clause that "excuses" technologies that cannot support the full list today. The SC doesn't say *how* to do it, it just says what you must deliver, and the Techniques section offers *one* way of doing so (in part to show it can be done). JF On Fri, Jan 12, 2018 at 3:11 PM, Michael Gower <michael.gower@ca.ibm.com> wrote: > John, the testing is determined at the technique level, right? So if > someone is using a sufficient technique that specifies html5 autofill, the > testing is going to be based on that. Other technologies may have a > different range of specified values and they would similarly have testing > based on that technique. So the technology, through the Sufficient > Techniques, will determine the scope for testing. > > Michael Gower > IBM Accessibility > Research > > 1803 Douglas Street, Victoria, BC > <https://maps.google.com/?q=1803+Douglas+Street,+Victoria,+BC+%C2%A0V8T+5C3&entry=gmail&source=g> > V8T 5C3 > <https://maps.google.com/?q=1803+Douglas+Street,+Victoria,+BC+%C2%A0V8T+5C3&entry=gmail&source=g> > gowerm@ca.ibm.com > voice: (250) 220-1146 * cel: (250) 661-0098 * fax: (250) 220-8034 > > > > From: John Foliot <john.foliot@deque.com> > To: "White, Jason J" <jjwhite@ets.org> > Cc: "Abma, J.D. (Jake)" <Jake.Abma@ing.nl>, Andrew Kirkpatrick < > akirkpat@adobe.com>, Michael Gower <michael.gower@ca.ibm.com>, Marc > Johlic <marc.johlic@gmail.com>, WCAG <w3c-wai-gl@w3.org> > Date: 2018-01-12 12:31 PM > Subject: Re: Possible wording for 1.3.4? > ------------------------------ > > > > Jason, > > Your point is taken, but we also need, as Alex Li noted, to know when to > 'stop' testing (today and in 3 years time), and so we need to reference > that "list" somehow. > > Additionally, unless we change the normative requirements for Conformance > statements to also reference external dependant specifications, a dated > conformance claim that purports to meet a WCAG 2.1 SC that has a "living > standard" component to it means that the conformance claim *could* become > invalid if the supporting non-milestoned spec changes - something we need > to acknowledge and "protect against" for legal reasons. (Having our > specification be the de facto legal requirements is a double-edged sword > unfortunately). > > JF > > On Fri, Jan 12, 2018 at 2:19 PM, White, Jason J <*jjwhite@ets.org* > <jjwhite@ets.org>> wrote: > I think efforts to insist on a fixed and normative list of terms or > concepts stated in the WCAG specification would move us away from the > notion of technology-independent guidelines that are designed to apply to > changing technical capabilities over time, as exemplified by 1.3.1 and > 4.1.2. I’m not supportive of this direction of development for WCAG. > > *From:* Abma, J.D. (Jake) [mailto:*Jake.Abma@ing.nl* <Jake.Abma@ing.nl>] > *Sent:* Friday, January 12, 2018 3:15 PM > *To:* 'Andrew Kirkpatrick' <*akirkpat@adobe.com* <akirkpat@adobe.com>>; > 'John Foliot' <*john.foliot@deque.com* <john.foliot@deque.com>>; White, > Jason J <*jjwhite@ets.org* <jjwhite@ets.org>> > *Cc:* Michael Gower <*michael.gower@ca.ibm.com* <michael.gower@ca.ibm.com>>; > Marc Johlic <*marc.johlic@gmail.com* <marc.johlic@gmail.com>>; WCAG < > *w3c-wai-gl@w3.org* <w3c-wai-gl@w3.org>> > *Subject:* RE: Possible wording for 1.3.4? > > I see and get your point, doesn’t make it more easy… Jbut this is also > the same for 4.1.2 as mentioned before where we judge new components on new > roles, states and values when they become conventional. > > > Or do we have another case with 4.1.2 except that we would like a fixed > minimum list to start with? > > (mind blowing..) > > *From:* Andrew Kirkpatrick [*mailto:akirkpat@adobe.com* > <akirkpat@adobe.com>] > *Sent:* vrijdag 12 januari 2018 21:08 > *To:* Abma, J.D. (Jake) <*Jake.Abma@ing.nl* <Jake.Abma@ing.nl>>; 'John > Foliot' <*john.foliot@deque.com* <john.foliot@deque.com>>; White, Jason J > <*jjwhite@ets.org* <jjwhite@ets.org>> > *Cc:* Michael Gower <*michael.gower@ca.ibm.com* <michael.gower@ca.ibm.com>>; > Marc Johlic <*marc.johlic@gmail.com* <marc.johlic@gmail.com>>; WCAG < > *w3c-wai-gl@w3.org* <w3c-wai-gl@w3.org>> > *Subject:* Re: Possible wording for 1.3.4? > > So the way to make it more stable is to allow the set of terms to change > in technologies that change even faster than our spec does? I’m not > following the reasoning… > > Thanks, > AWK > > Andrew Kirkpatrick > Group Product Manager, Accessibility > Adobe > > *akirkpat@adobe.com* <akirkpat@adobe.com> > *http://twitter.com/awkawk* > <https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Ftwitter.com-252Fawkawk-26data-3D02-257C01-257Cjjwhite-2540ets.org-257C32df36e31d2845dc5d4e08d559f9192c-257C0ba6e9b760b34fae92f37e6ddd9e9b65-257C0-257C0-257C636513848791103419-26sdata-3DDX-252BFa0plJO-252B855uaQdomUJN-252FLuRvTgyta3e0jNznkhw-253D-26reserved-3D0&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=_9rqR3xSCWQUlv9VpOcJwkP7H0XWQXmxeMmqQl6Fikc&m=jmjx1dk6fxGbpvkZUftO7iUtvQwgWdI2Pn5pJlzK394&s=gL4xsoG7FzwaB_JKU3cF8-iafBWoQ5StScPfmBjiJGA&e=> > > *From: *"Abma, J.D. (Jake)" <*Jake.Abma@ing.nl* <Jake.Abma@ing.nl>> > *Date: *Friday, January 12, 2018 at 15:01 > *To: *Andrew Kirkpatrick <*akirkpat@adobe.com* <akirkpat@adobe.com>>, > John Foliot <*john.foliot@deque.com* <john.foliot@deque.com>>, "White, > Jason J" <*jjwhite@ets.org* <jjwhite@ets.org>> > *Cc: *Michael Gower <*michael.gower@ca.ibm.com* <michael.gower@ca.ibm.com>>, > Marc Johlic <*marc.johlic@gmail.com* <marc.johlic@gmail.com>>, WCAG < > *w3c-wai-gl@w3.org* <w3c-wai-gl@w3.org>> > *Subject: *RE: Possible wording for 1.3.4? > > That could be true but I think we would like our SC as stable as possible > and not change with every new release! > > *From:* Andrew Kirkpatrick [*mailto:akirkpat@adobe.com* > <akirkpat@adobe.com>] > *Sent:* vrijdag 12 januari 2018 21:00 > *To:* Abma, J.D. (Jake) <*Jake.Abma@ing.nl* <Jake.Abma@ing.nl>>; 'John > Foliot' <*john.foliot@deque.com* <john.foliot@deque.com>>; White, Jason J > <*jjwhite@ets.org* <jjwhite@ets.org>> > *Cc:* Michael Gower <*michael.gower@ca.ibm.com* <michael.gower@ca.ibm.com>>; > Marc Johlic <*marc.johlic@gmail.com* <marc.johlic@gmail.com>>; WCAG < > *w3c-wai-gl@w3.org* <w3c-wai-gl@w3.org>> > *Subject:* Re: Possible wording for 1.3.4? > > Don’t forget that like HTML we are planning to update WCAG more regularly > also. > > Thanks, > AWK > > Andrew Kirkpatrick > Group Product Manager, Accessibility > Adobe > > *akirkpat@adobe.com* <akirkpat@adobe.com> > *http://twitter.com/awkawk* > <https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Ftwitter.com-252Fawkawk-26data-3D02-257C01-257Cakirkpat-2540adobe.com-257Cdf107cfb7b3b4e1453e508d559f75421-257Cfa7b1b5a7b34438794aed2c178decee1-257C0-257C0-257C636513841194260566-26sdata-3DX-252BtKbJHvJQ5hp58ajm-252BV1kRnBx-252FRoz38vHFWTS5ZGWU-253D-26reserved-3D0&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=_9rqR3xSCWQUlv9VpOcJwkP7H0XWQXmxeMmqQl6Fikc&m=jmjx1dk6fxGbpvkZUftO7iUtvQwgWdI2Pn5pJlzK394&s=OdLptNWJ0zPu4GXIVJt_PAhTZ0eBcTm6sudAlDhbjGo&e=> > > *From: *"Abma, J.D. (Jake)" <*Jake.Abma@ing.nl* <Jake.Abma@ing.nl>> > *Date: *Friday, January 12, 2018 at 14:57 > *To: *John Foliot <*john.foliot@deque.com* <john.foliot@deque.com>>, > "White, Jason J" <*jjwhite@ets.org* <jjwhite@ets.org>> > *Cc: *Michael Gower <*michael.gower@ca.ibm.com* <michael.gower@ca.ibm.com>>, > Andrew Kirkpatrick <*akirkpat@adobe.com* <akirkpat@adobe.com>>, Marc > Johlic <*marc.johlic@gmail.com* <marc.johlic@gmail.com>>, WCAG < > *w3c-wai-gl@w3.org* <w3c-wai-gl@w3.org>> > *Subject: *RE: Possible wording for 1.3.4? > > > Looking at it from a bit more distance I just have a gut feeling we do > need a fixed minimum list, I guess most of us agree. > But also it feels not right to point to HTML 5.2 although it is the best > choice for this moment because it may be this moment only. > Referring to old/outdated specs (5.2 will become outdated) are weakening > this SC day by day while we would like it to strengthen in time. > > Can’t we add something like “the latest version of the HTML spec at the > time of building / testing”. > This way you’ll judge it in the moment of time and this will create growth > possibilities. > > *From:* John Foliot [*mailto:john.foliot@deque.com* > <john.foliot@deque.com>] > *Sent:* vrijdag 12 januari 2018 20:14 > *To:* White, Jason J <*jjwhite@ets.org* <jjwhite@ets.org>> > *Cc:* Michael Gower <*michael.gower@ca.ibm.com* <michael.gower@ca.ibm.com>>; > Andrew Kirkpatrick <*akirkpat@adobe.com* <akirkpat@adobe.com>>; Marc > Johlic <*marc.johlic@gmail.com* <marc.johlic@gmail.com>>; WCAG < > *w3c-wai-gl@w3.org* <w3c-wai-gl@w3.org>> > *Subject:* Re: Possible wording for 1.3.4? > > Hi Jason, > > I think I will have to agree to disagree. One way of avoiding this new SC > altogether could be to state that your conformance claim is based on HTML > 4.1 and thus "not supported". We need a fixed normative minimum list, and > whether we point to the list in HTML 5.2, or include that list directly in > our Recommendation I still maintain that without the fixed and stable list, > it will be very difficult to test and make assertions toward. As Alex Li > noted on the call the other day, testers will also need to know when to > 'stop' testing (i.e. when they reach the end of the list), and that list > cannot be changing over time. > > JF > > On Fri, Jan 12, 2018 at 1:05 PM, White, Jason J <*jjwhite@ets.org* > <jjwhite@ets.org>> wrote: > You can handle the conformance by specifying HTML 5.1, (substituting the > appropriate version) in the “list of Web content technologies relied upon” > in any conformance claim. Using HTML in a “living standard” way doesn’t > require you to omit a version number – or, for that matter, a range of > version numbers – from any assertion of conformance as of a given date. > > Thus, I think that without an explicit list of form fields, a success > criterion along the lines that I wrote in response to Andrew’s proposal for > 1.3.4 remains reliably testable. > > > *From:* John Foliot [mailto:*john.foliot@deque.com* > <john.foliot@deque.com>] > *Sent:* Friday, January 12, 2018 1:55 PM > *To:* Michael Gower <*michael.gower@ca.ibm.com* <michael.gower@ca.ibm.com> > > > *Cc:* Andrew Kirkpatrick <*akirkpat@adobe.com* <akirkpat@adobe.com>>; > White, Jason J <*jjwhite@ets.org* <jjwhite@ets.org>>; Marc Johlic < > *marc.johlic@gmail.com* <marc.johlic@gmail.com>>; WCAG < > *w3c-wai-gl@w3.org* <w3c-wai-gl@w3.org>> > *Subject:* Re: Possible wording for 1.3.4? > > > AWK: If I use HTML in a “living standard” way today and include all of > the appropriate meanings/purposes that are defined, but then HTML adds > meanings, how will I be able to handle my conformance? I haven’t changed > the site, but the list changes. We can’t leave that open-ended. > > +1! > > > > MG: If something gets deprecated in 5.2, my page based on 5.1 is going > to continue to use that deprecated element until such time as I update the > page. How is this different? > > Personally, think there remains a bit of a gap here regarding conformance > statements, an area WCAG 2.0 is (IMHO) a little weak on. Specifically, > we've never really talked about (that I know of) this point or idea of > dated and referenced conformance claims as we progress along the > dot-release path. I agree with your perception here, but unless we have > that documented, it is a subjective opinion (I may agree with it, but I > also believe it is still an opinion). This is also related to the other > discussion (which we've re-shelved per Andrew's request) w.r.t. the > Landmarks Failure Technique and any other new Techniques for 2.0. > > Perhaps this is an area of further discussion for the WG once we finalize > the immediate tasks in front of us? (i.e. a potential topic for a CSUN F2F > session?) > > > > AC: As per Michael’s email on the other thread: Conformance is at a > particular date, so it’s the standard at the time. > > WCAG 2.0 states: > *Required Components of a Conformance Claim* > > Conformance claims are *not required*. Authors can conform to WCAG 2.0 > without making a claim. However, if a conformance claim is made, then the > conformance claim *must* include the following information: > > 1. *Date* of the claim > > 2. *Guidelines title, version and URI *"Web Content Accessibility > Guidelines 2.0 at *http://www.w3.org/TR/2008/REC-WCAG20-20081211/* > <https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Fwww.w3.org-252FTR-252F2008-252FREC-2DWCAG20-2D20081211-252F-26data-3D02-257C01-257Cjjwhite-2540ets.org-257Cfe05ec027a98467a49b608d559edfdc6-257C0ba6e9b760b34fae92f37e6ddd9e9b65-257C0-257C0-257C636513801066872449-26sdata-3DZpx93xVQXDqw9HTyE9GgSRWOIKf1VLQhnUfV-252BNYeFFk-253D-26reserved-3D0&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=_9rqR3xSCWQUlv9VpOcJwkP7H0XWQXmxeMmqQl6Fikc&m=jmjx1dk6fxGbpvkZUftO7iUtvQwgWdI2Pn5pJlzK394&s=OsGTVCd9vsXK4E4Fyb0xPGgSr-zhxrMqZSEC-ZCD4Gg&e=> > " > > 3. *Conformance level* satisfied: (Level A, AA or AAA) > > 4. *A concise description of the Web pages*, such as a list of URIs > for which the claim is made, including whether subdomains are included in > the claim. > > *Note 1: *The Web pages may be described by list or by an expression that > describes all of the URIs included in the claim. > > *Note 2: *Web-based products that do not have a URI prior to installation > on the customer's Web site may have a statement that the product would > conform when installed. > > 5. A list of the *Web content technologies* > <https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.w3.org-252FTR-252FWCAG20-252F-2523technologydef-26data-3D02-257C01-257Cjjwhite-2540ets.org-257Cfe05ec027a98467a49b608d559edfdc6-257C0ba6e9b760b34fae92f37e6ddd9e9b65-257C0-257C0-257C636513801066872449-26sdata-3DSA13I5jXpDHxLKu7YYgib3lTFAYRWRN9nhZ2e6vYL0A-253D-26reserved-3D0&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=_9rqR3xSCWQUlv9VpOcJwkP7H0XWQXmxeMmqQl6Fikc&m=jmjx1dk6fxGbpvkZUftO7iUtvQwgWdI2Pn5pJlzK394&s=bmyPV_-nWCbjU9AaxkjfZ4Qpty_gcr7wSeeAFZySes0&e=> > *relied upon* > <https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.w3.org-252FTR-252FWCAG20-252F-2523reliedupondef-26data-3D02-257C01-257Cjjwhite-2540ets.org-257Cfe05ec027a98467a49b608d559edfdc6-257C0ba6e9b760b34fae92f37e6ddd9e9b65-257C0-257C0-257C636513801066872449-26sdata-3DNIR1-252BHwV8QgLLEwKRdV8OXUf4gEFHmzJr2SfAosldeE-253D-26reserved-3D0&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=_9rqR3xSCWQUlv9VpOcJwkP7H0XWQXmxeMmqQl6Fikc&m=jmjx1dk6fxGbpvkZUftO7iUtvQwgWdI2Pn5pJlzK394&s=eBoKKu6FzgXMX8m7iMVRCFm_nrxm4nY9nH3avWVfIu8&e=> > . > > > ...which brings us back to the 'problem' that Techniques are not "...the > standard at the time..." because they are not dated or normative or > attached to a particular version of WCAG - there is no "time" associated to > them. We can fix that problem, but it exists today. > > Likewise for any "list" that we want to 'import' from another W3C Rec. - > we need a dated and referenceable Recommendation for today, for tomorrow, > or in 2028. For conformance claims, we need "snapshots" or milestone > releases that do not change, so that they can be referenced directly in the > Claim "forever". > > > AC: This was one of the reasons that the W3C has tried to ‘version’ HTML > though, so your conformance could also reference a specific version > > Exactly. Pointing to a specific version of HTML5 allows that referenceable > feature. @gowerm, if any of these autofill values were to be deprecated > down the road, I'm willing to bet that the browsers will still support them > (unless there is a critical security issue or similar catastrophic failure > being introduced - at which point we'd likely have to amend our Rec too), > because the browsers do not want to deliberately "break" legacy content. > Meanwhile, if the list were to expand, those new additions would either be > Best Practices, or we would need to re-address the SC (or augment it > somehow) to add those new token values. > > JF > > > > > On Fri, Jan 12, 2018 at 12:12 PM, Michael Gower < > *michael.gower@ca.ibm.com* <michael.gower@ca.ibm.com>> wrote: > If something gets deprecated in 5.2, my page based on 5.1 is going to > continue to use that deprecated element until such time as I update the > page. How is this different? > > 4.1.2 does not define a spec for name, role or value. > > > Michael Gower > IBM Accessibility > Research > > *1803 Douglas Street, Victoria, BC * > <https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fmaps.google.com-252F-253Fq-253D1803-252BDouglas-252BStreet-252C-252BVictoria-252C-252BBC-252B-2525C2-2525A0V8T-252B5C3-2526entry-253Dgmail-2526source-253Dg-26data-3D02-257C01-257Cjjwhite-2540ets.org-257Cfe05ec027a98467a49b608d559edfdc6-257C0ba6e9b760b34fae92f37e6ddd9e9b65-257C0-257C0-257C636513801066872449-26sdata-3DWdwW9i-252FmE-252Br4-252FIY8CbL2eRGvp1P3DTrGfre-252B85KvANc-253D-26reserved-3D0&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=_9rqR3xSCWQUlv9VpOcJwkP7H0XWQXmxeMmqQl6Fikc&m=jmjx1dk6fxGbpvkZUftO7iUtvQwgWdI2Pn5pJlzK394&s=DCigOZMQx_oP-gjO4Qe-SCFDKFz60ulqXrceaI6o7b4&e=> > *V8T 5C3* > <https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fmaps.google.com-252F-253Fq-253D1803-252BDouglas-252BStreet-252C-252BVictoria-252C-252BBC-252B-2525C2-2525A0V8T-252B5C3-2526entry-253Dgmail-2526source-253Dg-26data-3D02-257C01-257Cjjwhite-2540ets.org-257Cfe05ec027a98467a49b608d559edfdc6-257C0ba6e9b760b34fae92f37e6ddd9e9b65-257C0-257C0-257C636513801066872449-26sdata-3DWdwW9i-252FmE-252Br4-252FIY8CbL2eRGvp1P3DTrGfre-252B85KvANc-253D-26reserved-3D0&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=_9rqR3xSCWQUlv9VpOcJwkP7H0XWQXmxeMmqQl6Fikc&m=jmjx1dk6fxGbpvkZUftO7iUtvQwgWdI2Pn5pJlzK394&s=DCigOZMQx_oP-gjO4Qe-SCFDKFz60ulqXrceaI6o7b4&e=> > *gowerm@ca.ibm.com* <gowerm@ca.ibm.com> > > voice: *(250) 220-1146* <(250)%20220-1146>* cel: *(250) 661-0098* > <(250)%20661-0098>* fax: *(250) 220-8034* <(250)%20220-8034> > > > > > From: Andrew Kirkpatrick <*akirkpat@adobe.com* <akirkpat@adobe.com> > > > To: Marc Johlic <*marc.johlic@gmail.com* <marc.johlic@gmail.com>>, > "White, Jason J" <*jjwhite@ets.org* <jjwhite@ets.org>> > Cc: WCAG <*w3c-wai-gl@w3.org* <w3c-wai-gl@w3.org>> > Date: 2018-01-12 10:05 AM > Subject: Re: Possible wording for 1.3.4? > ------------------------------ > > > > If not referenced in the SC, then the conformance can change. > > > > If I use HTML in a “living standard” way today and include all of the > appropriate meanings/purposes that are defined, but then HTML adds > meanings, how will I be able to handle my conformance? I haven’t changed > the site, but the list changes. We can’t leave that open-ended. > > > > Thanks, > > AWK > > > > Andrew Kirkpatrick > > Group Product Manager, Accessibility > > Adobe > > > > *akirkpat@adobe.com* <akirkpat@adobe.com> > > *http://twitter.com/awkawk* > <https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Ftwitter.com-252Fawkawk-26data-3D02-257C01-257Cjjwhite-2540ets.org-257Cfe05ec027a98467a49b608d559edfdc6-257C0ba6e9b760b34fae92f37e6ddd9e9b65-257C0-257C0-257C636513801066872449-26sdata-3DkWRJQWKQ5b515lhSoBWWon1ROoEDOySE-252Ff2f2f8dFwA-253D-26reserved-3D0&d=DwMFaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=_9rqR3xSCWQUlv9VpOcJwkP7H0XWQXmxeMmqQl6Fikc&m=jmjx1dk6fxGbpvkZUftO7iUtvQwgWdI2Pn5pJlzK394&s=nx5J3SLnr--B2gl988twuX9oFP2qWZ8lbHG1zflZKHg&e=> > > > > *From: *Marc Johlic <*marc.johlic@gmail.com* <marc.johlic@gmail.com>> > *Date: *Friday, January 12, 2018 at 12:58 > *To: *"White, Jason J" <*jjwhite@ets.org* <jjwhite@ets.org>> > *Cc: *Andrew Kirkpatrick <*akirkpat@adobe.com* <akirkpat@adobe.com>>, > WCAG <*w3c-wai-gl@w3.org* <w3c-wai-gl@w3.org>> > *Subject: *Re: Possible wording for 1.3.4? > > > > I agree with Jason. I like having HTML 5.2 (or any standard) for a stake > in the ground, but I think we can get around having that in the actual SC > language as Jason describes.. We can reference it in the Understanding. > > > > -Marc > > > > On Fri, Jan 12, 2018 at 12:55 PM, White, Jason J <*jjwhite@ets.org* > <jjwhite@ets.org>> wrote: > > No, I think it’s testable in that it only applies to the field types > supported by the technology being used. > > > > *From:*Andrew Kirkpatrick [mailto:*akirkpat@adobe.com* > <akirkpat@adobe.com>] > *Sent:* Friday, January 12, 2018 12:53 PM > *To:* White, Jason J <*jjwhite@ets.org* <jjwhite@ets.org>>; Marc Johlic < > *marc.johlic@gmail.com* <marc.johlic@gmail.com>>; WCAG < > *w3c-wai-gl@w3.org* <w3c-wai-gl@w3.org>> > > > *Subject:* Re: Possible wording for 1.3.4? > > > > Jason, > > My concern is that without attaching a reference to a defined list this > becomes untestable. > > > > Thanks, > > AWK > > > > Andrew Kirkpatrick > > Group Product Manager, Accessibility > > Adobe > > > > *akirkpat@adobe.com* <akirkpat@adobe.com> > > *http://twitter.com/awkawk* > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Ftwitter.com-252Fawkawk-26data-3D02-257C01-257Cakirkpat-2540adobe.com-257Cd6ddd9365f2340afe82108d559e61973-257Cfa7b1b5a7b34438794aed2c178decee1-257C0-257C0-257C636513767211470990-26sdata-3D0pLgccc5eXldfA-252BrBDpNp6nNeOYT64pJHz5ffOnTWT4-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3Djf_iaSHvJObTbx-siA1ZOg%26r%3D_9rqR3xSCWQUlv9VpOcJwkP7H0XWQXmxeMmqQl6Fikc%26m%3DjIERTA7hqsqdWVgv_Tk9IHX9WbpseUmdoVj3QrWfXGg%26s%3Di1atiYmACZynEV620J6l6fuFK7qiks6Mb4LxoQps4lc%26e%3D&data=02%7C01%7Cjjwhite%40ets.org%7Cfe05ec027a98467a49b608d559edfdc6%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636513801066872449&sdata=U%2B6Ls31roH%2FFxh9O31K7ilrJkw6VzeyPAcZBboj5TE4%3D&reserved=0> > > > > *From: *"White, Jason J" <*jjwhite@ets.org* <jjwhite@ets.org>> > *Date: *Friday, January 12, 2018 at 12:51 > *To: *Andrew Kirkpatrick <*akirkpat@adobe.com* <akirkpat@adobe.com>>, > Marc Johlic <*marc.johlic@gmail.com* <marc.johlic@gmail.com>>, WCAG < > *w3c-wai-gl@w3.org* <w3c-wai-gl@w3.org>> > *Subject: *RE: Possible wording for 1.3.4? > > > > For content implemented using technologies that support specifying the > purpose of specific types of form input fields, the purpose of each such > field of a supported type can be programmatically determined. > > > > *From:*Andrew Kirkpatrick [*mailto:akirkpat@adobe.com* > <akirkpat@adobe.com>] > *Sent:* Friday, January 12, 2018 12:29 PM > *To:* Marc Johlic <*marc.johlic@gmail.com* <marc.johlic@gmail.com>>; WCAG > <*w3c-wai-gl@w3.org* <w3c-wai-gl@w3.org>> > *Subject:* Re: Possible wording for 1.3.4? > > > > Thanks Marc. > > > > Here’s a version with further edits: > > In content implemented using technologies with support for identifying the > expected meaning for form input data, the meaning can be programmatically > determined for each user interface component that accepts user input > corresponding to the user; inputs matching a meaning provided in the *HTML > 5.2 Autofill field names* > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.w3.org-252FTR-252Fhtml52-252Fsec-2Dforms.html-2523autofill-2Dfield-26data-3D02-257C01-257Cjjwhite-2540ets.org-257C99e76206120a43d0157708d559e214d4-257C0ba6e9b760b34fae92f37e6ddd9e9b65-257C0-257C0-257C636513749899118798-26sdata-3DYIsK5eWlo1OU-252BXq-252BdOXr245xRPZEfIvd5o6LCBeCjL0-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3Djf_iaSHvJObTbx-siA1ZOg%26r%3D_9rqR3xSCWQUlv9VpOcJwkP7H0XWQXmxeMmqQl6Fikc%26m%3DjIERTA7hqsqdWVgv_Tk9IHX9WbpseUmdoVj3QrWfXGg%26s%3DuFjRO94bHtuTYc3ZqqNn259qtZiCSzfWRAxSY7Y_FBg%26e%3D&data=02%7C01%7Cjjwhite%40ets.org%7Cfe05ec027a98467a49b608d559edfdc6%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636513801066872449&sdata=%2F%2B9U66iP8cNsQjZbv39Jq7%2F9d1elGzB5demYSoQGT%2FQ%3D&reserved=0>must > expose that meaning except if the technology being used does not support a > corresponding autofill meaning. > > > > What do people think? > > > > Thanks, > > AWK > > > > Andrew Kirkpatrick > > Group Product Manager, Accessibility > > Adobe > > > > *akirkpat@adobe.com* <akirkpat@adobe.com> > > *http://twitter.com/awkawk* > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Ftwitter.com-252Fawkawk-26data-3D02-257C01-257Cakirkpat-2540adobe.com-257Ce6416acb90d34228707808d559e5143a-257Cfa7b1b5a7b34438794aed2c178decee1-257C0-257C0-257C636513762788513280-26sdata-3DK2Pxk9EKsIqq42wTAblO1HC6NdU-252BKZZKiLCqWaUHMno-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3Djf_iaSHvJObTbx-siA1ZOg%26r%3D_9rqR3xSCWQUlv9VpOcJwkP7H0XWQXmxeMmqQl6Fikc%26m%3DjIERTA7hqsqdWVgv_Tk9IHX9WbpseUmdoVj3QrWfXGg%26s%3DapUOTb1RjezIb461EUkfLLg-s4YZIpkTFmoJF-kbKg4%26e%3D&data=02%7C01%7Cjjwhite%40ets.org%7Cfe05ec027a98467a49b608d559edfdc6%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636513801066872449&sdata=nfDIiMiaOscm3g7WlEkvkr%2BRTwcdsZLmbg79bdkLd1k%3D&reserved=0> > > > > *From: *Marc Johlic <*marc.johlic@gmail.com* <marc.johlic@gmail.com>> > *Date: *Friday, January 12, 2018 at 12:03 > *To: *Andrew Kirkpatrick <*akirkpat@adobe.com* <akirkpat@adobe.com>>, > WCAG <*w3c-wai-gl@w3.org* <w3c-wai-gl@w3.org>> > *Subject: *Re: Possible wording for 1.3.4? > > > > I like the idea / premise and would +1 this replacing the wording in 1.3.4 > - and even keeping it at AA with this idea / premise / wording. > > > > I know we're out of time, but I would like to simplify the wording of the > SC if possible. Sorry - no ideas right off the top of my head.. I'll try > to come up with suggestions. It really just boils down to being as simple > as Leonie asked.. if your tech supports autofill, use it - but I know the > SC language needs to cover all of the bases. (It just took me a few read > throughs to "get it"). > > > > Even if the wording stays as is, I would +1 this replacing current 1.3.4 > wording - and leaving in as AA. > > > > -Marc Johlic > > > > On Fri, Jan 12, 2018 at 10:43 AM, Andrew Kirkpatrick <*akirkpat@adobe.com* > <akirkpat@adobe.com>> wrote: > > This SC seems to be saying that when using HTML input fields to collect > user information, the input element needs to have the autocomplete > attribute set with a value corresponding to the expected information > (based on the tokens defined in HTML5.2). Is this right? > > That is right. Of course there isn’t a value needed for every input, just > the ones with the meaning that matches the list. > > The SC also applies to other technologies that support autofill. If a > technology other than HTML supports autofill and has some of the values > that HTML 5.2 supports, those values need to be supported when using that > technology also. > > AWK > > > > On 12/01/2018 14:47, Andrew Kirkpatrick wrote: > > OK, so here’s a new attempt at language for 1.3.4. > > > > This language is below. Several concerns are addressed: > > > > * Uses a small and already-established list of values, based on the > > values in HTML5.2, but only imposes those values on other > > technologies if those technologies share the same values. > > * Well-established browser support for input autofill, and provides > a > > pathway for cognitive AT innovation. > > * Addresses a need established by the COGA group related to > difficulty > > filling out forms as well as providing the personalization > > enhancements development pathway. > > * WCAG doesn’t need to provide a specific list of inputs by > > referencing the HTML list, but that list is versioned with HTML so > > the level of testability doesn’t change until we update the > > reference in WCAG 2.2 (or silver) to either an updated HTML or > > COGA/ARIA spec. > > * Specifically targeted to the user, so this isn’t for EVERY input > > control, just a handful in the HTML spec (~40) that relate to > common > > user information (name, address, phone, credit card). > > > > Title: Support Common Input Fields > > > > SC Text: > > > > In content implemented using technologies with support for autofilling > > form inputs, the meaning of each user interface component that accepts > > user input corresponding to the user can be programmatically > determined; > > inputs matching a meaning provided in the HTML 5.2 Autofill field > names > > > < > *https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fhtml52%2Fsec-forms.html%23autofill-field&data=02%7C01%7Cakirkpat%40adobe.com%7C6fb521158e4c4022002908d559d1ba79%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636513679887347881&sdata=ToUIE6G%2FsKjrtn5JMEwM9hTps6iMOc6BtZwokR8IAzI%3D&reserved=0* > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.w3.org-252FTR-252Fhtml52-252Fsec-2Dforms.html-2523autofill-2Dfield-26data-3D02-257C01-257Cakirkpat-2540adobe.com-257C6fb521158e4c4022002908d559d1ba79-257Cfa7b1b5a7b34438794aed2c178decee1-257C0-257C0-257C636513679887347881-26sdata-3DToUIE6G-252FsKjrtn5JMEwM9hTps6iMOc6BtZwokR8IAzI-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3Djf_iaSHvJObTbx-siA1ZOg%26r%3D_9rqR3xSCWQUlv9VpOcJwkP7H0XWQXmxeMmqQl6Fikc%26m%3DjIERTA7hqsqdWVgv_Tk9IHX9WbpseUmdoVj3QrWfXGg%26s%3DKwhRWsNCxJLmPtTZSk__WqkmNiIbl094ZPTvDGD2kkU%26e%3D&data=02%7C01%7Cjjwhite%40ets.org%7Cfe05ec027a98467a49b608d559edfdc6%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636513801066872449&sdata=512sLu4PaWmg41nXbZJLTcEfx44OGAjT7r3zpfoS%2B%2BY%3D&reserved=0>> > must expose > > that meaning except if the technology being used does not support a > > corresponding autofill meaning. > > > > Note: > > > > The set of meanings for inputs is based on HTML 5.2. It is not > expected > > that every technology supports the same set, so content implemented > > using a technology that supports a subset of the HTML 5.2 autofill > > meanings is not required to provide support for meanings that are not > > supported by that technology. > > > > Note: > > > > Some technologies are expected to provide a list of meanings that is a > > superset of the HTML 5.2 set; authors are encouraged to implement > > support for additional meanings in their content in order to provide a > > better experience for users. > > > > > *https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Frawgit.com%2Fw3c%2Fwcag21%2F1.3.4_autofill%2Fguidelines%2Findex.html%23identify-common-purpose&data=02%7C01%7Cakirkpat%40adobe.com%7C6fb521158e4c4022002908d559d1ba79%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636513679887347881&sdata=VHpV4ttfM7I2%2FFKZW6SCulpl8NgMOw%2BtZ2%2BRHugkCtE%3D&reserved=0* > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Frawgit.com-252Fw3c-252Fwcag21-252F1.3.4-5Fautofill-252Fguidelines-252Findex.html-2523identify-2Dcommon-2Dpurpose-26data-3D02-257C01-257Cakirkpat-2540adobe.com-257C6fb521158e4c4022002908d559d1ba79-257Cfa7b1b5a7b34438794aed2c178decee1-257C0-257C0-257C636513679887347881-26sdata-3DVHpV4ttfM7I2-252FFKZW6SCulpl8NgMOw-252BtZ2-252BRHugkCtE-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3Djf_iaSHvJObTbx-siA1ZOg%26r%3D_9rqR3xSCWQUlv9VpOcJwkP7H0XWQXmxeMmqQl6Fikc%26m%3DjIERTA7hqsqdWVgv_Tk9IHX9WbpseUmdoVj3QrWfXGg%26s%3DYjp5j5hVz3iy85qva1keCGGlHeirevH2uVUoUmq3eR8%26e%3D&data=02%7C01%7Cjjwhite%40ets.org%7Cfe05ec027a98467a49b608d559edfdc6%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636513801066872449&sdata=p%2BvOPHPIynFHQJ7enm4eXak4gG477rs8vLlaAnPCOfU%3D&reserved=0> > > > > If you like it, or don’t like it, please speak up ASAP! > > > > Thanks, > > > > AWK > > > > Andrew Kirkpatrick > > > > Group Product Manager, Accessibility > > > > Adobe > > > > *akirkpat@adobe.com* <akirkpat@adobe.com> > > > > > *https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftwitter.com%2Fawkawk&data=02%7C01%7Cakirkpat%40adobe.com%7C6fb521158e4c4022002908d559d1ba79%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636513679887347881&sdata=LG6X%2BPhGvkisWjEcmBqgBy%2FteFAEl9tq2izWdcwmbio%3D&reserved=0* > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Ftwitter.com-252Fawkawk-26data-3D02-257C01-257Cakirkpat-2540adobe.com-257C6fb521158e4c4022002908d559d1ba79-257Cfa7b1b5a7b34438794aed2c178decee1-257C0-257C0-257C636513679887347881-26sdata-3DLG6X-252BPhGvkisWjEcmBqgBy-252FteFAEl9tq2izWdcwmbio-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3Djf_iaSHvJObTbx-siA1ZOg%26r%3D_9rqR3xSCWQUlv9VpOcJwkP7H0XWQXmxeMmqQl6Fikc%26m%3DjIERTA7hqsqdWVgv_Tk9IHX9WbpseUmdoVj3QrWfXGg%26s%3D61z0SOgNS_ugr3TpfSDFaxVPRZMKiPvZv2ekRdSXjbQ%26e%3D&data=02%7C01%7Cjjwhite%40ets.org%7Cfe05ec027a98467a49b608d559edfdc6%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636513801066872449&sdata=cCOPctP7Fzs8zOgICnvroI0zE%2FSccEYdPqLy6KIW0z0%3D&reserved=0> > > > > > -- > @LeonieWatson @tink@toot.cafe *tink.uk* > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__na01.safelinks.protection.outlook.com_-3Furl-3Dhttp-253A-252F-252Ftink.uk-26data-3D02-257C01-257Cakirkpat-2540adobe.com-257C77857df5a72447614ae208d559de604e-257Cfa7b1b5a7b34438794aed2c178decee1-257C0-257C1-257C636513733998117846-26sdata-3DYtaWXq9SN2FjUMQYnIAGmvalPT6-252FHQxYEoBJO37shP0-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3Djf_iaSHvJObTbx-siA1ZOg%26r%3D_9rqR3xSCWQUlv9VpOcJwkP7H0XWQXmxeMmqQl6Fikc%26m%3DjIERTA7hqsqdWVgv_Tk9IHX9WbpseUmdoVj3QrWfXGg%26s%3D48EzoMKMcsyu9bUTUr7uNc8q_W3HfRpqpiYVquicVKA%26e%3D&data=02%7C01%7Cjjwhite%40ets.org%7Cfe05ec027a98467a49b608d559edfdc6%7C0ba6e9b760b34fae92f37e6ddd9e9b65%7C0%7C0%7C636513801066872449&sdata=5f9jNOIFln2p3lxFteyutiSkkEMXxHTq9PLWXscj2Fw%3D&reserved=0>carpe > diem > > > > > ------------------------------ > > > 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. > ------------------------------ > > > ------------------------------ > > > 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. > ------------------------------ > > > > > > > > -- > John Foliot > Principal Accessibility Strategist > Deque Systems Inc. > *john.foliot@deque.com* <john.foliot@deque.com> > > Advancing the mission of digital accessibility and inclusion > > ------------------------------ > > 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. > ------------------------------ > > > > > -- > John Foliot > Principal Accessibility Strategist > Deque Systems Inc. > *john.foliot@deque.com* <john.foliot@deque.com> > > Advancing the mission of digital accessibility and inclusion > ----------------------------------------------------------------- > ATTENTION: > The information in this e-mail is confidential and only meant for the > intended recipient. If you are not the intended recipient, don't use or > disclose it in any way. Please let the sender know and delete the message > immediately. > ----------------------------------------------------------------- > ----------------------------------------------------------------- > ATTENTION: > The information in this e-mail is confidential and only meant for the > intended recipient. If you are not the intended recipient, don't use or > disclose it in any way. Please let the sender know and delete the message > immediately. > ----------------------------------------------------------------- > ----------------------------------------------------------------- > ATTENTION: > The information in this e-mail is confidential and only meant for the > intended recipient. If you are not the intended recipient, don't use or > disclose it in any way. Please let the sender know and delete the message > immediately. > ----------------------------------------------------------------- > > ------------------------------ > > 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. > ------------------------------ > > > > > -- > John Foliot > Principal Accessibility Strategist > Deque Systems Inc. > *john.foliot@deque.com* <john.foliot@deque.com> > > Advancing the mission of digital accessibility and inclusion > > > -- John Foliot Principal Accessibility Strategist Deque Systems Inc. john.foliot@deque.com Advancing the mission of digital accessibility and inclusion
Received on Friday, 12 January 2018 21:56:59 UTC