For those interested in testing secured/hosted fields more in depth -
Post by Sean Murphy (seanmmur)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
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.
*Sent:* Tuesday, 20 November 2018 8:25 AM
*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
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.
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
..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=>
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=>
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.
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.
