How to Write an RFP for a Municipal Website Redesign That Actually Protects Your Municipality — What to Require, What to Watch Out For, What Contract Language Matters

If you've been following this series, you already know the landscape: most municipal websites in New Jersey have significant WCAG 2.1 AA compliance gaps, a DOJ Title II deadline is approaching in April 2027, and the municipalities doing accessibility well got there through deliberate decisions, not massive budgets. So let's say your municipality has decided to act. You're going to redesign your website, and you're going to do it right this time. That means issuing a Request for Proposal.

Here's where a lot of municipalities get into trouble — not because they chose the wrong vendor, but because they wrote the wrong RFP. The RFP is the single most important document in a municipal website redesign. It defines what you're buying, what standards the vendor has to meet, and what happens if they don't. A vague RFP gets you a vague website. A well-written one protects your municipality legally, financially, and operationally for years after the project is finished.

This blog walks through what your RFP should actually include, what most municipal RFPs get wrong, and what contract language you need to insist on before you sign anything.

Why the RFP Matters More Than You Think

Most municipal website RFPs are written by administrators, clerks, or IT staff who know they need a new website but haven't been through the process before — or went through it years ago when accessibility wasn't on anyone's radar. The result is usually a document that focuses on aesthetics, features, and cost, with accessibility mentioned in a single line somewhere near the bottom, if it's mentioned at all.

That's a problem, because the RFP is your leverage. Before you sign a contract, you have negotiating power. After you sign, you have whatever the contract says you have — nothing more. If the RFP doesn't specify WCAG 2.1 AA conformance as a deliverable, the vendor isn't obligated to provide it. If the contract doesn't include remediation timelines and accountability mechanisms, you have no recourse when the site launches with thirty accessibility failures on the homepage.

We've seen municipalities in Gloucester County and across New Jersey end up with inaccessible websites not because they hired bad vendors, but because they never told the vendor what accessible meant, never defined how it would be measured, and never put consequences in writing for failing to deliver it. The RFP is where you prevent that from happening.

Before You Write the RFP: Know What You Actually Need

Before you start drafting, your municipality should do a few things that will make the entire process smoother and produce a better outcome.

Audit your current site. You don't need a $20,000 professional audit at this stage. Run your homepage and five to ten of your most-visited pages through WAVE and Google Lighthouse. Document what comes back. This gives you a baseline — you'll know what's broken, how broken it is, and you'll be able to evaluate vendor proposals against real problems rather than abstract promises.

Identify your content. Municipal websites are content-heavy, and most of that content lives in PDFs, meeting minutes, agendas, ordinances, forms, and public notices. Before you ask a vendor to build you a new site, you need to understand the volume and condition of your existing content. How many PDFs are on the current site? Are any of them tagged for accessibility? Are you going to migrate all of them, or is this an opportunity to clean house? These questions directly affect scope, timeline, and cost, and a vendor can't answer them for you.

Designate a project lead. Someone on your staff needs to own this process — not just review proposals and pick a vendor, but serve as the point of contact throughout the project, make decisions when questions arise, and hold the vendor accountable to what they promised. This person doesn't need to be a web developer. They need to be organized, responsive, and empowered to make decisions without routing everything through a committee.

Understand the legal landscape. Your municipality is subject to ADA Title II. The DOJ's updated rule requires WCAG 2.1 Level AA conformance by April 2027 for municipalities with populations under 50,000 — which covers the vast majority of New Jersey municipalities. Your RFP should reflect this requirement explicitly. Don't assume the vendor knows about it or will account for it automatically.

What Your RFP Should Include

Here's what separates a municipal website RFP that protects you from one that doesn't.

A Clear Accessibility Standard With No Ambiguity

Your RFP should state, in plain language, that the delivered website must conform to WCAG 2.1 Level AA. Not "should follow accessibility best practices." Not "will be designed with accessibility in mind." Not "will include an accessibility widget." The standard is WCAG 2.1 Level AA, and it should be named explicitly as a deliverable, not an aspiration.

This matters because vague language gives vendors room to deliver something that looks accessible but isn't — a site that has an overlay installed, or that passes a single automated scan but fails when tested with an actual screen reader. Specificity protects you. If the contract says WCAG 2.1 AA and the delivered site doesn't conform, you have grounds to require remediation. If the contract says "accessible" with no definition, you're in an argument about what that word means.

