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

For those interested in testing secured/hosted fields more in depth -
Stripe provides examples that allow you to simulate checkout
https://stripe.github.io/elements-examples/

On Mon, Nov 19, 2018 at 5:00 PM Sean Murphy (seanmmur) <seanmmur@cisco.com>
wrote:

> 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
>
>
>
>
>
>
>
> [image:
> 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
>
> Tel: *+61 2 8446 7751*
>
>
>
>
>
>
>
>
>
> Cisco Systems, Inc.
>
> The Forum 201 Pacific Highway
>
> ST LEONARDS
>
> 2065
>
> Australia
>
> cisco.com
>
> [image: 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 or 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>
> 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> 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
> 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>
> To:        martin.bethann@gmail.com
> Cc:        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>
> 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.
>