Oxygen Builder Accessibility Checklist 2026 | WCAG 2.1 AA & EAA
Last updated: 2026-06-18
Oxygen Builder is a visual site builder for WordPress aimed at developers and agencies who want full control over markup, and that control is exactly what makes its accessibility outcomes so variable. Unlike Elementor or Divi, Oxygen does not wrap your content in a theme; it replaces the theme entirely and gives you a blank canvas of structural elements, mostly generic divs, that you assemble into pages. The benefit is lean output with no theme bloat. The cost is that nothing is semantic unless you make it semantic: a div styled to look like a heading is still a div, a clickable box is not a button, and a column that reads as a section to your eye carries no landmark for a screen reader. Oxygen will happily ship a page that looks finished and is structurally empty to assistive technology.
The most common Oxygen accessibility failures all stem from this blank-canvas model: heading elements faked with styled text or set to the wrong level, interactive elements built from divs with click handlers instead of real buttons or links, missing landmark structure because the header, nav, main, and footer were built as generic containers, and reusable components (Oxygen's templates and reusable parts) that propagate a single accessibility mistake across every page that uses them. Layered on top are the issues every builder shares: low-contrast color sets, images inserted without alt text, forms (whether the native Oxygen form element or an embedded plugin like Fluent Forms or WS Form) with placeholder-only fields, and focus outlines stripped by reset styles. This checklist maps each issue to its WCAG 2.1 AA success criterion and gives a concrete fix inside the Oxygen editor. It is ordered by impact, starting with the structural and interactive failures that most often block users and appear in accessibility complaints, because in Oxygen those are the ones the blank-canvas workflow makes easiest to ship by accident. Because components reuse propagates fixes too, correcting an issue once in a reusable part is often the highest-leverage change you can make.
Common Accessibility Issues
Oxygen makes it trivial to attach a link or click action to any div, so cards, calls-to-action, and menu items are frequently built as generic containers with a click handler rather than as a real <a> or <button>. These elements are not in the tab order, do not announce a role, and cannot be activated with Enter or Space, so keyboard and screen reader users cannot use them at all.
Build interactive elements with semantic tags: use the Link element (or set the tag to <a> with a real href) for navigation, and a <button> for in-page actions. If you must keep a div wrapper, add the link as a genuine anchor inside it rather than relying on a div click handler. Avoid the pattern of wrapping a whole card in a div with onclick; make the heading or a clear action link the real, focusable target.
<div class="card" onclick="location.href='/pricing'">View pricing</div><div class="card">
<a href="/pricing">View pricing</a>
</div>Because Oxygen's default text and div elements carry no semantic level, section titles are often styled to look like headings while remaining paragraphs or divs, and where real heading elements are used the levels are chosen by size. The result is pages with no H1, multiple H1s, or skipped levels, leaving screen reader users without a usable document outline.
Use the Heading element and set its tag explicitly: one H1 per page for the main title, H2 for each major section, H3 for sub-points, with no skipped levels. Do not promote a styled Text element to look like a heading; convert it to a real Heading and adjust its font size in styling instead. Check the resulting outline with a heading-map tool before publishing.
Oxygen templates are assembled from Section and Div elements that render as generic containers, so a page can look like it has a header, navigation, main content, and footer while exposing none of those landmarks to assistive technology. Screen reader users lose the ability to jump to the main content or navigate by region.
Set the wrapping element's tag to the correct HTML5 landmark: <header> for the site header, <nav> for the primary menu, <main> for the main content area (one per page), and <footer> for the footer. Oxygen lets you change the tag on Section and Div elements in their advanced settings. Pair this with a skip-to-content link targeting the <main> region.
Oxygen's reusable parts, templates, and the header/footer builders mean a single block of markup appears on many pages. A missing landmark, an unlabeled search field, or a low-contrast button inside a reusable header therefore becomes a site-wide barrier rather than a one-page bug, multiplying the impact of any single mistake.
Audit each reusable part and template once, in isolation, and fix accessibility there rather than per page: correct the header nav landmark and skip link, label the global search field, and verify menu and button contrast. Because the fix propagates everywhere the component is used, prioritising reusable parts gives the highest coverage for the least effort. Re-test a sample of pages after editing a shared component.
Whether you use Oxygen's native form element or an embedded plugin such as Fluent Forms, WS Form, or Gravity Forms, fields are commonly configured with placeholder text and no persistent visible label. Placeholders disappear on input and are inconsistently announced, so screen reader users meet unlabeled edit fields and sighted users lose the prompt once they start typing.
Give every field a persistent, programmatically associated label rather than relying on the placeholder. In the form element settings, enable visible labels and connect each label to its input. Mark required fields with text and an accessible indication, not color alone, and ensure validation errors are announced and tied to the field they describe.
Oxygen's global reset and custom CSS frequently strip the browser's default focus outline, and its color controls make it easy to set button, link, and body text that falls below the 4.5:1 contrast minimum. Together these leave keyboard users unable to see where focus is and low-vision users unable to read key text.
Never set outline: none without providing a clearly visible replacement focus style (a high-contrast outline or ring) on every interactive element, including links, buttons, and form fields. Run button text, link colors, and body text through a contrast checker and adjust until normal text reaches 4.5:1 and large text 3:1. Verify hover, focus, and active states as well as the resting state.
Oxygen Builder-Specific Tips
- Oxygen replaces your theme and gives you a blank, mostly div-based canvas; nothing is semantic unless you set the element's tag, so check structure first, not last.
- Build links and buttons as real <a> and <button> elements, never as divs with click handlers, so they are focusable and announce a role.
- Set Section and Div tags to <header>, <nav>, <main>, and <footer> to create the landmarks screen reader users navigate by, and add a skip-to-content link.
- Fix accessibility inside reusable parts and templates once; the correction propagates to every page that uses the component.
- Use the Heading element with an explicit level (one H1, then H2/H3) instead of styling Text to look like a heading.
- If your global CSS removes focus outlines, add a visible replacement focus style, and run all button, link, and body colors through a contrast checker.
Recommended Tools
WAVE Browser Extension
Run it on each published Oxygen page to surface missing landmarks, empty alt text, unlabeled form fields, and contrast errors that the blank-canvas workflow makes easy to ship.
axe DevTools
Automated WCAG scanning that reliably flags div-based controls with no role, missing button names, and skipped heading levels in Oxygen output.
HeadingsMap (browser extension)
Visualize the page's heading outline to confirm one H1 and no skipped levels after building with Oxygen Heading and Text elements.
Keyboard-only testing (Tab, Enter, Space, Escape)
Tab through every page to confirm that cards, CTAs, and menu items built in Oxygen are focusable and operable, and that focus is always visible.
NVDA + Firefox / VoiceOver + Safari
Screen-reader testing reveals whether your div-based components expose roles and landmarks, and whether form fields announce a usable label.
Oxygen Builder Accessibility At a Glance
| Plugin / Tool | Area | Common Failure | WCAG | Best Fix |
|---|---|---|---|---|
| Interactive elements cards/CTAs | Clickable divs, no role | 4.1.2 | Use real <a>/<button> | |
| Headings text vs heading | Fake/skipped levels | 1.3.1 | Heading element, explicit level | |
| Landmarks section/div tags | Generic divs, no regions | 1.3.1 | Set header/nav/main/footer tags | |
| Reusable parts templates | One error, every page | 1.3.1 | Fix once in the component | |
| Focus & contrast global CSS | Outline removed, low contrast | 2.4.7 | Visible focus, 4.5:1 text |
Frequently Asked Questions
Does Oxygen Builder produce accessible websites out of the box?
No, and that is by design rather than by neglect. Oxygen gives developers a near-blank canvas of structural elements, mostly generic divs, with very little semantic meaning attached by default. That means a page can look completely finished while exposing no headings, no landmarks, and no real buttons to assistive technology. Compared with builders that ship a theme and some baked-in structure, Oxygen puts more responsibility on you: you decide which element becomes an
, which container becomes , and whether a clickable card is a real link or a div with a click handler. The upside is that Oxygen does not force inaccessible patterns on you and produces lean markup, so a careful builder can reach WCAG 2.1 AA cleanly. The downside is that a builder who treats it as a purely visual tool will ship structurally empty pages. Plan to set tags and landmarks deliberately and to test with a keyboard and screen reader before launch.
How do I add proper landmarks and headings in Oxygen Builder?
Both are controlled by the element's HTML tag, which Oxygen lets you change. For landmarks, select the Section or Div that wraps your header, navigation, main content, or footer, open its advanced settings, and set the tag to
Do accessibility laws apply to a WordPress site built with Oxygen?
Yes. Accessibility obligations attach to the website and the experience it gives visitors, not to the tool used to build it, so a site built with Oxygen is treated exactly like any other website. In the US, ADA Title III demand letters and lawsuits routinely target the precise failures Oxygen makes easy to ship: div-based controls a keyboard user cannot reach, missing form labels, low-contrast text, and absent structure. In the EU, the European Accessibility Act, in force since June 2025, brings e-commerce and many consumer services within scope, so an Oxygen-built store or booking site serving EU consumers is very likely covered, subject to a limited microenterprise carve-out. WCAG 2.1 AA is the practical technical target under both frameworks. The blank-canvas nature of Oxygen means none of this is handled for you, so budget time to add semantic structure and test it. This is general guidance, not legal advice; consult a qualified attorney about your specific situation.
Further Reading
- Divi Accessibility Five Fixes
- Wordpress Accessibility Guide
- Focus Outline Removed Keyboard Accessibility
Other CMS Checklists
- Elementor Accessibility Checklist
- Bricks-builder Accessibility Checklist
- Beaver-builder Accessibility Checklist
Get our free accessibility toolkit
We're building a simple accessibility checker for non-developers. Join the waitlist for early access and a free EAA compliance checklist.
No spam. Unsubscribe anytime.