7 days left of the founding launch: 30% off both plugins, 50% off the SuiteSee pricing
← Docs

Understanding the Accessibility audit

The Accessibility audit checks your Bricks project against WCAG 2.2, Level A and AA, the standard European and US accessibility law points at. It reports what a machine can decide, cites the exact criterion behind every finding, and then tells you plainly what it could not check.

The claim, and its bound

Automated checking decides 13 of the 55 Level A and AA criteria outright. The rest depend on meaning, intent or interaction: whether your alt text describes the right thing, whether a video’s captions are accurate, whether an error message actually helps. No software can judge those, and any tool that says otherwise is selling you a risk rather than a result.

So this audit is deliberately bounded:

  • It will never tell you your site is compliant, accessible, or certified. Not in the plugin, not on this site, not in support. A clean scan is not a statement about conformance, and treating it as one is how sites get sued after paying for a green tick.
  • Every finding cites its criterion and level, 1.4.3 Contrast (Minimum) (AA), and links the W3C’s own explanation of it, so you can check our reasoning rather than trust it.
  • A permanent panel names what still needs a person. It sits under the findings, it cannot be dismissed, and it lists the human-only criteria that apply to the content actually found on your site, so a site with videos is told about caption quality and a site without them is not.

That panel is the honest half of the audit, and it is the half most tools leave out.

The two passes

Some accessibility problems are visible in how a page is built. Others only exist once a browser has painted it. The audit runs both ways.

Reading your Bricks data covers every page you have, and knows what you meant: missing alt text (including the media-library fallback that rendered markup cannot distinguish from a real one), skipped heading levels, unlabelled form fields, a positive tabindex, an untitled frame, ARIA attributes that do not exist.

Measuring the rendered page catches what data cannot show, and rides along with the Responsive audit’s browser pass so your pages are only loaded once: text contrast against the background actually painted (which may come from an ancestor, a global class or a theme style), form-field borders too faint to locate, focus outlines removed with nothing put back, and duplicated ids that an ARIA relationship points at.

Where both passes see the same problem on the same element, the one that read your Bricks data wins, because it can send you straight to that element in the builder.

Reading a finding

Each row carries the criterion number and its level as a badge, a plain-language title, and a description that says what the consequence is for a real person, not what rule was broken. Findings on Bricks elements deep-link into the builder and can be outlined and numbered on the live page. Markup that Bricks does not control, a theme header, a third-party embed, is reported and labelled as such rather than quietly dropped: the problem is real even when we cannot take you to it.

Two findings are deliberately marked minor because they are prompts rather than decided failures. A page with no main landmark and a page with no working skip link can both still satisfy their criterion through headings and structure, so they are raised for a human to judge and never counted as defects.

One finding is never a failure at all. When a video is found, the audit says so and asks a person to check the captions, because inaccurate captions are worse than none and no automated tool can tell the difference.

What it fixes

Six findings have one-click Smart Fixes: alt text, heading level, positive tabindex, autocomplete tokens, frame titles, and text contrast. They follow the same rules as every other Smart Fix, snapshot first, verify, undo cleanly.

Two of them refuse to invent anything. The alt-text fix asks you what the image conveys and offers “decorative” as a real answer, because generated alt text that reads plausibly and describes the wrong thing is worse than none. The contrast fix offers only colours already in your palette that pass, each labelled with the ratio it reaches, and will decline entirely rather than generate a shade: an invented “accessible” colour would pass the checker and quietly redesign your site.

Where a fix would be dishonest, there is no button. A missing language declaration, for instance, is reported with guidance pointing at your header template, because there is no setting the plugin could write that would put it back.

The European Accessibility Act (Directive (EU) 2019/882) applies from 28 June 2025 to a broad range of consumer-facing digital services sold in the EU. The harmonised standard behind it, EN 301 549, incorporates WCAG 2.1 Level AA today; version 4.1.1, which aligns it with WCAG 2.2, is prepared and awaiting citation in the Official Journal.

Bricks Health checks against WCAG 2.2 A and AA, which is a superset of WCAG 2.1 AA, so work you do now holds when 2.2 is cited. That is a factual statement about standards, not legal advice, and it is not a claim about your site’s status under any law. If you need a conformance statement, you need an audit by a person.

The full rule list

Every check, with its criterion, severity and whether it has a fix, is in the rule reference.