Deque • Enterprise software
axe Linter catches accessibility issues at the source-code layer before code ever runs.
Pre-commit and pull-request static accessibility analysis for HTML, JSX, TSX, Vue, Angular, React Native, and Markdown. Free VS Code edition for individual developers and a paid enterprise tier with CI/CD integration, pre-commit hooks, and team-wide rule configuration. Available through Merito with per-repo rollout and developer enablement.
What it is
axe Linter shifts accessibility checking left of every other tool in the Deque portfolio. It runs against source code itself, not against a rendered page or a built app, so accessibility violations get caught before code reaches a build, a browser, or a CI run. The free Axe Accessibility Linter for VS Code is the entry point. The paid axe DevTools Linter adds enterprise features: pre-commit hooks that block inaccessible code before it commits, pull-request integration that gates merges, CI/CD plugins for the major pipeline systems, REST API and CLI for custom integrations, and team-wide configurable rules.
Coverage spans the file types modern front-end teams actually ship. React (JS, JSX, TSX), React Native, Vue (.vue), Angular (component and template files), HTML, and Markdown. IDE integrations cover VS Code, IntelliJ IDEA, and WebStorm with real-time inline feedback during development. The 44-rule ruleset is a focused subset of the full WCAG surface: the rules that can be statically verified without rendering the page.
Merito frames axe Linter as the developer-experience entry point to the broader axe portfolio. Standalone deployment is fast (about a week per repo) and the value shows up in the next pull request cycle. The full accessibility program still needs axe DevTools for runtime scanning, axe Auditor for the structured manual surface, and axe Monitor for production drift detection. Linter is the leftmost shift; it is one quadrant of the four-product stack.
Ideal use cases
What it is best at
Pre-commit and PR-level accessibility blocking is rare in the accessibility tooling space. Most scanners run in a browser or a CI build environment. axe Linter runs against source files themselves, which is the cheapest place in the SDLC to catch a violation.
React (JSX, TSX), React Native, Vue (.vue), Angular component and template files, HTML, and Markdown. Covers the file types front-end teams actually ship; no custom parser configuration required.
The free Axe Accessibility Linter for VS Code is not a feature-stripped marketing demo. Individual developers can use it for real work. The paid tier adds enterprise features (pre-commit hooks, PR gating, team-wide rules) that only become valuable at organization scale.
Custom-component patterns specific to a team's design system get encoded as configurable rules so the linter recognizes them as accessible (or flags them when they should be).
Beyond the IDE plugins and CI/CD integrations, the REST API and CLI let teams wire axe Linter into bespoke developer tooling, code review bots, or pre-deploy validation gates.
Core capabilities
Static analysis against source files; no rendering, no build, no browser required.
44-rule WCAG-aligned ruleset
Curated set of accessibility rules that can be statically verified without rendering the page. A focused subset of the full WCAG surface, optimized for false-positive minimization in static analysis.
Multi-framework parsing
First-class parsing for JSX, TSX, .vue, Angular component templates, HTML, and Markdown. No bespoke parser configuration required for the dominant front-end frameworks.
Custom-rule authoring
Teams write their own rules for design-system component patterns. The linter learns to recognize accessible-by-construction custom components and to flag misuses.
Real-time inline accessibility feedback during development across the major front-end IDEs.
VS Code (free and paid)
Free Axe Accessibility Linter for individual developers; paid axe DevTools Linter for team and enterprise rollout. Both run as VS Code extensions with inline diagnostics.
IntelliJ IDEA and WebStorm
Plugin support for JetBrains IDEs with the same inline diagnostic experience as VS Code.
Inline fix suggestions
Findings include suggested fixes inline. Developers can apply most fixes from the IDE without leaving the file.
Block inaccessible code before commit and gate pull requests inside the major pipeline systems.
Pre-commit hooks
Hook configuration blocks commits that contain accessibility violations. Configurable severity thresholds determine which findings hard-block versus warn.
Pull-request gating
Native integration with GitHub, GitLab, Azure DevOps, and Bitbucket gates merges on accessibility findings. Comments inline on the PR diff.
CI/CD pipeline integration
Plugins for GitHub Actions, Jenkins, SonarQube, CircleCI, GitLab CI, Azure DevOps, Travis CI, and Bamboo. Accessibility scans ship in the same pipeline as security and quality scans.
REST API and CLI
REST API for custom developer tooling integrations. CLI for ad-hoc scanning, bespoke pre-deploy gates, and code-review bot integration.
Where it fits in the stack
First-party plugins for the major front-end IDEs.
Vendor-documented plugin patterns for the major CI systems and source-control hosts.
Programmatic interfaces for bespoke developer tooling integration.
Deployment and implementation
Licensing and packaging
Axe Accessibility Linter (free, VS Code)
Free VS Code extension with basic accessibility linting. Individual developer use only.
Best for: Individual developers running personal accessibility checks during development. Not licensed for organization-wide rollout.
axe DevTools Linter (standalone)
Paid enterprise tier. Pre-commit hooks, PR gating, CI/CD integration, team-wide custom rules, REST API, CLI. Standalone subscription.
Best for: Engineering organizations deploying accessibility shift-left as a program-level initiative.
axe DevTools Linter (bundled with axe DevTools Pro)
Bundle pricing combining Linter (source-side) and axe DevTools Pro (runtime + CI). Single contract.
Best for: Organizations standing up the full developer-tier of the axe portfolio under a single agreement.
Merito services
Pick the engagement that matches where you are in the lifecycle.
WCAG, ADA, and Section 508 program delivery built around shift-left accessibility tooling. Audit playbook design, governance, and ongoing run.
Explore service02License setup, IDE plugin rollout, pre-commit hook configuration, PR-gate wiring, custom-rule authoring for design-system components, and developer handover.
Explore service03Linter wired into CI/CD and PR gates so accessibility scanning ships alongside SAST, SCA, and quality gates in the same pipeline.
Explore service04Developer workshops on the 44-rule ruleset and on authoring custom rules for design-system component patterns.
Explore service05Named engineer, priority SLAs, and release-time coverage on the axe Linter rollout and CI/PR gating configuration.
Explore service06Merito-placed front-end engineers experienced with axe Linter rollout and custom-rule authoring.
Explore serviceaxe Linter licensing
axe Linter across IDE, pre-commit, PR gate, and CI, available through Merito with per-repo rollout, custom-rule authoring, and developer enablement.
Merito point of view
Merito's position. The cheapest place to catch any defect (security, quality, accessibility) is at the source. Linter runs against source files before they commit, so accessibility violations get caught before code reaches a build, a browser, or a CI run. The cost of fixing a finding scales with how late it is detected. Linter pulls accessibility detection as far left as it can go.
The 44-rule ruleset is a focused subset of the full WCAG surface. Linter is not a complete accessibility scanner. It catches what static analysis can verify without rendering the page. The rest of the WCAG surface requires runtime scanning (axe DevTools), structured manual audit (axe Auditor), and continuous production monitoring (axe Monitor). Customers who buy Linter expecting it to replace the full stack will be disappointed.
Linter is the smallest investment with the fastest payoff in the axe portfolio. Standalone deployment is about a week per repo. The value shows up in the next pull-request cycle. Merito recommends Linter as the first step for engineering organizations new to accessibility tooling because the install-cost-to-value ratio is the best in the portfolio.
Custom-rule authoring is the underrated capability. Most enterprise design systems have component patterns that look inaccessible to a generic scanner but are accessible by construction (or vice versa). Encoding those patterns as custom rules cuts false-positive noise and lets the linter understand the team's actual code. Merito's standard rollout includes one custom-rule authoring sprint per design system.
What buyers usually underestimate
Related from Merito
Related solutions
Related services
Related products
Frequently Asked Questions
Consultation request
Share your front-end framework mix, repository count, design-system maturity, and CI host. A Merito accessibility specialist follows up within one business day.
Leftmost shift
Linter is the only product in the axe portfolio that runs against source code before it commits. The cheapest place in the SDLC to catch a violation.
Custom rules
Merito's standard rollout includes a custom-rule authoring sprint per design system. False-positive noise drops; developer trust in the tool goes up.
Next step
A Merito axe Linter conversation starts with the reference repository and the design system. Pre-commit, PR gating, CI integration, and custom-rule authoring sequence in that order.