RE: [External Sender] Guidance regarding secured/hosted fields for PCI (Payment Card Industry) Compliance

  *   It's also worth mentioning that these input types are required under the new WCAG 2.1 Success Criterion 1.3.5: Identify Input Purpose<https://www.w3.org/WAI/WCAG21/Understanding/identify-input-purpose.html>! One might argue that using the wrong type for an input would be a failure of this SC.

It has not yet been determined by the Accessibility Guidelines working group that use of the type attribute is sufficient to unambiguously communicate the purpose of an input field programmatically.  At this point the autocomplete attribute is the method that has been documented as a sufficient technique.

Jonathan

Jonathan Avila, CPWA
Chief Accessibility Officer
Level Access
jon.avila@levelaccess.com
703.637.8957 office

Visit us online:
Website<http://www.levelaccess.com/> | Twitter<https://twitter.com/LevelAccessA11y> | Facebook<https://www.facebook.com/LevelAccessA11y/> | LinkedIn<https://www.linkedin.com/company/level-access> | Blog<http://www.levelaccess.com/blog/>

Looking to boost your accessibility knowledge? Check out our free webinars!<https://www.levelaccess.com/compliance-resources/webinars/>

The information contained in this transmission may be attorney privileged and/or confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is strictly prohibited.

From: Casey Smith <casey.smith@capitalone.com>
Sent: Monday, November 19, 2018 4:25 PM
To: martin.bethann@gmail.com
Cc: pjenkins@us.ibm.com; Brian Lovely <brian.lovely@capitalone.com>; w3c-wai-ig@w3.org
Subject: Re: [External Sender] Guidance regarding secured/hosted fields for PCI (Payment Card Industry) Compliance

While I can't attest to the browser support for these (as neither caniuse.com<http://caniuse.com/> or html5test.com<http://html5test.com/> mention these), there are indeed Credit Card input types available<https://www.w3.org/TR/WCAG21/#input-purposes> that would not only provide the number keypad functionality, but also provide robust autofill capability. It's also worth mentioning that these input types are required under the new WCAG 2.1 Success Criterion 1.3.5: Identify Input Purpose<https://www.w3.org/WAI/WCAG21/Understanding/identify-input-purpose.html>! One might argue that using the wrong type for an input would be a failure of this SC.

On Mon, Nov 19, 2018 at 3:16 PM Beth Martin <martin.bethann@gmail.com<mailto:martin.bethann@gmail.com>> wrote:
Yes - the form looks visually looks "normal" and is styled appropriately but the label/field/focus/error validation is all contained within an iframe.  As the user tabs in and out of each field using assistive technology, they are entering and leaving the iframe. If you are looking for a best-case example, Shopify implements this for their payment fields.  I believe we will see this more and more on eCommerce sites due to PCI compliance requirements.

On a related note, we are also seeing credit card payment providers using type="tel" on credit card inputs, sometimes with no label. The response I'm getting back from the payment provider (Ayden, in our case) is "the tel tag is necessary for older phones to switch to the proper number input. This is standard practice in the industry".

Thanks,
Beth


On Mon, Nov 19, 2018 at 2:50 PM Phill Jenkins <pjenkins@us.ibm.com<mailto:pjenkins@us.ibm.com>> wrote:
>..where each payment field (credit card number, CVV, and expiration date) is a DOM-injected iframe, comprising of a `label`, `input`, error validation, styling, and focus management.  These iframed fields are referred as "secure fields" or "hosted fields".

hmm, this does sound like a "something unusual and/or complicated".

@Martin, I think you're saying that although the form looks "normal" to the sighted user, underneath the covers many of the fields are actually iframed fields. so if all that complicated structure, such as a large form with mutiple embedded iframes and form field is what the assistive technology (e.g. screen reader) user hears, that will be very confusing at best and totally inaccessible at worst..

Does the user know that there are embedded iframes in the form? is there a way to hide that?  I don't think you could simply ignore the iframes since they include relevent form fields.

