AccessScanRun a free scan

Guide

Framer Accessibility: Building Sites That Pass WCAG 2.2 AA

Framer gives designers freedom that most code-first tools don't: pixel-level layout, native animation, and a canvas where anything can become anything. That same freedom is where Framer accessibility quietly breaks. A heading styled to look like a heading is not a heading. A clickable Frame is not a button. A scroll animation that feels delightful to you can be nauseating to someone with a vestibular disorder. None of this shows up in the preview, which is exactly why it ships.

This guide walks Framer designers through the five issues that cause the most real-world failures: semantic structure, focus order, alt text, animation and reduced motion, and contrast. Each maps to specific WCAG 2.2 criteria and to the European Accessibility Act baseline. To see which of these are live on your own site right now, run a free scan and fix the ranked results from the top down.

What Framer accessibility has to meet

The legal and technical baseline is WCAG 2.2 Level A and AA. The European Accessibility Act (Directive (EU) 2019/882) has applied since 28 June 2025 and references those success criteria through the European standard EN 301 549. For the US, the ADA names no specific WCAG version, but courts and settlements treat WCAG 2.1/2.2 AA as the working standard. The target is the same either way, and Framer can hit it — but the canvas won't enforce it for you.

WCAG 2.2 added criteria that matter directly to the kind of interactive, animated sites Framer is built for: 2.4.11 Focus Not Obscured (Minimum, AA), 2.5.7 Dragging Movements (AA), 2.5.8 Target Size Minimum (AA, 24x24 CSS pixels), and 3.2.6 Consistent Help (A). It also retired 4.1.1 Parsing, so old markup-validation advice no longer applies. Keep the new criteria in mind as you read on — they map cleanly to the sections below.

Semantic structure: stop styling, start tagging

The single most common Framer accessibility failure is text that looks structural but isn't. A 48px bold text layer reads as a page title to a sighted user and as plain paragraph text to a screen reader. Framer lets you assign a semantic tag to text and frames — use it. Set your page title to H1, section titles to H2, and subsections to H3, and never skip a level to get a font size you like. Style and structure are separate decisions.

  • One H1 per page, describing what the page is about — not your logo or a tagline.
  • Heading levels in order (H1, then H2, then H3); style controls size, the tag controls meaning.
  • Wrap your top navigation in a real nav element and the main content area in a landmark so screen-reader users can jump straight to it.
  • Lists of links or cards should be marked as lists, not a stack of loose frames.

The other half of structure is interactive semantics. A Frame with a click handler is announced as nothing useful — it has no role and often no keyboard access. Use Framer's link and button behaviors so the element renders as a real anchor or button, which gives you keyboard activation, focus, and the correct screen-reader announcement for free. If you build custom interactive components in code, follow established ARIA patterns rather than inventing roles.

Focus order and keyboard access

Every interactive element must be reachable and operable with the Tab key alone, and the focus order has to follow the visual reading order. Framer generally tabs in DOM order, which usually matches your layer stack — but absolute positioning, overlays, and reordered sections can scramble it. Tab through every page yourself: if focus jumps from the header to the footer and back up to a mid-page CTA, fix the structure, because that is the experience for keyboard and screen-reader users.

Two failures are especially common in Framer builds. First, the visible focus ring gets removed for aesthetics — don't. A clearly visible focus indicator is required (WCAG 2.4.7 Focus Visible, AA), and 2.4.11 Focus Not Obscured means a sticky header or cookie banner must not cover the focused element. Second, modals and menu overlays trap or lose focus: when an overlay opens, focus should move into it, Escape should close it, and Tab should not leak to the page behind. Also size tap targets to at least 24x24 CSS pixels (2.5.8 Target Size Minimum) — easy to miss on icon-only buttons and tight mobile menus.

Alt text for images, icons, and background frames

Framer images have an alt text field in the properties panel; fill it for every image that carries meaning. Describe the content and function, not the file — "Team reviewing an accessibility report on a laptop" beats "hero-image-final-v3." If an image is purely decorative, leave the alt empty so assistive tech skips it rather than reading a filename aloud.

  • Informative images: concise alt text describing what matters in context.
  • Decorative images and background frames: empty alt so they're ignored.
  • Icons that act as buttons (a bare hamburger or search glyph): give the control an accessible name like "Open menu," not the icon a description.
  • Text baked into an image: avoid it where possible; if unavoidable, repeat the text in the alt.