Your RFP should also require that the vendor describe, in their proposal response, exactly how they plan to achieve and verify conformance. What testing tools do they use? Do they conduct manual testing with assistive technologies? Do they test with actual screen readers, or just run automated scans? Do they have staff with accessibility expertise, or do they subcontract it? These questions separate vendors who understand accessibility from vendors who treat it as a checkbox.

Scope That Covers Documents, Not Just Pages

One of the most common gaps in municipal website RFPs is that they focus entirely on the website's pages and templates while ignoring the documents that make up the bulk of what residents actually interact with. Your municipality probably has hundreds or thousands of PDFs on its current site — meeting minutes, ordinances, applications, public notices, budgets, RFPs of your own. If your new website launches with a fully accessible front end but every linked PDF is a scanned image with no text layer and no tagging, you haven't solved the problem.

Your RFP should address document accessibility directly. At minimum, it should require that the vendor's content management system supports accessible PDF uploads and provides guidance or tooling for creating tagged, accessible documents going forward. Ideally, it should also include a scope item for remediating a defined set of existing documents — your most critical and most-accessed PDFs — as part of the project.

If full document remediation isn't in the budget, that's understandable, but the RFP should still require the vendor to deliver a documented process for how your staff will create and upload accessible documents after launch. Training should be part of the deliverable, not an upsell.

A Defined Testing and Acceptance Process

Your RFP should describe how the finished site will be evaluated before your municipality accepts it. This is the part most municipal RFPs leave out entirely, and it's the part that matters most when something goes wrong.

Specify that the delivered site will be tested for WCAG 2.1 AA conformance using both automated tools and manual testing methods before final acceptance. Require the vendor to provide a VPAT (Voluntary Product Accessibility Template) or equivalent accessibility conformance report as a deliverable. State that your municipality reserves the right to conduct its own independent accessibility evaluation — or hire a third party to do so — and that any issues identified during that evaluation must be remediated by the vendor within a defined timeframe before the site is considered complete.

This creates accountability. Without a defined testing and acceptance process, you're relying on the vendor to self-certify that their own work meets the standard. That's not a position any municipality should be in.

Requirements for the Content Management System

The website your vendor builds is only as accessible as the content your staff puts into it after launch. Your RFP should require that the content management system enforces or supports accessible content creation. That means requiring alt text fields for every image upload, providing accessible templates for pages and posts, supporting proper heading hierarchy in the content editor, and making it difficult — ideally impossible — for staff to publish content that breaks basic accessibility rules.

Ask vendors to describe what guardrails their CMS provides. Can a staff member upload an image without alt text? Can they publish a page with no heading structure? Can they paste in content from Word that brings along inaccessible formatting? The answers to these questions will tell you a lot about whether the vendor has thought about accessibility as a long-term practice or just a launch-day deliverable.

Mobile Accessibility as a Requirement, Not an Afterthought

The DOJ's Title II rule specifically requires that municipal websites work on mobile devices. Your RFP should require responsive design that's been tested on actual mobile devices — not just a desktop layout that reflows. Specify that all interactive elements must have touch targets of at least 44x44 pixels, that forms must be usable on mobile without horizontal scrolling, and that the mobile experience must meet the same WCAG 2.1 AA standard as the desktop experience.

This is worth calling out separately because many vendors treat mobile as a visual concern — does it look right on a phone? — rather than an accessibility concern. A site can look fine on mobile and still be unusable for someone navigating with a switch device or screen reader on a phone. Your RFP should make clear that mobile accessibility is a functional requirement, not a cosmetic one.

Training and Documentation Deliverables

Your staff will be managing this website long after the vendor finishes building it. Your RFP should require the vendor to provide training on accessible content creation and CMS management, along with written documentation that staff can refer to after the training is over.

Training should cover how to write meaningful alt text, how to create properly structured headings, how to upload accessible PDFs, how to add captions to video content, and how to use the CMS's built-in accessibility features. Documentation should be specific to your site and your CMS, not generic accessibility guides pulled from the web. And both should be included in the project scope and cost, not treated as optional add-ons.

Ongoing Support and Maintenance Terms

A website redesign isn't a one-time event — it's the beginning of an ongoing relationship with the platform and, in many cases, with the vendor. Your RFP should ask vendors to describe their post-launch support offerings, including how they handle accessibility issues discovered after launch, what their response times are for critical bugs, and whether ongoing accessibility monitoring is included or available.

