Comparison
Rams vs axe
axe tests a page after it renders. Rams reviews the code before it ships. Different points in the workflow — and a broader surface.
axe (axe-core, from Deque) is the industry-standard accessibility testing engine. It runs against a rendered page or DOM — in the browser, in your test suite, or via tools like Lighthouse — and reports WCAG violations it can detect at runtime. It is excellent at what it does.
Rams works earlier and wider. It reviews your UI source code at pull-request time, before the page renders, and it covers accessibility as one of eight design categories. Where axe answers "is this rendered page accessible right now," Rams answers "is this change good design, and will it ship problems" — and posts inline fixes on the PR.
Rams vs axe, side by side
| Dimension | Rams | axe |
|---|---|---|
| What it checks | Design quality + accessibility, from source | Accessibility violations, at runtime |
| When it runs | On the pull request, before render | After render — browser, test suite, or CI |
| Needs a running app / DOM | No — reads source code | Yes — needs a rendered page or DOM |
| Beyond accessibility | Yes — hierarchy, color, type, spacing, motion, slop | No — accessibility only |
| Visual & design-system issues | Yes | No |
| Inline one-click fixes | Yes — GitHub suggestions on the PR | Reports violations; fixes are manual |
| Setup | GitHub App, no config | Integrate into tests or CI pipeline |
| Coverage style | Reviews the files that changed | Tests the pages/components you point it at |
Use Rams when you want to…
- Catching accessibility and design issues at code-review time
- Reviewing changes that don’t have runtime tests yet
- Design quality beyond accessibility — hierarchy, color, spacing, motion
- A design-aware review on every PR with inline fixes
Use axe when you want to…
- Runtime verification that a rendered page passes WCAG checks
- Automated accessibility tests in a CI pipeline
- Auditing a live, deployed page or app
- Deep, standards-traceable accessibility violation reports
The bottom line
Use both, at different stages. Rams catches accessibility and design problems in code review, before they merge. axe verifies the rendered result at runtime. Shifting accessibility left with Rams means fewer issues ever reach the runtime axe tests in the first place.
Common questions
Does Rams replace axe?
No. axe verifies a rendered page at runtime; Rams reviews source code at pull-request time and covers design quality beyond accessibility. They complement each other — Rams catches issues earlier, axe verifies the final rendered output.
Does Rams need a running app to check accessibility?
No. Rams reads your UI source code, so it can review accessibility on a pull request before the app is built or deployed. axe, by contrast, needs a rendered page or DOM to test against.
Is Rams a full WCAG audit?
Rams checks a broad set of WCAG 2.2 issues at the source level (contrast, focus, touch targets, semantics, keyboard interaction) as part of its review. For runtime-verified, standards-traceable conformance reporting on a live page, a dedicated tool like axe remains the right choice. The two work well together.
See what Rams finds on your repo.
Free on public repos. Every pull request reviewed for design quality, with inline fixes.
Review my public repoFree