A11yInspect Accessibility Testing Tool

A11yInspect is a comprehensive accessibility checking tool for VS Code and CI/CD pipelines — powered by BarrierBreak custom rulesets. Runs accessibility checks to meet Web Content Accessibility Guideline (WCAG) for HTML, JSX/TSX, Vue, Angular, Svelte, Astro, Markdown, MDX, and template-engine files.

Building with accessibility in mind will ensure that your digital assets are accessible to people with disabilities.

Licensing

	Free	Pro	Enterprise
License key	Not required	Pro key	Enterprise key

Core
WCAG accessibility checks	✓	✓	✓
Diagnostics in Problems panel	✓	✓	✓
Sidebar issues panel	✓	✓	✓
Run on save / open	✓	✓	✓

Intellisense & Editor
Context-aware attribute completions	—	✓	✓
Hover accessibility tips	—	✓	✓
Code action quick fixes	—	✓	✓
Scan Workspace	—	✓	✓

Enterprise
Show pass diagnostics	—	—	✓
CLI for CI/CD pipelines	—	—	✓

A11yAssist (AI-powered)
Inline ghost text suggestions	—	—	✓
A11yAssist AI: Explain issue	—	—	✓
A11yAssist AI: Fix element	—	—	✓

Activating a License

Go to VS Code Settings → search for A11yInspect
Enter your license key in the License Key field
Features unlock automatically based on your tier

Visit A11yInspect for Visual Studio Code Extension for subscription information.

Supported File Types

File Type	Details
HTML	Standard HTML files
React (JSX/TSX)	Components with deep cross-component scanning — issues inside imported child components are detected. Handles dynamic text (ternaries, variables, template literals), optional-chained `.map()` rendering, mixed text + element content, and SVG icons with ARIA labels.
Vue	Single-file components (`<template>` section)
Angular	Inline templates and external `templateUrl` files in `.component.ts` files
Svelte	Markup only — `<script>`/`<style>` and logic blocks (`{#if}`, `{#each}`, …) are stripped
Astro	Markup only — the frontmatter fence is stripped
Markdown	Converted to HTML for checking
MDX	Markdown + JSX components
Template engines	EJS, ERB, Handlebars, Nunjucks, Liquid, Twig — template tags stripped, remaining HTML checked

Coverage & Limitations

Read this before your first scan. A11yInspect checks your source files, not a running website. That is what lets it work in your editor and in CI with nothing built and nothing deployed — but it also sets a boundary on what it can see. Knowing where that boundary is will save you from misreading a clean result.

What gets checked exactly, and what gets approximated

File type	What A11yInspect checks	Accuracy
HTML, Markdown, MDX	The final markup itself	Exact
Vue, Svelte, Astro, template engines	The template markup, with directives stripped	High — markup and logic are already separate
JSX/TSX	The component, actually rendered where possible (see below)	Varies by project

Where the check runs

The same rules run in one of two places, chosen automatically by file type:

	Where it runs	Colour contrast
HTML and everything except JSX/TSX, in the editor	VS Code's own Chromium renderer	Checked for real — provided the page loads its stylesheets
JSX/TSX, in the editor	Simulated browser (JSDOM)	Not checked
Any file, in the CLI	Simulated browser (JSDOM) — CI has no VS Code to borrow a renderer from	Not checked

The choice depends on the file, never on the machine, so two developers checking the same file always get the same result. Override with a11yinspect.engine (auto | jsdom | webview).

JSX/TSX: rendered vs. approximated

By default (buildExecute), each React component is bundled and really rendered, so what gets checked is real output. When a component cannot render on its own, A11yInspect automatically falls back to a static approximation — reading the JSX as text instead of running it.

A component typically fails to render alone when it:

Requires a context provider that lives higher up the app (theme, auth, sidebar, i18n) — the component throws without it
Requires a router — useLocation, useParams, or an <Outlet /> with no routes configured
Imports a browser-only library at module scope — charting, mapping, calendar and carousel libraries that touch window or self on import