This is particularly important because accessibility is not static. Content changes. Staff turns over. New features get added. Browser and assistive technology updates can break things that were working. If your contract ends the day the site launches, you're on your own — and most municipalities don't have the internal expertise to maintain WCAG compliance without some level of external support.

What to Watch Out For in Vendor Proposals

Once your RFP is out and proposals start coming in, here's what to look for — and what should raise red flags.

Overlay solutions presented as compliance. If a vendor's accessibility strategy is to install an overlay widget — AccessiBe, UserWay, EqualWeb, or similar — that's a disqualifying answer. Overlays don't fix underlying code issues. They don't make PDFs accessible. They've been the subject of hundreds of ADA lawsuits and have been explicitly rejected by the disability community and, increasingly, by courts. A vendor who proposes an overlay either doesn't understand accessibility or is hoping you don't.

Vague language about accessibility. Watch for proposals that say the site will be "designed with accessibility in mind" or will "follow best practices" without naming WCAG 2.1 AA specifically or describing a concrete testing methodology. If the proposal doesn't get specific about how conformance will be achieved and verified, the vendor is leaving themselves room to deliver something that doesn't actually meet the standard.

No mention of manual testing. Automated tools catch roughly 30 to 40 percent of WCAG issues. The rest require manual testing — keyboard navigation, screen reader testing, cognitive walkthrough, review of dynamic content and interactive elements. If a vendor's testing plan begins and ends with an automated scan, they're not testing for real-world accessibility.

Accessibility treated as a separate line item. Be cautious of proposals that treat accessibility as an add-on package or an optional upgrade. Accessibility should be woven into every phase of the project — design, development, content creation, testing, launch. A proposal that separates it out is telling you that the vendor's default process doesn't include it.

No examples of accessible work. Ask vendors to provide examples of municipal or government websites they've built that conform to WCAG 2.1 AA. Then test those sites yourself. Run them through WAVE. Try navigating them with a keyboard. If the vendor's portfolio sites have obvious accessibility failures, that tells you more than anything in their proposal.

Contract Language That Protects You

The contract is where everything in the RFP becomes enforceable. Here are the provisions that matter most.

A conformance warranty. The contract should include a warranty that the delivered website conforms to WCAG 2.1 Level AA at the time of launch. This warranty should survive acceptance — meaning if issues are discovered after you've accepted the site, the vendor is still obligated to fix them within a defined warranty period. Twelve months is a reasonable minimum.

Remediation obligations with timelines. The contract should specify that any WCAG 2.1 AA conformance failures identified during the warranty period will be remediated by the vendor at no additional cost, within defined timelines. Critical issues — those that prevent a user from completing a core task — should have a shorter remediation window than minor issues. Put actual numbers here: five business days for critical issues, fifteen for moderate, thirty for minor. Whatever you agree on, get it in writing.

Indemnification for accessibility claims. If your municipality gets sued or receives a complaint because the website the vendor built doesn't meet WCAG standards, the vendor should bear responsibility for the deficiency they created. Your contract should include an indemnification clause that covers accessibility-related legal claims arising from the vendor's failure to deliver a conformant site. This is not unusual in government contracts, but it's frequently missing from municipal website agreements.

Right to independent audit. The contract should preserve your municipality's right to conduct or commission an independent accessibility audit at any time, and should require the vendor to cooperate with the auditor and remediate any verified conformance failures.

Escrow or source code access. If the vendor goes out of business, gets acquired, or simply becomes unresponsive, your municipality needs to be able to maintain and modify its own website. The contract should include provisions for source code access or escrow, particularly if the site is built on a proprietary platform.

Clear deliverable definitions. Every deliverable in the contract should be defined specifically enough that you can determine whether it's been delivered. "An accessible website" is not a defined deliverable. "A website that conforms to WCAG 2.1 Level AA as verified by automated testing using WAVE and axe, manual keyboard navigation testing, and screen reader testing using NVDA, with a completed VPAT delivered to the municipality before final acceptance" — that's a defined deliverable.

A Note on Cost

Municipalities frequently ask what a WCAG-compliant website redesign should cost. The honest answer is that it depends — on the size and complexity of the site, the volume of content to be migrated, the amount of document remediation involved, the level of customization, and the vendor's pricing model.

