A billing or payment portal is one of the highest-stakes pages to get wrong for accessibility, because it is where a financial transaction actually happens. Under the Americans with Disabilities Act, a private company's customer-facing portal is a Title III public accommodation, and the Department of Justice's position is that "the ADA's requirements apply to all the goods, services, privileges, or activities offered by public accommodations, including those offered on the web" (DOJ). The ADA itself names no technical standard, but DOJ points to the Web Content Accessibility Guidelines (WCAG) as the practical measure, and a small set of WCAG success criteria carry most of the weight on a checkout flow. This is the billing-portal slice of our accessibility testing guide; here are the criteria that matter, and why payment pages are held to a higher standard than the rest of a site.
Does the ADA actually require a billing portal to be accessible?
For a business open to the public, yes. DOJ states that "Title III prohibits discrimination against people with disabilities by businesses open to the public" (DOJ) and that it "has consistently taken the position that the ADA's requirements apply to all the goods, services, privileges, or activities offered by public accommodations, including those offered on the web" (DOJ). A customer billing or payment portal is squarely one of those services. What DOJ does not provide for private businesses is a detailed technical rule: "The Department of Justice does not have a regulation setting out detailed standards, but the Department's longstanding interpretation of the general nondiscrimination and effective communication provisions applies to web accessibility" (DOJ).
So does the ADA require WCAG, or not?
This is where most write-ups get it wrong, so it is worth stating precisely. The ADA statute names no standard. For a private billing portal, which falls under Title III, DOJ treats WCAG as guidance rather than a mandate: existing standards "provide helpful guidance concerning how to ensure accessibility of website features. These include the Web Content Accessibility Guidelines (WCAG) and the Section 508 Standards" (DOJ). WCAG is named outright in adjacent regimes, however. DOJ's 2024 rule under Title II makes "WCAG Version 2.1, Level AA... the technical standard for state and local governments' web content and mobile apps" (DOJ Title II rule). Section 508 requires federal content to "conform to Level A and Level AA Success Criteria... in WCAG 2.0" (U.S. Access Board). And the European standard EN 301 549 states that conformance with "WCAG 2.1... Level AA is equivalent to conforming with" its web clauses (ETSI EN 301 549).
| Regime | Named standard |
|---|---|
| ADA Title III (private business) | No standard named; DOJ points to WCAG as guidance |
| ADA Title II (state/local government), 2024 rule | WCAG 2.1 Level AA |
| Section 508 (US federal) | WCAG 2.0 Level AA |
| EN 301 549 (EU) | WCAG 2.1 Level AA |
The practical takeaway: WCAG Level AA is the working standard for a billing portal even where no statute names it, and the AA conformance level is the one every adjacent regime selects (WCAG 2.2). No US legal instrument currently mandates WCAG 2.2, so treat the 2.2 additions below as current best practice, not a named legal requirement.
Why are payment and checkout pages held to a higher standard?
Because WCAG itself singles out financial transactions. Success Criterion 3.3.4, Error Prevention (Legal, Financial, Data), at Level AA, applies "for web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses" (WCAG 2.2, 3.3.4). For those pages, the submission must be reversible, checked for errors, or confirmable before it commits. The supporting documentation explains the reason: the intent is "to help users with disabilities avoid serious consequences as the result of a mistake when performing an action that cannot be reversed" (W3C, Understanding 3.3.4). A brochure page never triggers this. A checkout page always does, which is why a billing portal carries obligations the rest of the site does not.
Which WCAG criteria matter most on a billing portal?
| Criterion (Level) | What it requires | Why it bites on checkout |
|---|---|---|
| 3.3.4 Error Prevention, Legal/Financial/Data (AA) | Reversible, checked, or confirmed submissions | The financial transaction itself |
| 3.3.1 Error Identification (A) | "the item that is in error is identified and the error is described to the user in text" | Declined cards, invalid fields |
| 3.3.2 Labels or Instructions (A) | "Labels or instructions are provided when content requires user input" | Card, billing-address, CVV fields |
| 3.3.3 Error Suggestion (AA) | Suggest a correction when one is known | Fixing a mistyped field |
| 2.2.1 Timing Adjustable (A) | Time limits can be turned off, adjusted, or extended | Payment session timeouts |
| 2.1.1 Keyboard (A) | "All functionality... operable through a keyboard interface" | Custom dropdowns, date pickers |
| 1.4.3 Contrast Minimum (AA) | Text contrast "at least 4.5:1" | Low-contrast totals and fine print |
| 4.1.2 Name, Role, Value (A) | Name and role programmatically determinable | Screen-reader support for custom widgets |
Each criterion above is quoted or summarised from its WCAG 2.2 normative entry (WCAG 2.2). Together they cover the form, the errors, the timing, and the assistive-technology surface, which is most of what a payment page is.
How do session timeouts trip up payment flows?
Payment sessions expire on a timer for security, and that timer can collide with accessibility. Success Criterion 2.2.1, Timing Adjustable, requires that "for each time limit that is set by the content, at least one of the following is true," then lists the options to turn off, adjust, or extend the limit (WCAG 2.2, 2.2.1). A user relying on a screen reader or switch input may need several times longer to complete a card form, so a hard ten-minute checkout timeout with no warning and no extension fails the criterion. The fix is not to remove the security timeout but to warn before it expires and offer a simple way to extend it.
What do the WCAG 2.2 additions change for checkout?
Three new criteria land directly on payment flows. Accessible Authentication (Minimum) says "a cognitive function test (such as remembering a password or solving a puzzle) is not required for any step in an authentication process" unless an alternative is offered (WCAG 2.2, 3.3.8), which constrains how a portal can gate a saved-card or account login. Redundant Entry requires that "information previously entered by or provided to the user that is required to be entered again in the same process is either auto-populated, or available for the user to select" (WCAG 2.2, 3.3.7), which is the billing-equals-shipping pattern done correctly. And Target Size (Minimum) sets pointer targets at "at least 24 by 24 CSS pixels" with exceptions (WCAG 2.2, 2.5.8), which matters for the small quantity steppers and radio buttons common in mobile checkout.
How do you test a billing portal for ADA and WCAG?
With both machines and people, because the criteria that matter most on a checkout are the ones automation cannot fully judge. Automated scanners reliably catch contrast (1.4.3), missing form labels (3.3.2), and programmatic-name gaps (4.1.2), and they belong in the pipeline on every build. The criteria that decide whether a real customer can pay are confirmed by hand: a keyboard-only run through the entire purchase to prove every control is operable (2.1.1); a screen-reader pass that listens to how each field, error, and total is announced (3.3.1, 4.1.2); a check that a card error is described in text with a correction suggested (3.3.1, 3.3.3); a deliberate wait to confirm the session timeout warns and can be extended (2.2.1); and a confirmation step that satisfies error prevention on the transaction (3.3.4). Target Level AA, the level that Section 508, the 2024 Title II rule, and EN 301 549 all select (DOJ Title II rule). This is what the "508 accessibility testing" and "ADA and EN 301 549 compliance" questions are really after: a tested checkout, not a badge, and it is what Vervali's WCAG and ADA accessibility testing service runs against checkout and billing flows.
The verdict: the checkout is the page to get right first
A billing portal carries accessibility obligations the rest of a site does not, because WCAG attaches a higher duty to pages that take a payment. The ADA does not name WCAG for a private business, but DOJ treats it as the measure, and every neighbouring regime names WCAG Level AA outright, so AA is the working target. Concentrate on the criteria that bite on a transaction: error prevention, labelled fields, described errors, adjustable timeouts, keyboard operability, and the WCAG 2.2 authentication and redundant-entry rules. If a team has budget to make one flow accessible first, the checkout is the one that carries both the legal exposure and the lost revenue.
Sources
- U.S. Department of Justice, Guidance on Web Accessibility and the ADA, 2022. https://www.ada.gov/resources/web-guidance/
- U.S. Department of Justice, Fact Sheet: New Rule on the Accessibility of Web Content and Mobile Apps (Title II), 2024. https://www.ada.gov/resources/2024-03-08-web-rule/
- W3C, Web Content Accessibility Guidelines (WCAG) 2.2. https://www.w3.org/TR/WCAG22/
- W3C, Understanding Success Criterion 3.3.4: Error Prevention (Legal, Financial, Data). https://www.w3.org/WAI/WCAG22/Understanding/error-prevention-legal-financial-data.html
- W3C, WCAG 2.2 Success Criterion 2.2.1 Timing Adjustable. https://www.w3.org/TR/WCAG22/#timing-adjustable
- W3C, WCAG 2.2 Success Criterion 3.3.8 Accessible Authentication (Minimum). https://www.w3.org/TR/WCAG22/#accessible-authentication-minimum
- W3C, WCAG 2.2 Success Criterion 3.3.7 Redundant Entry. https://www.w3.org/TR/WCAG22/#redundant-entry
- W3C, WCAG 2.2 Success Criterion 2.5.8 Target Size (Minimum). https://www.w3.org/TR/WCAG22/#target-size-minimum
- U.S. Access Board, Information and Communication Technology Standards (Section 508). https://www.access-board.gov/ict/
- ETSI, EN 301 549 V3.2.1, Accessibility requirements for ICT products and services. https://www.etsi.org/deliver/etsi_en/301500_301599/301549/03.02.01_60/en_301549v030201p.pdf
Email Us
Call Us
