Your Municipality's Payment Portal Is Probably the Least Accessible Part of Your Website — And the Hardest to Fix
Every municipal administrator in New Jersey knows the payment portal. It's the page — or more accurately, the series of pages — where residents go to pay their water and sewer bills, property taxes, parking tickets, permit fees, and whatever else your municipality collects online. It's probably the single most used function on your entire website. And it's almost certainly the part of your site that is furthest from WCAG 2.1 AA compliance.
Not because nobody cares. Not because your staff is negligent. But because payment portals create a specific set of technical problems that make them extraordinarily difficult to audit, extraordinarily difficult to fix, and extraordinarily easy to ignore — until someone files a complaint.
This is the accessibility problem that almost nobody is talking about in the municipal web space, and it's the one most likely to trip up small New Jersey municipalities as the April 2027 compliance deadline approaches. Here's why.
The Problem Starts With How Payment Portals Actually Work
To understand why payment portals are such an accessibility headache, you need to understand how they're built — because they don't work like the rest of your website.
Your typical municipal website is made up of static or semi-static pages. Your homepage, your department pages, your contact page, your meeting calendar — these are all pages with fixed URLs that live on your server and can be visited, bookmarked, and crawled by search engines or testing tools at any time. When an accessibility auditor or an automated scanning tool needs to evaluate one of these pages, it just loads the URL and goes to work.
Payment portals are different. Most municipalities don't build their own payment systems. They use third-party platforms — Edmunds GovTech, Invoice Cloud, Municipal Online Payments, Paymentus, and others — that handle the actual transaction processing. When a resident clicks "Pay My Bill" on your municipal website, they're typically handed off to one of these platforms through a redirect, an iframe, or a popup that loads content from a completely separate domain.
And this is where things start to fall apart from an accessibility standpoint.
The Dynamic URL Problem
Most payment portals generate dynamic URLs — web addresses that change with every session, every user, every step of the payment process. Instead of a clean, predictable address like yourtown.gov/pay-water-bill, you get something like paymentplatform.com/portal?sessionID=a7f3b2c9d1e4&step=2&token=x8k2m — a string of session tokens, query parameters, and authentication variables that are unique to that specific user at that specific moment.
When the user moves to the next step — entering their account number, reviewing their balance, confirming their payment — the URL changes again. And again. Each step generates a new dynamic address that exists only for that session and expires shortly after.
This matters for accessibility compliance because of how auditing and monitoring tools work.
Automated Scanners Can't Reach What They Can't Find
The automated accessibility scanning tools that form the first layer of any WCAG audit — axe, WAVE, SortSite, Lighthouse, Tenon — work by crawling URLs. You give the tool a starting point, and it follows links, loads pages, and evaluates each one against the WCAG criteria. This works beautifully for static content. It breaks down completely when it hits a payment portal.
The scanner follows the "Pay My Bill" link and lands on a login page or an account lookup screen. Maybe it can evaluate that first screen. But it can't authenticate. It can't enter an account number. It can't proceed through the multi-step payment flow. Every subsequent page in the process is gated behind a session-specific, dynamically generated URL that requires user input to advance. The scanner hits a wall on the first or second screen and reports back that it scanned one or two pages of the payment portal. The other five to ten steps in the flow — the screens where residents actually enter sensitive information, review charges, select payment methods, confirm transactions, and receive receipts — go completely untested.
This isn't a minor gap. For many residents, the payment portal is the only part of your website they ever use. If the single most important user flow on your entire site is the one your testing tools can't reach, you have a massive blind spot in your compliance posture.
Iframes Make It Even Worse
Many municipalities embed their payment portal within their own site using an iframe — a window that loads external content inside a page on your domain. The resident sees your municipal header and navigation at the top, and the payment form appears below it as if it's part of your site. Visually, the experience feels seamless.
Technically, it's a nightmare for accessibility.
An iframe loads content from a different domain, with its own HTML structure, its own CSS, its own JavaScript, and its own accessibility characteristics — or lack thereof. The content inside the iframe is controlled entirely by the third-party vendor. Your municipality's web team can't edit it, can't style it, and can't fix accessibility issues within it. But because it appears on your website, within your domain, as part of your resident-facing experience — it's your responsibility under the DOJ's Title II rule.
Automated scanners handle iframes inconsistently. Some skip them entirely. Some scan the outer page but not the iframe content. Some attempt to scan the iframe but can't follow the dynamic URLs inside it. The result is the same: the payment experience that your residents actually interact with goes largely or entirely untested.
And the accessibility problems lurking inside those iframes are often severe. Form fields without proper labels. Error messages that don't get announced to screen readers. Focus order that jumps erratically between the iframe content and the parent page. Keyboard traps where a user tabbing through the form gets stuck inside the iframe with no way to navigate back out. Timeout warnings that aren't communicated to assistive technology. Confirmation pages that auto-redirect before a screen reader user has time to read them.
These aren't edge cases. They're common patterns in third-party payment platforms, and they directly affect the residents who are most dependent on accessible digital services.
The Vendor Gap
Here's where the conundrum gets really painful for municipal administrators.
Your municipality didn't build the payment portal. You chose a vendor — or more likely, you inherited a vendor from a previous administration — and that vendor provides the platform as a service. You pay them a fee. They handle the technology. You link to their system from your website.
When your accessibility auditor tells you the payment portal has critical WCAG failures, your first instinct is to call the vendor. And that's when you discover one or more of the following realities.
The Vendor's Accessibility Is Not Your Accessibility
Some payment platform vendors will tell you their product is "accessible" or "ADA compliant." They may even have a VPAT — a Voluntary Product Accessibility Template — that describes their product's conformance with accessibility standards. But a VPAT is a self-reported document prepared by the vendor. It's not a third-party audit. It's not verified by the DOJ or any regulatory body. And even a well-prepared VPAT for the platform in its default configuration doesn't account for how the platform behaves when it's embedded in your specific site, configured with your specific settings, and accessed through your specific user flow.
The DOJ has been clear on this point: when a municipality uses a third-party vendor to provide digital services, the municipality retains responsibility for the accessibility of those services. You can't delegate your ADA obligations to a vendor and walk away. If the payment portal doesn't meet WCAG 2.1 AA, it's your compliance problem — even if the vendor is the only one who can fix it.
The Vendor May Not Prioritize Accessibility
For many payment platform vendors serving the municipal market, accessibility has historically been a secondary concern. Their clients are mostly small local governments that, until very recently, weren't asking about WCAG compliance and weren't auditing the portal experience. The vendor's development roadmap has been driven by features that municipalities do ask about — fraud prevention, PCI compliance, new payment methods, reporting dashboards — and accessibility improvements have taken a back seat.
That's starting to change as the April 2027 deadline approaches, but change in enterprise software is slow. Even if your vendor commits today to bringing their platform into full WCAG 2.1 AA compliance, the development, testing, and deployment process could take months or years. And during that time, your municipality is the one on the hook for non-compliance.
You May Not Have Leverage
If you're a small borough paying a few thousand dollars a year for a payment processing platform, your account isn't exactly a top priority for the vendor's product team. When you call to report accessibility issues, you may get a polite acknowledgment and a vague timeline. Or you may get a response that amounts to "our platform meets accessibility standards" with no detail, no evidence, and no willingness to engage further.
Larger municipalities and counties have more purchasing power and can exert more pressure on vendors through contract negotiations and procurement requirements. But a borough of 3,000 residents doesn't have that kind of leverage, and the vendor knows it.
The Testing Conundrum
So you've got a payment portal that your residents depend on, that generates dynamic URLs your scanning tools can't follow, that's embedded in an iframe your auditor can't fully access, that's controlled by a vendor you can't compel to make changes, and that the DOJ says is your responsibility regardless.
How do you even evaluate it?
Manual Testing Is the Only Reliable Option
The dynamic URL problem makes automated scanning insufficient for payment portals. The only way to get an accurate picture of the portal's accessibility is to have a trained evaluator manually walk through the entire payment flow using assistive technology — keyboard-only navigation, a screen reader, a screen magnifier — and test each step against the WCAG criteria.
This means the evaluator needs access to a test account or a sandbox environment where they can enter account numbers, view balances, and proceed through the full payment process without making actual transactions. Some vendors provide test environments for this purpose. Many don't — which means the evaluator may need to use a real account in a controlled way, or the municipality may need to work with the vendor to set up a testing pathway.
This kind of testing takes more time and costs more than scanning static pages. But it's the only way to know what's actually happening inside the portal, and the issues it uncovers are often among the most critical on the entire site — because they affect the task that residents care about most.
Test Environment Access Is a Fight Worth Having
If your payment vendor doesn't currently provide a test environment or sandbox for accessibility evaluation, make getting one a priority. Frame it as a compliance requirement, not a request. Under the DOJ's Title II rule, you are required to ensure the accessibility of the digital services you provide, including those delivered through third-party platforms. You cannot evaluate the accessibility of a system you can't test. Therefore, the vendor's cooperation in providing a testable environment is a necessary component of your compliance effort.
Put it in writing. If you're renegotiating your vendor contract or going through an RFP process, include explicit requirements for accessibility testing access, WCAG 2.1 AA conformance, and ongoing remediation commitments. The more municipalities that include these requirements in their procurement language, the faster the vendor market will adapt.
What Municipalities Should Be Doing Right Now
The payment portal accessibility problem isn't going to solve itself, and ignoring it doesn't reduce your exposure. Here's a practical path forward.
Audit the Full Payment Flow, Not Just the Landing Page
When you commission a WCAG audit of your municipal website, make sure the scope explicitly includes the payment portal — not just the page with the "Pay My Bill" button, but the entire multi-step flow from account lookup through payment confirmation. Your auditor needs to manually test every screen in the process using keyboard navigation and screen readers. If the audit report doesn't include findings from inside the payment portal, it's incomplete.
Document Your Vendor's Accessibility Posture
Request a current VPAT or accessibility conformance report from your payment platform vendor. If they can't provide one, that's a significant red flag. If they do provide one, have your auditor review it critically — a VPAT is only useful if it's detailed, honest, and recently updated. Ask the vendor specifically what WCAG 2.1 AA criteria their platform meets and which it doesn't. Get it in writing.
Include Accessibility Requirements in Vendor Contracts
Whether you're renewing an existing contract or selecting a new vendor through an RFP, include specific, measurable accessibility requirements. Don't accept vague language like "vendor will use best efforts to ensure accessibility." Instead, require conformance with WCAG 2.1 Level AA as a contractual obligation. Require the vendor to provide a test environment for accessibility evaluation. Require the vendor to remediate identified accessibility issues within a defined timeline. Require the vendor to provide updated VPATs on an annual basis. Include a provision that allows the municipality to audit the platform's accessibility at any time.
This language protects your municipality and signals to the vendor that accessibility is a contractual requirement, not an optional nice-to-have.
Have a Contingency Plan
If your current payment vendor is unable or unwilling to bring their platform into WCAG compliance, you need to know what your options are. Research alternative platforms that have stronger accessibility track records. Talk to other municipalities about what they're using and how it performs with assistive technology. Start the conversation early so that if you need to switch vendors, you're not scrambling to do it under deadline pressure.
Don't Ignore the Interim
Even while you're working on the vendor issue, there are steps you can take to improve the accessibility of the payment experience right now. Make sure the page on your own site that links to the portal is fully accessible — clear heading structure, descriptive link text, instructions that make sense to a screen reader user. Provide a phone number prominently on the payment page so that residents who can't use the portal have an immediate alternative. If you know the portal has specific accessibility barriers, consider posting a brief, honest accessibility statement that acknowledges the issues and describes what you're doing to address them — along with contact information for anyone who needs assistance.
This Is Going to Be the Weak Link for a Lot of Municipalities
Here's the uncomfortable truth: even municipalities that are doing everything right on the rest of their website may end up out of compliance because of their payment portal. You can have perfect alt text, flawless heading structure, beautiful color contrast, fully accessible PDFs, and a site that sails through every automated scan — and still fail a WCAG audit because the third-party payment system your residents use every month can't be navigated with a keyboard.
And because the payment portal is the highest-stakes interaction on your site — the place where residents enter personal and financial information, where errors can cost real money, where frustration has the most direct consequences — it's exactly the kind of accessibility failure that's most likely to result in a complaint.
The dynamic URL problem, the iframe problem, the vendor problem, the testing problem — these are all real, and they're all solvable. But they require municipalities to engage with the issue directly, to hold their vendors accountable, and to invest in the kind of manual testing that automated tools can't provide.
The municipalities that figure this out early will be in compliance. The ones that assume the payment portal is someone else's problem will find out the hard way that it isn't.
Frequently Asked Questions
Is Our Municipality Really Responsible for a Third-Party Payment Portal?
Yes. The DOJ's Title II rule is explicit on this point. When a municipality uses a third-party platform to deliver government services — including bill payment — the municipality retains responsibility for the accessibility of that service. You can require your vendor to meet accessibility standards through your contract, but you can't transfer your legal obligation to them. If a resident files a complaint because they can't use your payment portal with a screen reader, the complaint is against your municipality, not the vendor.
Our Payment Vendor Says They're ADA Compliant. Should We Take Their Word for It?
Not without verification. "ADA compliant" is not a regulated term, and vendors use it loosely. Ask for a detailed VPAT or third-party audit report that maps the platform's accessibility against specific WCAG 2.1 AA success criteria. If the vendor can only offer a general statement of compliance without supporting evidence, treat that claim with skepticism. The only way to verify accessibility is to test the actual platform as your residents experience it — which means manual testing with assistive technology through the full payment flow on your site.
Can an Automated Scan Tell Us If Our Payment Portal Is Accessible?
Not adequately. Automated scanners can evaluate the first page the resident lands on, but they can't authenticate, enter account information, or proceed through a multi-step payment flow with dynamic URLs. The screens where residents actually enter payment details, review charges, and confirm transactions are typically invisible to automated tools. Manual testing by a trained accessibility evaluator is the only reliable way to assess the full payment experience.
What If Our Vendor Won't Fix the Accessibility Issues?
Document everything. Put your accessibility requirements in writing to the vendor, reference the DOJ's Title II rule and the April 2027 deadline, and request a specific remediation timeline. If the vendor is unable or unwilling to commit to WCAG 2.1 AA compliance, begin researching alternative platforms. Include the vendor's lack of accessibility commitment as a factor in your next procurement decision. In the meantime, make sure residents have an alternative way to make payments — a phone number, an in-person option — and publicize those alternatives clearly on your site.
We're Going Through an RFP for a New Payment Vendor. What Should We Require?
At minimum, require full conformance with WCAG 2.1 Level AA, an up-to-date VPAT or third-party audit report, a test environment or sandbox for accessibility evaluation, a commitment to remediate identified accessibility issues within a defined timeline, and compatibility with common assistive technologies including JAWS, NVDA, and VoiceOver. Make these requirements pass/fail evaluation criteria in your scoring, not just nice-to-haves. The vendor you select will be providing one of the most critical resident-facing services on your website — accessibility can't be an afterthought in that decision.
What's the Most Common Accessibility Failure in Municipal Payment Portals?
The single most common issue is form fields without proper programmatic labels. The payment form may visually display text like "Account Number" or "Amount Due" next to each field, but if those labels aren't associated with the fields in the code using proper <label> elements or ARIA attributes, a screen reader user encounters blank input fields with no indication of what information to enter. This one issue can make the entire payment process unusable for a blind resident. Other extremely common failures include error messages that aren't announced to screen readers, keyboard focus that gets trapped inside iframe content, session timeouts that expire without warning, and confirmation pages that auto-redirect before assistive technology can read them.