EAA compliance for Sanity: WCAG 2.1 AA checklist & fixes

What the EAA actually requires from a Sanity site

Sanity is a headless CMS that renders nothing itself, so under the EAA the accessibility obligation splits between your front-end code and Sanity's content-schema discipline. EN 301 549 conformance forces you to make the alt-text field required on image types (Sanity's default image type does not require it), validate heading levels, and ensure portable-text serializers emit semantic HTML rather than divs where a button or nav belongs. The requirement is effectively enforced at two layers: schema-level validation in Studio and correct rendering in whatever front-end consumes the content.

Sanity is chosen by design-led teams and agencies for content-rich sites, so in-scope Sanity-backed sites are typically mid-sized brands and their agency partners, with the front-end technology determining the exact exposure. A large consumer brand's Sanity-powered site could reach turnover-percentage penalties, while a smaller operator faces fixed national fines. The distinctive risk is organisational: because content editors and front-end developers are often different teams, an unenforced alt-text field lets non-compliant content ship even when the front-end code is otherwise correct.

Remediation happens in two places: the schema author makes alt required with a validation rule on image fields so editors cannot save without it, and the front-end developer ensures portable-text serializers produce semantic, accessible markup. Add Studio validation rules for heading structure and audit the rendered front-end rather than Studio itself. Because the fixes are structural and enforced at the content layer, once the schema and serializers are corrected, editors are largely prevented from reintroducing the most common failures.

Top WCAG failures we see on Sanity sites

Across hundreds of Sanity scans, the same handful of issues show up over and over. None of them require ripping the theme apart — most are fixable in a few hours by someone comfortable in the platform's editor or template files.

• Optional alt text on image fields

  Sanity's default image type does not require alt; editors ship without it.

  1.1.1

• Custom blocks rendering without semantic equivalents

  Authors create blocks that render as <div> when a <button> or <nav> would fit.

  1.3.1, 4.1.2

Concrete code fixes for Sanity

Below are copy-paste fixes for the most common Sanity issues. They assume you have access to your theme code or the platform's custom-code injection panel. If you cannot edit code directly, share these snippets with whoever maintains the site — every one of them is a ten-minute change.

// schemas/objects/imageWithAlt.ts
export default {
  name: 'imageWithAlt',
  type: 'image',
  fields: [
    {
      name: 'alt',
      type: 'string',
      title: 'Alternative text',
      validation: (Rule: any) => Rule.required().error('Alt text is required for accessibility.'),
    },
  ],
};

Tools and plugins worth installing first

• Sanity Studio validation rules

• Custom portable-text serializers

How to scan a Sanity site without missing anything

Automated scanners catch about 30–40% of WCAG issues; the rest need manual review. The good news is that the 30–40% includes the most expensive issues to remediate after the fact, so an automated scan is the cheapest way to get unstuck. Run one before you change a line of theme code.

• Audit the rendered front-end, not Studio itself.