Accessibility (a11y) Posture: a proposed benchmark axis for AI app builders (August 2026)

Quick answer

As of August 2026, most leading AI app builders publish little or nothing about the accessibility (a11y) of the code they generate. BuilderProof proposes Accessibility Posture as a benchmark axis: a neutral, documentation-based read of what each builder commits to on semantic HTML, accessible component primitives, keyboard and focus behavior, color contrast, and accessible forms. Scored across the current cohort (v0, Lovable, Replit, Base44, and Bolt.new), only v0 has a documented accessibility foundation, and it comes entirely from its default component library (shadcn/ui on Radix UI), not from an app-level guarantee. The other four builders document no accessibility posture for generated output. "Not documented" is a finding about published commitments, not a claim that the output is inaccessible.

Why accessibility belongs on the benchmark

Accessibility is where a lot of generated code quietly fails. The academic work is blunt about it: in CodeA11y (Mowar, Peng, Wu, Steinfeld, and Bigham, arXiv, February 2025), the authors note that roughly 96% of web pages contain accessibility violations, and they find that AI coding assistants do not generate accessible code by default. That matters more each year as conformance moves from a nicety to a requirement. The reference standard is the W3C's Web Content Accessibility Guidelines (WCAG) 2.2, published October 2023: 13 guidelines organized around four principles (perceivable, operable, understandable, robust) with testable success criteria at three levels (A, AA, AAA).

BuilderProof already runs an empirical accessibility check inside its deploy-quality benchmark, where a deployed app is audited with Lighthouse. This proposed axis is the complement to that audit, not a duplicate of it. The empirical audit asks "how did this one build score after deploy?" This axis asks a different, earlier question: "what does the builder commit to about accessibility, before you ever hit deploy?" Both are useful. A builder can score well on one and poorly on the other.

What this axis measures, and what it does not

This is a documentation-posture axis. It scores what a builder publicly documents about the accessibility of its generated output, using the builder's own docs, changelogs, and component-library references as primary sources. It does not run a screen reader over generated apps, and it does not assign a Lighthouse or axe score. Documentation posture is a leading indicator: teams that write down an accessibility commitment tend to ship it more consistently, and buyers evaluating a builder for a regulated product need to know whether any commitment exists on paper at all.

Two guardrails apply throughout. First, "Not documented" does not mean "inaccessible." A model can emit perfectly accessible markup without the vendor writing a word about it. Second, the reverse is also true: a documented accessible component library does not guarantee an accessible finished app, because landmarks, heading order, contrast choices, and form labels are assembled at the app level.

The five proposed sub-criteria

Each builder is read against five sub-criteria, chosen to map onto the WCAG 2.2 principles and the WAI-ARIA Authoring Practices Guide:

1. Accessible component primitives. Does the builder's default component library document WAI-ARIA roles, states, and keyboard behavior for interactive controls (menus, dialogs, tabs, comboboxes)?
2. Semantic HTML and landmark structure. Does the builder document generating semantic elements and page-level landmarks (a single main, real nav and header, sensible heading order) rather than a wall of styled div elements?
3. Keyboard navigation and focus management. Does the builder document focus order, focus trapping in modal dialogs, focus return on close, and a visible focus indicator?
4. Color contrast and accessible visual defaults. Do the default themes or design tokens document a WCAG AA contrast commitment (4.5:1 for body text)?
5. Accessible forms, labeling, and built-in validation. Does the builder document programmatic label association, accessible error messaging, and any automated accessibility check (axe-core, Lighthouse, or pa11y) run over the generated output?

Scoring rubric

Every cell is one of three values, applied identically to every builder:

• Documented. The builder or its named default component library publicly documents a specific commitment for this sub-criterion, with a citable source.
• Partial. A relevant commitment exists but is incomplete: it covers components but not the assembled app, or it names the capability while explicitly leaving the work to the developer.
• Not documented. BuilderProof found no published accessibility commitment for this sub-criterion in the builder's public docs as of August 2026. This is a statement about documentation, not about runtime behavior.

The cohort, scored

Cohort logos below are shown for identification only, inside the comparison table.

