Accessibility conformance checklist before launching a public service

Reference article · 9 min read

Use this checklist in the weeks before a resident-facing website or application goes live, alongside functional acceptance testing. Defects found now are still inside the acceptance process, where the vendor or the project team is obligated to correct them. After launch they compete with everything else in the backlog, and residents who cannot finish a task have to call, visit, or complain instead.

A clean automated scan is not the goal. The record you want shows that each item was checked by a named person on a named date, that every failure has an owner and a target date, and that nothing left open prevents a resident from completing a task. Mark each item yes, no, or not applicable, and note the evidence beside every yes.

Scope, standard, and ownership

• The technical standard is named in writing. Check the contract, statement of work, or acceptance criteria for a named standard, version, and level. The Department of Justice rule under Title II of the ADA adopts WCAG 2.1 Level AA for the web content and mobile applications of state and local government entities, with compliance dates that depend on the size of the entity. If no standard is named, add one through a contract change or the acceptance criteria before testing starts, and confirm with counsel which compliance date applies to your entity.
• Everything in scope is listed. Check for a written inventory that covers page templates, shared components, forms, documents, mobile applications, and any handoff to a payment, scheduling, or identity service operated by someone else. If the inventory stops at "the website," add the missing items and re-estimate the test effort before testing starts.
• Every third-party component has a named owner for defects. For each embedded widget, iframe, or hosted page, check that a person or vendor is recorded as responsible for fixing accessibility defects in it. If no owner is recorded, raise it with the contract manager now and plan an accessible route to that service in case the defect is not fixed by launch.
• Exceptions are confirmed in writing, not assumed. The Title II rule includes a limited set of exceptions, including certain archived web content. Check that any exception your team is relying on has been reviewed and confirmed in writing by your ADA coordinator or counsel. If it has not been confirmed, test and remediate that content as though the exception does not apply.
• One person owns accessibility sign-off. Check the acceptance record for accessibility as its own line with a named approver, separate from general quality approval. If no one is named, ask the project sponsor to name someone before testing starts.

Structure, labels, and presentation

• An automated scan has run against every unique template. Check the scan report for at least one page per template plus the highest-traffic pages, and confirm the scan ran against the build you intend to deploy. If only a few pages were scanned, scan the rest, since one template fix usually clears the same issue on every page built from it.
• Page structure is marked up, not only styled. Check that headings nest in order without skipped levels, that landmarks identify the main regions of the page, and that lists are marked up as lists. If headings are styled text rather than heading elements, log the defect against the template rather than against each page.
• Every image, icon, and chart has a text alternative. Check that meaningful images carry alternative text describing their purpose or content, and that decorative images are marked so assistive technology skips them. If the alternative text is missing, is a filename, or repeats adjacent text, return the list of pages to the content owner with a due date before sign-off.
• Every form control has a persistent programmatic label. Check that each control has a label or accessible name that remains available once the field has content, and that radio and checkbox groups carry a group label. If a control is identified only by placeholder text, position, or color, log it as a defect against that form and hold sign-off on the form.
• Contrast, resize, and reflow meet the Level AA criteria. Check text and control boundaries with a contrast tool against the Contrast (Minimum) and Non-text Contrast criteria, and check the page at the zoom level and narrow width the Resize Text and Reflow criteria call for, with no horizontal scrolling or lost content. If the approved palette or layout cannot meet them, take it to whoever owns the design system, since page-by-page fixes will not hold.

Keyboard, screen readers, and forms

• Every primary task can be completed with the keyboard alone. Set the mouse aside and work each primary task end to end, recording where you get stuck. If a control cannot be reached or operated, treat it as a launch blocker unless another route to the same service is available.
• Focus is visible, ordered, and never trapped. Tab through each task and check that the focus indicator is visible against every background it crosses, that the order follows the reading order, and that Escape or a visible control closes each dialog and returns focus. If focus disappears or cannot leave a component such as a modal or date picker, fix that component before continuing, since it blocks the rest of the walkthrough.
• Custom components announce their name, role, and state. With a screen reader, check that something styled as a button is announced as a button, that an expanded menu reports that it is expanded, and that a selected option reports that it is selected. If a component does not, replace it with the native HTML element where one exists, and otherwise log the defect against the component library so every page using it gets the fix.
• Primary tasks have been walked with a screen reader. Check the test notes for at least one desktop screen reader and browser pair and one mobile pair, with a record of who tested, what pairs they used, and what failed. If no one on the team can run this, arrange a tester, and do not treat an automated scan as a substitute.
• Dynamic changes are announced. Check that result counts, filter updates, validation summaries, and save confirmations reach someone who is not watching the screen. If a change is conveyed visually only, add a live region or move focus to the new content, then retest that task.
• Errors are described in text, tied to the field, and suggest a correction. Submit each form with deliberate mistakes and check that the error text identifies the field, does not depend on color alone, says how to fix the problem, and that data already entered survives. If a single mistake clears the form, or the message only says that an error occurred, log it as a blocker for that form.

Documents, media, and go-live readiness

• Video is captioned and audio-only content has a transcript. Check that captions match the spoken audio and identify speaker changes, including any auto-generated captions, which need review and correction. If captions or a transcript are not ready, hold the media rather than the launch and publish it once it is done.
• Documents are tagged with a correct reading order, or another route to the service exists. Check that documents needed to complete a service have tags, a sensible reading order, and real text rather than an image of text. Prefer an HTML form over a PDF form where the service allows it. If a document cannot be remediated in time, publish another way to get the service and record the document as an open defect with an owner and a date.
• Purchased components carry a conformance report and a written remediation obligation. Check the vendor's accessibility conformance report against the version you are deploying and against your own test results. If the report is missing, out of date, or contradicted by your testing, send the vendor the specific failures and confirm what the contract requires before final payment.
• An accessibility statement is drafted and ready to publish. Check that it names the standard the agency is working to, discloses known nonconformance, explains how to report a barrier, and says who responds. If no statement is drafted, assign an owner and a publish date on the go-live plan, and reference your ADA coordinator and grievance procedure where those apply.
• An alternative way to receive the service is available and staffed. Check that the phone, counter, and mail options shown on the site are current, and that front-line staff know the service is launching and what to do when a resident cannot use it. If no alternative exists for a task, treat any unresolved barrier in that task as a launch blocker.

What to do with the results

Sort the failures into three groups before the release meeting rather than during it. A blocker prevents a resident from completing a primary task and has no reasonable alternative, so it stops the launch. A launch-window item is a real barrier with a workaround, and it gets a fix date inside a period agreed in advance. Everything else goes to a dated backlog and is reviewed alongside other defects.

Record each open item against the success criterion it fails, with a severity, an owner, and a date, and attach the checklist and its evidence to the acceptance record. If a complaint or a records request arrives later, that file shows what was checked, by whom, and what was known at launch. Content and code change after go-live, so schedule the next test and name who runs it before the project team disperses.

Frequently asked questions