AxcessAccessibility evidence workbench
How it works

From a web address to a verified fix

Axcess follows the way an accessibility expert already works. Here is each step in plain language, followed by what the checks actually look at and how sure each one is.

The workflow

Six steps, one scan

  1. Choose the site

    Pick a public website, or choose Site with a login or 2FA for a site that needs a sign-in. For a protected site, Axcess opens a visible browser window and you sign in yourself, with your password, passkey, or one-time code. Axcess never asks for any of them.

    Only scan sites you are authorized to test.

  2. Set the scope

    Decide which part of the site to cover: a single section such as /admissions/ or the whole site. Set a page limit, how deep to follow links, and how gently to crawl. A live preview shows what the scope means before you start.

  3. Watch the scan

    You see the current page, how many pages were discovered, loaded, and tested, which checks ran and which were skipped, and an estimated finish time. Live updates never steal your keyboard focus or jump the page.

  4. Read the report

    One table lists every issue and answers four questions:

    • What is the issue?
    • Why does it matter?
    • What is the expected fix?
    • Where exactly is it?

    Axcess groups repeated occurrences of the same check into one row, so you can look for a shared cause.

  5. Open the evidence

    Follow any issue to the page, the element, the snippet, the rule, or the screenshot that produced it. Everything is stored with the scan, so a claim can be checked months later.

  6. Export and verify

    Record your decisions, export the workbook or report, assign the work, and rescan when fixes land. The comparison shows what is new, still detected, changed, or no longer detected.

Under the hood, in plain words

What each check looks at

A scan runs several independent checks. Each result keeps the name of the check that produced it, so two methods are never blended into one unexplained verdict.

Rule engine

The widely used axe-core engine inspects each rendered page for machine-testable problems: missing image descriptions, broken headings, form fields without names, low contrast, and more.

Deterministic

Second opinion

Optionally, Siteimprove's independent Alfa engine takes its own look. Each result keeps the name of the engine that found it, so you can compare them yourself.

Deterministic

Keyboard check

Axcess presses Tab and Shift+Tab through each page looking for places where keyboard users get stuck. It is deliberately cautious: ordinary focus loops and dialogs are not reported as traps.

Browser-observed

Zoom and reflow check

Each page is squeezed to a phone-width view, zoomed to about 200%, and given wider text spacing to see whether anything is cut off or overlaps.

Browser-observed

Focus check

Finds keyboard focus hidden behind sticky headers or banners, and tab orders that were forced out of sequence.

Browser-observed

Image text check

Text recognition (OCR), included in the desktop app, finds text inside images and compares it with the alt text. An optional local vision model judges what the text is for.

Mixed

Visual and motion check

Measures video and audio that autoplay without controls, records scrolling text, and, with a local vision model, compares the visual reading order to the order a screen reader would hear.

Mixed

Meaning check

With a local language model, asks judgement questions a rule engine cannot: does this link make sense out of context? Does this heading describe its section? Is this form field explained well enough?

AI-assisted lead

Every AI-assisted check is optional and runs on a local model you install yourself. Without one, the browser-only checks still run in full. See exactly which WCAG criteria each check covers.

Evidence before verdicts

How sure is each result?

Not all findings are equally certain, and Axcess never pretends they are. Every result lands in one of three report groups, and only rule-engine failures become Barriers. The glossary defines each group, and What Axcess checks shows which checks feed each one.

Decisions are recorded, not just made. You can mark each finding in progress, remediated, accepted risk, or false positive. Each of those decisions needs a short written reason.

Modern websites

Works with apps, not just pages

Many sites today are applications built with React, Vue, Angular, or similar frameworks. A traditional crawler sees an empty shell. By default, Axcess renders every page in a real browser first.

Routes are discovered by following real links

Axcess follows links it can see on rendered pages, including app-style routes, and stays inside the scope you set. It does not guess private addresses or read application code.

States are counted separately from pages

When Axcess opens a menu or dialog and tests what appears, it reports that as a DOM state alongside the page count, not folded into it. A page count alone would undersell an app; counting states as pages would oversell the crawl.

Interaction is bounded and safe

The probe never follows links to other addresses, and it refuses risky controls such as sign out or delete. It stops at 100 clicks per page, 20 of any repeated control, and five levels of newly revealed controls. See every safety rule.

Some things still need a person

Hover-only content, gestures, operating-system menus, embedded third-party widgets, and states without a visible change on the page are outside what the probe can see. The report says so.

Follow-up

Rescan and compare

Run the same scope again and open Compare reports to see what is new, resolved and remaining, issue group by issue group.

When evidence is missing or the two scans covered different things, Axcess says it cannot compare reliably instead of guessing. "Not found this time" is not automatically "fixed". Read what each comparison result means.