# Oxygen Builder Accessibility Reality Check > [!question] Lingering Questions > - Does modern (post-Classic) Oxygen resolve the dynamic-attribute-concatenation and concurrent-editing limitations described here, or do they persist in the current product? > - What do WebAIM Million or HTTP Archive data actually show for healthcare-sector WCAG failure rates — does it support the hosts' "worst performers" claim? > [!tip] Article Ideas > - A pre-quote checklist item for remediation agencies: identify the page builder and add-ons before pricing, and flag builders (like Oxygen Classic) that force JS-patching for a cost premium. > - "The sub-component attribute gap" as a named, recurring page-builder design flaw — worth a comparison piece across Oxygen, Divi, Elementor, and Gutenberg. > [!link] Cross Reference > - [[3. Resources/Permanent Notes/Zet · CSS-only carousel solutions improve performance]] — carousel accessibility and performance intersect at the same component the episode flags for missing pause controls > - [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] — remediation cost and platform architecture recur as a theme across hosting/security sources > [!quote] Vocabulary > - **VPAT** — Voluntary Product Accessibility Template; a standardized disclosure format the hosts suggest builder vendors should publish per interactive component > - **Sub-component attribute control** — UI-level ability to set ARIA/HTML attributes on elements nested inside a page-builder block, not just the top-level block itself ## Author's thesis Accessibility compliance is legally non-negotiable and enforcement is being actively defended in court even as deadlines slip; but the technical cost of compliance is dominated by page-builder architecture, not developer skill — remediation on Oxygen Classic (and comparable builders) costs far more than a naive engagement estimate would suggest because the tools themselves don't expose the controls remediators need. ## Key arguments (≤3) 1. **The legal and technical stories are separable but reinforcing.** The NFB's lawsuit against the ADA Title II deadline extension signals organized pushback against regulatory rollback, independent of how hard remediation actually is. 2. **Page-builder architecture is a root cause, not the developer's failure.** Across 18+ builders tested by Equalized Digital, only two or three natively ship a carousel pause button — a systemic vendor gap, not a site-specific oversight. 3. **Remediation approach has a maintainability tradeoff.** Working within a client's existing builder (vs. building custom deployment tooling) costs more in JS-patching hours but leaves the client able to maintain the fix after the engagement ends. ## Claim atoms ### Page-builder remediation costs spike when sub-component attribute access is blocked > [!quote] ID:rw_ep168_01 > "You only get attribute controls at the main block level. So if that component has subcomponents, I don't get that same level of control of the thing inside, which is very frustrating and very hard for a remediator." Where/why: ~01:02:00, Steve describing Oxygen Classic's attribute panel limits. This is the structural root cause behind the majority of the case study's 144 remediation hours, and it generalizes beyond Oxygen to every builder the team tested. ### Working within client tooling is a prerequisite for post-remediation maintainability > [!quote] ID:rw_ep168_02 > "Working within their framework allows us to remediate and allows them to access those changes we've made later on if they become an issue." Where/why: ~00:30:00. This is the methodological principle governing the whole engagement — a direct counterpoint to overlay/SaaS remediation models that bolt fixes on outside the client's own tooling. ### Carousel pause-button absence is a near-universal page-builder failure, not a site-specific oversight > [!quote] ID:rw_ep168_03 > "Of the carousels that we looked at across however many 18 plus builders, only like two or three actually had a pause button as a setting. I do not understand why." Where/why: ~00:55:00, Amber summarizing Equalized Digital's builder comparison. Reframes individual-site WCAG 2.2.2 failures as a vendor-ecosystem problem, useful for advocacy or plugin-review policy arguments. ## Permanent candidates - **Accessibility remediation that introduces proprietary infrastructure creates the same lock-in risk it claims to solve** — supported directly by H2 (working within client tooling) and the broader case study; promoted below. ## Processing checklist - [x] Ported existing deep-read (Refactor Appendix) into Konik Literature Note format - [ ] Verify WebAIM Million healthcare-sector WCAG failure-rate claim against primary data - [ ] Check whether modern Oxygen resolves the dynamic-attribute-concatenation gap - [x] Connect into the relevant MOC — [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] ## Metadata - Source: [[3. Resources/Literature Notes/Oxygen Builder Accessibility Reality Check]] ## Links - [[3. Resources/MOCs/WordPress Hosting Security Stack MOC]] — remediation cost, page-builder architecture, and third-party dependency risk are a recurring thread across this MOC's sources - [[3. Resources/MOCs/Accessibility & Disability Inclusion MOC]] — applies-in: Joins the build-time decisions that prevent remediation cluster.