Repository navigation
Accessibility (a11y) Audit and Fixes #440
Description
- Labels:
bug,a11y,standards
Description
To ensure SkillSphere is usable by everyone, we need to resolve several accessibility warnings. This includes adding proper ARIA labels, managing keyboard focus traps inside modals, and improving color contrasts.
Technical Scope & Steps
- Audit all interactive components (e.g.
Navbar.tsx,FundSessionModal.tsx,Sidebar.tsx) for keyboard accessibility. - Add missing
aria-labeloraria-expandedattributes on collapsible buttons. - Implement focus traps on open modals so pressing
Tabdoesn't cycle behind the modal. - Replace
div-based clickable elements with semantic<button>tags where appropriate.
Acceptance Criteria
- Users can navigate the entire marketplace booking flow using keyboard controls (
Tab,Enter,Escape). - Screen readers read button actions clearly.
- Modals close on pressing the
Escapekey.
Activity
gregemax commentedon Aug 19, 2026
I would like to work on this accessibility issue because it involves improving the usability of the application at both the component and user-flow level.
I plan to first audit the affected interactive components, including the Navbar, Sidebar, and FundSessionModal, and identify issues with semantic elements, ARIA attributes, keyboard navigation, focus management, and color contrast.
For the modal, I will implement proper focus management so that focus moves into the modal when it opens, remains within the modal while navigating with Tab/Shift+Tab, and returns to the triggering element when the modal closes. I will also ensure Escape closes the modal correctly.
I will replace inappropriate clickable elements with semantic buttons where necessary and add appropriate
aria-labelandaria-expandedattributes to interactive controls. I will then test the complete marketplace booking flow using only the keyboard to verify Tab, Shift+Tab, Enter, and Escape behavior and make sure the changes do not introduce regressions.I’m particularly interested in this issue because it requires more than a simple UI change it involves understanding the existing component behavior and improving the overall accessibility and usability of the application.
vic-Gray commentedon Aug 21, 2026
Application: SkillSphere Accessibility Improvements
Introduction
I’m interested in working on this accessibility issue because it addresses an important part of building a production-quality application: making sure the interface is usable not only with a mouse, but also through keyboard navigation and assistive technologies.
I would approach this issue as a focused accessibility audit and implementation task rather than simply adding ARIA attributes wherever warnings appear. The goal would be to ensure that the marketplace booking flow has a logical keyboard experience, that interactive elements communicate their purpose correctly to screen readers, and that modal interactions behave predictably.
Understanding of the Issue
From the description, the main accessibility problems fall into four areas:
The most important acceptance criteria are that a user should be able to complete the marketplace booking flow using only the keyboard, understand interactive controls through a screen reader, and close modals using the Escape key.
Proposed Implementation
I would first inspect the relevant components, including:
I would trace the complete interaction path rather than modifying only the files explicitly mentioned in the issue.
For every interactive element, I would check:
Where the application currently uses clickable "
This provides built-in keyboard behavior and significantly reduces the amount of custom accessibility logic required.
I would avoid adding unnecessary ARIA roles when native HTML semantics already provide the correct behavior.
For controls whose state or purpose is not sufficiently communicated through native semantics, I would add the appropriate attributes.
For example, collapsible navigation controls would receive attributes such as:
The values would be dynamically synchronized with the actual UI state rather than hard-coded.
I would also make sure buttons have descriptive accessible names, particularly icon-only buttons such as menu, close, navigation, and action controls.
The modal is one of the most important parts of this issue.
When "FundSessionModal" opens, I would ensure that:
I would implement this carefully so that the focus trap does not interfere with normal React state updates or cause focus-related bugs.
I would test the complete marketplace booking journey using only:
I would verify that users can move through the interface in a predictable order and complete the booking interaction without requiring a mouse.
Particular attention would be given to:
I would audit the affected UI for insufficient foreground/background contrast and update the relevant styles while preserving the existing SkillSphere visual design.
I would pay particular attention to:
The objective would be to bring the affected components in line with appropriate WCAG contrast requirements rather than simply making colors darker or brighter without considering the design system.
Testing Strategy
I would test the changes at multiple levels.
Keyboard Testing
I would manually navigate the marketplace booking flow without using a mouse and verify:
Screen Reader Testing
Where available, I would test the affected components with a screen reader to verify that:
Automated Accessibility Testing
I would also run an accessibility auditing tool such as axe against the affected pages/components to identify remaining issues.
Automated testing would complement—not replace—manual keyboard and screen-reader testing, because focus management and interaction behavior cannot always be validated through static accessibility checks.
Regression Testing
Finally, I would verify that the accessibility changes do not break existing functionality, particularly:
Implementation Approach
I would keep the implementation focused and consistent with the existing SkillSphere architecture.
Rather than introducing a large accessibility abstraction unnecessarily, I would first use native HTML semantics and React patterns. Where reusable behavior is required—especially modal focus management—I would create a small, maintainable solution that can be reused by other modals in the application.
I would also avoid using ARIA as a replacement for semantic HTML. For example, I would prefer a real "" over making a "
Acceptance Criteria Validation
Before considering the issue complete, I would verify each requirement explicitly:
Why I’m a Good Fit
I would treat this issue as both a bug fix and an opportunity to improve the underlying quality of SkillSphere. Accessibility should not be implemented as a collection of isolated warnings; it should be reflected in the structure and interaction model of the application.
My approach would therefore prioritize semantic HTML, predictable keyboard behavior, correct focus management, meaningful accessible names, and thorough manual testing alongside automated accessibility checks.
The final result should allow a keyboard-only user and a screen-reader user to navigate and complete the marketplace booking experience with the same core functionality available to a mouse user.
grantfox-oss commentedon Aug 22, 2026
🦊 GrantFox — @vic-Gray has been assigned to this issue as part of the Third Campaign campaign!
Next steps:
Closes #440)Good luck! Track your progress on GrantFox.
grantfox-oss commentedon Aug 22, 2026
🎉 This issue has been marked as completed on GrantFox as part of the Third Campaign campaign!
@vic-Gray's PR #452 was approved and merged by @Luluameh.
🏆 @vic-Gray: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (284 total points). Track your full progress on GrantFox.
👏 Great work, @vic-Gray! Keep contributing to LightForgeHub.