Why this matters: the static approximation cannot evaluate your code. It can't know which branch of a conditional renders, what a .map() produces, or what a prop's value will be. On a codebase built mostly from reusable components, that leaves very little concrete markup to check.

A file with few or no issues may mean "could not be read", not "accessible." Check the CLI's stderr for build-execute failed for <file>, falling back to static-approx to see which files were approximated.

Not checked, by design

Not checked	Why
Colour contrast in JSX/TSX, and everywhere in the CLI	These run in a simulated browser with no CSS cascade. Rather than guess and risk a false "pass", contrast is not reported. HTML files in the editor do get real contrast results — see the table above.
Colour contrast on a page with no stylesheet	Even in the real renderer, an unstyled page resolves to default black-on-white and would report a perfect score for everything. Those results are dropped rather than shown.
Target size / spacing (WCAG 2.5.8)	Reported as a manual-verification prompt rather than measured — expect a high volume of these on button-heavy files.
Interaction states	Components are rendered once with default props: menus closed, dialogs unmounted, nothing clicked or focused. Focus order and focus visibility can't be verified from a static snapshot.
Event-handler behaviour	Server rendering never emits `onClick` and friends, so a clickable non-interactive element is not detectable from markup alone.
Assets loaded via build plugins	SVGR icon imports (`icon.svg?react`), `?raw`, `?url` and similar are stubbed, not resolved through your real build. Icon-only buttons are therefore checked against a placeholder, not the real icon.

Page-level rules in component files

Rules such as "page has a main landmark", "page has an h1", "page has a title", or "skip link present" are properties of a whole page. A single component file has no answer, so these are reported against a synthetic wrapper — once per file. The extension suppresses the worst offenders in JSX/TSX automatically; the CLI is less aggressive, so expect some repetition in whole-project scans.

To opt a file back into full page-scope checking (e.g. a real page component), add this line comment anywhere in the file:

// a11yinspect-full-page

Getting the best results

Keep buildExecute on. It is the difference between checking real output and checking a guess.
Point the checker at page-level components, not only at leaf primitives — a page component renders its children and yields far more signal.
Pair it with the A11yInspect Chrome extension. The two are complementary, not competing: this extension prevents issues before they ship and covers every file; the browser extension verifies the finished page with real layout, real CSS and real geometry. Their issue counts will not match — one checks every component once, the other checks one screen with every instance counted.
Don't compare raw totals between a whole-project scan and a single-page browser scan without accounting for that difference.

VS Code Extension

Installation

Open VS Code
Go to Extensions (Ctrl+Shift+X / Cmd+Shift+X)
Search for A11yInspect
Click Install

Core Features

WCAG Accessibility Checks

A11yInspect runs WCAG checks powered by BarrierBreak custom rulesets on every supported file. Issues are classified as Fail, Validate, or Suggestion based on their impact, severity and success criteria.

Type	Description
Fail	Critical accessibility violations that must be fixed
Validate	Issues that require manual review to confirm
Suggestion	Best practice recommendations
Pass	Checks the element passed (Only in Enterprise)

Diagnostics in Problems Panel

All accessibility issues are surfaced directly in VS Code's built-in Problems panel (Ctrl+Shift+M / Cmd+Shift+M), just like lint errors. Each issue shows the rule code, issue type, and the affected line — making it easy to scan issues without leaving your workflow.

Run on Save / Open

A11yInspect can run checks automatically:

On save — opt-in, runs when you save a supported file (a11yinspect.runOnSave)
On open — opt-in, runs when you open a supported file (a11yinspect.runOnOpen)

Both can be toggled independently in VS Code Settings.

You can also trigger a check manually at any time by right-clicking in the editor and selecting A11yInspect: Run Accessibility Check, or by using the run button in the sidebar panel toolbar.

The A11yInspect panel appears in the VS Code Activity Bar (side icon bar) and provides a dedicated tree view of all accessibility issues across your workspace.

