Accessibility should not be the last thing you check in a TYPO3 project
Accessibility issues are often discovered too late in TYPO3 projects. Moving checks into the editorial workflow makes them easier to find and fix before content goes live.
I started building AQG after seeing the same pattern in TYPO3 projects: accessibility was checked only after templates were finished, content was entered and the launch date was already close.
Then someone ran a checker and found missing alternative text, empty links, skipped heading levels, unlabeled form fields, untitled iframes and tables that assistive technology could not navigate.
None of these issues was impossible to fix. But at that stage, every fix was more expensive. Developers were closing bugs, editors were busy and the project manager wanted to ship.
This is not only a technical problem. It is a workflow problem.
Accessibility problems are often workflow problems
Accessibility discussions often focus on frontend code: semantic HTML, ARIA attributes, color contrast, keyboard navigation and screen reader testing. All of that matters, but many common issues in a TYPO3 project are created during everyday editorial work.
An editor uploads an image without alternative text. A link uses vague text such as “click here”. A heading is chosen because it looks right rather than because its level is correct. A table is added without headers, or an iframe without a title.
These are not always deep technical failures. They are often gaps in the publishing workflow. If TYPO3 gives no feedback when content is created, the editor has little indication that anything is wrong.
Why external tools are not enough on their own
Browser extensions, online scanners, axe-based audits and manual expert reviews all have a place in a serious accessibility process. The problem is that they usually live outside TYPO3.
That creates a gap between the tool and the people who create content every day. A developer or auditor may find an issue later, but the editor who built the page never received feedback when the issue was easiest to fix.
For larger installations with many editors, languages and content types, accessibility cannot depend on someone remembering to run an external tool from time to time. The feedback has to move closer to the normal CMS workflow.
Three layers of accessibility checks in AQG
Accessibility Quality Gate is designed to surface common issues at different stages of the TYPO3 workflow, rather than waiting for one large report at the end.
Local content checks
Inspect stored CKEditor content and configured TYPO3 fields before the frontend is rendered.
Rendered HTML checks
Inspect the server-rendered HTML returned by TYPO3 without executing JavaScript.
PRO browser scans
Open the final page in a real browser with Playwright and axe-core, including JavaScript-rendered content, color contrast, forms and landmarks.
No automated tool can establish full WCAG conformance or legal compliance on its own. Meeting obligations under the EAA, BFSG or BITV also requires human review, project-specific judgment and appropriate documentation. Automated checks are still valuable when they catch repeatable issues early and show teams where to act.
A practical TYPO3 accessibility workflow
- An editor saves content. AQG detects common issues in CKEditor fields and configured content elements.
- An integrator opens Page Detail. Findings are linked to the responsible content record, with a direct Edit record action.
- A project manager reviews the Overview. The team can see which pages and severities need attention first.
- A TYPO3 Scheduler task runs regularly. New and resolved issues can be tracked without relying on a manual audit before launch.
- A PRO browser scan checks the final frontend. It adds browser-level findings, screenshots and reports for agency QA and client reporting.
What this changes for TYPO3 teams
For agencies
TYPO3 agencies increasingly need a repeatable accessibility process they can use across projects and explain clearly to clients. AQG can become part of a pre-launch checklist, a recurring QA process or an accessibility service included in a maintenance agreement.
PDF and CSV exports provide a structured record of what was found, what has been addressed and what still requires attention. They do not replace an expert audit, but they make ongoing accessibility work easier to organize and communicate.
For editors
Editors should not need to understand every WCAG criterion to improve content. They need clear feedback they can act on: whether an image needs alt text, where an empty link appears, why a heading level is wrong or what is missing from a table.
When that feedback appears inside the CMS, repeated mistakes become easier to avoid. Editors do not become accessibility experts overnight, but the system gives them better signals while they work.
What automated checks cannot replace
Automated checks can reliably find many structural and content problems, but they cannot determine everything that matters to a real user.
They cannot fully judge whether alt text communicates the purpose of an image, whether link text is meaningful in context, whether focus order makes sense, whether form errors are understandable or whether an important user journey works well with a screen reader.
AQG should therefore be understood as an accessibility quality workflow, not as a legal certificate. Manual audits, assistive technology testing and expert review remain essential. However, a manual audit should not be the first time a team discovers a repeatable content issue that could have been caught months earlier.
Read more about automated accessibility testing and manual audits.
Accessibility as a continuous TYPO3 process
My goal is not to build another generic scanner that happens to have a TYPO3 plugin. The goal is a workflow that feels like it belongs inside TYPO3: useful for editors, technical enough for integrators, structured enough for agencies and honest about the limits of automation.
TYPO3 websites are often maintained for many years. Content changes, new pages are added, old pages are updated and editorial teams change. Accessibility therefore has to be continuous, not limited to a relaunch, an audit or a response after something goes wrong.
That is why I am building Accessibility Quality Gate: to help TYPO3 teams find accessibility issues earlier, while they are still practical to fix.
Catch accessibility issues before content goes live.
The free extension includes local content checks, page-level issue tracking, CLI and Scheduler scans, and a rendered page check. PRO adds remote browser scans, screenshots, PDF/CSV exports and structured reporting for agencies and TYPO3 teams.