I have no immediate sugggestions on how to fix / make that accessible. Anyone else?
___________
Regards,
Phill Jenkins
Check out the new system for requesting an IBM product Accessibility Conformance Report VPAT®at  able.ibm.com/request<https://urldefense.proofpoint.com/v2/url?u=https-3A__able.ibm.com_request_&d=DwMFaQ&c=pLULRYW__RtkwsQUPxJVDGboCTdgji3AcHNJU0BpTJE&r=a2IkSvJwyjZXKucTfiFA6y2OFiimV_7eb-gf0jOlneM&m=-NvXDufhf6_m6bCcqf15fkrzd-eqzEr4P41Tqw7lo3E&s=V4YTt_LbpVFg4wgNagc8RbpYsVBJA5In9Mq_RveZywM&e=>
pjenkins@us.ibm.com<mailto:pjenkins@us.ibm.com>
Senior Engineer & Accessibility Executive
IBM Research Accessibility

linkedin.com/in/philljenkins/<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.linkedin.com_in_philljenkins_&d=DwMFaQ&c=pLULRYW__RtkwsQUPxJVDGboCTdgji3AcHNJU0BpTJE&r=a2IkSvJwyjZXKucTfiFA6y2OFiimV_7eb-gf0jOlneM&m=-NvXDufhf6_m6bCcqf15fkrzd-eqzEr4P41Tqw7lo3E&s=YWM4yJZlB4sJBC0ssr7xIeqfZNt5T3HPdan6Yd1NuRM&e=>
www.ibm.com/able<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ibm.com_able&d=DwMFaQ&c=pLULRYW__RtkwsQUPxJVDGboCTdgji3AcHNJU0BpTJE&r=a2IkSvJwyjZXKucTfiFA6y2OFiimV_7eb-gf0jOlneM&m=-NvXDufhf6_m6bCcqf15fkrzd-eqzEr4P41Tqw7lo3E&s=p-hyvreplFHPSj2qsrD8ShWEY0ULqBBqjCJ_dTF6Y9s&e=>
twitter.com/IBMAccess<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_IBMAccess&d=DwMFaQ&c=pLULRYW__RtkwsQUPxJVDGboCTdgji3AcHNJU0BpTJE&r=a2IkSvJwyjZXKucTfiFA6y2OFiimV_7eb-gf0jOlneM&m=-NvXDufhf6_m6bCcqf15fkrzd-eqzEr4P41Tqw7lo3E&s=rA_cNjiImxHmDx1UeJvqtPDelR_9lnBa-aJEgUa1Ho0&e=>
ageandability.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__ageandability.com&d=DwMFaQ&c=pLULRYW__RtkwsQUPxJVDGboCTdgji3AcHNJU0BpTJE&r=a2IkSvJwyjZXKucTfiFA6y2OFiimV_7eb-gf0jOlneM&m=-NvXDufhf6_m6bCcqf15fkrzd-eqzEr4P41Tqw7lo3E&s=X1os9xXAxNoUiuNv5QN_P96PC5Ma5WbnjB-XEXx6YV0&e=>




From:        Brian Lovely <brian.lovely@capitalone.com<mailto:brian.lovely@capitalone.com>>
To:        martin.bethann@gmail.com<mailto:martin.bethann@gmail.com>
Cc:        w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org>
Date:        11/19/2018 01:21 PM
Subject:        Re: [External Sender] Guidance regarding secured/hosted fields for  PCI (Payment Card Industry) Compliance
________________________________



Usually, unless you do something unusual and/or complicated, sticking to the HTML standards (programmatically associated form labels, fieldset/legend for groups, titles for iframes), will be fairly compliant.


On Mon, Nov 19, 2018 at 1:37 PM Beth Martin <martin.bethann@gmail.com<mailto:martin.bethann@gmail.com>> wrote:
Hello,

I'm looking for some additional guidance regarding secure fields needed for PCI (Payment Card Industry) compliance for ecommerce.  Payment providers now offer a solution for a higher level of conformance where each payment field (credit card number, CVV, and expiration date) is a DOM-injected iframe, comprising of a `label`, `input`, error validation, styling, and focus management.  These iframed fields are referred as "secure fields" or "hosted fields".

We are working with our payment provider to improve their markup, however, if they followed all form and iframe related guidelines, would there be any other concerns regarding accessibility?

Thanks!

Beth Martin


--
Brian Lovely
Digital Accessibility
804.389.1064
________________________________

The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.



--
Casey Smith
Digital Accessibility Team

________________________________

The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.