Most accessibility checklists tell you to add alt text and check your colour contrast. Useful, but you already knew that. What they don't tell you is where Webflow specifically works against you, which of its native components ship with problems, and what its Audit panel won't catch.
This is that list. It's ordered roughly by how often we find each issue in real Webflow builds.
Start here: what Webflow's Audit panel actually does
Webflow has a built-in Audit panel. It's genuinely helpful and it's the fastest first pass you can make.
It catches things like missing alt text, colour contrast failures, and empty links.
It does not catch keyboard traps, focus order, whether your headings make structural sense, whether your interactions are usable without a mouse, or whether a screen reader can understand your page. Those are the failures that actually stop people from using your site, and no automated tool finds them. Neither does Lighthouse. Neither does axe.
Run the Audit panel. Then do the rest of this by hand.
1. Heading structure
The Webflow-specific problem: Webflow decouples how text looks from what tag it uses. That's a feature. It's also the single most common accessibility failure we find, because designers pick a heading level for its size and move on.
Check:
- One H1 per page. Webflow won't stop you from shipping four.
- No skipped levels. H2 to H4 with no H3 between them is a structural break.
- Headings describe structure, not size. If you wanted smaller text, change the style, not the tag.
- On Collection pages, check the template. One bad heading level there repeats across every item.
Where: Select the element, open the Settings panel, check the tag dropdown.
2. Alt text, including the CMS trap
The Webflow-specific problem: Alt text set on an asset in the Asset Manager doesn't always carry to every instance, and CMS-bound images are the bigger issue. If your Collection has an image field with no matching alt text field, every image on every item ships with nothing.
Check:
- Static images have alt text, or are explicitly marked decorative.
- Every CMS image field has a companion alt text field, and someone fills it in.
- Alt text describes the purpose of the image, not its contents. A logo linking home is "Home," not "blue circular logo."
- Decorative images are marked decorative, not given empty alt by accident. Same result, different intent, and it matters for whoever maintains this next.
Where: Asset Manager for the default, Settings panel per instance, Collection settings for the CMS field.
3. Link text in Collection Lists
The Webflow-specific problem: This one is almost unique to CMS-driven sites and we find it constantly.
You build a Collection List of blog posts. Each card has a "Read more" link. It looks fine. A screen reader user pulling up a list of links on that page gets "Read more, Read more, Read more, Read more" nineteen times, with no way to tell them apart.
Check:
- Link text makes sense out of context. If it doesn't, bind an aria-label to the item's title field, or add visually hidden text.
- The same applies to icon-only links. An arrow with no text is a link with no name.
- Card patterns where the whole card is a link block need one accessible name, not three nested links to the same place.
4. Forms
The Webflow-specific problem: Webflow's default Form Block ships with proper labels. Then a designer deletes them because the mockup used placeholder text, and now the form is unusable.
Check:
- Every input has a real, visible label. Placeholders are not labels. They vanish on focus and screen readers treat them inconsistently.
- If the design truly can't show a label, it still needs one, visually hidden.
- Required fields are marked in text, not only with a red asterisk or a colour.
- Error messages say what's wrong and how to fix it. Webflow's default error state is a generic block at the top of the form that isn't tied to any field. If your form has more than two inputs, that's not good enough.
- The success and error states get announced, not just displayed.
5. Focus states
The Webflow-specific problem: Templates and designers remove focus outlines because they look untidy. Many Webflow templates ship with them already suppressed, so you inherit the problem without choosing it.
Check:
- Tab through every page. If you can't see where you are, it's broken.
- Focus is visible on links, buttons, inputs, and anything custom.
- Focus contrast is high enough against the background behind it.
- Nothing sets outline: none without providing a replacement.
Where: Style panel, states dropdown, Focus. Also check your template's global styles.
6. Native components worth checking
Webflow's built-in components are better than they used to be. They still need review.
Navbar: Test the mobile menu with a keyboard. Open it, tab through it, close it with Escape. Check whether focus stays inside the open menu or wanders off behind it, and whether it returns to the hamburger button on close.
Dropdown: Test with keyboard alone. Opens on Enter, navigates with arrows or Tab, closes on Escape.
Tabs: Check keyboard navigation between tabs and that the panel content is properly associated.
Slider: Two problems. If it auto-plays, WCAG requires a way to pause it, and Webflow doesn't give you one by default. And the arrows and dots need to be reachable and named.
Lightbox: Check that focus moves into the lightbox when it opens, stays there while it's open, and returns to the trigger when it closes.
7. Interactions and motion
The Webflow-specific problem: Interactions are what people buy Webflow for. They're also where accessibility quietly falls over.
Check:
- Anything that moves, flashes, or auto-scrolls respects a reduced-motion preference. Some users get migraines or nausea from parallax and scroll-jacking. This is not a small thing.
- Nothing flashes more than three times a second. That's a seizure risk, and it's one of the few WCAG failures with a physical consequence.
- Content that appears on hover also appears on focus. Hover-only means keyboard users never see it.
- Scroll-triggered content still exists for someone who doesn't scroll that way. If your content only appears via an interaction, check that it's in the DOM.
Webflow's handling of reduced-motion preferences has changed over time. Check the current behaviour in your Site Settings rather than assuming, and test it with the OS-level setting turned on.
8. Background video
Webflow's Background Video component auto-plays, loops, and has no controls.
If it plays for more than five seconds, WCAG wants a way to pause it. There's no toggle for this. You add a control yourself, or you keep it under five seconds, or you accept the failure knowingly.
Also worth asking whether the video is doing enough work to justify what it costs your users on mobile data.
9. Skip link
Webflow doesn't add one. You need to.
Without it, a keyboard user tabs through your entire navigation on every single page before reaching content. On a site with a big nav, that's thirty keystrokes per page.
Add a link at the very top of the body, pointing to your main content, styled to be hidden until focused.
10. Embeds and iframes
Anything you drop into an Embed component is outside Webflow's checks and outside its Audit panel.
Check:
- Every iframe has a title attribute. Maps, videos, forms, all of them.
- Third-party widgets are tested, not trusted. Booking tools, donation forms, and chat widgets are frequently the least accessible thing on a non-profit's site, and they're the thing that actually matters.
- Custom code hasn't introduced its own problems.
11. Rich text fields
Your CMS rich text field is a small CMS inside your CMS, and whoever edits it can undo your work.
Check:
- Editors know which heading levels to use. Rich text usually starts at H2 because H1 is the page title.
- Images added in rich text get alt text.
- Links pasted into rich text have meaningful text, not a bare URL.
- Tables, if anyone uses them, have proper headers.
This is a training problem more than a build problem. The build can be perfect and one editor can undo it in a week.
12. Language
Set the site language in Site Settings. It's one field and it tells screen readers which pronunciation rules to use.
If you're running multiple locales, check each one carries the right language attribute.
What none of this catches
Everything above is findable by a careful person with a keyboard and an hour.
What it won't tell you is whether your site is actually usable. That takes testing with a screen reader, and ideally testing with people who use one daily. The gap between "passes the checklist" and "a blind user can donate to your organization" is wide, and it's where the real work is.
Automated tools catch a fraction of WCAG failures. The rest needs a person. Anyone selling you a script that fixes accessibility automatically is selling you a liability, not a solution.
A 20-minute test you can do today
- Put your mouse away. Tab through the whole page. Can you reach everything? Can you see where you are? Can you get back out of the menu?
- Zoom to 200%. Does anything overlap or disappear?
- Turn on your OS reduced-motion setting. Does the site calm down?
- Turn on VoiceOver or NVDA and try to complete your primary conversion. Donate, sign up, register. Not read the homepage. Complete the thing you actually need people to do.
Most sites fail step four. That's usually the conversation worth having.
Pragmatica builds Webflow sites for Canadian non-profits, charities, and associations. Our accessibility work is done by IAAP-certified specialists doing manual testing. If you want to know where your site actually stands, get in touch.
