The pre-launch accessibility checklist I run on every site

If you run a digital agency or build websites for clients, you need to establish a quality gate: what should I check for accessibility before launching?

Too many agencies design a beautiful client site, publish the files, and move on to the next project. Then, six months later, the client receives an ADA Title III lawsuit summons.

The client is angry, blames the agency, and demands a free fix. You are forced to pull developers off active projects to remediate legacy code for free, destroying your project profit margins and damaging your professional reputation.

To prevent this, you must implement a repeatable accessibility checklist before any website goes live. Shipping an accessible site is far cheaper and easier than trying to fix a broken one after the lawyers have found it.

The agency quality gate: why automated scans are not enough

Many developers think they are compliant if they run a Google Lighthouse audit and get a green score.

This is a dangerous assumption. Automated accessibility tools (like Lighthouse or the axe browser extension) are useful, but they only catch between 30% and 40% of all WCAG violations. They can tell you if an image is missing an alt tag, but they cannot tell you if the alt text actually describes the image. They cannot check if your custom mobile navigation menu contains a keyboard trap.

To protect your clients, your pre-launch check must combine automated scans with manual testing.

Here is the exact six-step checklist I run before any site launches.

The pre-launch accessibility checklist

1. The image alt text pass

Do not let a site ship with raw file names or missing alt tags.

• Audit: Check every image on the site. Ensure all meaningful photos have descriptive, context-rich alt text.
• Decoration Check: Verify that purely decorative images, background grids, or icons have explicit alt="" tags. This ensures screen readers skip them instead of reading out file paths.

2. The keyboard operability check

Unplug your mouse and test the site using only the Tab, Shift+Tab, and Enter keys.

• Focus Indicators: Ensure every link, button, and input field has a visible, high-contrast focus ring when highlighted. If you see focus outlines disappear, find and delete any outline: none CSS rules.
• Logical Sequence: Verify that the tab focus moves in a logical order, typically from left to right and top to bottom.
• Component Test: Verify that dropdown menus expand, slider elements advance, and mobile overlays close using standard keyboard keys.
• Trap Check: Ensure users cannot get stuck inside slide-out shopping carts or cookie consent banners. Pressing the Escape key should close these elements and return focus to the parent page.

3. The color contrast audit

Ensure all text is legible for users with low vision or color blindness.

• Ratios: Run the stylesheet colors through a contrast checker. Verify that all standard text has a contrast ratio of at least 4.5:1 against its background. Large headers (18px+ bold or 24px+ normal) must have a ratio of at least 3:1.
• Forms: Ensure input borders have a contrast ratio of at least 3:1 against the surrounding page colors so users can identify where to click.
• No Color-Only Cues: Ensure that links inside paragraphs are underlined, and that form error states include warning icons or text messages, rather than relying solely on red text to show errors.

4. The form and checkout audit

Forms are where conversions and lawsuits collide. Pay close attention to input fields.

• Programmatic Labels: Every input field must have a visible <label> element linked to the input's ID using the for attribute.
• No Placeholders as Labels: Do not rely on placeholder text inside the input box to label fields. The label must remain visible when the user begins typing.
• Validation Messages: Ensure all validation error messages are placed inside an aria-live region or linked to the input using aria-describedby so screen readers read the error automatically.

5. The structural outline audit

Ensure search engines and screen readers can parse the document hierarchy.

• Single H1: Verify that each page contains exactly one H1 tag (typically the main page title).
• Logical Order: Ensure that headings follow a strict hierarchy (H1 leads to H2, which leads to H3). Never skip levels (such as H2 directly to H4) for visual styling purposes.
• Semantic tags: Check that the page outline uses HTML5 structural elements (<header>, <nav>, <main>, <footer>) instead of generic nested divs.

6. The screen reader dry run

The final test is a real-world simulation. Turn on your device's built-in screen reader (VoiceOver on macOS/iOS or Narrator on Windows).

Close your eyes, load the staging site, and try to navigate your main menu, select a product or service, fill out the booking form, and submit it.

If you get lost, hear confusing file names, or cannot select the form inputs, your layout has a barrier. Document the step and send it back to the design team for adjustments.

Making compliance standard agency policy

Do not treat this checklist as an optional step. Make it a mandatory gateway in your agency's deployment process. The lead developer must sign off on the accessibility checklist before the DNS records are updated.

Investing an extra hour in pre-launch manual testing protects your project margins, secures your client's business from legal liability, and improves the site's organic SEO performance. If your development team needs help building this quality gate, a developer training and accessibility setup project can align your workflows. Ship compliant sites from day one.