Introducing Accented
Accented helps you catch accessibility issues on your page the moment they appear — no need to run audits using browser extensions. It integrates seamlessly into your dev flow with just a few lines of code.
Here’s what Accented is about.
You add a bit of code to your web app, for example:
if (process.env.NODE_ENV === 'development') {
const { accented } = await import('accented');
accented();
}
That’s all the setup you need to get real-time accessibility auditing of the page that’s rendered in your browser, using axe-core, the most popular accessibility testing engine.
Each element with at least one accessibility issue gets highlighted.


Clicking one of the added buttons shows enough information to understand what the issue is and how to fix it.

The issues are updated when page contents or styles change (Accented uses a mutation observer to detect changes), which is common in apps of all kinds — from mostly static pages to full-blown single-page apps (SPAs).
Accessibility testing tools: an overview
To see where Accented fits in a dev workflow, let’s take a look at the landscape of available accessibility testing tools.
Disclaimer: I’m only reviewing automated approaches here. Many types of issues may only be correctly identified by a human, so none of these tools are intended to replace manual audits.
All the tools fall into two broad categories:
- The ones that audit the source code.
- The ones that audit the rendered page.
I will leave AI-based tools out of the conversation. They can potentially identify more issues than the algorithmic approaches (they can sometimes even catch what human auditors may miss), but they’re not free and are by nature unreliable. They’re simply an entirely different category of tools.
Source-code-based tools
These tools operate on a limited test surface — there’s a finite amount of source code in any project.
The downside is that they’re limited in the types of issues they can detect.
For example, they can help with missing alt attributes or inputs not having correctly associated labels.
They won’t tell you if your headings are in an incorrect order — that requires a rendered page to test.
The most widely used tool in this category is eslint-plugin-jsx-a11y, which is a plugin for ESLint.
As its name suggests, if you author your app using JSX, it checks your whole codebase against a set of accessibility rules.
It’s great as the first line of defense, it’s very easy to set up, and it requires virtually no maintenance.
Rendered-page-based tools
Such tools can never test all the surfaces: even in the simplest cases, the page may be presented to the user in a multitude of ways, depending on their device, OS, browser, preferences, and so on, and with every new input, the number of possibilities grows exponentially.
The potential to be able to correctly identify issues is also higher because, unlike with the source code, your test script actually perceives the page the way your user may perceive it.
Most tools in this category are based on axe-core, and can detect a wide range of accessibility concerns, such as contrast issues, heading structure problems, and list semantics.
- Accented belongs to this category. It costs very little to set up and maintain, it catches issues in real time (similar to linters), and it’s completely framework-agnostic.
- There are on-demand auditing tools, such as browser extensions or Lighthouse. Their major downside is that such audits are not triggered automatically — running them requires developer involvement.
- The Astro framework (and possibly others too) has an accessibility auditing tool built into their dev toolbar, and its output is similar to what Accented provides (overlays and hints on the page). Showing the overlays, however, also requires an explicit action, reducing the impact of the tool.
- Accessibility testing can be performed in automated test suites. Such tests can be valuable, as they prevent accessibility regressions. We have to keep in mind, however, that testing is a high-friction approach: every test needs to be written and maintained.
- There’s also @axe-core/react, which is very similar in spirit to Accented. It also scans the rendered page and outputs scan results (only to the console). Unfortunately, it’s only meant for React applications, it doesn’t support modern versions of React, and overall it’s in maintenance mode, with no further development plans.
Comparison
Here’s a summary to help you choose the right tools.
- Linting.
- Pros: checks the whole codebase in real time, easy to set up, can be used in CI.
- Cons: tests only code, JSX-specific.
- Accented.
- Pros: tests current page in real time, easy to set up, framework-agnostic.
- Cons: modifies the page, may impact runtime performance.
- Browser devtools (axe, Lighthouse).
- Pros: zero setup required.
- Cons: requires an explicit action to run the audit.
- Framework devtools.
- Pros: zero setup required.
- Cons: framework-specific by definition, may require an explicit action to run the audit.
- Tests (jest-axe, @axe-core/playwright, etc.).
- Pros: prevent regressions, can be used in CI.
- Cons: high cost (tests need to be written and maintained).
Overall, I think of Accented as an additional safety net that can further strengthen the accessibility posture of your application, even if it’s already relying on a few other tools. And it does so at very low cost (just a few lines added to your codebase, as demonstrated earlier).
Success stories
The benefits are not purely theoretical.
Accented just launched, but I’m already seeing real results.
accented.dev
I used Accented while developing this website (dogfooding, you know).
I literally set it up and forgot about it.
Then one day it flagged a contrast issue in the code blocks, which I was able to quickly fix by choosing a different theme.
I don’t know of any other tool that would help me catch this issue automatically (without me explicitly running an audit on a specific page), and with almost no setup.
squarespace.com
From 2021 to 2024, I led accessibility engineering at Squarespace, and our team built an internal library that was the predecessor to Accented.
That library was used by the developers of Squarespace’s main user-facing website (squarespace.com), and I’m happy to report that most marketing pages on the website still have very few issues at the WCAG 2.1 AA level that axe-core can detect.
You can verify it yourself with a tool like Lighthouse or the axe DevTools extension.
Common concerns
Accented is easy to set up, and its maintenance cost is negligible.
That said, developers may have legitimate concerns.
Page modifications
Accented modifies the DOM of the host application: it adds stylesheets, attributes, and elements.
It strives to minimize the impact: for instance, it uses shadow DOM to isolate the styles.
Still, some changes are unavoidable, so whenever there’s an accessibility issue on the page, there is a also chance that when Accented makes its modifications, something else on the page changes as well.
For example, if your JavaScript assumes a specific number of child elements, or if styles rely on sibling selectors, Accented’s DOM changes might interfere.
Fortunately, as soon as the underlying accessibility issue is fixed (which is the whole point of using Accented), the changes will be reverted, and the page will return to its original state.
Noisy output
If you’re installing Accented in an existing app, it may flag many issues at once, potentially overwhelming the developer with its output.
On one hand, those are all legitimate issues that need to be addressed.
On the other, we want things to be manageable,
and the strategy here is to use axeOptions
and context
to start small and then gradually expand the scope of the tests
(see Using in large projects).
Runtime performance
Accented runs axe-core in the browser, and that may be an expensive operation (especially on large, complex pages).
Accented runs the minimum necessary axe-core tests to ensure accurate output, but in some cases the slowdown to the host application may still be noticeable.
The developers can further mitigate the impact by using the performance-focused APIs.
Bundle size
Accented should have zero impact on the production bundle size because it’s only supposed to be used in development.
All modern bundlers support tree shaking, so Accented will be fully removed in production builds.
In closing
I believe that any web project can benefit from using Accented, no matter if it’s in early development or already live and evolving.
No matter which framework you use or how deep your accessibility knowledge is, this tool can help your users have a smoother experience with your application.
Try it out and let me know what you think at hello@pavelpomerantsev.com.
Happy accenting.