Skip to content

Web: Add an automated accessibility check to CI for the dashboard #205

Description

@mallison031

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.

  1. Wire an automated pass@axe-core/playwright if the Playwright harness has landed, otherwise a standalone runner against a local build.
  2. 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.
  3. 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.
  4. 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

  • An automated accessibility check runs in CI and can fail the build.
  • All five states listed above are covered, including the open modal.
  • Pre-existing violations are enumerated in an allowlist, each linked to an issue.
  • A newly introduced violation fails the build — demonstrated in the PR.
  • Failure output names the offending element and rule.
  • pnpm lint passes in apps/web.
  • pnpm test passes, including new tests covering this change.
  • pnpm build succeeds for apps/web.
  • PR description includes Closes #<this issue>.

Contact & Support

Metadata

Metadata

Assignees

Labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions