Payment Accessibility User Requirements

W3C Editor's Draft

This version:
Latest published version:
Latest editor's draft:
Shane McCarron (Spec-Ops)
Janina Sajka (Invited Expert)


This document presents the accessibility requirements users with disabilities have with respect to making payments on the web.

It first provides an introduction to the needs of users with disabilities in relation to payments.

Then it explains what accessibility enhancing technologies have been developed to help such users.

A third section explains how these technologies fit in the larger picture of accessibility, both technically within a web user agent and from a production process point of view.

This document is most explicitly not a collection of baseline user agent requirements. It is important to recognize that not all user agents will support all the features discussed in this document. Rather, this document attempts to supply a comprehensive collection of user requirements needed to support payment accessibility in the context of HTML5.

Please also note this document is not an inventory of technology currently provided by, or missing from HTML5 specification drafts. Technology is listed here because it's important for accommodating the alternative access needs of users with disabilities to web-based payments. This document is an inventory of Payment Accessibility User Requirements.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at

This document is a very early editors draft.

This document was published by the Accessible Platform Architectures Working Group as an Editor's Draft.

Comments regarding this document are welcome. Please send them to (archives).

Publication as an Editor's Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 1 March 2019 W3C Process Document.

1. Summary of Accessible Payment Requirements by Type of Disability

This section provides examples of the accessibility requirements of people with auditory, cognitive, neurological, physical, speech, or visual disabilities to access and comprehend web content. For a broader exploration of how people with different disabilities interact with web content and tools, see How People with Disabilities Use the Web.

1.1 Visual: Blindness

People who are blind cannot access visual information in prompts, selectors, status indicators, etc. They need the information in an alternative representation of audio or text. People who are blind use a screen reader and/or refreshable Braille display, and content needs to be operable with these assistive technologies (ATs).

1.2 Visual: Low vision

People with low vision can use some visual information. Depending on their visual ability they might have specific issues such as difficulty discriminating foreground information from background information, or discriminating colors. Glare caused by excessive scattering in the eye can be a significant challenge, especially for very bright content or surroundings. They may be unable to react quickly to transient information, and may have a narrow angle of view and so may not detect key information presented temporarily where they are not looking, or in text that is moving or scrolling. A person will likely use screen magnification software. This means that they will only be viewing a portion of the screen, and so must manage content (e.g., pop-up windows or dynamic prompts) via their AT. They may have difficulty reading when text is too small, has poor background contrast (too high or too low), or when outlined or other fancy font types or effects are used. If the font is an image, it is likely to appear grainy when magnified. They may be using an AT that adjusts all the colors of the screen, such as inverting the colors, so the content must be viewable through the AT. Users with low vision will often benefit from the same augmented content or instructions that are sometimes hidden or displayed off screen for users of screen readers or refreshable Braille.

1.3 Visual: Atypical color perception

People with atypical color perception (often called "color blindness") may not be able to discriminate between different colors, or may miss key information when coded with color only, such as colors in selection boxes or prompts embedded in input fields.

1.4 Auditory & Visual: Deaf-blind

Individuals who are deaf-blind have a combination of conditions that may result in one of the following: blindness and deafness; blindness and difficulty in hearing; low vision and deafness; or low vision and difficulty in hearing. Depending on their combination of conditions, individuals who are deaf-blind may need text that can be enlarged, changed to high-contrast colors, or otherwise styled; or they may need text that can be presented with AT (e.g., a refreshable Braille display).

1.5 Physical impairment

Some people with physical disabilities such as limited muscle control (including tremors, lack of coordination, and paralysis), pain that impedes movement, or missing limbs, cannot use a keyboard or mouse to interact with content and controls. Some use a keyboard but not a pointing device, some use a switch with an on-screen keyboard, and some use other assistive technology. The content must be usable with only a keyboard, including making selections of items that might have otherwise been done with a pointing device.

1.6 Cognitive disabilities

Cognitive disabilities include a wide range of conditions that may include intellectual disabilities (called learning disabilities in some regions), autism-spectrum disorders, memory impairments, mental-health disabilities, attention-deficit disorders, audio- and/or visual-perceptive disorders, dyslexia and dyscalculia (called learning disabilities in some regions), or seizure disorders. The accessibility supports for these different conditions vary widely. Individuals with some conditions may process information aurally better than by reading text; therefore, information that is presented as images (e.g., a so-called captcha image) should also be available as audio descriptions. Individuals with other conditions may need to reduce distractions or flashing. Some conditions, such as autism-spectrum disorders, may have multisystem effects. Individuals may need a combination of different accommodations. Overall, the user experience for people on the autism spectrum should be customizable and well designed so as to not be overwhelming. Care must be taken to present an experience that focuses on the purpose of the content and provides alternative content in a clear, concise manner.

2. Alternative Content Technologies

A number of alternative content types have been developed to help users with sensory disabilities gain access to textual web content. This section lists them, explains generally what they are, and provides a number of requirements on each that need to be satisfied with technology developed in / supported by HTML5.

@@@@@ this is where we need the most work @@@@@

3. System Requirements

3.1 Access to interactive controls / menus

Payment interfaces offer a rich set of interaction possibilities to users. These interaction possibilities must be available to all users, including those that cannot use a pointer device for interaction. Further, these interaction possibilities must be available to all users for all means in which the controls are exposed - no matter whether they are exposed by the user agent, or are scripted. Further, the interaction possibilities need to be rich enough to allow all users complete access to the payment interface.

It is imperative that controls be device independent, so that control may be achieved by keyboard, pointing device, speech, etc.

Systems supporting accessibility for interactive controls must:

[IC-1] Support operation of all functionality via the keyboard on systems where a keyboard is (or can be) present, and where focusable elements are used for interaction. This does not forbid and should not discourage a providing pointing device or other input methods in addition to keyboard operation.

This means that all interaction possibilities with payment interaces need to be keyboard accessible; e.g., through being able to tab onto the various fields, select among payment methods, authenticate, etc. via the keyboard.

[IC-2] All functionality available to native controls must also be available to scripted controls. The author would be able to choose any/all of the controls, style them and position them.

This may mean that user agents need to expose the UI aspects of embedded payment controls so that they can be adequately scripted and controlled.

[IC-3] The scripted and native controls must go through the same platform-level accessibility framework (where it exists), so that a user presented with the scripted version is not excluded from participating in or experiencing some expected behavior.

This is below the level of HTML and means that the accessibility platform needs to be extended to allow access to these controls.

3.2 Requirements on making properties available to the accessibility interface

On self-contained products that do not support assistive technology (e.g., a kiosk on a train platform), any menus in the content need to provide information in alternative formats (e.g., talking menus). Products with an external control, or that are self-contained boxes, should ensure the physical design does not block access, and should make accessibility controls, such as the closed-caption toggle, as prominent as the other controls.

[API-1] Since authors will need access to any alternative content made available by the payment system to the end user, the structure needs to be exposed to authors as well, which requires a dynamic interface.
[API-2] Accessibility APIs need to gain access to alternative content no matter whether that content comes from within a resource or are combined through markup on the page.

A. Acknowledgments

The following people contributed to the development of this document.

A.1 Participants and Contributors

Participants in the APA:

Other contributors and commenters:

Additionally, the following W3C groups contributed to, and commented on this document: