Website Accessibility Checklist Before Launch

Why accessibility belongs in launch QA

Accessibility sits inside the same system as conversion and maintainability.

A button with poor contrast hurts buyers who scan the page in sunlight. A broken focus state traps keyboard users. A vague form error costs demo requests. A heading structure built for decoration makes the page harder to understand for assistive technology and for humans skimming under pressure.

Your team should not test accessibility after launch as a separate cleanup project. Test it while designers, developers, and content owners can still fix templates, components, and CMS rules in one pass.

Custom sites create leverage here. Fix the accessible card component once and every resource card improves. Add required alt text rules in the CMS and editors stop guessing. Build form errors the right way and every lead path gets safer.

The short version: what to check

Use this as the release gate before a new website, redesign, migration, or CMS rebuild goes live.

Start with revenue and trust paths

Do not begin with every low-value archive page. Start where a real person makes a decision:

• homepage
• service or solution pages
• pricing or plan pages
• demo, contact, and booking pages
• comparison pages
• high-intent blog posts
• case studies with approved proof
• resource pages used by sales
• legal, privacy, and trust pages

Then test the templates that create many pages. A broken blog template can repeat the same accessibility issue across every article. A bad card component can affect case studies, resources, integrations, and landing pages.

Virdis treats this as a systems check because accessibility defects often come from handoff gaps. Strategy defines the page job. Design defines visual hierarchy. Development builds interaction. The CMS keeps it alive after launch.

Test the site without a mouse

Keyboard testing finds problems automated tools miss.

Open the production candidate in a browser. Put the mouse aside. Use Tab, Shift Tab, Enter, Space, and Escape. Move through the homepage, navigation, dropdowns, forms, modals, cookie banner, and core CTAs.

Check these items:

• The skip link appears and works if the page needs one.
• The tab order follows the visual order.
• Every interactive element can receive focus.
• Focus states are visible against the page background.
• Menus open and close with expected keys.
• Modals trap focus while open and return focus when closed.
• Escape closes overlays where users expect it.
• The current page or selected state uses more than color.

If a buyer cannot book a call without a mouse, the site is not ready.

Check contrast in real components

Color contrast problems hide inside polished design systems. Brand palettes can pass in a style tile and fail inside buttons, badges, overlays, disabled states, and chart labels.

Test contrast across:

• body text
• small captions
• buttons and hover states
• navigation links
• form labels and helper text
• error states
• cards on tinted backgrounds
• testimonial or case study modules
• chart labels and icons that carry meaning

Do not test color values in isolation. Test the component in the layout where people will use it. A green button on white may pass. The same button on a gradient or image may fail.

Use WCAG 2.2 as the baseline reference, then make product decisions for the actual audience and page context. If the page asks someone to trust the company, the content needs to be easy to read.

Fix headings before content freeze

Headings are not decoration. They tell people how the page works.

Each priority page needs one clear H1. The rest of the headings should describe the sections in order. Do not skip from H2 to H5 because a smaller style looked better in the design file. Style the heading in CSS. Keep the structure useful.

Check these items:

• One H1 appears on the page.
• The H1 matches the page intent.
• H2s name the major sections.
• H3s support the H2 above them.
• Repeated components do not inject random headings.
• Hidden headings still help, not confuse.
• CMS editors cannot create a broken structure with one rich text field.

This matters for screen readers. It also matters for impatient buyers. Clear headings make the page easier to scan, easier to edit, and easier to maintain.

Write alt text as part of content QA

Alt text should explain the meaning of an image in context.

A product screenshot may need a short description of the interface and the point it supports. A headshot may need the person's name. A decorative gradient should use empty alt text so assistive technology can skip it.

Check these items:

• Informative images have useful alt text.
• Decorative images use empty alt text.
• Icons that carry meaning have labels.
• Linked images describe the link destination or action.
• CMS image fields include alt text guidance.
• Editors cannot publish key images without reviewing the alt field.

Bad alt text creates noise. Missing alt text can hide meaning. Treat the field like content, not a box to appease an audit tool.

Make forms usable under stress

Forms often carry the money path. They deserve more than a visual check.

Test demo forms, contact forms, newsletter forms, account forms, gated asset forms, and any form embedded through a third-party tool.

Check these items:

• Every input has a persistent label.
• Required fields are clear before submission.
• Error messages explain the fix.
• Error messages connect to the fields they describe.
• Success states confirm what happened.
• The form works by keyboard.
• The form does not erase valid entries after one mistake.
• CAPTCHA or spam controls do not block users without a fallback.
• Analytics events do not fire false submissions.

A form error should tell the user what to do next. “Invalid input” is not enough. “Enter a work email address” helps.

Check links, buttons, and CTAs in context

