Sitecore Accessibility Checklist 2026 | WCAG 2.1 AA, EN 301 549 & EAA
Last updated: 2026-05-24
Sitecore is an enterprise digital experience platform used by large B2B companies, financial institutions, universities, and public-sector organizations - exactly the audiences most likely to face procurement accessibility requirements, VPAT requests, and regulatory scrutiny. That makes accessibility a contractual and legal question on most Sitecore projects, not a nice-to-have. The platform itself does not force accessible output: it gives developers near-total control over markup through renderings, layouts, and the Sitecore Experience Accelerator (SXA), and whatever the front-end team builds is what ships. In practice the failures come from a few predictable layers. Component renderings (MVC views, JSS React/Next components, or SXA partial designs) frequently emit div-based structures with no landmarks, headings chosen by visual size, and interactive widgets - carousels, tabbed panels, mega-menus - that have no keyboard support or ARIA state. The Rich Text Editor lets authors apply heading styles by appearance, paste inline styles, and create dozens of links that all read 'read more'. Image fields and the Media Library expose an Alt field that authors routinely leave blank, so informative images reach screen reader users as filenames. Sitecore Forms can be configured with placeholder-only labels and validation that is not programmatically tied to the field that failed. Personalization and A/B testing add a Sitecore-specific risk: a variant served to one audience can quietly differ in heading structure, link text, or accessible names from the variant an auditor sees, so a page can pass once and fail for a real visitor. Multilingual sites - common in Sitecore - often forget to set the correct html lang attribute per language version. This checklist focuses on the developer and author decisions that determine whether a Sitecore site passes a WCAG 2.1 AA, EN 301 549, or EAA audit, and gives the specific place to fix each issue.
Common Accessibility Issues
Sitecore renderings - whether MVC Razor views, SXA partial designs, or JSS (React/Next) components - give the front-end team full control of the output, and the default scaffolding is usually generic <div> nesting with no header, nav, main, or footer landmarks and no heading hierarchy. Screen reader users lose the ability to jump between regions and to understand the page outline, and a placeholder full of stacked div components reads as one undifferentiated block.
Build semantic structure into the base layout and the shared renderings, not into individual pages. The page layout should provide a single <main> with an id for the skip link, a <header> with <nav aria-label>, and a <footer>. Each content rendering should expose proper headings (one H1 per page from the page title field; sequential H2/H3 inside components) and use real list, table, and figure elements where appropriate. For SXA, set this in the partial and page designs; for JSS, bake it into the shared layout components so every route inherits it.
<!-- typical rendering output -->
<div class="component hero">
<div class="field-title">Quarterly Results</div>
<div class="component rich-text">...</div>
</div><main id="main-content">
<section aria-labelledby="hero-title">
<h1 id="hero-title">Quarterly Results</h1>
<div class="rich-text">...</div>
</section>
</main>The Sitecore Rich Text Editor lets authors style text to look like a heading without using a real heading element, skip heading levels, and create many links that all read 'read more', 'click here', or 'learn more'. Screen reader users navigating by heading get a broken outline, and users listing links out of context cannot tell where any of them go.
Configure the RTE profile so authors can only apply the heading levels intended for body content (typically H2 and H3), with the H1 supplied by the template from the page title field. Train authors to write descriptive link text that makes sense out of context ('Read the Q2 results report', not 'read more'). Where a repeated CTA is unavoidable, add a visually hidden suffix or an aria-label that distinguishes each link. Audit the rendered page with a screen reader's headings list and links list before publishing.
<p><strong style="font-size:24px">Our Services</strong></p>
<a href="/services/audit">Read more</a>
<a href="/services/training">Read more</a><h2>Our Services</h2>
<a href="/services/audit">Read more about our audit service</a>
<a href="/services/training">Read more about our training service</a>Sitecore stores an Alt value on each media item and image field, but authors frequently leave it blank or let it default to the file name. Informative images - charts, product shots, infographics, images containing text - then reach screen reader users as a meaningless filename or nothing at all. The opposite failure also occurs: purely decorative images are given descriptive alt text that clutters the experience.
Treat the Alt field as required for informative images and write text that conveys the image's purpose, not its file name. For decorative images, set the alt to empty so assistive technology skips them. Because the same media item can be reused across many pages, remember that the alt set on the field instance (not just the media item) is what should match the context. Consider surfacing missing alt text in author workflow or preview so it is caught before publish.
<img src="/-/media/chart-q2.ashx" alt="chart-q2"><img src="/-/media/chart-q2.ashx" alt="Revenue grew 18% from Q1 to Q2 2026, reaching 4.2 million euros">Sitecore Forms fields can be configured to show a placeholder in place of a visible label, and validation messages are often rendered in a way that is not programmatically connected to the input that failed. Placeholders disappear on focus and are not reliable labels, and a screen reader user who hits a validation error has no way to navigate to the broken field or hear what went wrong.
Give every field a persistent, visible <label> tied to the input with for/id - do not rely on placeholder text as the label. Mark required fields with the required attribute and aria-required. Associate each error message with its field using aria-describedby and set aria-invalid on the field when it fails. Put the error summary in an aria-live region so it is announced without stealing focus. Override the Sitecore Forms field view/templates to control this markup.
<input type="email" name="email" placeholder="Email">
<div class="validation-summary">Email is invalid.</div><label for="email">Email address <abbr title="required">*</abbr></label>
<input type="email" id="email" name="email" required aria-required="true"
aria-invalid="true" aria-describedby="email-err">
<span id="email-err">Enter a valid email address, for example [email protected].</span>Personalization, audience targeting, and A/B testing are core Sitecore capabilities, but each variant of a component is authored separately. A variant can quietly differ from the default in its heading structure, link text, alt text, button labels, or accessible names. The result is a page that passes an audit when the auditor happens to see the compliant variant and fails for a real visitor who is served a different one. Automated scanners typically test only the variant rendered at scan time.
Make accessibility part of the definition of done for every personalization variant, not just the control. When authoring a variant, check that headings, link text, alt text, and accessible names are present and equivalent. Keep a shared component template that bakes in labels and ARIA so each variant only changes copy and media, not structure. Spot-check high-traffic personalization rules with a screen reader using the experience editor's variant preview, and document which variants were tested in the accessibility statement or VPAT evidence.
<!-- control variant -->
<button aria-label="Download the 2026 buyer's guide">Download</button>
<!-- personalized variant: accessible name lost -->
<button>Get it now</button><!-- both variants keep an equivalent accessible name -->
<button aria-label="Download the 2026 buyer's guide">Download</button>
<button aria-label="Download the 2026 buyer's guide">Get it now</button>SXA themes and custom CSS often ship brand colors that fail the minimum contrast ratios - light gray body text, low-contrast placeholder text, and button styles below 4.5:1 - and global resets that remove the focus outline on links and buttons. Low-vision users cannot read low-contrast text, and keyboard users cannot tell which element has focus.
Check every text/background and UI-component color pairing against the WCAG minimums (4.5:1 for normal text, 3:1 for large text and meaningful non-text elements) and adjust the SXA theme tokens accordingly. Never leave outline:none without a replacement; provide a clearly visible focus style using :focus-visible with an outline or box-shadow that meets 3:1 contrast against adjacent colors. Set these in the base theme so every component inherits them.
a:focus, button:focus { outline: none; }
.btn-primary { color: #9aa0a6; background: #d7dadd; }a:focus-visible, button:focus-visible {
outline: 3px solid #1a4fd6; outline-offset: 2px;
}
.btn-primary { color: #ffffff; background: #1a4fd6; }Sitecore's strength in multilingual content is also a common accessibility gap: language versions are created per item, but the rendered html lang attribute is frequently hard-coded to one language (often en) for every version, and inline passages in another language are not marked up. Screen readers then pronounce content with the wrong voice and phonetics, which can make translated content unintelligible.
Bind the html lang attribute to the context language of the current Sitecore item so each language version outputs the correct value (for example lang="de" on the German version). For inline foreign-language phrases inside otherwise same-language content, give authors a simple way to wrap them with a lang attribute (3.1.2 Language of Parts). Verify each language version's lang value in the rendered source after publishing.
<html lang="en"> <!-- hard-coded on every language version --><html lang="@Sitecore.Context.Language.Name"> <!-- e.g. resolves to de, fr, ja -->Sitecore-Specific Tips
- Decide accessibility in the layout and shared renderings, not page by page. Landmarks, the skip link, heading conventions, focus styles, and color tokens set in the base layout, SXA theme, or JSS shared components fix every page at once.
- Lock down the Rich Text Editor profile so authors can only apply body-level headings (H2/H3) and cannot paste arbitrary inline styles; supply the single H1 from the page title field via the template.
- Treat the image Alt field as required for informative images and surface missing alt text in author workflow or preview so it is caught before publishing.
- Make accessibility part of the definition of done for every personalization and A/B variant, not just the control, since each variant is authored separately and scanners only see one at a time.
- Override Sitecore Forms field templates to render real labels, required indicators, and aria-describedby error association rather than relying on placeholder-only fields.
- Bind the html lang attribute to the item's context language so each multilingual version outputs the correct value, and give authors a way to mark inline foreign-language passages.
- If the site serves EU public-sector or B2B procurement audiences, plan for an accessibility statement and VPAT evidence; document which components, forms, and personalization variants were tested.
Recommended Tools
axe DevTools
Deque's browser-based scanner runs axe-core against rendered Sitecore pages and reports WCAG-referenced issues across renderings, forms, and themes. Useful for catching ARIA, contrast, and structure problems, though it tests only the personalization variant rendered at scan time.
WAVE Browser Extension
WebAIM's free extension visually flags missing alt text, unlabeled form fields, heading-structure breaks, and contrast failures directly on the live page, which helps content authors see the impact of RTE and Media Library choices.
Sitecore Documentation
Sitecore's official documentation for XP, XM, XM Cloud, SXA, JSS, and Sitecore Forms, including the rendering, theming, and form-template references you need to control markup for landmarks, labels, and ARIA.
Sitecore Accessibility: Where Failures Come From and How to Fix Them
| Plugin / Tool | Layer | Common Failure | What WCAG 2.1 AA Needs | Where to Fix It |
|---|---|---|---|---|
| Component renderings 1.3.1 | Div-only output, no landmarks or headings | Semantic landmarks, sequential headings | Base layout + shared renderings / JSS | |
| Rich Text Editor 2.4.4 / 1.3.1 | Fake headings, generic 'read more' links | Real headings, descriptive link text | RTE profile + author training | |
| Media Library / images 1.1.1 | Alt field blank or set to file name | Descriptive alt; empty alt for decorative | Image field + media item metadata | |
| Sitecore Forms 3.3.1 | Placeholder labels, errors not tied to fields | Real labels, aria-describedby error link | Override form field templates | |
| Personalization / A/B 4.1.2 | Variant differs in names / structure | Equivalent accessible content per variant | Per-variant QA + shared templates |
Frequently Asked Questions
Is Sitecore accessible out of the box?
Sitecore does not force accessible output. It gives the front-end team near-total control over markup through renderings, layouts, SXA, and JSS, so the accessibility of a real site is decided by what your developers build and how your authors use the Rich Text Editor, image fields, and forms. A careful team can ship an accessible Sitecore site; a careless one can fail WCAG on every page. This is general information, not legal advice.
Why is personalization an accessibility risk in Sitecore?
Each personalization or A/B variant of a component is authored separately, so a variant can differ from the control in heading structure, link text, alt text, or accessible names. A page can pass an audit when the auditor sees the compliant variant and still fail for a visitor served a different one. Automated scanners only test the variant rendered at scan time, so accessibility has to be checked for every variant, not just the default.
What standards should a Sitecore site target?
The practical working target is WCAG 2.1 AA, which underpins the European Accessibility Act, EN 301 549 (used for EU public-sector and procurement), ADA expectations in the US, and most enterprise procurement requirements. Enterprise and public-sector buyers frequently also request a VPAT or accessibility conformance report. WCAG 2.2 adds criteria such as focus appearance, target size, and redundant entry that increasingly appear in audits. This is general information, not legal advice.
Further Reading
- Eaa Compliance Checklist 2026
- Wcag Explained Plain English
- What Is A Vpat Plain English Guide
- Accessible Forms Guide
- Wcag Audit Report Guide
- How To Hire Accessibility Consultant
Other CMS Checklists
- Umbraco Accessibility Checklist
- Drupal Accessibility Checklist
- Typo3 Accessibility Checklist
- Adobe-experience-manager Accessibility Checklist
Get our free accessibility toolkit
We're building a simple accessibility checker for non-developers. Join the waitlist for early access and a free EAA compliance checklist.
No spam. Unsubscribe anytime.