Frequently Asked Questions

Concepts

What is the difference between a Git project and a Gitless project?

Developer Hub organizes your results differently depending on whether your tests use Git:

• A Git project associates accessibility results with branches and commits, allowing you to track issues back to specific code changes.
• A Gitless project organizes results as a series of test runs ordered by timestamp, without any Git data.
• Git data is available when using Axe Watcher, the Axe CLI, or the Axe DevTools for Web APIs (which upload results via the CLI). Mobile projects are always Gitless.

See Understand Your Results and the glossary entries for Git and Gitless for more details.

What is the a11y threshold and how do I configure it?

The a11y threshold reflects your organization's tolerance for accessibility issues and determines what counts as a failure in your CI/CD pipeline:

• It is computed from two criteria: whether to count all issues or only new issues, and which impact levels to include (Critical is always included).
• Only project admins can configure the threshold.

See Change the A11y Threshold for full details.

What do the impact levels (Critical, Serious, Moderate, Minor) mean?

Every accessibility violation is assigned one of four impact levels, from most to least severe:

• Critical: Users with disabilities are completely blocked from accessing or interacting with a feature.
• Serious: Users with disabilities face significant barriers when interacting with the site.
• Moderate: Some barriers exist, but basic content is still accessible.
• Minor: Less severe issues that still require resolution for full compliance.

See the Glossary for detailed definitions.

Why do the same issues keep getting reported as new?

To decide whether an issue is new, Developer Hub compares each result against the previous run by rule, element selector, and URL, as described under Duplicate in the glossary. If the same issue on the same element is reported as new on every run, one of those is changing between runs. There are two common causes.

The URL changes between runs. The URL is compared in full, so a session ID, a timestamp, a cache-busting parameter, or any other dynamic value in the query string makes each run look like a different page, and every issue on a URL that hasn't been seen before is reported as new. No setting normalizes URLs before they are compared, so the fix is to make the URLs your tests visit deterministic: remove or fix the volatile parameters in your test setup so the same page produces the same URL on every run.

The element's IDs or classes change between runs. Frameworks that generate identifiers such as #component-a1b2c3d4 or .form-field-xyz789 on each render change the element's selector, so it no longer matches the element recorded previously. Setting the ancestry run option to true fixes this, because the ancestry selector describes the element by its position in the DOM tree and contains no IDs or classes:

axe: {
  runOptions: {
    ancestry: true
  }
}

See Using Dynamic Selectors for the full explanation, including Java configuration and the trade-offs of enabling ancestry.

Comparisons

Every "new issue" or "resolved issue" count in Developer Hub comes from comparing the current scan against a baseline scan. Which scan counts as the baseline depends on where you're looking:

• Cross-branch comparisons appear in the Branches view. They compare your branch's latest scan against the latest pipeline run on the default branch. A pipeline run is a scan triggered by your CI/CD pipeline, as opposed to a local run from a developer's machine; Developer Hub flags these separately so it always knows which scan of the default branch is authoritative. This answers "what would change if I merged right now?"
• Within-branch comparisons appear on the Commits view. They compare a commit's scan against the scan from the previous commit that has results on the same branch, which isn't necessarily the literal previous commit in your Git history: a commit with no scan is skipped over. This answers "what did this specific commit introduce or fix?"

The GitHub Action isn't a third comparison type. The counts it posts to a pull request are the within-branch comparison for the current commit, not a comparison against the default branch, which is a common source of confusion since a PR check is often expected to compare against the branch you'd be merging into.

See Understand Your Results for the full picture.

How do I determine what is changing from release to release?

The Branches view in a Git project lets you track accessibility changes across releases using a cross-branch comparison:

• Each branch's latest scanned commit is compared against the latest pipeline run on your default branch.
• The comparison shows the total number of issues, new issues introduced, issues resolved, and any changes in the number of page states scanned.

To see what changed in individual commits within a branch, see How do I see what has changed from commit to commit within a branch?

How can I determine what the impact will be of a pull request?

Run your test suite on the pull request branch so that results appear in Axe Developer Hub:

• On the Branches view, each non-default branch displays a cross-branch comparison to the default branch, showing new issues introduced, issues resolved, and the total difference.
• If you use the GitHub Action, it can automatically post a comment on the PR with a summary and a link to the full results.

