Who owns accessibility on a headless Shopify team?
Nobody, by default, which is the problem. On a headless Shopify build, accessibility falls between design, frontend, and QA unless one role owns it end to end. The pattern that works: design owns the specs, frontend owns the implementation, QA owns the verification, and one named person owns the standard and signs off on releases.
Why headless breaks the default ownership
On a standard Shopify theme, accessibility is partly inherited. The theme vendor handled focus management, semantic structure, and keyboard patterns, and your team customized on top. Going headless deletes that inheritance. Every dialog, every cart drawer, every filter interaction is custom code now, and custom code is only as accessible as the person who wrote it decided to make it.
This is where ownership fails. Design assumes frontend will handle it. Frontend assumes the component library handles it. QA tests what the ticket describes, and the ticket never mentioned screen readers. The result is a storefront that looks finished and fails basic checks, discovered months later by a monitoring scan or a demand letter.
The split that actually works
Design owns accessibility in the specs. Every component design should state the keyboard interaction, the focus behavior, and the announced names, not just the visuals. A design that shows a filter dropdown without specifying how it opens by keyboard is an incomplete design. This is the cheapest place to catch issues, because a spec sentence costs nothing and a rebuild costs weeks.
Frontend owns accessibility in the code. The developer building the component implements the spec: real buttons, focus traps in dialogs, live regions for dynamic updates, visible focus indicators. Code review should check these the way it checks for bugs, because they are bugs.
QA owns verification. Accessibility acceptance criteria belong in the definition of done for every user-facing ticket. QA runs the keyboard pass, the screen reader spot check, and the automated scan on the journeys the release touched. If it is not tested, it is not done.
The one named owner
Split responsibility still needs a single throat to choke. Name one person the accessibility owner: they maintain the standard, they review the specs for new components, they sign off on releases, and they are the escalation point when design and frontend disagree about what "accessible enough" means.
This person does not do all the accessibility work. They make sure it gets done and done consistently. Without them, every release re-litigates the same questions. With them, the standard compounds: each release gets a little better because someone is keeping score.
Where monitoring fits
Automated monitoring is the safety net, not the owner. It catches regressions between releases: the marketing tag that broke focus order, the new app embed with unlabeled buttons, the CMS editor who published an image without alt text. But monitoring finds failures after they ship. Ownership prevents them before.
The mature setup is both: a named owner who keeps the standard rising, and monitoring that catches what slips through. One without the other fails. Monitoring without ownership produces a dashboard of issues nobody fixes. Ownership without monitoring produces confidence without evidence. Name the owner, run the scans, and make the release gate require both.
Start with a one-page standard
The owner’s first deliverable should fit on one page: the accessibility standard for this storefront. It names the target level, lists the non-negotiable patterns (keyboard operability, focus management, names and announcements, contrast, reduced motion), and links to the component examples the team should copy. One page, pinned where everyone can find it, beats a fifty-page guideline nobody opens.
Review the standard quarterly, not because the rules change, but because the team’s understanding deepens. Each quarter, add the patterns the team got wrong and the fixes that worked. The standard becomes a record of what this team has learned, which is more valuable than any generic checklist, because it is written in the vocabulary of your own codebase.