Case Study · Hackathon, Grand Champion

GoA11y

An accessibility-checking feature built into GoDaddy's Airo website builder, created with my team during GoDaddy's internal Summer Hackathon.

Result · 🏆 Grand Champion Format · Team hackathon build Presented to · GoDaddy engineering & executive leadership, including the CEO

Problem

Airo lets people generate and publish a working website in minutes without writing code. That speed cuts both ways: it's easy to end up with visual choices — a price label a shade too light, button text that blends into its background — that are hard for some visitors to read, and because pages are generated quickly and often, small contrast issues like these can ship on page after page before anyone notices. Catching them after the fact, one audit at a time, doesn't scale to how fast Airo lets people publish.

What We Built

We added an Accessibility panel directly inside the Airo editor, next to the live page preview. Running a scan surfaces issues individually — what's wrong ("Price text color is too light to read"), how severe it is, and which page it's on — along with a plain-language explanation of why it matters. Each issue can be previewed as a code change before anything happens, applied with one click via Apply fix, or left for later; a Re-scan action re-checks the page once fixes land.

GoA11y accessibility panel inside the Airo editor, showing flagged issues, severity, and an Apply fix action

Architecture & Tech Stack

GoA11y runs as a panel inside Airo's existing page editor rather than as a separate tool. Scans operate on the page's generated source — Airo builds pages as files like pages/shop.tsx — so a fix is a real code change to that page, shown to the user before it's applied, not a cosmetic overlay on top of the preview.

Tradeoffs

Two decisions stand out, based on how the feature actually behaves:

  • Reviewable before automatic. Seeing the code change and applying it are two separate steps (Show code change vs. Apply fix), not one. That costs a click, but it matters when the "fix" touches a live, published site.
  • In the workflow, not beside it. The check lives in the same panel someone is already using to edit the page, instead of a separate audit report they'd have to go run. That's a bet that a check people already see beats a more thorough one they have to seek out.

Lessons Learned

  • Where a check lives matters as much as what it catches — putting accessibility scanning inside the editor, instead of a separate report, is what makes it something a non-specialist would actually use.
  • A fix that changes someone's published site has to earn trust before it's automatic; showing the code change first was a deliberate trade of speed for control.
  • Presenting the same build to engineering leadership and then executive leadership in the same day meant compressing it into very different levels of detail for each room.