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

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