If you built your site on Webflow, you probably picked it because the Designer gives you precise control over the HTML and CSS in a way drag-and-drop builders normally do not. That precision is real. The DOM Webflow ships is cleaner than what comes out of WordPress page builders, and the team has invested in semantic defaults across most components.
The trade-off is that Webflow gives the designer responsibility for the things a CMS would normally make uneditable. Heading levels, ARIA roles, focus management, motion preferences — all of it lives in panels the designer can change, and the defaults are tuned for visual flexibility, not screen readers. We have audited a meaningful number of Webflow sites in the last few months. Five patterns show up on roughly every one.
None of them are platform limitations. All five are fixable in the Designer without writing custom JavaScript. Three of them are settings most designers do not know exist.
Why Webflow sites fail in these specific ways
Webflow's product philosophy is "designers shouldn't be limited by templates." Every element on the canvas — from a Heading block to a Lottie animation to a CMS Collection list — exposes its full set of HTML and CSS knobs in the right-hand panel. Heading level is a dropdown. ARIA role is a dropdown. The interaction trigger is configurable per-element. This is great for designers who know what they want.
It is also, in practice, a system where every accessibility decision is a designer decision, and the defaults make the prettiest visual outcome rather than the most semantic DOM. CMS Collections render with whatever heading level the template's first item used. Symbols share their semantic structure across every page they appear on. Lottie animations ship without aria-hidden unless the designer remembers to add it.
The five patterns below are all consequences of this trade-off. The fixes are all in the Designer.
The five things that almost always fail
1. CMS Collection list templates with wrong heading levels
Webflow's CMS Collection lets you bind a template to a collection of items — blog posts, team members, case studies, product cards — and Webflow renders one instance of the template per item. If your template has a Heading element bound to the item's Name field, every item in the list gets that heading.
What we keep finding: the Collection Item template was built with H2 because the designer wanted big text. The Collection list lives on a page that already has an H1 (the page title) and an H2 (the section heading above the list). So the rendered DOM has one page-level H1, one section-level H2, and then twelve more H2s — one per blog post card — all at the same level as the section heading. A screen reader user navigating by heading lands at the page, hears "section, H2," then twelve more H2 announcements with no indication that they are list items, not new sections.
The fix lives in the Collection Item template. Open the Designer, navigate to the template, click the Heading element bound to the Name field, and change its level to H3 (one level below the section heading that introduces the list). Save the template. All twelve items re-render at the correct level. The heading hierarchy now nests correctly: H1 page, H2 section, H3 per-item title.
Verify on a CMS-rendered page (not the Designer preview) — the rendered output is what counts.
2. Tabs, Dropdown, and Accordion components without complete ARIA state announcements
Webflow ships built-in Tabs, Dropdown, and Accordion components. They look polished out of the box. They are also missing the ARIA state attributes screen readers need to announce the open/closed state correctly.
The Tabs component sets role="tab" and role="tabpanel" on its parts, but does not always update aria-selected="true" on the active tab when it changes. The Dropdown component has a trigger that opens a list, but the trigger does not toggle aria-expanded between true and false. The Accordion component opens and closes panels visually but does not announce the state change.
A keyboard user navigating to the Tabs and pressing Right Arrow may visually see the tab change but hears no audible confirmation. The dropdown opens and the user has no way to know the menu appeared.
The fix is per-component, in the Designer's element settings. Click each component, open the right-hand panel, scroll to the "Custom Attributes" section, and add the missing ARIA attributes:
- Tabs: bind
aria-selected="true"on the active tab via Webflow Interactions on tab change - Dropdown: bind
aria-expandedon the trigger to toggle between true and false on open/close - Accordion: bind
aria-expandedon each panel header to toggle on open/close
Webflow Interactions has a "Set Attribute" action that lets you do this without writing JavaScript. It is buried in the action panel, but it works. Each component takes about ten minutes to wire correctly.
3. Lottie animations and scroll interactions that ignore prefers-reduced-motion
Lottie files are vector animations rendered in the browser via JavaScript. Webflow's built-in Lottie integration drops one onto the canvas with a few clicks, and Webflow Interactions can trigger animations on scroll, hover, click, page load, and so on.
What is usually missing: a check for prefers-reduced-motion, the OS-level user setting that tells websites the visitor has motion sensitivity. Visitors with vestibular disorders, certain forms of migraine, or autism-spectrum sensory issues set this to "reduce" in their OS settings. Their browser then sends a CSS media query that says "minimize animation."
A Webflow site with five Lottie animations and ten scroll-triggered interactions, none of which check the media query, is a site that triggers symptoms in those visitors. WCAG 2.3.3 (Animation from Interactions, AAA) and the broader 2.2 spec both require respecting this preference.
The fix has two parts. First, in the Designer, every Lottie element has a panel setting for "Reduced motion" — set it to "Use reduced motion preference." Second, every Webflow Interaction that animates an element should be wrapped in a media query check. Webflow does not have a native panel for this on Interactions; you add a CSS rule via the Designer's Custom CSS section that disables transforms inside @media (prefers-reduced-motion: reduce).
4. Symbol-shared headings creating duplicate H1s across pages
Webflow Symbols are reusable components. You build a header once as a Symbol, drop it on every page, and any change to the Symbol propagates everywhere. This is the right primitive for a design system. It is also the source of one of the most common heading hierarchy bugs we see.
The pattern: the designer built a homepage with a hero section that has the company name as an H1. They saved the hero as a Symbol called "Hero." They then dropped the same Hero Symbol on the About page, the Services page, and the Contact page, each of which already has its own H1 ("About Us," "Our Services," "Get in Touch"). Every page now ships with two H1 elements — the one from the Hero Symbol and the one from the page-specific section.
The fix has two clean paths. Either change the Hero Symbol so the company name is an H2 (the page-specific H1 stays as the actual page title), or override the Symbol's Heading level on each per-page instance. Webflow allows per-instance overrides on Symbol elements, but most designers do not realize this option exists.
If your site has more than three Symbols with headings, audit each one in the Designer and decide which level they should be. Pages that link Symbol headings into the wrong hierarchy are the easiest accessibility fixes you can ship: the change takes seconds, and it removes a real screen reader confusion.
5. Form fields with placeholders pretending to be labels
Webflow's Form Block ships with placeholder-style fields by default. The "Label" field above each input is empty in the default template, and the placeholder inside the input ("Your name," "Your email") is what visitors see.
To a screen reader, the input is announced as "edit text, blank" — the placeholder is ignored once the field is focused, and the label is empty. We have audited Webflow forms where five fields all read as "edit text, blank" in the same form.
The fix is in the Designer. Click the Form Block, open the structure panel, and for each input, set the Label element's text to the field name (matching the placeholder). Either show the label visually (recommended) or visually hide it with the screen-reader-only class while keeping it programmatically associated. Webflow's Designer has a built-in helper to apply this class, listed under "Accessibility" in the Designer settings.
This is the same pattern we see on Showit, Squarespace, and most page builders. The fix is the same on all of them: programmatic label, even if the visual presentation hides it.
Verifying the fixes
For three of the five — heading hierarchy, form labels, ARIA state — running axe-core or Lighthouse after the fix will tell you whether the change took. The automated scanners catch these.
For Lottie and scroll interactions, automated scanners cannot tell you whether the animation actually pauses when prefers-reduced-motion is set. The verification step is a manual test: enable Reduce Motion in your OS settings (System Settings → Accessibility → Display on Mac, Settings → Ease of Access → Display on Windows), reload the page, and confirm the animations stop or simplify. If they keep running, the fix did not take.
For the Tabs/Dropdown/Accordion ARIA wiring, automated scanners can tell you whether the attributes exist on the elements but cannot verify they update correctly when the user interacts. Use NVDA or VoiceOver: navigate to the component, activate it with Enter or arrow keys, and listen for whether the state announcement is correct ("button, expanded" vs "button, collapsed", "tab, selected" vs "tab"). If the announcements match the visual state, the binding is working.
Run the full sequence at both desktop and mobile widths. Webflow's responsive variants can change which Symbol or component shows at smaller viewports, and a fix verified at desktop can regress on mobile.
What to ask before you hire someone
If you are paying a developer or auditor to fix accessibility on your Webflow site, three questions before you sign:
Will the work include wiring the ARIA state attributes on Tabs, Dropdown, and Accordion components via Webflow Interactions? This is the only fix in the list that requires more than panel settings. If the proposal does not mention "Set Attribute" interactions, the components will look fixed in axe-core but still announce wrong to screen readers.
Will the audit include a prefers-reduced-motion test? Most Webflow audits skip this entirely because automated scanners do not test it. The fix takes minutes once known; the audit takes minutes more. If the proposal does not mention motion preferences, your visitors with vestibular disorders are not being checked for.
Will the auditor look at the CMS Collection templates and Symbols, not just rendered pages? The heading hierarchy bug from Section 1 lives in the Collection Item template, not in any individual page. The Symbol H1 bug lives in the Symbol definition. An auditor who only walks rendered pages without opening the Designer can fix individual pages and miss the source.
If those three are clear with examples, you are talking to someone who has shipped Webflow accessibility work before. If not, the report will look thorough and miss exactly the patterns that lose your screen reader visitors.
Closing
Webflow gives designers more control over the rendered HTML than any other visual builder we work with. That control is real, and the team has shipped better accessibility defaults than several of its competitors. The five patterns above are not platform criticism — they are recurring traps the Designer makes easy to fall into without knowing.
The fix on all five is in the Designer. None of them require ejecting from Webflow. Three of them are settings most designers have never opened.
If you want a free 5-minute manual pass on your highest-traffic Webflow page — heading hierarchy, ARIA state announcements, motion preference handling, the things automated tools cannot see — drop the URL in the comments. We are running these for the first 5 sites that ask, mainly because we are building a public review base and the writeups make good case studies.
Top comments (0)