Group by type — Issues grouped as Fails → Validates → Suggestions → Passes; within each group sorted by line number
Group by file — Issues organised under their source file, sorted Fail → Validate → Suggestion → Pass within each file
Active grouping indicator — The currently active grouping button shows a ✓ icon in the toolbar, so it's always clear which mode is in use
Click to navigate — Click any issue in the tree to jump directly to its location in the editor
Toolbar actions — Run check, Scan workspace, Refresh, and Clear all buttons in the panel header
Live updates — The panel refreshes automatically when a check completes

Switch grouping mode via the toolbar or via a11yinspect.panel.groupBy in settings.

Scan Workspace (Pro / Enterprise)

The Scan Workspace button (search icon, second in the panel toolbar) scans all supported files in your workspace at once. It is also available from the Command Palette as A11yInspect: Scan Workspace. Requires a Pro or Enterprise license — Free users will see an upgrade prompt.

When triggered, a file picker opens with every supported file pre-selected. Deselect any files you want to skip, then confirm to start the scan. A single progress bar tracks the scan (Scanning: filename (X/N)), and a summary notification shows the total issue counts when complete. All results are accumulated in the sidebar panel across every scanned file.

Running Run Accessibility Check on a single file (via right-click, toolbar, or Command Palette) clears the panel first and shows only that file's results.

Build+Execute Mode

React/TSX component files are bundled and actually rendered (react-dom/server) by default, so real component output — including third-party UI libraries and conditionally-rendered content — gets checked directly instead of a static approximation. Falls back to the static approximation automatically whenever a component can't be rendered on its own (e.g. it depends on an app-specific context provider). Disable a11yinspect.buildExecute to use the static approximation only.

Intellisense & Editor Features (Pro)

Context-Aware Attribute Completions

As you type inside an HTML or JSX tag, A11yInspect suggests the accessibility attributes most relevant to that element — alt for <img>, aria-label for <button>, role for custom elements, and so on. Suggestions are tailored per element type, so you only see what's applicable.

Hover Accessibility Tips

Hover over any HTML element to see a structured accessibility guidance panel — what attributes are missing, what values are expected, and relevant WCAG references. Tips are organised by category for easy scanning.

Code Action Quick Fixes

When a diagnostic underline appears on an element, a lightbulb (💡) shows in the gutter. Clicking it presents a list of pre-written, rule-based fixes — e.g. "Add alt attribute", "Add role" — that can be applied instantly without manual editing. No AI required; these are static fixes based on the accessibility rule.

Show Pass Diagnostics (Enterprise)

By default, only issues are shown. Enterprise users can enable pass diagnostics to see which checks an element successfully passed. This is useful for audits and compliance reporting where proof of passing checks is needed.

Enable via a11yinspect.showPasses: true in settings.

AI Integration — A11yAssist (Enterprise)

A11yAssist AI is built into A11yInspect and provides AI-powered accessibility fixes and explanations. All AI features are available with an Enterprise license — no additional API configuration is required.

Feature	Trigger	What You See
Inline Ghost Text	Type `<img` (space after tag)	Ghost text suggests `alt="..."` inline as you type; a status bar spinner shows while the suggestion loads
Explain Issue	Click the explain icon on a sidebar issue, or use the lightbulb → "Explain using A11yAssist AI"	A panel opens with a plain-language explanation of the issue, its impact on users with disabilities, how to fix it, and a WCAG reference
Fix Element	Click the fix icon on a sidebar issue, or use the lightbulb → "Fix using A11yAssist AI"	AI rewrites the element with a proper accessible fix, shown as an inline diff (green = new, red = old). Accept or revert with the CodeLens buttons that appear above
Fix All Fails	Click the Fix All Fails button in the status bar (bottom of VS Code)	AI fixes all accessibility fails in the current file in one pass. A confirmation dialog shows the count before applying

AI fixes also work for page-level issues — issues that apply to the page as a whole rather than a specific element (such as "Page contains no headings" or "Page has no main landmark"). For these, AI suggests HTML to insert at the appropriate location.

How Inline Ghost Text Works

Ghost text appears directly in your editor as greyed-out text — you haven't typed it, it's just a preview suggestion:

Trigger — Type an opening tag followed by a space, e.g. <img or <button
Detection — A11yInspect checks the element type and identifies missing required accessibility attributes
Loading — A $(loading~spin) A11yInspect: Generating suggestion… message appears briefly in the status bar
Ghost text appears — The suggestion renders inline at your cursor, e.g. alt="product thumbnail"
Accept or ignore — Press Tab to insert it, or keep typing to dismiss it

Ghost text is non-blocking and only appears when A11yInspect detects a likely accessibility gap — not on every keystroke. It requires an Enterprise license.

Configuration

{
  "a11yinspect.licenseKey": "",
  "a11yinspect.engine": "auto",
  "a11yinspect.runOnSave": false,
  "a11yinspect.runOnOpen": false,
  "a11yinspect.ignore": [],
  "a11yinspect.rootElement": "",
  "a11yinspect.hideElements": "",
  "a11yinspect.intellisense.enabled": true,
  "a11yinspect.intellisense.showCompletions": true,
  "a11yinspect.intellisense.showHover": true,
  "a11yinspect.intellisense.showCodeActions": true,
  "a11yinspect.showFail": true,
  "a11yinspect.showValidate": true,
  "a11yinspect.showSuggestions": true,
  "a11yinspect.showPasses": false,
  "a11yinspect.ai.ghostText": true,
  "a11yinspect.ai.autoFix": true,
  "a11yinspect.ai.explainIssues": true
}

Settings

General

