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

There is a bigger concern, the PCI org is not considering accessibility in their standards. Rather they are more concern in relation to accessibility. Not sure how to educate or change this.

Technically, it might be accessible if people follow WCAG. But is it usable? IFrames are usable if the related content is maintained in the iframe. But if you have multiple iframes for the single form. Then I don’t see this usable at all for specific user bases like screen reader users.

On a side point, PCI in their standards have a range of technology barriers causing serious accessibility challenges for banking organisations with their terminals used within shops. Such as touch screen FPoS or Retail transaction devices. Security is the reasons provided by the banks when this topic is raised. For example, entering in the pin on a touch screen FPoS. As there is no physical keyboard and nor can you connect one via USB or Bluetooth. Multiple disabilities are impacted and the banks have to create innovative solutions which some work and some don’t. Some PWD users are unable to manage the solution while other PWD’s with the same disability can. A real night mare for the banks due to PCI. So there is a bigger issue here for this organisation to address accessibility concerns.

Note: ADA in the USA proscribe physical keyboards on the ATM’s. But I am not sure if this includes FPoS in shops as well. Other countries have different requirements.



Sean



[https://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/02_standard_ciscoblue02.png]




Sean Murphy
SR ENGINEER.SOFTWARE ENGINEERING
seanmmur@cisco.com<mailto:seanmmur@cisco.com>
Tel: +61 2 8446 7751










Cisco Systems, Inc.
The Forum 201 Pacific Highway
ST LEONARDS
2065
Australia
cisco.com



[http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]

Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.
Please click here<http://www.cisco.com/c/en/us/about/legal/terms-sale-software-license-agreement/company-registration-information.html> for Company Registration Information.







From: Casey Smith <casey.smith@capitalone.com>
Sent: Tuesday, 20 November 2018 8:25 AM
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.