Repo context. accensa-app is the off-chain half of Accensa — the merchant back-office for x402 sellers on Stellar. Three workspace packages matter: apps/web (Next.js dashboard and the indexer at src/app/api/sync), packages/sdk (@accensa/sdk), and apps/demo-merchant. The Soroban contracts live in accensa-contracts.
🟡 Partially blocked. The Playwright harness is the natural host for this. It can be built standalone, but coordinate if both are being worked in the same Wave.
Problem
This audit found four separate accessibility defects on the dashboard — rows that cannot be reached by keyboard, a modal that is not announced as a dialog and does not trap focus, tables without column scope, and a verify result that is never announced. All four are the kind that automated tooling catches immediately, and all four have been in main unnoticed.
There is no accessibility check in CI. The ci.yml workflow does not run one, and nothing in apps/web depends on an accessibility tool.
The pattern is the point: these defects were not hard to find once someone looked in a browser. Without a gate, the next four will accumulate the same way.
What to build
Add a check that fails the build on regressions.
- Wire an automated pass —
@axe-core/playwright if the Playwright harness has landed, otherwise a standalone runner against a local build.
- Cover the real routes:
/dashboard, /dashboard/routes, /verify, /login, and the dashboard with its payment modal open. The modal is where several known defects live, so a check that never opens it is close to worthless.
- Set an honest baseline. If existing violations would fail the build immediately, record them explicitly as a documented allowlist with a linked issue each — never a blanket severity threshold that hides the whole category.
- Make failures readable. The output should name the element and the rule, so a contributor can act on it without rerunning locally.
Out of scope: fixing the existing violations. Each is tracked separately; this issue makes sure new ones cannot land silently.
Acceptance criteria
Contact & Support
Problem
This audit found four separate accessibility defects on the dashboard — rows that cannot be reached by keyboard, a modal that is not announced as a dialog and does not trap focus, tables without column scope, and a verify result that is never announced. All four are the kind that automated tooling catches immediately, and all four have been in
mainunnoticed.There is no accessibility check in CI. The
ci.ymlworkflow does not run one, and nothing inapps/webdepends on an accessibility tool.The pattern is the point: these defects were not hard to find once someone looked in a browser. Without a gate, the next four will accumulate the same way.
What to build
Add a check that fails the build on regressions.
@axe-core/playwrightif the Playwright harness has landed, otherwise a standalone runner against a local build./dashboard,/dashboard/routes,/verify,/login, and the dashboard with its payment modal open. The modal is where several known defects live, so a check that never opens it is close to worthless.Out of scope: fixing the existing violations. Each is tracked separately; this issue makes sure new ones cannot land silently.
Acceptance criteria
pnpm lintpasses inapps/web.pnpm testpasses, including new tests covering this change.pnpm buildsucceeds forapps/web.Closes #<this issue>.Contact & Support
SUPPORT.md— contribution help, Wave process, and the full list of channels