Title II Website Accessibility Checklist

Website Pages

• Every meaningful image has alt text that says what the image shows. Decorative images are marked decorative.
• Every page can be fully used with a keyboard alone: no mouse, no traps, a visible focus indicator.
• Text meets the contrast minimums. No light gray on white, no gold on cream.
• Pages use real coded headings in logical order, one h1 per page.
• Link text says where the link goes. No bare "click here" or "read more."
• Nothing conveys information by color alone, and nothing flashes more than three times per second.

PDFs and Documents

• Documents have real, selectable text, not scanned images of paper.
• PDFs are tagged with headings, lists, and a logical reading order, and tables have header rows.
• Each document has a title and a set language.
• Anything residents use to apply for or access a current service is accessible, even if it is old.
• Outdated documents are removed or properly archived rather than left to fix.
• Where possible, content is published as a web page instead of a PDF in the first place.

Forms

• Every field has a coded label that screen readers announce, not just placeholder text.
• Required fields are marked in text, not by color or an unexplained asterisk.
• Error messages say in words what went wrong and where, and focus moves to the problem.
• The whole form, including date pickers and dropdowns, works by keyboard.
• Time limits can be extended, and a session timeout does not silently destroy someone's work.

Videos

• Prerecorded videos have accurate, edited captions. Auto-captions alone do not pass.
• Live streams, like council meetings, have live captions.
• Videos where the visuals matter have audio description or a described alternative.
• The video player itself is keyboard operable, and nothing autoplays with sound.

Third-Party Tools

• You have a list of every embedded or linked tool residents use: payments, agendas, registration, library catalog, GIS maps.
• You know which ones you provide or make available, because the rule makes those your responsibility even when a vendor runs them.
• Each vendor has stated their WCAG 2.1 AA status in writing, ideally with a current ACR or VPAT document.
• You have spot-tested the highest-traffic vendor tools yourself rather than taking the brochure's word for it.

Mobile Apps

• You have inventoried every app offered in your entity's name, including vendor-built ones.
• Apps work with the platform screen readers, VoiceOver and TalkBack.
• Content works in portrait and landscape, and text can be enlarged without breaking the layout.
• Buttons and controls are labeled, and nothing requires a complex gesture with no alternative.

Procurement and Vendor Questions

• New contracts and renewals require WCAG 2.1 AA conformance in writing.
• RFPs score accessibility, and you ask vendors how they tested, not just whether they comply.
• Contracts say who fixes accessibility defects and how fast.
• Someone reviews vendor claims before signature, the same way legal reviews indemnification.

Ongoing Maintenance

• A written accessibility policy names who is responsible for what.
• Staff who post content are trained, and new hires get the same training.
• Automated scans run on a schedule, and someone owns the findings.
• New pages, documents, and tools are checked before launch, not after complaints.
• Residents have an easy, published way to report a barrier, and reports get answered.

If several of these sections came up short, that is normal, and it is exactly what the 11 first steps are designed to work through in order.