Apr 28, 2026

Wix Accessibility: Seven Issues We Find on Almost Every Wix Site (And How to Fix Them Without Migrating)

If your accessibility audit landed in your inbox last week and the recommendation was to rebuild your site on WordPress, take a breath. Most of what your auditor flagged is not a Wix limitation. It is a small set of editor patterns that the Wix interface makes easy to introduce, and most of those patterns can be fixed in an afternoon by the person who built the site.

We have audited a meaningful number of Wix sites since the European Accessibility Act came into force on 28 June 2025. The seven issues below show up on roughly every site we look at. One of them genuinely needs a developer or a Wix Studio rebuild. The other six are settings, copy decisions, or a single Custom Code injection that any non-developer can ship today.

This post is not legal advice. It is a triage list for a small business owner with a Wix site, an audit they did not ask for, and a deadline they did not pick.

Why Wix sites are easy to break

Wix is a visual builder, and the thing visual builders fundamentally optimise for is what the page looks like. They are not optimising for what the page sounds like to a screen reader or feels like to a keyboard user, and they are not really able to. The result is a workflow where you can drag a beautiful page into existence without once being shown the underlying HTML, and the underlying HTML can have heading levels that do not match the visual hierarchy, alt text fields that were skipped because the editor did not stop you, and dynamic interactions whose state is invisible to assistive technology.

The patterns below are direct consequences of that gap. Wix has actually invested more in accessibility tooling than most builders in its tier — its Accessibility Wizard inside the editor catches a real share of common issues — but the wizard does not catch everything, and most owners never run it twice.

The seven things that almost always fail

1. Images have no alt text because the editor did not require it

This is the most common Wix issue we see, and it is the easiest to fix. The Wix image uploader does not require alt text before you save. It surfaces a small “Settings” panel where you can add it, but if you do not click in, the image ships with an empty alt attribute. Screen-reader visitors hear nothing where your hero photo, product gallery, or trust badges are; the same images publish to social previews and search engines with the same emptiness.

Open the Wix Editor, click each image, click “Settings,” and write one sentence in the “What’s in the image?” field that describes what the image conveys to a sighted visitor. For decorative images that add no information, mark them as decorative in the same panel so screen readers correctly skip them. Work through your homepage, About page, and top three product or service pages before moving on; that order matches the pages an auditor or a complainant is most likely to load first.

We wrote a longer guide to writing alt text that covers product photos, charts, and decorative images specifically.

2. Heading levels are picked because they “look right”

Wix’s editor lets you set every text element to H1, H2, H3, paragraph, or any of several styled variants. Owners pick the option that visually matches the size they want. The result is a page with three H1s in a row at the top, no H2, then five H3s scattered through the body — and a screen reader user navigating by heading lands in the middle of nowhere.

A page should have exactly one H1, which is the page title or the main heading of the page. Major sections under it are H2. Sub-points within a section are H3. If a paragraph just needs visual emphasis, bold it; do not promote it to a heading.

Open each page, click each heading-styled text element, and use the “Tag” dropdown in the text panel (it is sometimes labelled “Format” depending on your editor version) to set the actual semantic tag. Visual size is controlled separately by the typography settings, so you can keep the look and fix the structure independently. Run the free WAVE browser extension on the published page afterwards to confirm the outline.

3. Buttons are images, not buttons

A surprising number of Wix sites use shape elements or images styled like buttons for their primary call-to-action. The “Book a call” or “Buy now” element looks like a button, behaves like a button when you click it, and is announced by a screen reader as “image” or “graphic.” Keyboard-only visitors cannot tab to it; voice-control users cannot say “click ‘Book a call’” because the element has no accessible name.

In the Wix Editor, replace each image-styled CTA with the actual Button element from the “Add” panel. Style the button to match your brand — Wix gives you control over background, hover, border, and corner radius — so you keep the look while gaining the right semantics. For each button, write a verb-led label that describes what happens when you press it: “Book a discovery call,” not “Book.” For Wix Stores’ product cards, use the built-in “Add to cart” and “Quick view” buttons rather than custom shape overlays; they ship with the correct ARIA roles by default.