But here's what's worth knowing: accessibility done right at the beginning of a project adds a relatively modest amount to the total cost — typically in the range of 10 to 20 percent over what you'd spend on the same site without accessibility considerations. Accessibility retrofitted after the fact costs significantly more, both in direct remediation expenses and in the legal and reputational risk you carry in the meantime. And an accessibility lawsuit or DOJ complaint costs more than either.

The municipalities we profiled in our last post — Montgomery Township, Princeton, Hoboken — didn't spend dramatically more than their peers. They spent more deliberately. A well-written RFP is how you make sure your municipality does the same.

The Bottom Line

Your RFP is your protection. It's the document that defines what you're buying, how it will be measured, and what happens when something goes wrong. A municipal website redesign is a significant investment for any local government, and for most municipalities, it's a decision you'll live with for five to ten years. Getting the RFP right means getting the website right — and getting the website right means serving every resident in your community, including the ones who depend on accessibility to interact with their local government at all.

Don't leave accessibility to the vendor's good intentions. Put it in the RFP. Put it in the contract. Define it, measure it, and hold people accountable for it. That's how the leading municipalities in New Jersey are doing it, and it's how every municipality should.

Ritner Digital helps New Jersey municipalities write RFPs that protect them and build websites that serve every resident. Whether you need help scoping a redesign, writing accessibility requirements into your procurement documents, or evaluating vendor proposals, we can help you get it right from the start. Let's talk.

Frequently Asked Questions

We Already Have a Vendor Under Contract. Is It Too Late to Add Accessibility Requirements?

It's not too late, but it's harder. If your current contract doesn't include specific WCAG conformance requirements, you'll likely need to negotiate an amendment or a separate scope of work for accessibility remediation. Start by running your site through WAVE and documenting the issues, then approach your vendor with a clear list of what needs to be fixed and a request for a remediation proposal. If they're unwilling or unable to do the work, that's important information as you plan for your next contract cycle. The worst option is doing nothing and hoping no one notices — the DOJ's April 2027 deadline doesn't care when your contract was signed.

Should We Require a Specific CMS Platform in the RFP?

Generally, no. It's better to specify functional requirements — including accessibility requirements — and let vendors propose the platform that best meets those requirements. If you require a specific platform, you limit your vendor pool and you take on the risk of that platform's limitations. That said, if your municipality has strong reasons for preferring a particular platform — existing staff familiarity, interoperability with other systems, a cooperative purchasing agreement — you can name it as a preference without making it a requirement. What matters more than the platform is whether the vendor can demonstrate that their proposed solution meets WCAG 2.1 AA and supports accessible content creation by your staff.

How Do We Evaluate Vendor Accessibility Claims if We Don't Have Technical Expertise?

Ask them to show, not tell. Request URLs of live sites they've built and test those sites yourself using free tools. WAVE will show you alt text issues, contrast failures, and structural problems. Keyboard navigation testing requires no special tools — just try tabbing through the site without a mouse. If the vendor's own portfolio sites have obvious accessibility failures, their proposal language doesn't matter. You can also include in your RFP a requirement that the vendor conduct a live accessibility demonstration as part of the evaluation process, walking your team through how the site works with a screen reader and keyboard navigation.

What Should We Budget for Accessibility in a Website Redesign?

Accessibility shouldn't be a separate budget line — it should be integrated into the project cost. When it's built in from the start, it typically adds 10 to 20 percent to the total project cost compared to a redesign that ignores accessibility. The more significant cost variable is usually document remediation — if your municipality has hundreds of inaccessible PDFs that need to be brought into conformance, that's a substantial scope item. Ask vendors to break out their costs so you can see what's included for accessibility-specific work, but be wary of proposals where accessibility appears as a small add-on. That usually means it's not deeply integrated into their process.

Do We Need to Hire an Independent Accessibility Auditor?

You don't strictly need to, but it's strongly recommended — especially for the pre-acceptance evaluation of a new site. A professional WCAG audit costs a fraction of what you're spending on the redesign and gives you an independent, expert assessment of whether the vendor delivered what they promised. Think of it as the web accessibility equivalent of a building inspection before you accept construction work. Some municipalities build the cost of an independent audit directly into the project budget. Others use their right-to-audit clause and engage an auditor only if they have concerns. Either approach works, but having the option in your contract is essential.