Watch background images set on Frames. Visually they're content, but Framer exposes no alt for them, so any meaning they carry is invisible to screen readers. If a background image is informative, move it to a real image layer with alt text, or convey the same information in nearby visible text.

Animation and reduced motion

Framer's animation tools are its signature feature and its biggest accessibility liability. Large parallax moves, auto-playing scroll effects, spinning transitions, and aggressive scaling can trigger nausea, dizziness, or migraines for people with vestibular disorders. WCAG 2.3.3 Animation from Interactions (AAA) and the broader motion guidance expect you to honor the user's stated preference. The browser exposes this through the prefers-reduced-motion media query, set in the operating system's accessibility settings.

Framer supports a reduced-motion option on its animation and appear effects — enable it so motion is dampened or removed when the user has asked for less. For animations you build in code components, wrap them in a check for prefers-reduced-motion and provide a calm fallback (a simple fade or an instant state change). Never make essential content appear only at the end of a long scroll animation; a reduced-motion user may never see it. The principle: motion should be an enhancement, never the only path to information.

Color contrast

Framer's design-led templates lean on low-contrast, on-trend palettes — light gray text on white, thin type over photographic heroes, ghost buttons with faint borders. These routinely fail. Under WCAG 1.4.3 Contrast (Minimum, AA), body text needs a contrast ratio of at least 4.5:1 against its background; large text (18pt, or 14pt bold, and above) needs 3:1. Under 1.4.11 Non-text Contrast (AA), interactive elements and their states — button borders, input outlines, focus rings — also need 3:1 against adjacent colors.

Check every text-on-image combination at the worst point of the image, not the average, and account for hover and disabled states. Set contrast-safe color styles once in Framer and reuse them so a single token fix propagates everywhere. Run candidate pairs through our free contrast checker before committing.

A practical order of operations

Don't try to fix everything at once. Work in the order that removes the most user-facing failures fastest: tag your headings and landmarks, convert click-Frames to real links and buttons, fill in alt text, fix contrast tokens, then audit focus order and reduced motion. Publish, then verify on the live site — Framer's preview hides some structural issues that only appear in the exported markup.

Pair automated and manual checks. Automated tools catch missing alt text, contrast failures, and broken heading order; only a human catches a confusing focus order or a misleading link name. Tab through the whole site, then test with a screen reader. AccessScan's free checker handles the automated pass and produces an accessibility statement when you're ready to publish a conformance claim. The same principles carry over to any Framer project extended with custom React code.

Check your site against AccessScan

See your issues ranked by impact in seconds — free.

Run a free accessibility scan

FAQ

Can a Framer site be fully WCAG 2.2 AA accessible?

Yes. Framer can produce accessible markup, but it doesn't enforce it. You have to assign semantic tags to text and frames, use real link and button behaviors instead of clickable frames, add alt text, meet contrast ratios (4.5:1 for body text, 3:1 for large text and UI components), and honor reduced-motion preferences. Done deliberately, a Framer site meets the WCAG 2.2 AA baseline that the EAA requires.

Does Framer add alt text automatically?

No. Framer gives every image an alt text field, but it's empty until you fill it. Write concise, contextual alt text for informative images, leave it empty for decorative ones, and give a meaningful name to icon-only buttons. Background images set on frames have no alt field at all, so move any informative background to a real image layer.

How do I handle animations for users who get motion sickness?

Respect the prefers-reduced-motion setting. Framer offers a reduced-motion option on its animation and appear effects — enable it so motion is reduced or removed for users who request it in their OS accessibility settings. For code-based animations, check prefers-reduced-motion and provide a calm fallback. Never hide essential content behind a scroll animation a reduced-motion user won't trigger.

Why does my Framer heading not register as a heading for screen readers?

Because styling text to look like a heading doesn't make it one. A large, bold text layer is still announced as paragraph text unless you assign it a heading tag (H1, H2, H3) in Framer's properties. Set the correct tag in order without skipping levels; use font size for appearance and the tag for structure.

What's the fastest way to find Framer accessibility issues?

Run an automated scan to catch missing alt text, contrast failures, and heading problems, then do a manual pass: tab through the whole published site to check focus order and visible focus, and test with a screen reader. Automated and manual testing cover different gaps, so use both. Verify on the live site, since Framer's preview can hide structural issues.

More guides