Building accessibility
from the ground up, at MagicSchool
I joined MagicSchool in January 2025 as the company's second product design hire, and their first accessibility hire. MagicSchool is an AI-driven ed-tech platform used by millions of educators and students, and when I started, there was no formal accessibility practice at all. They had a self-reported VPAT, no vendor-backed audit, and no dedicated a11y expertise on the team. In under two years, I built an a11y program from scratch: strategy, culture, tooling, process, and conformance.
Some of the bigger pieces of that work:
- Founded and run a weekly, cross-functional Accessibility Guild spanning Design, Engineering, and Product.
- Led a full manual accessibility audit, then partnered with engineering to remediate 80 of the 100 issues it surfaced, and published MagicSchool's first vendor-backed VPAT/ACR.
- Contributed accessibility documentation and design reviews to the design system, covering contrast, ARIA, and focus states for key components.
- Ran 23+ cross-functional accessibility reviews covering nearly every major feature area.
- Led accessibility learning sessions across Design, Engineering, and Product to build shared working knowledge of key WCAG topics.
When I started
The world moved fast when I joined: legally, competitively, and for the people we serve.
Legal urgency
The DOJ updated ADA Title II in April 2024. Every ed-tech vendor selling to public schools now has to meet WCAG 2.1 AA, with deadlines in April 2026 for large districts and April 2027 for small ones.
Business risk
Districts can issue a formal Notice of Failure to Meet Standards for inaccessible ed-tech, putting contracts at risk. Sales and support were already fielding questions they couldn't fully answer.
Mission alignment
More than 1 in 4 U.S. adults has a disability. For a company serving educators and students, inaccessibility means exclusion, a direct contradiction of what we're supposed to be doing.
"Accessibility is not 'on' or 'off.' It is more or less. A product is more or less accessible."Anna Cook, Microsoft
Progress over perfection
There's no "done" in accessibility. I set up systems to improve continuously rather than chase a one-time certificate.
Shared, cross-functional ownership
Accessibility can't live in one role. I embedded it across Design, Engineering, and Product, so every team is accountable for it.
Shift left
A11y issues are cheap to fix early and expensive to fix later, so I moved checks into the design and ticket phase, not just QA.
Conformance, not just compliance
We build accessible products because it's right, not only because the law requires it. Both happen to be true here.
This work doesn't stop.
Audit and remediation.
I contracted accessiBe for a comprehensive manual audit of the full web app, run from May 27 to July 1, 2025. It covered color contrast, keyboard navigation and focus order, screen reader compatibility, form fields and labels, zoom and reflow at 400%, heading hierarchy, image alt text, and interactive elements.
Of the 100 issues it surfaced, we fixed 80 internally. The remaining 20 were in third-party tools outside our control. That gave us an honest picture of where we stood, which fed directly into MagicSchool's first vendor-backed VPAT/ACR, now published publicly at magicschool.ai/accessibility .
The A11y Guild: making it everyone's job.
What the Guild does
- Weekly cross-functional meetings across Design, Engineering, and PM
- An accessibility review for every new feature before it ships
- Squads own the resulting a11y tickets in their own sprint work
- Internal learning sessions on key WCAG topics
- Automated accessibility scanning on every pull request
What it's produced
- An A11y Checklist used across PM, Design, and Engineering
- 8+ "A11y Bites" learning modules
- A documented review process and prep guide
- Automated axe testing running on every PR
- MagicSchool's 2026 accessibility roadmap
Baking accessibility into how we ship.
The goal was to make the accessible path the easy path, so it holds up even when I'm not in the room.
WCAG-forward design system
Contributed accessibility documentation and design review to key components in the design system, covering contrast ratios, ARIA attributes, and focus states so they're built in once and reused everywhere.
Automated testing
Automated axe accessibility scanning runs on every pull request, with a dashboard that tracks trends over time so regressions get caught before they reach users.
A11y checklist
An actionable checklist covering interactive elements, color, keyboard and focus, headings, images, forms, zoom, and screen readers, usable by PMs, designers, and engineers alike.
accessiBe overlay, honestly framed
Kept as a supplemental tool sitting on top of an already-accessible product, not a replacement for real fixes, with clear internal messaging about its limits.
The work continues.
Testing with disabled users
Moving beyond automated scans to testing with real users of assistive technology. Automation can claim progress while the real experience is still broken.
A11y requirements in tickets
Formalizing accessibility requirements at the ticket-writing stage, shifting the work even further left.
A customer feedback loop
Building a direct channel for teachers, students, and districts to surface accessibility concerns.
AI + accessibility, cautiously
Exploring AI-assisted workflows like drafting alt text, always with a human verifying the result.
"It's okay to not know. But it's not okay to never try."
Accessibility at MagicSchool isn't finished, and it never fully will be. But it's a practice now, not a project. It's a community and a set of systems that make accessibility the default way of working.