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

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://able.ibm.com/request/>
> pjenkins@us.ibm.com
> Senior Engineer & Accessibility Executive
> IBM Research Accessibility
>
> linkedin.com/in/philljenkins/ <https://www.linkedin.com/in/philljenkins/>
> www.ibm.com/able
> <http://ageandability.com/>twitter.com/IBMAccess
> ageandability.com
>
>
>
>
> 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*
> <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.
>
>
>