TYPO3 Accessibility Checklist 2026 | WCAG 2.1 AA, EN 301 549 & EAA
Last updated: 2026-05-23
TYPO3 is an enterprise open-source CMS used heavily across Europe, particularly by universities, municipalities, and government agencies in German-speaking countries. That audience matters for accessibility because public-sector sites in the EU already have to meet the Web Accessibility Directive (which points to EN 301 549 and therefore WCAG 2.1 AA), Germany's BITV 2.0 adds its own requirements, and the European Accessibility Act now extends accessibility obligations to many private businesses too. TYPO3 itself takes accessibility more seriously than most platforms: the backend has had accessibility work, the project publishes accessibility guidance, and well-built distributions can be very clean. The failures in practice come from the layers integrators and editors add. The rich-text editor (CKEditor) lets content authors apply heading styles by appearance, paste formatted text full of inline styles, and create links that all read 'more' or 'read more'. Image content elements have an 'Alternative text' field in the File Abstraction Layer metadata that editors routinely leave blank. Third-party extensions from the TYPO3 Extension Repository render their own front-end markup whose quality varies widely, so a single non-semantic extension can undermine an otherwise accessible site. Custom 'site packages' (the Fluid templates and TypoScript that define a site's theme) are where navigation, skip links, landmarks, and contrast are decided, and a site package built without accessibility in mind bakes the problems into every page. Multilingual sites, common in TYPO3, frequently forget to set the correct language attributes when content switches language. This checklist focuses on the editor habits and integrator decisions that determine whether a TYPO3 site passes a WCAG, EN 301 549, or BITV audit, and what to do about each.
Common Accessibility Issues
In the TYPO3 rich-text editor (CKEditor), content authors pick heading styles from the format dropdown based on how big the text looks, not on where the section sits in the document outline. They skip levels (an H2 followed by an H4), reuse H1 inside body content, or apply bold paragraph text to fake a heading so it never becomes a real heading at all. Screen reader users who navigate by heading get a structure that does not match the visible sections, and a fake bold 'heading' is invisible to heading navigation entirely.
Configure the editor's RTE preset (the YAML configuration) to expose only the heading levels editors should use for body content, typically H2 and H3, reserving H1 for the page title rendered by the template. Train editors to choose heading levels by structure and to never bold a paragraph to imitate a heading. Use the page-title field for the H1 in your Fluid template so editors are not tempted to add their own. Review the document outline of representative pages with a heading-map tool.
<h1>Welcome</h1> <!-- second H1 inside RTE body -->
<p><strong>Our Departments</strong></p> <!-- fake heading -->
<h4>Admissions</h4> <!-- jumps from page H1/H2 to H4 --><!-- page title H1 comes from the template; RTE uses H2/H3 -->
<h2>Our Departments</h2>
<h3>Admissions</h3>TYPO3 stores image metadata, including the 'Alternative text' field, in the File Abstraction Layer (FAL). When editors add an Image or Text & Media content element, the alt field is optional and frequently left empty, or the same generic value is reused across many images. Informative images then reach screen reader users with no description, and images that contain text (a common pattern for infographics and event posters on institutional sites) lose their content entirely.
Fill in the 'Alternative text' field in the FAL metadata for every informative image, describing its purpose and any text it contains. For decorative images, set the alt explicitly to empty so they are skipped rather than announced. Where the same image is used in different contexts, override the alt per content element if its meaning changes. Consider configuring your Fluid image rendering so that an image with no alt is flagged in editing/preview, and audit older content elements that predate any alt-text policy.
Much of a TYPO3 site's front end is rendered by extensions from the TYPO3 Extension Repository (sliders, accordions, tab panels, card grids, news lists, event calendars). The accessibility quality of these extensions varies enormously: some emit clean semantic HTML, others produce div-only structures with no headings, no ARIA, click-only interactions, and tab/accordion widgets with no keyboard support. A single such extension can break an otherwise accessible page, and editors usually have no way to know which extensions are safe.
Before adopting an extension that renders interactive or structured front-end content, test its output for semantic markup, keyboard operability, and screen reader announcement, and check whether the maintainer documents accessibility. Prefer extensions whose templates you can override via Fluid so you can fix markup without forking the extension. For sliders, accordions, and tabs, override the templates to add the correct roles, states, and keyboard handling, or replace the widget with a native, accessible pattern. Re-test after extension updates, which can change the rendered markup.
TYPO3's Form Framework (EXT:form) lets editors build forms in the backend, but the resulting front-end forms can ship without proper label association, without fieldset/legend grouping for radio and checkbox groups, and with validation errors shown in a way that is not programmatically tied to the field that failed. Screen reader users then cannot tell which field they are completing or which field an error refers to, which is especially serious on the contact, application, and request forms that institutional sites rely on.
Override the Form Framework's Fluid templates so each field renders a real associated <label>, related options are wrapped in fieldset/legend, required fields are marked with aria-required, and validation messages are linked to their field with aria-describedby and announced (an aria-live summary helps). Confirm the configured field labels actually render as label elements rather than placeholder text. Test the full form, including the error state, with a keyboard and a screen reader.
TYPO3 is widely used for multilingual sites, but the lang attribute is often only set once on the html element for the default language and not updated when a page or a passage is in a different language. When a screen reader encounters German text on an English page (or vice versa) with no lang change, it pronounces the words with the wrong language's speech rules, making them hard or impossible to understand.
Ensure your site configuration and Fluid templates output the correct lang attribute on the html element for each language version of a page, and add lang on any inline passage that switches language (for example a quotation or a proper name in another language). TYPO3's language handling sets the page language when configured correctly, so verify each translated page renders the right html lang, and give editors a simple way (an RTE option or a wrap) to mark inline foreign-language text.
<html lang="en">
...
<p>Willkommen auf unserer Seite.</p> <!-- German text, no lang change --><html lang="de"> <!-- correct for the German page version -->
...
<p>Willkommen auf unserer Seite.</p>
<!-- or inline on an English page: -->
<p><span lang="de">Willkommen</span> means welcome.</p>A TYPO3 site's navigation, header, and footer are produced by the site package's Fluid templates and menu processors. Custom site packages frequently render the main menu as nested lists with no nav landmark and no aria-label, omit a skip-to-content link, and do not expose dropdown submenu state to assistive technology. Keyboard users then have to tab through the entire menu on every page before reaching the content, and screen reader users cannot jump between page regions.
In the site package templates, wrap primary navigation in a <nav> element with an aria-label, add a visible-on-focus skip-to-content link as the first focusable element pointing at the main landmark, mark up the main content with <main> and other landmarks (header, footer), and ensure dropdown submenus are keyboard operable with their expanded/collapsed state exposed via aria-expanded. Build these into the base site package so every page inherits them.
Corporate and institutional color palettes baked into a TYPO3 site package, light gray body text, brand-colored links and buttons, pale captions, and low-contrast hover states, often fall below the 4.5:1 ratio for normal text and 3:1 for large text and UI components. Because these colors live in the theme rather than in individual content, the failure repeats site-wide on every page until the theme is fixed.
Audit the site package's color tokens against a contrast checker, especially body text, link colors (default, hover, visited, and focus), button text and backgrounds, captions, and form field borders, and adjust the theme variables until they meet at least 4.5:1 for normal text and 3:1 for large text and UI components. Fixing this once in the site package corrects it everywhere. Re-test after any brand-color update.
TYPO3-Specific Tips
- Decide accessibility at the site-package level. Skip links, landmarks, nav labels, heading-level conventions, and color contrast all live in the Fluid templates and theme tokens, so building them into the base distribution fixes every page at once.
- Lock down the RTE (CKEditor) YAML preset so editors can only apply the heading levels meant for body content (typically H2/H3) and cannot paste arbitrary inline styles. The page-title field should supply the single H1 via the template.
- Treat the FAL 'Alternative text' field as required for informative images. Consider surfacing missing alt text in editing or preview so authors notice it before publishing.
- Vet TER extensions for accessibility before adopting them, and prefer ones whose Fluid templates you can override so you can correct slider, accordion, and tab markup without forking the extension. Re-test after updates.
- On multilingual sites, verify each language version renders the correct html lang attribute and give editors a simple way to mark inline foreign-language passages, since wrong-language pronunciation is a frequent and easily missed BITV/WCAG failure.
- If the site is public-sector in the EU, remember it must also publish an accessibility statement and meet EN 301 549 / BITV, not just internal goals; build the statement and a feedback mechanism into the site package.
Recommended Tools
axe DevTools
Deque's browser-based scanner runs axe-core against rendered TYPO3 pages and reports WCAG-referenced issues, useful for catching extension markup, ARIA, and contrast problems across templated pages.
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 editors see the impact of content choices in CKEditor.
TYPO3 Accessibility Documentation
TYPO3's official documentation, including its accessibility guidance and the Form Framework and Fluid template references you need to override markup for labels, navigation, and content elements.
TYPO3 Accessibility: Where Failures Come From and How to Fix Them
| Plugin / Tool | Layer | Common Failure | What WCAG 2.1 AA / BITV Needs | Where to Fix It |
|---|---|---|---|---|
| RTE (CKEditor) content 1.3.1 | Headings chosen by size; fake bold headings | Sequential headings; H1 from page title | RTE YAML preset + editor training | |
| Images (FAL) 1.1.1 | Alternative text field left blank | Descriptive alt; empty alt for decorative | FAL metadata per content element | |
| TER extensions 1.3.1 / 2.1.1 | Div-only sliders/accordions, no keyboard support | Semantic markup, ARIA state, keyboard operable | Override Fluid templates in site package | |
| Form Framework 3.3.1 | Placeholder labels, errors not tied to fields | Real labels, fieldset/legend, error association | Override form Fluid templates | |
| Site-package theme 1.4.3 / 2.4.1 | Low contrast, no skip link or landmarks | 4.5:1 text, skip link, nav landmark, main | Site-package templates + color tokens |
Frequently Asked Questions
Is TYPO3 accessible out of the box?
TYPO3 gives you a strong foundation, the project does real accessibility work and a well-built distribution can be very clean, but no production TYPO3 site is just core. The accessibility of a real site is decided by the site package's templates, the RTE configuration, the third-party extensions installed, and editor habits. A careful integrator can ship an accessible TYPO3 site; a careless one can fail WCAG on every page despite the platform's good defaults.
What standards does my TYPO3 site need to meet in the EU?
Public-sector TYPO3 sites in the EU fall under the Web Accessibility Directive, which points to EN 301 549 and therefore WCAG 2.1 AA, and in Germany BITV 2.0 adds further requirements and an accessibility statement obligation. The European Accessibility Act now extends accessibility duties to many private businesses too. In practice the working target is WCAG 2.1 AA. This is general information, not legal advice.
Why do third-party TYPO3 extensions cause accessibility problems?
Extensions from the TYPO3 Extension Repository render their own front-end markup, and their accessibility quality varies a lot. A slider, accordion, or tab extension with div-only markup, no keyboard support, and no ARIA can break an otherwise accessible page. Because TYPO3 lets you override extension templates with Fluid, the fix is usually to prefer extensions you can override and to correct their markup in your site package rather than forking the extension.
Further Reading
- Eaa Compliance Checklist 2026
- Wcag Explained Plain English
- Accessible Forms Guide
- Accessible Navigation Guide
- Wcag Audit Report Guide
- Eaa Fines By Country
Other CMS Checklists
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.