The accessibility fixes you cannot ship
WCAG 2.2 became a W3C Recommendation on 5 October 2023 and added nine success criteria to WCAG 2.1. One of them, 2.4.11 Focus Not Obscured, fails on a lot of modern sites for a boring reason: a sticky header or footer covers the element you just tabbed to. W3C lists one sufficient technique for it, C43, which applies the CSS scroll-padding property to the scroll container. Whether you can apply it comes down to how much of your own document the platform lets you reach.
What the built-in audit actually checks
Webflow's Audit panel runs four accessibility checks: missing alt text, non-descriptive link content, skipped heading levels, and duplicate element IDs. Those are worth catching, and catching them in the designer beats catching them in a report six months later. The panel also flags them while you work rather than after you publish, which is the right place for that kind of feedback.
Webflow's own documentation is candid about the edges. The Audit panel does not check inside components, so anything you turned into a reusable component has to be reviewed by hand. It skips alt text on CMS-bound images and on images inside Lightbox elements. It has no contrast ratio check at all, though the colour picker carries a separate contrast checker you can use while choosing a text colour.
Look at what those four checks have in common. Each one sits in a field the builder already owns. Alt text is an input on the image element. Heading level is a dropdown. The platform can audit them because it stores them. The criteria it cannot audit are the ones that live in markup and CSS it generates for you.
The fixes that live in the DOM
Keyboard focus follows source order. When a visual builder positions elements with CSS and your layout no longer matches the document order, a keyboard user tabs through your page in an order nobody designed. You can sometimes fix this by rebuilding the section so the source order matches, and sometimes you cannot, because the layout that works visually is the one that breaks the order. A skip link has the same shape of problem: it needs a target near the top of the body, ahead of the navigation, which means editing a region the platform treats as its own.
ARIA on generated widgets is harder. A dropdown, a tab set or a slider you assembled from platform components ships with whatever roles and states the platform decided to emit. If a tab panel lacks aria-selected, you are patching output you did not write, usually through a custom code embed, and the next component update can quietly put it back. WCAG 2.2 also added 2.4.13 Focus Appearance at AAA, which asks for a focus indicator at least as large as a 2 CSS pixel perimeter of the component with a contrast ratio of 3:1 against the unfocused state. That is a measurable property of a rendered element, and measuring it in a pipeline requires a pipeline.
That last part matters more than any single criterion. On Stay World Class we replaced Webflow and Xano with Next.js, NestJS and Supabase, moving the data through a four stage ETL that mapped legacy IDs onto PostgreSQL UUIDs. The Lighthouse score went from 55.91 to 91 out of 100 and LCP got 77% faster. The durable win was not the number. It was that focus order, landmark structure and ARIA became things we could assert on in a test and block a merge over.
When the platform is still the right answer
If you sell to consumers in the EU, Directive 2019/882, the European Accessibility Act, applies to e-commerce and banking services provided after 28 June 2025. Member states had to write it into national law by June 2022. That is a legal fact about your checkout, not a reason to panic about your marketing site, and the two are usually not the same codebase.
For most Webflow sites, staying is correct. If your pages are marketing content built from standard headings, links, images and a contact form, then alt text, heading order and colour contrast are the whole job, and the builder handles all three. You will get further running axe against your published pages and fixing what it finds than you will running a migration. Accessibility on its own is a thin reason to move.
The argument changes when your interactive surface grows. Custom widgets, multi step flows, an authenticated dashboard, anything where a keyboard user has to complete a task rather than read a page. At that point the fixes you need are DOM fixes, and you want a stack where you can write them, test them, and know they survive the next deploy. If you are not there yet, you are fine where you are.
Sources
- W3C, "What's New in WCAG 2.2"
- W3C, "Understanding SC 2.4.11: Focus Not Obscured (Minimum)"
- W3C, "How to Meet WCAG (Quick Reference)"
- Webflow, "Intro to the Audit panel"
- EUR-Lex, "Directive (EU) 2019/882 on the accessibility requirements for products and services"
- European Commission, "European Accessibility Act (EAA)"