4. Forms use placeholder text instead of labels

Wix’s contact form, newsletter signup, and Wix Forms templates all default to “show placeholder, hide label” mode. The field looks clean — until the visitor starts typing and the placeholder disappears, leaving a field with no visible name. Cognitive-disability visitors, screen-magnification users, and screen-reader users without recent placeholder support cannot recover from typos.

Open each form, click the field, open the field-settings panel, and toggle “Show field title” or its equivalent in your form template. Place the title above the field, not inside it. While you are there, mark required fields with both a visible asterisk and the word “required” in the field title — colour and asterisks alone fail WCAG 1.4.1 (Use of Color) for color-blind visitors. Our accessible forms guide walks through the same fixes for every major builder.

5. Brand colours fail contrast

Most small businesses on Wix pick a brand palette in the Wix Editor’s theme panel and let it apply globally. The palette was chosen by a designer or a Canva template who optimised for “looks good,” not for “passes 4.5:1 contrast against the chosen background.” We see light-grey body text on white, soft-pink CTA buttons on cream, and pastel link colours that fall well short of the WCAG 2.1 AA contrast minimum.

Open WebAIM’s free Contrast Checker in another tab and test every text/background pair on your site: body text, link text, button text, navigation text, footer text. For pairs that fail, darken the foreground or lighten the background until you pass 4.5:1 for body and 3:1 for large text (24px regular or 18.66px bold). Save the new values back into the Wix theme panel so they apply everywhere consistently. We dig deeper into contrast in our color contrast guide.

6. Pop-ups trap keyboard focus

Wix’s Lightbox feature is heavily promoted as the way to capture email opt-ins, run promotions, and announce events. The default Lightbox traps keyboard focus inside it, which is correct behaviour — but the close button is often a small “X” with no visible focus outline and no accessible name beyond “X.” Keyboard-only visitors cannot find the way out; some users hit Escape, find that nothing happens, and quietly bounce.

In each Lightbox you publish, replace the “X” close icon with a visible “Close” button or, if you keep the X, set the button’s accessible name to “Close” via the field that Wix exposes in the icon settings. Confirm that pressing Escape closes the Lightbox; this is a Wix setting under the Lightbox’s “Settings > Behaviour” tab. Keep the focus outline visible on the close button — do not set its border or outline to zero in custom CSS.

While you are auditing pop-ups, switch off any auto-opening Lightbox that appears on the first page load. Auto-popping modals that interrupt visitors fail WCAG 3.2.1 (On Focus) and almost always cause more lost conversions than they earn.

This is the one issue on the list that genuinely needs a Wix Studio rebuild or a careful Custom Code patch. The default Wix mobile navigation on the classic Wix Editor (not Wix Studio) renders the hamburger as a tap target with limited keyboard support; some templates ship with the menu items only reachable via touch, not via Tab key.

If you are on Wix Studio, the new mobile navigation widget supports keyboard navigation correctly out of the box — switch to it via the editor’s mobile-view panel. If you are on the classic Wix Editor and migration to Studio is not on the table, file a Wix support ticket citing WCAG 2.1.1 (Keyboard) and add a sentence to your accessibility statement acknowledging the limitation and naming a contact route for visitors who cannot use the mobile menu. This is not ideal, but it is honest, and an honest accessibility statement is a meaningful defence in an EAA enforcement action.

What to do this week

If you read this and want a sequence, here is the one we give clients: write alt text for every image (Issue 1), fix heading tags on the homepage and your top three pages (Issue 2), replace image-buttons with real buttons on every CTA (Issue 3), turn on field labels for every form (Issue 4), check brand colours against the contrast checker (Issue 5), audit your Lightboxes (Issue 6), and decide whether to migrate to Wix Studio or document the mobile-menu limitation (Issue 7).

That sequence handles roughly 80% of what an auditor will flag on a Wix site, and none of it requires migrating to a different platform. If the audit you received recommended a rebuild, ask the auditor which specific WCAG criteria require a platform change rather than a settings change, in writing. Most of the time, the answer is none.

We’re building a simple accessibility checker for non-developers — no DevTools, no jargon. Join our waitlist to get early access.