Accessibility audit after converting a Framer site

A converted Framer site has the same accessibility as the published site it came from: the conversion keeps the structure, text, alt text and interactions, so it neither fixes nor adds problems. What changes is that you can now fix them in code. Run an automated check with axe on every page type, then do a short manual pass for keyboard use, headings, alt text, form labels, contrast and motion, and fix what you find in the views and components.

This checklist uses a Next.js project from Deframer; it applies equally to the TanStack Start, Astro, React Router and Vite exports. Deframer is an independent tool and is not affiliated with, endorsed or sponsored by Framer. It converts only sites you own or have permission to convert. This post is practical guidance, not legal advice; if you have a legal accessibility obligation, check the standard that applies to you.

Why audit after converting?

On Framer, some accessibility fixes are hard or impossible: the markup a component produces is the editor's, and you work around it. In code, every element is yours. A conversion is also a natural checkpoint: the team is already reviewing every page, and fixes made now carry forward. The target most teams use is WCAG 2.2 level AA.

Step 1: Automated checks with axe

Automated tools find maybe a third of real problems, but they find them quickly and repeatably. Add axe to Playwright:

npm install -D @playwright/test @axe-core/playwright

// tests/a11y.spec.ts
import { test, expect } from "@playwright/test";
import AxeBuilder from "@axe-core/playwright";

const routes = ["/", "/about", "/blog", "/blog/first-post", "/contact"];

for (const path of routes) {
  test(`a11y ${path}`, async ({ page }) => {
    await page.goto(path);
    const results = await new AxeBuilder({ page })
      .withTags(["wcag2a", "wcag2aa", "wcag21aa", "wcag22aa"])
      .analyze();
    expect(results.violations).toEqual([]);
  });
}

Take the routes from the project README's routes table. Run it once at desktop width and once at 390 pixels, because breakpoints are separate layouts in the converted project and a phone layout can have its own problems. If you already have visual regression tests, this sits next to them.

The first run will likely fail. Don't fix violations one by one; group them by rule, because most come from one shared component used on every page.

Step 2: The manual checklist

Work through these on the home page, one content page, a CMS detail page and the contact page.

Keyboard

• Press Tab from the top of the page. Every link, button and form field should receive focus in a sensible order.
• Focus must be visible. Framer designs often remove outlines; if yours did, add a :focus-visible style to the relevant CSS modules or a global rule.
• Open and close the mobile menu with the keyboard alone. Check that Escape closes overlays and that focus doesn't get lost behind them.
• Carousels, tabs and accordions must be operable without a mouse.

Headings and landmarks

• One h1 per page, then a logical order. In Framer, the heading level is a setting on the text layer, separate from how it looks, so designers sometimes set every large text as h1 or use paragraphs styled as headings. In the converted views, change the element, not the class: the text style class keeps the look.
• Page regions should use header, nav, main and footer. Check the layout templates in src/layouts and the root layout.
• Add a "Skip to content" link if the navigation is long.

Images and icons

• Every meaningful image needs alt text that says what it shows; decorative images need empty alt (alt=""). Alt text set in Framer comes across; missing alt text stays missing.
• Icons that are the only content of a link or button need an accessible name, such as aria-label="Open menu".
• Text baked into images can't be read by screen readers. Make it real text or put it in the alt.

Forms

• Every field needs a label a screen reader can find: a visible <label> or, at least, an aria-label. Placeholder text alone isn't a label.
• Errors should be announced and say how to fix the problem.
• The converted forms post to the project's own API route, with a hidden honeypot field for spam. That field is meant to be hidden from people; keep it out of the tab order and hidden from assistive technology if your audit flags it. Migrating Framer forms covers the form routes.

Colour and contrast

• Body text needs a contrast ratio of at least 4.5:1, large text 3:1. Check text on images and gradients by hand; tools can't always compute those.
• Colours are tokens in src/styles/tokens.ts. Fixing a low-contrast grey there fixes it everywhere, but check the design still works, and agree on it with the designer.
• Don't rely on colour alone: links in body text need an underline or another cue.

Motion

• Framer sites often have appear effects, scroll transforms and parallax. People with vestibular disorders can get sick from large motion.
• The converted project keeps the site's reduced-motion setting from Framer in its site tables. Turn on "Reduce motion" in your operating system and check that large movements stop or shrink. If they don't, the animations guide shows where motion is configured; motion's useReducedMotion hook is available for your own components.
• Autoplaying video or carousels need a pause control.

Zoom and reflow

• Zoom the browser to 200% and to 400% at desktop width. Content should reflow without horizontal scrolling or overlapping text. Fixed heights in CSS modules are the usual culprit.

Step 3: Screen reader spot check

Spend fifteen minutes with a screen reader: VoiceOver on macOS or iOS, NVDA on Windows, TalkBack on Android. Read the home page from top to bottom, then navigate by headings and by landmarks. You'll hear problems no checker reports: duplicated link text ("Learn more" five times), decorative text read aloud, or a menu announced in the wrong order.

Step 4: Fix in the right file

Each breakpoint is its own layout, so a fix to the Desktop variant of a component may need repeating for Tablet and Phone. Search the component file for the element before you call it done.

Step 5: Keep it fixed

• Keep the axe test in CI so new violations fail the build.
• Add accessibility to your code review checklist.
• Tell AI coding tools the rules in your AGENTS.md, for example "every image needs alt text; never remove focus styles".
• Re-audit after design changes, especially new components.