Reviewed October 17, 2026

Accessibility clauses to put in your theme and app contracts

When a vendor's code introduces a barrier, the store wears the lawsuit. Contract language that sets accessibility expectations with theme developers and app vendors before the work starts.

Why the contract is where accessibility is won

When your store is named in an accessibility complaint, the plaintiff does not care that the barrier came from a theme developer's menu code or an app's popup. It is your storefront and your problem. Contracts are how you move some of that risk and, more usefully, how you make vendors build accessibly in the first place, because expectations written down before work starts shape the work.

This applies to freelance theme customizations, agency builds, and the paid apps you install. The leverage differs, you negotiate with a freelancer and merely choose among apps, but the principle is the same: accessibility is a requirement to state, not a hope to hold.

Clauses for theme and development work

Name the standard: deliverables conform to WCAG 2.1 AA, or 2.2 AA if that is your store's target. Require keyboard operability and visible focus for every interactive element the work touches, since custom code most often fails there. Add an acceptance step: you or an auditor test with keyboard and a screen reader before final payment, and defects against the standard are fixed as part of the engagement, not as billable extras.

Include a regression promise for a defined period: if their code breaks accessibility in an update within, say, ninety days, remediation is on them. And require them to disclose any components they know do not conform, in writing, at delivery. A known limitations list turns surprises into managed decisions.

What to demand from apps, where you cannot negotiate

App contracts are take it or leave it, so the clause becomes a selection test. Before installing, check whether the vendor publishes an accessibility statement or conformance information, whether their demo passes a keyboard walkthrough of the widget or embed, and how they respond when you ask directly about WCAG conformance. A vendor who cannot answer the question has answered it.

Favor apps that put accessible output in writing in their documentation, and keep a note of what you checked and when. If a complaint ever targets an app's barrier, that record shows diligence, and your first move, pressing the vendor with a documented defect, is stronger for having chosen them deliberately.

Keeping the paper aligned with reality

Contracts do not remediate anything by themselves. Pair the clauses with your audit cadence: retest custom features after launch, spot check apps after major updates, and log what passes. When a vendor fails their commitment, enforce it promptly, while the engagement and the evidence are fresh, rather than discovering the gap during a legal exchange.

Review template language with your own counsel before relying on it, especially indemnity and liability provisions, which vary in enforceability. The accessibility specifics, standards, testing, disclosure, are the parts your lawyer may not think to include. Bring those to the conversation, and the contract starts working as an accessibility tool instead of just a legal one.

Frequently asked questions

Can I make my theme developer liable if their code causes a complaint?

You can allocate risk through indemnity and warranty language, and many stores should, but enforceability varies and the complaint still arrives at your door first. Treat contract terms as leverage to get defects fixed fast and as partial financial protection, not as a shield that keeps you out of the matter entirely.

What conformance level should I write into contracts?

WCAG 2.1 AA is the widely referenced target in US accessibility disputes and procurement. Some organizations specify 2.2 AA now. Pick the level your own store aims for and use it consistently across vendors, so every contract pulls toward the same standard and audits can test against one benchmark.

An app I depend on fails accessibility checks. Now what?

Document the specific barriers with steps to reproduce, send them to the vendor, and ask for a remediation timeline in writing. If they will not commit, start evaluating replacements before the issue becomes urgent, and consider whether the feature can be disabled or worked around in the meantime. Your record of pressing the vendor matters.

Do these clauses matter for a one hour freelance fix?

Scale the paperwork to the job, but the standard still applies. Even a short email confirming the work will conform to WCAG 2.1 AA and be keyboard operable creates the expectation and the paper trail. Barriers introduced by small changes are a common audit finding, precisely because nobody specified anything.