The application has no accessibility testing of any kind — no axe integration, no a11y specs, no `jsx-a11y` lint rules

[Jagadeeshftw]

Priority: High  ·  Area: Accessibility  ·  Est. effort: 8–12 h

📌 Problem

Across 135 source files and 59 test files there is no accessibility verification at any layer:

• No automated auditing — no axe-core / jest-axe / @axe-core/react in the dependency tree.
• No a11y specs — find . -name '*.spec.ts' returns 0; there is no browser-level test layer at all.
• No lint rules — no eslint-plugin-jsx-a11y configuration.

So nothing checks for missing form labels, images without alternative text, controls that cannot be reached or operated by keyboard, focus that is lost after a modal closes, or colour contrast.

This matters concretely for what the app renders: SettlementTable and MetricsBar are data-dense components. Tables are among the easiest things to build inaccessibly — missing header associations make a screen reader announce cells with no context, which for a settlement table means numbers with no indication of what they represent.

🎯 Design decision required

Do not add every possible tool at once. State and defend:

1. Which layer first. jsx-a11y lint rules catch static markup problems cheaply at author time. jest-axe catches rendered-output violations in the existing suite without new infrastructure. A browser-level a11y spec catches focus and keyboard behaviour but requires a whole test layer this repo does not have. Rank them by value-per-effort for this codebase and implement the top one or two.
2. Baseline handling. Expect existing violations. Do you fix them all now, or establish a baseline that may only shrink? A gate that is red on day one gets disabled — argue for something that stays on.
3. Scope of the gate. All components, or the highest-traffic ones first? Justify from what users actually interact with.

🧩 Requirements and context

• Run your chosen tool against the current tree first and report every violation found. That inventory is the first deliverable and determines everything else.
• State the WCAG level you are targeting (AA is the usual baseline) and gate against it explicitly.
• Do not suppress a violation to reach green. Fix it, or record it in a baseline with a reason.
• Any fix must not change visual appearance without saying so — adding a label or an ARIA attribute should be invisible to sighted users.
• Keyboard operability of interactive elements must be covered, not only static markup.
• All 59 existing tests must pass.

🛠️ Suggested execution

1. Add your chosen tool locally and run it across the components; paste the full violation list.
2. Rank violations by severity and user impact.
3. Fix the top ones; baseline the rest with reasons.
4. Wire the check into CI.
5. Prove it fires — introduce a deliberate violation (remove a label) on a scratch branch, show it failing, revert.

✅ Acceptance criteria

• The PR opens with the full violation inventory from a real run.
• The target WCAG level is stated.
• At least one automated a11y check runs in CI and fails the build on a violation, demonstrated with a linked failing run.
• SettlementTable and MetricsBar are covered.
• A test asserts keyboard operability of at least one interactive component.
• Remaining violations are baselined with reasons — none silently suppressed.
• No visual change, or every visual change is called out.
• All 59 tests pass.

🚫 Out of scope

• Building a full e2e test layer — separate issue.
• Visual redesign.
• Coverage enforcement — separate issue.

🧪 Verification

npm ci
npm test
npm run lint
npx tsc --noEmit

📤 What your PR must include

1. The violation inventory.
2. Your layer-ranking argument for this codebase.
3. Your baseline decision.
4. A link to a run failing on a deliberate violation.
5. Closes #<n>.

🔒 Security notes

Accessibility is a correctness and inclusion requirement, and for a financial interface it is also a safety one: a user who cannot perceive a settlement's status, or who cannot reach a confirmation control by keyboard, may act on an incomplete understanding of what they are approving. Data tables and status indicators are the highest-risk surfaces here precisely because their meaning depends on structure a screen reader can only convey if the markup provides it.

📋 Guidelines

• Minimum 95% test coverage on changed lines
• Clear documentation
• Timeframe: 96 hours from assignment
• One logical change per commit; no merge commits

---

💬 Join our community

Working on this, or want to sanity-check your approach before you start? Come and ask — the maintainers are there and happy to help.

Telegram: https://t.me/Grainlify

[Opulencechuks]

I am confident that I can implement this issue having worked on something similar in the past

[grantfox-oss]

🦊 GrantFox — @Opulencechuks has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

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

Good luck! Track your progress on GrantFox.

[Jagadeeshftw]

Assignment update — accessibility test foundation

Good luck, @Opulencechuks! This issue is assigned to you to establish accessibility coverage for the application. Read the full issue description first, then implement every requested testing and linting safeguard with accessible assertions that catch real regressions. Please raise a high-quality PR with sensible scope, documented decisions, and reproducible verification instead of adding a nominal check that does not exercise the UI.

Please raise the PR within 48 hours of being assigned. If no PR is opened by then, the issue may be unassigned for reassignment. Join the Telegram group for project coordination: https://t.me/+u5qmu35nZ7I0OTU1