Generic labels create friction.

“Learn more” works when the surrounding context makes the destination clear. In a grid of cards, repeated “Learn more” links can become useless for assistive technology. Buttons should describe actions. Links should describe destinations.

Check these items:

• CTA labels match the action.
• Repeated links have enough context.
• Icon buttons have accessible names.
• External links behave with intent.
• Download links name the file type when that matters.
• Disabled buttons explain what the user needs to do.

This is conversion work as much as accessibility work. Clear labels reduce hesitation.

Respect reduced motion

Motion can help a site feel polished. It can also make a site harder to use.

Audit animations, scroll effects, video backgrounds, carousels, counters, marquees, loading states, and page transitions. Then test the site with reduced-motion preferences enabled.

Check these items:

• Nonessential animation reduces or stops when users request reduced motion.
• Autoplaying media has a clear control.
• Carousels do not steal focus.
• Motion does not hide content or delay a CTA.
• Loading states do not trap screen reader users.

If animation makes the buyer wait to act, the animation is serving the wrong master.

Test the CMS before editors touch it

Accessibility can decay after launch if the CMS has no guardrails.

A custom website should help editors publish clean content without remembering every rule. That means fields, validation, helper text, previews, and component choices need the same QA pass as the front end.

Check these CMS items:

• Image fields include alt text guidance.
• Required content fields match the template needs.
• Rich text options do not allow fake headings for style.
• Button labels have character guidance.
• Components preview real states, not perfect placeholder content.
• Empty fields have safe fallbacks.
• Authors can test a draft before publishing.

This is where maintainability shows up. A site that launches clean and decays in the CMS was not finished.

Use automated tools, then do the human pass

Automated tools help. They do not replace judgment.

Run an accessibility checker against priority pages and templates. Use it to catch missing labels, contrast failures, heading issues, ARIA mistakes, and common HTML defects. Then test the page yourself with keyboard navigation and real content.

The human pass catches the problems that need context:

• Does this alt text explain the right thing?
• Does this CTA make sense outside the visual layout?
• Does this error message help someone recover?
• Does this animation get in the way?
• Does this CMS field protect the template after launch?

Tools can identify many defects. Your team still has to decide what the page should do.

Build accessibility into the launch checklist

Accessibility QA should happen in three moments.

First, test components while the design system and front-end patterns are still active work. Second, test templates after real content enters the CMS. Third, test the production candidate after content freeze.

Assign owners:

• Design owns contrast, focus visibility, hierarchy, and motion intent.
• Development owns semantic HTML, keyboard behavior, ARIA use, and component states.
• Content owns headings, link labels, alt text, and plain-language errors.
• Strategy owns the priority path and launch risk.

One person can coordinate the pass. The work still crosses roles.

Common launch mistakes

Watch for these before the deploy goes out:

• navigation works by mouse but not keyboard
• focus styles removed for aesthetics
• form errors shown by color alone
• placeholder alt text shipped in CMS content
• image-heavy hero sections with weak contrast
• repeated “Learn more” links in card grids
• modals that trap users with no Escape behavior
• carousels that auto-advance without controls
• headings chosen by size instead of structure
• accessibility checks stop at the homepage

Most of these issues are cheap to fix before launch. They become political after launch because the team has moved on.

What Virdis checks before a custom site ships

For Virdis, accessibility QA sits next to performance, metadata, analytics, sitemap, robots.txt, and CMS checks. It is part of building a website the team can operate.

The practical goal is simple: the page should work for more people, in more contexts, with fewer fragile handoffs. That requires design taste, front-end discipline, content clarity, and CMS rules that survive launch week.

If you are planning a custom website or rebuild, do the accessibility pass before launch. It is easier to fix the system while the team still has the hood open.

Frequently asked questions

Is this checklist a WCAG compliance audit?

No. This is a practical launch QA checklist based on common accessibility risks and WCAG-informed checks. For legal compliance or formal certification, work with a qualified accessibility specialist.

Should accessibility testing happen before or after content entry?

Do both. Test components early, then test templates with real content before launch. Real CMS content exposes broken headings, weak alt text, vague CTAs, and missing fallbacks.

Can automated accessibility tools find every issue?

No. Automated tools catch many technical defects, but they cannot judge whether alt text, CTA labels, error messages, and page structure make sense for the user.

Who should own accessibility QA during a website launch?

A single owner should coordinate the pass, but design, development, content, and strategy all own part of the work. Accessibility breaks when one role treats it as someone else's cleanup.

Does accessibility affect conversion?

Accessibility can remove friction from key paths like navigation, forms, CTAs, and content scanning. Do not treat it as a guaranteed conversion lift. Treat it as part of making the site usable.