No builder earns a clean sweep, and every builder carries at least one documented gap. The headline is the shape of the table, not a winner: accessibility is the least-documented posture BuilderProof has scored to date, with a single builder (v0) accounting for every non-blank cell, and only because of the component library it standardizes on.

Reading the matrix, builder by builder

v0. v0 generates shadcn/ui components, described as "beautifully-designed, accessible components," built on Radix UI primitives. Radix states that its primitives "follow the WAI-ARIA authoring practices guidelines" and handle "aria and role attributes, focus management, and keyboard navigation." That is a genuine, citable foundation, and it is why v0 is the only builder with any Documented or Partial cells. The gaps are equally real: this posture lives at the component level. Radix is explicit that labeling is "up to you," v0 documents no app-level landmark or heading-order guarantee, ships no documented WCAG AA contrast commitment, and documents no automated accessibility validation of the finished app. Strong primitives, undocumented assembly.

Lovable. Lovable's documentation is detailed on security and compliance (SOC 2, ISO 27001, GDPR) but says nothing about the accessibility of generated apps. A robust compliance story is not an accessibility story; on this axis, Lovable is Not documented across all five sub-criteria.

Replit. Replit's docs cover Agent, deployment, and monitoring in depth, with no published accessibility posture for the apps its Agent builds. Not documented across the board.

Base44. Base44's documentation focuses on features and getting started and does not address accessibility of generated output. Not documented across the board.

Bolt.new. Bolt's help center documents troubleshooting and workflow but no accessibility commitment for generated code. Not documented across the board.

What this axis deliberately does not measure (its own bias)

Every BuilderProof axis names its own bias, because a scorecard that hides its blind spots is worse than no scorecard.

• It measures documentation, not behavior. A builder marked Not documented may still emit accessible markup, and a builder with a documented library can still assemble an inaccessible app. Treat this axis as a leading indicator, paired with the empirical Lighthouse audit.
• It rewards component-library standardization. A builder that standardizes on an accessible library (v0 on shadcn/Radix) scores above one that emits bespoke markup, even if a strong model's bespoke output is perfectly accessible. That is a documentation advantage, not proof of a runtime advantage.
• Automated checks are not the whole story. Even an empirical follow-up has limits: automated tooling catches only a fraction of WCAG issues. As one front-end practitioner put it on r/Frontend, "No automated tool can ensure accessibility, it can only find certain flaws" (r/Frontend, 2025). Manual audit with a real screen reader remains mandatory for a conformance claim.
• It is a point-in-time read. Documentation changes. This scan reflects public docs as of August 2026 and is meant to be re-run.

This axis is a proposal, consistent with the BuilderProof methodology. It enters the composite only after a fixed, published scan procedure and a review window, not on the strength of a single reading.

How to reproduce this scan

1. Fix the target: WCAG 2.2 level AA, plus the WAI-ARIA Authoring Practices Guide for interactive components.
2. For each builder, search its public docs, changelog, and any named default component library for the terms accessibility, a11y, WCAG, ARIA, screen reader, semantic HTML, focus, and contrast.
3. Classify each of the five sub-criteria as Documented, Partial, or Not documented, and record the source URL for every non-blank cell.
4. Do not infer runtime behavior from documentation, and do not infer documentation from runtime behavior. Keep the two scans separate.
5. Re-run quarterly, since component libraries and docs move.

FAQ

Common questions about the proposed accessibility posture axis are answered below.

BuilderProof editorial team. "Accessibility (a11y) Posture: a proposed benchmark axis for AI app builders (August 2026)". BuilderProof, August 2026. https://www.builderproof.org/benchmarks/accessibility-a11y-posture-axis-proposal-august-2026.

@misc{builderproof-accessibility-a11y-posture-axis-proposal-august-2026,
  title  = {{Accessibility (a11y) Posture: a proposed benchmark axis for AI app builders (August 2026)}},
  author = {{BuilderProof editorial team}},
  year   = {2026},
  month  = {aug},
  howpublished = {\url{https://www.builderproof.org/benchmarks/accessibility-a11y-posture-axis-proposal-august-2026}},
  note   = {BuilderProof, builderproof.org}
}