Automated accessibility checks are useful — but they are not enough

What automated accessibility checks do well

Automated tools are good at finding issues that can be evaluated consistently from stored content, HTML markup or the rendered page. Depending on the scanner, they can detect images without alternative text, empty links or buttons, form controls without accessible labels, missing iframe titles, duplicate IDs, missing document language, incomplete ARIA attributes, table problems, missing landmarks, certain color contrast failures and elements without an accessible name.

These are real problems. They can prevent people from understanding content, completing forms or navigating a page with assistive technology. Automation is especially valuable because the same checks can run while editors prepare content, before publishing, after deployment, during scheduled scans or across many TYPO3 pages.

That repeatability makes automated testing useful for finding regressions. A team does not need to wait for the next large audit to discover that a previously fixed problem has returned.

What automated checks cannot prove

A clean scan is not proof of accessibility

A clean-looking score can be useful for comparing the same website over time, but it does not prove that the website is accessible. The result depends on which pages were included, whether authenticated areas were reachable, whether menus and dialogs were opened, whether a consent banner blocked content, which user journeys were tested and which rules the tool supported.

A homepage scan says nothing about an inaccessible checkout step that was never opened. A passing result also says nothing about issues that require human judgment.

An attribute can exist and still be wrong

An automated tool may confirm that an image has a non-empty alt attribute, but it cannot always judge whether the text is meaningful in context. Values such as image or team-photo-final-2.jpg may pass a simple presence check, while Customer support team in the Berlin office is more likely to communicate the purpose of the image.

The same applies to links, headings, labels, button names and ARIA. A scanner can confirm that something is present and syntactically valid. It cannot always determine whether people can understand and use it.

What manual accessibility testing adds

Manual testing looks at the actual experience, not only the source code. A reviewer can verify whether the website works with a keyboard, whether focus remains visible, whether focus order is logical, whether form errors are announced clearly, whether dialogs return focus correctly and whether a screen reader user can understand the page structure.

These questions require interaction and judgment. A scanner can detect that a button has a name; a person must decide whether that name explains the action. A scanner can detect focusable elements; a person must verify that keyboard navigation remains usable.

Manual testing has limits too

Manual testing is essential, but its quality depends on the reviewer, selected pages, scenarios, browsers, assistive technologies, available time and documentation. It is also unrealistic to repeat a complete expert audit whenever an editor changes a page or uploads an image.

Automated checks and manual testing should therefore not compete. They solve different parts of the same problem.

Why TYPO3 needs more than one type of check

Accessibility problems in TYPO3 can be introduced at several levels, which is why a serious workflow must inspect more than one source.

Editorial content

Editors manage headings, images, links, tables, documents, embedded media and form content. Missing image descriptions or unclear link text may originate directly in an editor-managed field.

TYPO3 configuration

Integrators configure TCA fields, CKEditor behavior, content elements, Form Framework definitions, languages, file references and permissions. A field may exist but still be difficult for editors to understand or use correctly.

Templates and frontend components

Developers control Fluid templates, semantic HTML, navigation, interactive components, frontend JavaScript, ARIA, focus behavior and styling. Stored content can be correct while the final template renders inaccessible markup.

All of these layers are combined on the final page. Content passes through records, processors, Fluid templates, CSS and JavaScript before it reaches the browser. A check that inspects only one layer will miss issues introduced by the others.

Three layers of automated checks in AQG

Local content checks

Local checks review TYPO3-managed content such as CKEditor fields, image references, link text, heading structures, tables, documents and structured TCA fields. Findings can be connected directly to the affected page or content record, so editors see where an issue originated and can open the relevant record.

aqg · local scan

Enlarge

Rendered Page Check

The Rendered Page Check inspects the server-rendered HTML produced by TYPO3. It can reveal problems introduced by templates or content elements, including incorrect heading levels, missing image alternatives, empty links, missing iframe titles and duplicate IDs.

aqg · rendered page check

Enlarge

PRO remote browser scan

The PRO remote browser scan loads the page with Playwright and axe-core and inspects the fully rendered frontend. It can process multiple pages, capture screenshots and add browser-visible findings such as color contrast, landmark, form-label and ARIA problems.

aqg pro · scan progress

Enlarge

Together, these layers provide broader coverage. None of them can prove full accessibility on its own.

Manual review and expert assessment

Manual review of important pages and components

Manual review should focus on primary navigation, forms and errors, search, dialogs, interactive components, keyboard operation, visible focus, screen reader structure, important documents and high-value user journeys. The scope should reflect the website rather than treating every page as equally important.

Expert audits and user testing

Projects with legal, contractual, public-sector or complex service requirements may need a deeper assessment. An experienced accessibility specialist can define the audit scope, select suitable methods and document the results. Testing with people who use assistive technologies can reveal barriers that neither automation nor a technical reviewer expected.

AQG is not intended to replace this work. Its role is to help teams reach that stage with fewer basic problems and better information.

A practical testing model for TYPO3 teams

1. During content editing. Use Local checks to catch editor-managed issues while they are still easy to fix.
2. Before publishing. Review the affected TYPO3 page and run a Rendered Page Check.
3. During regular maintenance. Run scheduled content scans and review new or reopened issues.
4. After deployments or template changes. Check representative frontend pages and components for regressions.
5. For agency and professional workflows. Use PRO remote browser scans across selected pages and prepare structured reports.
6. At defined intervals. Perform manual keyboard, screen reader and component testing.
7. Before important launches or formal assessments. Use an experienced accessibility specialist for a broader audit.

Questions to ask when choosing an accessibility tool

1. What exactly does it check?
2. Does it inspect CMS content, rendered HTML or the browser result?
3. Which parts of the website can it reach?
4. Can findings be connected to the affected TYPO3 page or record?
5. Can scans be repeated automatically?
6. Can the team distinguish new, open and resolved issues?
7. Are results useful for both editors and developers?
8. Does the tool explain what still requires manual review?

The number of rules is not the only important factor. Results also need to fit the way the team works.

Where Accessibility Quality Gate fits

I am building Accessibility Quality Gate for the earlier and repeatable parts of accessibility work. The FREE workflow includes Local content checks, page-level issue management, CLI and Scheduler scans, and the Rendered Page Check. The PRO workflow adds remote browser scanning with Playwright and axe-core, multi-page frontend results, screenshots and reporting for professional teams and agencies.

The goal is not to replace manual testing. It is to make sure that a manual audit is not the first time a team discovers basic problems that could have been found weeks or months earlier.

aqg pro · finding detail

Enlarge

Automated and manual testing belong together. Use automation continuously to catch repeatable problems early, manual testing for issues that require human judgment and expert audits when the project needs deeper assessment and reliable documentation.