tests: add an axe-core accessibility check to CI

[tech-adrian]

Area
.github/workflows/ci.yml, frontend/

Problem
Following on from the manual accessibility audit issue, there's no automated regression guard — a future PR could silently reintroduce an a11y violation with nothing catching it before merge.

Proposed change
Add an automated axe-core (e.g. via @axe-core/playwright or jest-axe) check for the deposit, withdraw, compliance, and history pages, wired into the frontend CI job so violations fail the build.

Acceptance Criteria

• Automated axe-core check added for all 4 main pages
• Wired into CI and failing the build on new violations
• Relevant tests (just test, pnpm test, cargo test, or nargo test as applicable) pass locally and in CI
• A screenshot or short screen recording is attached to the PR showing the change working (a CI run showing the axe check passing/failing appropriately) — required before this can be merged.

Open your PR against the dev branch, not main. All active development merges into dev.

Discuss this issue / coordinate work: join the DShield contributor Telegram group: https://t.me/+SiGHH24No9U2MDJk

[Tobi-8]

Please maintainer assign me to this issue
I have the knowledge and skill to complete this task

[yusufmuhammadayodeji-netizen]

Hello, I’ve thoroughly read the issue description and understand the expected outcome. I’d love to work on it.

[nurudeenheroic]

Hello! I'd be happy to take this on. I pay close attention to detail and will ensure the solution is reliable, clean, and well-tested.

[Yerimahjr]

Hi @tech-adrian, I'd like to take this on.
Relevant experience: Active GrantFox contributor (17+ merged PRs across 14+ repos, spanning TypeScript/Next.js/Node.js as well as Rust/Soroban). I've wired CI checks into GitHub Actions workflows before and am comfortable making a new automated check block the build rather than just warn.
Approach:
Check whether the repo already has Playwright or Jest set up for the frontend (or neither), since that determines whether I reach for @axe-core/playwright (full page render + navigation, better fit if pages have async data loading) or jest-axe (component-level, faster but needs each page rendered in isolation).
Add an automated axe-core scan for all 4 pages (deposit, withdraw, compliance, history), asserting zero violations at the default WCAG2A/WCAG2AA rule set (matching whatever severity the manual audit issue established, if there's a baseline to align with).
Wire the check into the existing frontend CI job in .github/workflows/ci.yml so a new violation fails the build, not just logs a warning.
Run the relevant test command locally first (pnpm test or whichever the repo uses) to confirm the check passes clean against current markup, then intentionally introduce a known violation locally to confirm the check actually fails — proving it's a real regression guard, not a no-op.
Capture the required screenshot/recording showing the CI run catching a violation appropriately.
Open the PR against dev per the repo's contribution guidelines, not main.
I'll join the DShield Telegram to coordinate on the exact axe ruleset/severity expectations before finalizing, since aligning with the prior manual audit's findings will make this check meaningfully useful rather than just decorative.

[grantfox-oss]

🦊 GrantFox — @Yerimahjr has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #32)
2. Your PR will be reviewed by the Dshield-xyz maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Official Campaign | FWC26 campaign!

@Yerimahjr's PR #44 was approved and merged by @tech-adrian.

🏆 @Yerimahjr: You earned 40 FoxPoints for this contribution! Your current tier: Builder (1,249 total points). Track your full progress on GrantFox.

👏 Great work, @Yerimahjr! Keep contributing to Dshield-xyz.