TYPO3 accessibility checklist for editors: what to check before publishing
A practical checklist for TYPO3 editors covering images, headings, links, tables, forms and other accessibility issues to review before content goes live.
Editors influence accessibility every time they publish a page, add an image, create a link, insert a table or embed a form. A technically sound TYPO3 template can still produce barriers when the content inside it is unclear or incomplete.
This checklist focuses on the decisions editors can review before content goes live. It does not replace manual testing or developer work, but it helps teams catch common issues while they are still easy to fix.
Accessibility works best when it becomes part of the normal editorial process rather than a final audit task. Read why accessibility should not be the last thing checked in a TYPO3 project.
Page structure
1. Does the page have a clear title?
The page title should explain what the page is about before a visitor starts reading. It should be specific enough to distinguish the page from other pages in the same section and should match the content people find after following a link or search result.
Avoid vague titles such as Information, Overview or Welcome when a more precise title is available. Editors should also check that the browser title and visible page heading do not contradict each other.
2. Do the headings describe the page structure?
Headings should divide the content into understandable sections and follow a logical hierarchy. A heading level should communicate structure, not just create larger or smaller text.
Start with the page H1, use H2 for the main sections and H3 for subsections. Do not skip from H2 to H4 because a lower level looks visually better. Styling belongs in the template or editor configuration; the heading level should reflect the meaning of the content.
Images and links
3. Do meaningful images have useful alternative text?
Alternative text should communicate the purpose of an informative image in the context of the page. It does not need to describe every visible detail, but it should provide the information a visitor would otherwise miss.
Avoid filenames, generic values such as image, and phrases such as picture of when they add no useful information. Ask what the image contributes to the surrounding content and write the alternative text around that purpose.
4. Is the image informative or decorative?
Not every image needs descriptive alternative text. A decorative image that adds no information should usually have an empty alternative text so assistive technology can skip it. An informative image needs a meaningful description.
Editors should decide based on the page context. The same visual may be decorative in one place and important in another. Do not duplicate nearby text in the alternative text unless that repetition is necessary to preserve meaning.
5. Does every link explain where it goes?
Link text should make sense when read on its own or in a list of links. Replace repeated text such as click here, read more or more with wording that identifies the destination or action.
For downloads, include the document purpose and, where useful, the format or size. For external services, make clear when the link opens a different website or starts an action that may surprise the visitor.
6. Are there empty links or buttons?
Links and buttons need an accessible name. An icon-only control may look understandable visually but remain silent to a screen reader when no accessible label is provided.
Editors should remove empty links left behind after copying or deleting content. Reusable controls, icons generated by templates and missing programmatic labels usually need developer or integrator attention.
Tables, embeds and forms
7. Are tables used for data?
Use tables for related data, not for visual layout. A data table needs clear column headings, a predictable reading order and content that still makes sense when a visitor navigates cell by cell.
| Workshop | Duration | Format |
|---|---|---|
| Editor training | 2 hours | Online |
| Accessibility review | 1 day | On site |
The column headers identify the meaning of each value and the row headers identify each workshop. Editors should also check that the table remains usable on smaller screens, either through responsive formatting or a safe horizontal scroll area.
8. Do embedded videos, maps and iframes have useful titles?
An embedded frame should have a title that describes its content or purpose, such as Map showing the Munich office or Video: Introduction to the application process. A generic title such as iframe does not help.
Editors should also provide captions, transcripts or another accessible alternative when the embedded media communicates important information.
9. Do forms have persistent labels?
Form fields need labels that remain visible when a visitor starts typing. Placeholder text alone is not a reliable label because it disappears and is often displayed with low contrast.
Instructions, required-field information and error messages should be understandable before and after submission. Problems in TYPO3 Form Framework definitions or custom form templates normally need an integrator or developer.
10. Are instructions independent of color and position?
Instructions should not depend only on color, shape or location. Text such as complete the fields in red or use the button on the right may fail when colors are not distinguishable, the layout reflows or the page is read linearly.
Use names, labels and clear descriptions in addition to visual cues. Color can reinforce meaning, but it should not be the only way meaning is communicated.
Documents, language and frontend output
11. Are document links understandable?
Document links should explain what the file contains. Prefer Download the 2026 accessibility report (PDF) over Download or a raw filename.
The linked document also needs its own accessibility review. An accessible link does not make an inaccessible PDF, spreadsheet or presentation accessible.
12. Is the language of the page correct?
The document language is usually set by the TYPO3 site configuration and templates. Editors should still verify that they are working in the correct language version and that copied content matches it.
Mixed-language content, untranslated fallbacks or text entered in the wrong page version can remain difficult to understand even when the technical language attribute is present.
13. Has the final frontend page been checked?
The backend record is not the final user experience. TYPO3 processors, Fluid templates, content elements, CSS and JavaScript can change the result before it reaches the browser.
Review the frontend preview before publishing. Check the heading order, links, images, forms and responsive behavior, and test important controls with a keyboard. Learn what automated accessibility checks can find and what still requires manual testing.
What editors can fix — and what needs a developer
Usually editor-fixable
Page titles, headings, image alternative text, link wording, table content, document descriptions, embed titles and clear instructions can often be corrected directly in the relevant TYPO3 record.
Usually developer or integrator work
Template semantics, focus behavior, navigation, reusable components, missing programmatic labels, ARIA, frontend JavaScript, color contrast and site-language configuration normally belong to the technical implementation.
The boundary is not always perfect. The useful question is where the issue originates and who can fix it safely. Page-level findings help teams route the work instead of sending every problem to the same person.
A checklist helps. Feedback inside TYPO3 helps more.
A checklist depends on memory and discipline. Contextual feedback can show which record contains the problem, explain why it matters and provide a direct route to the affected content. That makes accessibility easier to include in everyday editorial work.
Final checklist before publishing
- The page has a clear and specific title.
- Headings describe the structure and use logical levels.
- Informative images have meaningful alternative text.
- Decorative images are treated as decorative.
- Links explain their destination or action.
- No empty links or buttons remain in the content.
- Data tables have clear row and column headings.
- Embedded content has a useful title and accessible alternative where needed.
- Forms use persistent labels and understandable instructions.
- Meaning does not depend only on color or position.
- Document links explain the file and format.
- The content is in the correct TYPO3 language version.
- The frontend preview has been reviewed before publishing, including keyboard use and responsive layout.
Check TYPO3 content before it goes live.
Accessibility Quality Gate helps TYPO3 editors, integrators and agencies find common content issues earlier through Local checks, page-level issue tracking and the Rendered Page Check. The FREE workflow requires no license key.