ADA Compliance for Billing and Payment Portals: The WCAG Criteria That Matter Most in 2026

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).

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?

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.

Which billing platforms have fully ADA-compliant payment portals?

None of them, and a vendor that claims otherwise is describing its product rather than your deployment. WCAG conformance is a property of the page a user actually receives, so it depends on your theme, your custom fields, your error handling and your third-party widgets as much as on the platform underneath. A payment provider can ship accessible components and still leave the checkout non-conformant once a custom step, a session-timeout modal or an embedded fraud-check iframe lands on top of them.

Ask a vendor these four questions instead of asking whether they are compliant:

• The current VPAT or Accessibility Conformance Report, naming the WCAG version and level it was assessed against.

• Which components that report covers, and which parts remain the responsibility of the integrator.

• How the platform handles 3.3.4 Error Prevention on the payment confirmation step.

• Whether hosted card fields are keyboard operable and correctly labelled for screen readers.

Then test the rendered flow yourself, because the only answer that matters is what your customers actually receive.

How does an accessible payment portal reduce legal risk?

It removes the barrier a complaint would be built on. The Department of Justice position is that ADA requirements reach the goods and services a public accommodation offers on the web (DOJ), and a checkout that cannot be completed with a keyboard or a screen reader denies the service itself rather than inconveniencing someone on a marketing page. That is why payment and billing flows attract attention out of all proportion to their page count.

The practical protection is evidence: a dated conformance report against a named WCAG version, a record of which criteria were tested, and remediation tickets showing when each barrier was closed. This is not legal advice, and an accessible portal is not a legal shield. It is the difference between a defensible position and an indefensible one.

What remediation at scale actually looks like

Vervali has done this work at volume. For NEOGOV, a US provider of on-demand HR software serving more than 6,000 public-sector and education organisations, the engagement covered more than 2,000 URLs across the client platforms, identified and remediated more than 5,000 accessibility gaps, and submitted every platform for certification review inside the committed 90-day window. The public-sector HR software provider achieved Section 508 AA certification on the first attempt, and a further product that had been outside the original scope and was fully non-compliant was remediated to meet the applicable requirements as well.

That engagement was scoped to WCAG 2.0 and Section 508, the standards in force for it. A billing portal being specified today should be tested against WCAG 2.2 AA.

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

1. U.S. Department of Justice, Guidance on Web Accessibility and the ADA, 2022. https://www.ada.gov/resources/web-guidance/
2. 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/
3. W3C, Web Content Accessibility Guidelines (WCAG) 2.2. https://www.w3.org/TR/WCAG22/
4. 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
5. W3C, WCAG 2.2 Success Criterion 2.2.1 Timing Adjustable. https://www.w3.org/TR/WCAG22/#timing-adjustable
6. W3C, WCAG 2.2 Success Criterion 3.3.8 Accessible Authentication (Minimum). https://www.w3.org/TR/WCAG22/#accessible-authentication-minimum
7. W3C, WCAG 2.2 Success Criterion 3.3.7 Redundant Entry. https://www.w3.org/TR/WCAG22/#redundant-entry
8. W3C, WCAG 2.2 Success Criterion 2.5.8 Target Size (Minimum). https://www.w3.org/TR/WCAG22/#target-size-minimum
9. U.S. Access Board, Information and Communication Technology Standards (Section 508). https://www.access-board.gov/ict/
10. 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