Inspiration
Small web teams struggle to understand and fix common accessibility failures without losing human design control. Existing tools either automate too aggressively (risking design integrity) or require deep accessibility expertise. We saw an opportunity to use WebMCP's structured semantic context to let AI agents manipulate accessibility intent more reliably than visually clicking unfamiliar pages, while keeping humans in full control of every change.
What it does
Accessibility Repair Studio provides a four-part collaborative workspace:
- Left panel: Page templates and component semantic outline
- Center: Responsive live preview with selectable elements and viewport controls
- Right panel: Issue list, issue inspector, patch editor, and approval controls
- Bottom: Keyboard path, screen-reader-style narrative, audit comparison, and agent activity
The product loop: audit → inspect an issue in context → stage a constrained repair → preview visual and semantic changes → obtain human approval → apply → test keyboard and narrative behavior → compare audits → export a patch manifest
The studio includes a seeded "Field Notes" event-registration page with eight deliberate accessibility issues: unnamed icon-only navigation, skipped heading level, insufficient text contrast, form error without input relationship, positive tabindex changing focus order, ambiguous link text, unhelpful image description, and unannounced registration status. Two clean reference templates are also included.
How we built it
Tech Stack:
- React, TypeScript, and Vite for the frontend framework
- Next.js for deployment and server-side billing integration
- axe-core for documented subset of automated accessibility checks
- Custom deterministic checks for the seeded component model
- Vitest, Testing Library, and Playwright for comprehensive testing
- Polar for paywall and benefit entitlements
- Remotion for demo video rendering
Architecture:
- Typed component schema with safe renderer (no arbitrary HTML)
- Versioned state reducer with patch history
- Safe finite repair DSL with 10 allowed operations
- WebMCP tool registry with state-scoped capabilities
- Device-local persistence and one-click reset
- Apple-inspired studio UI with translucent surfaces, careful typography, high-visibility focus rings, and reduced-motion support
Safety Model:
- Preview isolation until human approval
- Version guards and approval token expiration
- Rejection of raw HTML, CSS, JavaScript, event handlers, URLs, arbitrary ARIA
- Finite allowlists for element, content, color, relationship, and ordering values
apply_accessibility_patchregistered only after visible human approval
Challenges we ran into
Balancing automation with human control: Designing a safe repair DSL that's powerful enough to be useful but constrained enough to prevent dangerous changes required careful iteration on the operation allowlist.
WebMCP integration complexity: Implementing state-scoped tool registration where
apply_accessibility_patchonly appears when a preview has human approval required understanding the evolving WebMCP spec and handling edge cases like stale approvals.Truthful audit representation: Avoiding claims of complete WCAG conformance while still providing actionable insights meant carefully labeling automated results as partial checks and preserving issues requiring human judgment.
Studio accessibility: The interface itself had to be keyboard accessible and pass its own core audit, which required rigorous focus management and testing.
Embedded git repository: During initial commit, the studio directory had its own .git folder, which required removing it to properly commit as part of the main repository.
Accomplishments that we're proud of
- Safe collaboration model: Successfully implemented a human-in-the-loop workflow where AI agents can suggest repairs but humans always approve before application
- Comprehensive tool surface: 11 WebMCP tools covering the full audit-inspect-repair-apply-compare-export loop
- Truthful limitations: Clear labeling of partial checks, manual-review requirements, and screen-reader narrative as approximation rather than emulator
- Beautiful accessible UI: Apple-inspired studio design that itself passes accessibility audits with excellent focus management
- Full test coverage: Vitest, Testing Library, and Playwright tests covering safety, approval, version guards, and keyboard operability
- Real demo: Three-minute narrated walkthrough showing the complete product loop with real screenshots
- Production-ready: Polar integration for paid features, admin allowlist, and static deployment configuration
What we learned
- WebMCP's potential for accessibility: Structured semantic context allows agents to understand accessibility intent much better than visual inspection alone
- State-scoped tool registration: Dynamic tool availability based on UI state is a powerful pattern for safety-critical operations
- The importance of version guards: Approval tokens must expire on any relevant state change to prevent stale approvals
- Partial audit honesty: Being transparent about what automated checks can and cannot prove builds trust
- DSL design trade-offs: Finite operations are safer but require careful selection to remain useful
- Studio self-auditing: Building accessibility tools requires the tools themselves to be accessible
What's next for it
- Additional repair operations: Expand the safe DSL to cover more common accessibility patterns
- More seeded templates: Add diverse page types (forms, navigation, data tables) with representative issues
- Enhanced narrative: Improve the screen-reader approximation with more semantic nuance
- Real assistive-technology integration: Partner with actual screen reader vendors for validation
- Team collaboration: Multi-user support with attribution and review workflows
- CI/CD integration: Export manifests that can be applied to production codebases
- Advanced analytics: Track accessibility improvements over time across projects
Built With
- webmcp
Log in or sign up for Devpost to join the conversation.