Skip to content
Utiloom

Accessibility Checker

Calculate WCAG 2.2 contrast evidence and run bounded axe-core checks against sanitized HTML in a network-denied unique-origin iframe.

LocalNo HTML retention

Reviewed July 13, 2026

Guide, examples, and validation Show

About this tool

Separate deterministic contrast calculations, automated violations, uncertain findings, passes, and manual review without claiming WCAG conformance.

Accessibility Checker bundles two checks front-end teams run most often. The contrast calculator takes a foreground and background in six-digit hex, along with text size in CSS pixels, font weight, and whether the sample is text or a UI component, and reports the ratio against the WCAG 2.2 thresholds of 4.5:1, 3:1, and 7:1 with the large-text rule applied automatically. The HTML audit takes a document or fragment up to 500,000 characters, strips scripts, event handlers, embedded frames, and resource URLs, then runs axe-core inside a sandboxed iframe that cannot reach the network. You get violations, incomplete checks, and passes with CSS selectors for each node, a manual review list, and downloadable JSON for either check.

  • Calculates normal, large, enhanced, and non-text contrast thresholds from opaque sRGB colors, text size, and weight.
  • Removes executable elements, event handlers, embedded documents, and resource URLs before running axe-core in a unique-origin iframe with network-denying CSP.
  • Reports violations, incomplete checks, passes, CSS targets, sanitized-input evidence, and a manual checklist while explicitly excluding conformance claims.

How to use Accessibility Checker

Use the Accessibility workflow control to switch between contrast and HTML audit. For contrast, type hex values into Foreground and Background, or use the swap button to invert them, choose Text or UI component or graphic, then enter Text size in CSS px from 1 to 512 and a weight from 400 to 800. The preview updates live and the badge reads Meets or Below selected threshold, with the required ratio spelled out. For the audit, paste markup into HTML document or fragment or open an .html file up to 1,000,000 bytes; a sample product-update page is available to try. Run the audit, then browse the Automated result group tabs for violations, incomplete, and passes. Download JSON saves either report.

When this tool is useful

  • A designer proposing a lighter grey for helper text needs the exact ratio before the token change is approved.
  • A front-end developer pastes a rendered component's HTML to catch missing labels and alt attributes before opening a pull request.
  • A content editor checks that a marketing page's heading levels do not skip from h1 to h4.
  • A QA engineer confirms that icon-only buttons in a static template carry accessible names.
  • A theme author confirms that link colours on the dark variant still clear 4.5:1 against the card background.

Practical tips

  • Large text means at least 24 CSS px at any weight, or 18.66 px at weight 700 and above; an 18 px bold heading still counts as normal text.
  • The calculator assumes opaque colours. If the real UI uses transparency, gradients, or an image behind text, measure the composited colour from a screenshot instead.
  • Incomplete findings are not failures. axe-core flags them when it cannot decide, which often means colour from an external stylesheet it could not see.
  • External stylesheets and images are neutralised before the audit, so paste HTML with the relevant styles inlined if colour or visibility rules matter.
  • The fixture renders at a fixed 1280x720 viewport and caps at 5,000 elements, so audit one page section at a time rather than a whole app shell.

Examples you can test

Load an example, compare the result with the expected output, then replace it with your own input.

Helper text on a light card

Example input

Foreground #626c67, background #f6f7f5, Text, 14 px, weight 400

Expected output

Ratio 5.06:1, required 4.5:1 for normal AA text, Meets selected threshold; the AAA 7:1 row still fails

Lighten the grey a few steps and this pair drops below AA, so record the exact token value rather than an approximation.

Audit a form fragment

Example input

<form><input type="email" placeholder="Email"><button><svg></svg></button></form>

Expected output

Violations for the unlabeled input and the button with no accessible name, each with a CSS selector such as form > button

A placeholder is not a label; add a visible label or aria-label, then re-run to watch the violation move into passes.

Validation checklist

  • Confirm the hex values match the rendered colours, including hover and disabled states.
  • Check text size and weight against the actual CSS, not the design file.
  • Fix every violation, then review each incomplete item by hand.
  • Walk through the real page with a keyboard and a screen reader afterwards.
  • Avoid describing a clean audit as WCAG conformance in release notes.

Frequently asked questions

Does a clean result prove WCAG conformance?

No. Automated rules cover only detectable conditions; keyboard, screen reader, content, complete-process, zoom, motion, media, and usability review remain manual.

Is pasted HTML executed directly?

No. User scripts, event handlers, embedded documents, and network URLs are removed or neutralized before a trusted axe-core bundle runs in a unique-origin sandbox.

Which contrast thresholds are used?

WCAG 2.2 ratios: 4.5:1 for normal AA text, 3:1 for large AA text and non-text UI, 7:1 for normal AAA text, and 4.5:1 for large AAA text.

Related tools

Keep the workflow moving

Continue with tools that handle a related input, output, or validation step.

Developer

CSV Viewer & Cleaner

Profile, clean, and convert CSV data locally.

Local
Developer

JSON Patch Builder & Applier

Build and atomically apply verified RFC 6902 JSON patches.

Local
Developer

JSON Schema Validator

Validate bounded JSON Schema and instance data locally.

Local
Developer

Unicode Inspector & Normalizer

Inspect and normalize Unicode text with encoding evidence.

Local