Accessibility on municipal websites is usually treated as an audit to survive rather than a way of building. A template is chosen, content is added for years, and then a complaint or a review arrives and the town is asked to retrofit what it has. Retrofitting is the expensive way to do this, and it rarely reaches the documents, which is where most of the real problems are.
Illustration with invented content.
What we check before a site goes live
- Keyboard onlyEvery control reachable and operable without a mouse, in an order that makes sense.
- Visible focusYou can always see where you are. This is the rule most sites quietly break.
- StructureReal headings in order, landmarks, and link text that says where it goes.
- ContrastMeasured at the sizes text is actually set in, not in a swatch.
- FormsLabelled fields and errors that say what to fix rather than that something is wrong.
- Zoom and reflowReadable at 200 percent without losing content or sideways scrolling.
What residents get
Keyboard operability and a visible focus indicator are the two criteria most sites quietly fail, usually because somebody removed the outline for looking untidy. Every control here takes focus, shows it, and can be operated from the keyboard alone.
A page that looks structured and is not structured is the most common accessibility failure on municipal sites. Headings are headings rather than bold text, regions are marked, and links say where they go rather than "click here".
Documents are where the real problems are, and a scanned PDF from 2003 cannot be made accessible by conversion. We will tell you which ones need rebuilding rather than quietly migrating the problem.
Alt text, headings used as headings, and documents that were accessible before upload are decided by whoever posts them. We build the platform so the accessible path is the easy one, and we are clear that the rest is a shared responsibility.
What staff get
Landmarks, focus order, contrast and keyboard operability are built into the templates. An editor cannot undo them by writing a page, which is where most accessibility regressions actually come from.
The editor asks when an image says something and stays quiet when it is decoration. Asking every single time trains people to type anything at all to get past the prompt.
The editor produces proper heading levels, so nobody has to remember the rule. A screen reader user navigates by headings, and a page of bold paragraphs has none.
Documents are where the real problems are, and a scan of a 2003 ordinance cannot be fixed by conversion. We will tell you which ones need rebuilding rather than migrating the problem quietly.
What we will and will not claim
- We build and test to WCAG 2.1 Level AA, the standard the Department of Justice’s ADA Title II rule adopts, and check against WCAG 2.2 Level AA criteria. That is a standard to design against, not a certificate, and no honest vendor will tell you a site is permanently compliant once content starts being added
- Requirements generally cover documents, forms, maps and media as well as pages, which is why the document review matters as much as the template
- Where your town needs a formal accessibility statement and a way for residents to report a barrier, both are part of the build
Included in every TownFront site
This is part of the core product, not an add-on module. Every TownFront website includes it, and it is built to the same standard as the rest of the site: fast on an ordinary phone connection, navigable by keyboard, readable by a screen reader, and maintainable by your own staff.
See how this would work for your community. Request a conversation and we will walk through your current site and what changes.
What we test, and what the claim means
We say built and tested to WCAG 2.1 Level AA, the standard the Department of Justice’s ADA Title II rule adopts, and checked against WCAG 2.2 Level AA criteria, and we mean it literally. Templates and components are checked with automated tooling and then by hand: keyboard only, focus order, visible focus, heading structure, landmarks, form labels and error messages, contrast at the sizes text is actually set in, and behavior at 200 percent zoom.
We do not claim certified conformance, and we will not tell you a website makes a municipality permanently compliant. Nobody can promise that. Accessibility is a moving target on a live site: a scanned PDF, an untagged budget document, an embedded map, a third-party payment portal or a photo posted without alt text can each introduce a barrier the day after launch.
Who is responsible for what
- We handle the platform. Templates, components, navigation, forms, color, focus behavior and the editing patterns that make it hard to publish something inaccessible by accident.
- You handle the content. Alt text on photos, headings used as headings, meaningful link text, and documents that were accessible before they were uploaded.
- We help with documents. Your existing PDFs get reviewed during the move, and we will tell you plainly which ones need to be rebuilt rather than converted.
- Third-party embeds are a shared problem. A payment portal or mapping service you embed is governed by its vendor. We will flag what we can see and help you ask the right questions.
The rules that apply to you
The U.S. Department of Justice rule under Title II of the ADA sets WCAG 2.1 Level AA as the technical standard for state and local government web content and mobile apps. Compliance dates depend on population: entities of 50,000 or more, and special district governments, have different deadlines from smaller entities. Check the current dates against the source below rather than trusting a vendor’s summary, including ours.
WCAG 2.2 is backwards compatible with 2.1: the W3C states that content conforming to 2.2 also conforms to 2.1, subject to the standards’ own conformance requirements. Checking against the newer criteria as well is the simpler way to be sure of the version the rule adopts.
- ADA.gov: small entity compliance guide for the Title II web rule
- W3C: Web Content Accessibility Guidelines overview
Reporting a barrier
Every TownFront site ships with an accessibility statement and a way for a resident to report a problem to a person who can fix it. A route for complaints is part of the Title II expectation, and it is also the fastest way to find the barriers testing missed.