Wix Accessibility — Reaching WCAG 2.2 AA Without Bolting It On

Accessibility on the Wix sites we audit is one of two states: ignored entirely, or "compliant" via a third-party overlay that does not actually help users. Both are wrong. Reaching genuine WCAG 2.2 AA on Wix Studio is not difficult; it is just not the default. Here is the discipline.

Keyboard navigation

Every interactive element must be reachable, focusable, and operable with the keyboard alone.

• Tab order matches visual order. Wix Studio's default usually does, but custom layouts can break this. Test.
• Focus is visible. Default focus rings get suppressed by themes. Restore them with strong, branded focus styles.
• Custom components have keyboard handlers. Velo-driven carousels, accordions, and modals need keyboard support. They do not get this for free.
• Skip links. A "Skip to main content" link, first focusable item, takes keyboard users past the nav.

Screen reader testing

We test new builds with NVDA on Windows and VoiceOver on macOS/iOS before launch. Quick checklist:

• Headings form a logical outline — one H1, then H2s, no skipped levels.
• Form labels are programmatically associated — <label for> or aria-labelledby, never just placeholder.
• Landmarks are used — header, nav, main, footer. Avoid div-soup.
• Images have meaningful alt text — or alt="" if purely decorative.
• Buttons are buttons, links are links — semantics matter.

Color contrast

• 4.5:1 minimum for body text against background (WCAG AA).
• 3:1 minimum for large text (18pt+ or 14pt bold) and UI components.
• AAA target (7:1) for healthcare or low-vision audiences.

We test every color pairing with the WCAG Contrast Checker before approving. Trends like grey-on-white body text are usually contrast failures.

Reduced motion

CODE0

Wix Studio respects this if your custom CSS does. Test with reduced motion enabled in OS settings.

Forms

• Labels visible, not placeholder-only.
• Errors programmatically announced via aria-live regions.
• Required fields indicated beyond just color (asterisk + text).
• Submit feedback (success or error) announced.

What about overlays?

There is a class of "accessibility overlay" widgets that promise instant compliance. They do not work. They:

• Break screen reader compatibility for users who already have their own assistive tech configured.
• Do not fix underlying semantic problems.
• Have produced multiple ADA lawsuits in the US that failed because of the overlay.

We have never installed one. We have removed many.

The pre-launch audit

We run a 6-part accessibility audit before every launch:

1. Automated — axe DevTools, Lighthouse a11y, WAVE. Catches the obvious.
2. Keyboard pass — navigate every page with keyboard only.
3. Screen reader pass — NVDA + VoiceOver on key pages.
4. Contrast pass — every color pair verified.
5. Reduced motion pass — test with OS setting on.
6. Zoom pass — site usable at 200% zoom.

If all six pass, we sign off. If not, we fix and re-audit.

Why bother

Beyond the obvious moral case:

• The accessibility-first audience is larger than most teams realise. ~15% of internet users have a permanent disability. Many more use assistive tech temporarily.
• Legal exposure is real. ADA lawsuits in the US, EAA enforcement coming online in the EU. Overlay vendors do not protect you.
• Accessible sites convert better. Friction reduction for disabled users is friction reduction for everyone.
• Search engines like accessible sites. Semantic HTML, proper headings, alt text — all SEO inputs too.

The takeaway

WCAG 2.2 AA on Wix Studio is not a sprint at the end; it is a discipline from the first wireframe. Color choices, focus states, semantic structure, motion preferences — designed in, not bolted on. The cost of doing this from day one is tiny. The cost of remediating after launch is large.