-
Notifications
You must be signed in to change notification settings - Fork 16
Description
Problem Description
An audit of the codebase reveals that only approximately 11 out of 300+ files contain any accessibility attributes (aria-label, role, etc.). The vast majority of interactive elements — buttons, text inputs, select dropdowns, file upload areas, and tool output regions — lack proper ARIA labels, roles, and states. The homepage search input has no aria-label. Filter buttons do not communicate their pressed/selected state to assistive technologies. Tool components do not announce output changes to screen readers. There are no skip-navigation links, and keyboard navigation through the tool interface is not explicitly managed. The color contrast between the primary green (#00da92) on certain backgrounds may not meet the 4.5:1 contrast ratio required by WCAG AA.
Why It Is Required
Accessibility is not optional — it is both a legal requirement in many jurisdictions (ADA in the US, EAA in the EU) and a moral imperative. Developer tools should be usable by all developers, including those who rely on screen readers, keyboard-only navigation, or other assistive technologies. The current state of the application would fail a WCAG 2.1 AA audit. Making the application accessible expands its user base, improves SEO (search engines favor accessible markup), and sets a positive example for the open-source community.
My Approach
I would conduct a full accessibility audit using automated tools (axe-core, Lighthouse) and manual testing with screen readers (NVDA, VoiceOver). I would then systematically address the findings: add aria-label attributes to all interactive elements across tool components, add role attributes where semantic HTML is insufficient, implement aria-live regions for dynamic tool output so screen readers announce changes, add skip-navigation links to app/layout.tsx, ensure all form elements in app/components/theme/form/ have associated labels, verify and fix color contrast ratios in tailwind.config.ts, and add keyboard focus management for tool navigation. I would also add a reusable AccessibleToolWrapper component that provides consistent accessibility patterns for all tools.
I want to work on this issue.