Setting	Default	Description
`a11yinspect.licenseKey`	`""`	License key for Pro or Enterprise features
`a11yinspect.engine`	`"auto"`	Check engine: `auto` (static files → VS Code's Chromium renderer, JSX/TSX → JSDOM), `webview` (always Chromium), `jsdom` (always JSDOM, no contrast checks)
`a11yinspect.runOnSave`	`false`	Run check automatically on file save
`a11yinspect.runOnOpen`	`false`	Run check automatically when opening a file
`a11yinspect.ignore`	`[]`	Rule codes or types to suppress
`a11yinspect.rootElement`	`""`	CSS selector for the root element to check (empty = entire document)
`a11yinspect.hideElements`	`""`	CSS selector for elements to exclude from checks

Issue Visibility

Setting	Default	Description
`a11yinspect.showFail`	`true`	Show Fail diagnostics (critical violations)
`a11yinspect.showValidate`	`true`	Show Validate diagnostics (require manual review)
`a11yinspect.showSuggestions`	`true`	Show Suggestion diagnostics (best practice recommendations)
`a11yinspect.showPasses`	`false`	Show Pass diagnostics — requires Enterprise

Intellisense (Pro / Enterprise)

Each feature can be toggled independently. intellisense.enabled is the master switch that overrides all sub-settings when disabled.

Setting	Default	Description
`a11yinspect.intellisense.enabled`	`true`	Master switch for all intellisense features
`a11yinspect.intellisense.showCompletions`	`true`	Attribute suggestion popup (Ctrl+Space) inside HTML/JSX tags
`a11yinspect.intellisense.showHover`	`true`	Accessibility tips when hovering over elements
`a11yinspect.intellisense.showCodeActions`	`true`	Quick fix actions in the lightbulb menu

A11yAssist AI (Enterprise)

Setting	Default	Description
`a11yinspect.ai.ghostText`	`true`	Show AI-powered ghost text suggestions while typing inside tags
`a11yinspect.ai.autoFix`	`true`	Enable AI-powered fix actions (individual fix + Fix All Errors button)
`a11yinspect.ai.explainIssues`	`true`	Enable the AI Explain panel for accessibility issues

JSX/TSX

Setting	Default	Description
`a11yinspect.useASTParser`	`true`	Use AST-based JSX/TSX parsing for accurate line positions
`a11yinspect.componentDepth`	`10`	Max depth for resolving nested component imports (max 20)
`a11yinspect.buildExecute`	`true`	Bundle and actually render JSX/TSX (react-dom/server) instead of the static AST approximation. Falls back to the approximation automatically when a component can't render on its own — see Coverage & Limitations

CLI Tool (Enterprise)

The CLI requires an Enterprise license key. Provide it via --license-key=<key> argument or the A11YINSPECT_LICENSE_KEY environment variable.

Usage

# Static file analysis
a11yinspect --license-key=YOUR_KEY "src/**/*.html"
a11yinspect --license-key=YOUR_KEY --format=sarif --output=a11y-report.sarif "**/*.html"

# With reporters
a11yinspect --license-key=YOUR_KEY --github --fail-on=error "src/**/*.{html,jsx,tsx}"

CLI Options

Options:
  -h, --help                Show help message
  -v, --version             Show version number
  --license-key=<key>       Enterprise license key (or set A11YINSPECT_LICENSE_KEY)
  --config=<path>           Path to config file (default: a11yinspect.config.json)
  --format=<format>         Output format: json, junit, sarif, html, console
  --output=<path>           Output file path
  --severity=<level>        Minimum severity: error, warning, notice, pass
  --fail-on=<level>         Fail CI on: error, warning, notice, none
  --ignore=<codes>          Comma-separated rule codes to ignore
  --exclude=<patterns>      Comma-separated patterns to exclude
  --build-execute           Bundle and actually render JSX/TSX (react-dom/server)
                            instead of the static AST approximation (default: on)
  --no-build-execute        Disable build-execute, use the static approximation only

Reporters (opt-in, only enabled ones run):
  --github                  Enable GitHub reporter (uses GITHUB_TOKEN)
  --github-annotations      Add PR annotations
  --github-grouped          Use grouped issue mode
  --jira=<url>              Jira base URL (uses JIRA_TOKEN)
  --jira-project=<key>      Jira project key
  --api=<url>               Custom API endpoint URL
  --api-token=<token>       API bearer token

Reporters are opt-in — only the ones you explicitly pass will run. For example, --github alone enables only GitHub Issues without Jira or API reporting. See CI/CD Documentation for details.

Output Formats

Format	Description	Use Case
`console`	Human-readable output	Local development
`json`	JSON report	Custom processing
`junit`	JUnit XML	Jenkins, CI test reports
`sarif`	SARIF format	GitHub Code Scanning
`html`	Standalone HTML	Shareable reports

GitHub Action (Enterprise)

name: Accessibility Check

on: [push, pull_request]

jobs:
  a11y:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: barrierbreak/a11yinspect@v1
        with:
          license-key: ${{ secrets.A11YINSPECT_LICENSE_KEY }}
          files: 'src/**/*.{html,jsx,tsx}'
          format: sarif
          output: a11y-report.sarif
          fail-on: error

See CI/CD Documentation for detailed setup instructions including Jenkins, GitLab CI, and reporter configuration.

License

Proprietary - see LICENSE file for the full End User License Agreement.

Credits

Developed by BarrierBreak.

A11yInspect Accessibility Testing Tool

BarrierBreak Solutions Pvt Ltd

A11yInspect Accessibility Testing Tool

Licensing

Activating a License

Supported File Types

Coverage & Limitations

What gets checked exactly, and what gets approximated

Where the check runs

JSX/TSX: rendered vs. approximated

Not checked, by design

Page-level rules in component files

Getting the best results

VS Code Extension

Installation

Core Features

WCAG Accessibility Checks

Diagnostics in Problems Panel

Run on Save / Open

Sidebar Issues Panel

Scan Workspace (Pro / Enterprise)

Build+Execute Mode

Intellisense & Editor Features (Pro)

Context-Aware Attribute Completions

Hover Accessibility Tips

Code Action Quick Fixes

Show Pass Diagnostics (Enterprise)

AI Integration — A11yAssist (Enterprise)

How Inline Ghost Text Works

Configuration

Settings

General

Issue Visibility

Intellisense (Pro / Enterprise)

A11yAssist AI (Enterprise)

JSX/TSX

CLI Tool (Enterprise)

Usage

CLI Options

Output Formats

GitHub Action (Enterprise)

License

Credits