Audit and Remediate WCAG 2.1 Accessibility (A11y) Issues

[Lakes41]

Background

Custom UI components like the token selection modal, network switcher dropdowns, and custom sliders were built without ARIA attributes or keyboard navigation support.

Problem

Screen reader users and users who rely on keyboard navigation cannot effectively use the dApp, blocking a segment of users and failing standard accessibility compliance.

Expected Outcome

A fully accessible UI that passes WCAG 2.1 AA standards, ensuring all interactive Web3 elements are focusable, readable by screen readers, and operable via keyboard.

Suggested Implementation

• Run automated accessibility audits using Lighthouse and eslint-plugin-jsx-a11y.
• Refactor custom select menus and modals to utilize Radix UI or Headless UI primitives, which have built-in accessibility.
• Add appropriate aria-labels, aria-expanded, and role attributes to all interactive elements.
• Ensure sufficient color contrast ratios for text on active/inactive buttons.

Acceptance Criteria

• A user can successfully connect a wallet, select a token, and submit a transaction using only the Tab, Enter, and Arrow keys.
• Lighthouse Accessibility score reaches 100 on all major application routes.

Likely Affected Files

• src/components/Modals/TokenSelectModal.tsx
• src/components/Inputs/AmountInput.tsx
• src/styles/theme.ts

Requirements

• Focus trapping must be properly implemented within all open modals.

[darius-daniel]

I'd like to work on this issue.

I'll perform a comprehensive accessibility pass on the affected Web3 UI components, focusing on the token selection modal, network switchers, and amount input. I'll improve keyboard navigation, add the necessary ARIA attributes, implement proper focus trapping within modals, and leverage accessible primitives such as Radix UI or Headless UI where appropriate. I'll verify that users can connect a wallet, select a token, and submit a transaction using only the keyboard, add focused accessibility tests, run Lighthouse and eslint-plugin-jsx-a11y audits, address any contrast issues needed to meet WCAG 2.1 AA, and ensure the project passes all linting, build, and test checks before submitting the PR.

[Phantomcall]

I’d like to take this on. I have experience building accessible React applications, modernizing custom component libraries, and implementing WCAG 2.1 AA-compliant interfaces without sacrificing usability or design.

For this issue, I'll perform an accessibility audit using Lighthouse and eslint-plugin-jsx-a11y, then systematically address the identified issues by replacing brittle custom interactions with accessible Radix UI or Headless UI primitives where appropriate. I'll ensure interactive components—including the token selection modal, network switcher, amount input, and related controls—provide the correct ARIA semantics, keyboard interactions, and focus management.

I'll implement proper focus trapping and focus restoration for all modals, verify that every workflow can be completed using only the keyboard (Tab, Shift+Tab, Enter, Space, and Arrow keys where applicable), and improve color contrast where necessary to satisfy WCAG 2.1 AA requirements. I'll also ensure screen readers correctly announce component state through attributes such as aria-label, aria-expanded, aria-labelledby, and appropriate roles.

Finally, I'll add accessibility-focused tests for keyboard navigation, modal focus behavior, and ARIA attributes, document any reusable accessibility patterns introduced, and verify the application achieves a Lighthouse Accessibility score of 100 across the primary routes before submitting the PR.

GitHub: @PHANTOM_CALL