Contentful is a headless CMS that separates content from presentation, delivering structured content via API to any frontend. This architecture gives development teams complete control over rendered HTML - and complete responsibility for accessibility. Under the EAA, any site or application powered by Contentful that serves EU consumers must meet EN 301 549 requirements.
Common Contentful accessibility issues
Content model doesn't enforce accessibility fields
Contentful's content model is fully customisable, but teams frequently omit accessibility-critical fields - alt text for images, accessible names for links, and caption fields for media. If the content model doesn't include these fields, authors can't provide them even if they want to.
Rich Text field output lacks semantic validation
Contentful's Rich Text field type produces a structured JSON AST that frontends render to HTML. The Rich Text editor doesn't enforce heading hierarchy, validate link text quality, or require alt text for embedded images - and the rendering layer may not add these controls either.
Frontend rendering is entirely uncontrolled by Contentful
As a headless CMS, Contentful has no control over how content is rendered. The same content can be rendered accessibly or inaccessibly depending on the frontend implementation. Two sites using the same Contentful space can have completely different accessibility profiles.
Asset metadata lacks accessibility governance
Contentful's asset library stores images, videos, and documents. Alt text is supported on assets but is optional and often left empty. There's no workflow enforcement to prevent publishing assets without accessibility metadata.
Localised content may have inconsistent accessibility
Contentful's localisation features support multi-language content, but accessibility quality can vary between locales. Alt text might be provided in the primary language but missing in translations, or heading structure might be correct in one locale but broken in another.
How Lumi works with Contentful
Lumi scans the rendered frontend of your Contentful-powered site - the actual pages that users see, not the API responses. Our five engines detect issues originating from both the content layer (missing alt text, poor heading structure in Rich Text) and the frontend layer (missing landmarks, broken focus management, inaccessible components). Monitor continuously to catch issues from content updates and frontend deployments.
Contentful-specific WCAG gotchas
Accessibility is split across two layers
With Contentful, accessibility issues can originate in the content (missing alt text, poor text structure) or the frontend (missing ARIA, broken keyboard navigation). Both layers need attention, and they're often managed by different teams.
Content previews don't validate accessibility
Contentful's preview functionality shows content in context but doesn't include accessibility checking. Content editors can preview and approve content that has significant accessibility failures.
Multiple frontends multiply the testing surface
A single Contentful space can power a website, a mobile app, and a kiosk display. Each frontend needs independent accessibility testing, as the same content can be rendered differently across channels.
Scan your Contentful site for free
See how your site measures up against WCAG 2.2 and EN 301 549 - in 30 seconds, no signup required.
Frequently asked questions
Is Contentful responsible for my site's accessibility?
No. Contentful is a headless CMS that delivers content via API - it has no control over how that content is rendered. Accessibility is the responsibility of the team building the frontend that consumes Contentful's API. Contentful provides the content infrastructure; you provide the accessible rendering.
How do I enforce alt text in Contentful?
Add a required 'Alt Text' field to your image content types, and make it a mandatory field in the content model. For assets in the media library, train editors to populate the description field. Consider using Contentful Apps or webhooks to flag assets published without alt text.
Does the EAA apply to headless CMS sites?
The EAA applies to the service delivered to users, not the underlying technology. If your Contentful-powered site provides services to EU consumers, it must meet EN 301 549 regardless of whether the CMS is headless, traditional, or custom-built.
How should I structure my Contentful content model for accessibility?
Include required alt text fields on all image-containing content types. Add accessible name fields for interactive elements. Structure Rich Text usage to encourage proper heading hierarchy. Consider adding a 'language' field for multilingual inline content to support correct lang attributes in the rendered HTML.
Related resources
Last reviewed: April 2026. Content is reviewed quarterly for accuracy.