WCAG accessibility audit for Wix sites

Wix generates HTML via its own rendering engine. The user cannot choose to use a nav tag instead of a div for navigation, or add an ARIA role on a specific component. HTML structure is determined by the system, not the site creator. Semantic tags are applied unevenly across components, making the page structure incomprehensible to screen readers.

Wix apps (gallery, store, blog, third-party forms) are rendered in separate iframes. Each iframe has its own accessibility tree, creating breaks in keyboard navigation: the user tabbing enters the iframe, traverses it, then must exit to continue. Iframes do not always have a descriptive title attribute. Navigation between the main site and apps is chaotic for assistive technologies.

Wix offers an accessibility widget (Accessibility Wizard) that adds a JavaScript overlay to the site. This overlay allows changing contrasts, text size, or spacing, but it does not fix structural problems (non-semantic HTML, missing ARIA, unmanaged focus). Accessibility overlays are rejected by experts and disability advocacy organizations. They do not make the site WCAG conformant and offer no legal protection.

Wix gallery, slider, and carousel components do not support standard keyboard navigation. Navigation arrows are not focusable. Gallery images are not reachable by keyboard. Lightboxes open without moving focus and without focus trap. Active slide content is not announced by aria-live. These components are among the most used on Wix sites and are totally excluded for keyboard users.