To drill into what each commit on the branch changed, see How do I see what has changed from commit to commit within a branch?

How do I see what has changed from commit to commit within a branch?

From the Branches view, click on View Commits on any branch to see its individual scanned commits. Unlike the cross-branch comparisons on the Branches view, the Commits view uses within-branch comparisons:

• Each commit is compared to the previous scanned commit on that branch, showing new issues, resolved issues, and changes in page states.
• Only commits where the test suite was run will appear.

To see how the branch as a whole compares to the default branch, see How do I compare a branch with the latest CI/CD run on the default branch?

How do I compare a branch with the latest CI/CD run on the default branch?

The Branches view automatically performs a cross-branch comparison for each non-default branch against the default branch's latest pipeline run:

• This requires a project admin to have configured Axe Watcher to run on the default branch as a pipeline run.
• The comparison shows total issues, new issues, resolved issues, and page state differences.

To see what changed in individual commits within that branch, see How do I see what has changed from commit to commit within a branch?

How do I get accurate comparison results before creating a pull request?

For the most accurate cross-branch comparison before merging, keep your feature branch up to date with the default branch:

1. Merge the default branch into your feature branch (for example, git merge main) before running your test suite.
2. Push the merge commit so Axe Developer Hub can scan the updated branch.
3. The Branches view will then compare your branch against the latest pipeline run on the default branch, showing only the accessibility changes your branch actually introduces.

If your feature branch is behind the default branch, the comparison may surface issues that were already fixed in the default branch but haven't been merged into your feature branch yet. Merging the default branch in first eliminates those false positives and reduces surprises when the pull request is merged.

Why do I see issues reported as new or resolved when a different set of tests ran?

A comparison is only meaningful when the same set of tests ran on both sides of it:

• If a run visits a page the baseline run never visited, every issue on that page is reported as new, because there is nothing to compare it against.
• If a run skips a page the baseline covered, that page's issues show as resolved even though nobody fixed anything, since they simply weren't tested.
• Two runs covering genuinely different test suites shouldn't be compared at all; the result won't tell you anything useful.

This isn't something a setting can fix. See Best Practices for Accurate Comparisons for how to set up your test suite so comparisons stay meaningful.

Best Practices for Accurate Comparisons

• Use one project per set of tests. A project should correspond to one test suite. Pointing several suites at one project means every run compares against a baseline produced by a different set of tests, and the new and resolved counts stop meaning anything.
• Run the same set of tests every time. Changing what the suite covers changes what the comparison can tell you. When the suite legitimately grows, expect a one-time jump in new issues on the run that adds the coverage.
• Set up a pipeline run on your default branch. Cross-branch comparisons measure a branch against the latest pipeline run on the default branch. Without one there is no baseline at all, and every issue is reported as new, which is the most confusing version of this symptom. Setting this up is a project admin task; see Pipeline Information.

CI/CD

How do I make sure no new accessibility issues are merged into my code?

Integrate Axe Developer Hub into your CI/CD pipeline so that accessibility checks run automatically on every commit or pull request:

• If you use GitHub, the Axe Developer Hub GitHub Action can block PRs that introduce accessibility errors.
• For other platforms like GitLab or Bitbucket, use the REST Service API to query results and fail your pipeline when issues are detected.
• You can fine-tune what counts as a failure by configuring the a11y threshold.

How do I integrate Axe Developer Hub with my CI/CD pipeline if I don't use GitHub?

You can use the REST Service API to integrate with any CI/CD platform:

• The REST Service API lets you query Axe Developer Hub for results after your test suite runs.
• The API returns the issue count, new violations, resolved violations, and a link to the full results in Developer Hub.
• You can use this response to pass or fail your pipeline in GitLab, Bitbucket, Jenkins, or any other platform.

Project Management

How do I view other team members' accessibility scans on a project?

All project members can view all results within a shared project once they've been added:

• Add team members through the Members settings page.
• On Git projects, the Branches view displays results grouped by API key, so you can see who ran each scan.

For details on roles and permissions, see Set Up Projects for Team Use.

How do I export my accessibility results?

Developer Hub offers several ways to export your data:

• From the issue summary view, click the Export Issues button to download results as CSV or JSON.
• For programmatic access, use the REST Service API to query results for a specific commit and project.

See Get Results Programmatically for more options.