TYPO3 and its Accessibility in the Backend

Categories: Community, TYPO3 CMS Created by Alexa Kreßmann
Man sitting in front of a computer screen and Braille display. Screen shows the TYPO3 backend.
Matthias Henke manages, updates and edits the DRK Clinics intranet. He posts news and events, updates food plans, and publishes self-produced podcasts. He works with the screen reader Jaws, the 80 Braille display and TYPO3 v9, v10, and v11. Photo: Sebastian Kreideweiß
Two accessibility case studies from the daily work of a blind editor, and the experience of a blind tester.

What Does Digital Accessibility Mean?

It is a task for society as a whole to provide everyone with equal access to relevant information and digital participation. This clearly formulated guiding principle and the legal implementation deadlines in Germany since 2018 have resulted in a gradual rethinking in many different areas of life. The premise is to remove barriers. The goal is to be accessible for everyone.

To ensure that all people have access to digitally-provided information, there are many approaches and tools for making digital information processing systems accessible.

Let's take a website as an example. Everyone should be able to perceive, operate and understand it in a robust way, without any particular difficulty and, in principle, without outside help—under their individual technical conditions. Today, there is a wide range of end devices with different software, as well as assistive devices and technologies, that support people with disabilities.

Background to the Legal Situation

The legal situation can be divided into three levels: the international, the European and the national level.

International Standard: WCAG 2.1

At the international level, the Web Content Accessibility Guidelines (WCAG 2.1) exist as a recommendation of the World Wide Web Consortium (W3C). They are now established as an international standard.

European Standard and EU Directives

At the European level, various EU directives set out the principles of digital accessibility. This is based on the European standard EN 301 549, which defines the accessibility requirements for information and communication technology products and services of public authorities. Directive EU 2016/2102 applies to public authorities and defines accessible usage for websites and mobile applications. In addition, Directive EU 2018/2048 contains the associated implementation decision and a template for the accessibility declaration for the digital offerings of public authorities.

National Layer: Example Germany

At the national level, country-specific laws define individual accessibility requirements for public authorities on the basis of the international standard.

In Germany, section 2a of the Federal Disability Equality Law (Bundes-Behindertengleichstellungsgesetz, BGG) requires public authorities to design their information technology offerings to be accessible. This includes websites and also PDF documents, regardless of their size or design. In Germany, technical details are regulated by the Federal Accessible Information Technology Directive (Barrierefreie-Informationstechnik-Verordnung des Bundes, BITV 2.0). The latest version of BITV 2.0 refers to the European standard EN 301 549, which came into effect at the end of 2016 as a result of EU Directive 2016/2102 on accessible access to public sector websites.

Outlook: Digital Accessibility in the Business Sector

The European Accessibility Act (EAA) is specified in EU Directive 2019/882 and is to be implemented in national law by June 28, 2022.  The aim here is to promote accessibility in online commerce. Among other things, this affects the accessible provisioning of banking and travel services, audiovisual offerings and e-books, as well as hardware such as laptops, tablets, smartphones, card readers, and parking meters.

Digital Accessibility as a Benefit for Society as a Whole

In Germany, almost 8 million people are living with a recognized severe disability. It is very challenging to statistically determine how many of these people are restricted in their digital participation. There are currently no representative figures available. A few small, qualitative surveys on individual forms of disability do exist, but these are not based on current figures.

The German Association for the Blind and Visually Impaired (Deutscher Blinden- und Sehbehindertenverband e.V., DBSV) states on its website: “Blind and visually impaired people are not counted in Germany. [...] The lack of numbers leads to the fact that in many areas responsible persons are dependent on assumptions, where they actually need planning security - as an example only the public hand is called. The DBSV demands therefore for many years empirically raised numerical material for the situation of the blind and visually impaired humans in Germany. This would be particularly important for the visually impaired sector, where the numbers of affected people seem to have been increasing dramatically for years (see WHO figures) [...]”.

Limitations can be on a visual, auditory, functional motor, or cognitive level. Examples include blindness, color vision deficiency, deafness, hearing loss, low literacy, or learning disabilities.

It's safe to say that everyone will benefit from digital accessibility at least once in their lives - temporary limitations can affect all of us. Be it tendinitis, forgotten headphones on the subway, working on a laptop on the balcony, or receiving information in a foreign language. A helpful formula could be: digital accessibility is essential for 10 percent of society, necessary for 30 percent and helpful for 100 percent.

Digital Accessibility in a Content Management System

A website is filled with content via a content management system (CMS). This is usually done via the backend. In the frontend, this content is then visible to the end users of the website.


Digital accessibility of the frontend of websites is elementarily important to ensure that the interested target group can receive the relevant information. Many technical efforts to remove barriers from websites focus primarily on accessible design of the frontend. However, the accessible design of the backend often takes a back seat.


This is precisely where universal design (an accessible design of digital living and working areas) must not stop. Professionals in this field, for example content managers, should be equally able to operate a CMS with congenital, age, environment or accident-related limitations and thus be able to do their job.

In the public sector, legislation stipulates that editors with disabilities should be given preference in job advertisements if they are equally qualified. For this purpose, the system to be used must be accessible and usable for them.

“People with disabilities still have a hard time on the job market.” As reported by the Federal Statistical Office (Statistisches Bundesamt, Destatis) on the occasion of German Diversity Day, “nearly 57 percent of people with disabilities between the ages of 15 and 64 were employed or looking for work.”

Integrating qualified and dedicated people with or without disabilities into the digital industry and filling positions there is more successful when information processing systems are designed to be accessible.

Criteria for the Accessible Handling of a CMS 

All users need textual representation of non-text elements for orientation, as well as a clearly structured and meaningful reading order, which can be experienced via the screen reader or the keyboard (tab key).

In order to enable intuitive and as accessible as possible editorial editing for all people, the Authoring Tool Accessibility Guidelines (ATAG) provide a technical reference. Authoring tools are software and applications that are used to create web content, which also includes CMSs. ATAG explains how the authoring tools themselves can be programmed and configured to be accessible and help editors to produce more accessible content.

Success criteria are formulated for this purpose. The user interface of the CMS needs to be designed in accordance with the applicable accessibility guidelines:

  • Accessible (for example, alternatives for images and videos)
  • Perceivable (for example, error messages or misspelled words in the editor window)
  • Operable (for example, keyboard operability, sufficient time, no flashing content that could trigger seizures) 
  • Understandable (help to prevent errors, documentation of all user interface accessibility features, and accessible templates)
  • Robust (Content must be robust enough that it can be interpreted by a wide variety of user agents, including assistive technologies.)

Furthermore, the ATAG contains specifications for automatically generated content. Information about the accessibility of the content should be preserved or warnings should exist, for example in case of copy paste or file conversion.

The TYPO3 Backend: Is Accessible Operation Possible?

Using two case studies, we will approach the question of whether the TYPO3 backend can be used without restrictions. For this purpose, we observed two blind people in the operation of the TYPO3 backend: Matthias Henke, an editor, and Dennis Westphal, a software tester focussing on accessibility. In both cases, the operation of the backend is reduced to a few frequently used editing steps. These serve as the basis for assessing accessibility. The tests were carried out in October and November 2021 in Berlin.

Case Study 1

About Matthias

Matthias Henke suddenly went blind at the age of 15. For the past five years, he has been working as an editor at the DRK Clinics Berlin and manages, updates and edits the DRK Clinics intranet. For example, he posts news and events, updates food plans, and publishes self-produced podcasts.

Matthias Henke works with the screen reader Jaws and the 80 Braille display. There are speaker boxes on his desk. He has the Jaws license for Google Chrome, Mozilla Firefox and Internet Explorer 11 browsers. He works with TYPO3 v11, and uses TYPO3 v9 and v10 for the DRK clinics. The test for this article was carried out on v11.5.1.

Test scenario

The editorial steps in the test are as follows:

  • Login
  • Create a page
  • Create, save, edit and delete a content element on the page
  • Display in the frontend

While operating the backend (German language is set), he finds it very easy to use well-known, trained, and tried-and-tested ways, for example, when creating and editing structured data sets such as news or events. Uploading and assigning files via the file list is also successful. 

In new or unknown scenarios, which are easier for people with sight without prior knowledge through exploration, Matthias Henke has to overcome obstacles. Examples are missing labels above the page tree or the untranslated English label for the global search. In some places it is possible to compensate for the lack of knowledge about accessible usability of the backend, for example to empirically work out the use of the arrows on the keyboard by trial and error. In others cases it is not.

Therefore, a complete execution of all the editing steps in the test was only possible with the help of the test moderators.


  1. For trained and experienced editors, the backend can be used by blind users.
  2. The backend in v11 is optimized for accessibility in many places, but the knowledge about this has to be passed on via training. A separate documentation section "Accessibility" in the TYPO3 Guide for Editors should be created as a supplement.
  3. Workarounds such as browser searches as well as JAWS searches and restarts (browser reloads) are part of his everyday editorial work.
  4. Guidance in the workflow should be offered.


Matthias Henke says about his usage experience of the TYPO3 backend: "I have a good feeling about the handling. There is more labeling in v11 than there was in V6. Events are easier to recreate, more direct editing is possible, and there are fewer tables and lists than in V6."

Conclusion: The digital accessibility of the TYPO3 backend has steadily improved over the years and with the latest versions.

Case Study 2

About Dennis

Dennis Westphal is a Software tester and blogger for accessibility on the internet. He uses assistive devices as a blind user and was available to perform a Usabilitally Test of the TYPO3 backend. Usabilitally is the product name of his service which is a blend of the English term usability with the numeronym for accessibility A11y or Ally.  The Usabilitally Test thus combines both disciplines. In his test, Dennis Westphal examines the login process as well as the editing of page content. In the NVDA speech viewer function of the screen reader NVDA, he has the speech output displayed in text.

Test Scenario

View the Recording

On the login page in TYPO3, Dennis Westphal enters his user name and password in the provided input fields. He deliberately adds a letter to the user name so that it is no longer correct. An error message appears saying: “Your login attempt did not succeed. Make sure to spell your username and password correctly, including upper/lowercase characters.” Unfortunately, this error message is only visible and is not audible from the screen reader. The cursor is placed back in the User name input field, but blind or visually impaired users will not get to the important information in the error message until they proactively navigate out of the input field using the up arrow key. Experienced users like Dennis can compensate for this circumstance. 

After a second successful login attempt, the system sets the focus and cursor directly on a search field. The following is read out: “Enter search term. Input field empty”. 

However, no label is assigned to this search field, so it is not clear in which context and which content can be searched for here.

Dennis Westphal's goal after logging in is to find the page tree so that he can move around the CMS, access specific pages and create a new page in the appropriate place. To do this, he uses the Tab key. In doing so, he stumbles on another search field that also does not have a label and thus does not clarify what can be searched here. This applies to both sighted and non-sighted users, since this is also a criterion of usability. There also is a button visible for sighted users, but for limited users it is not clear what this button does, because nothing is read out when the focus is set.

Having arrived at the page tree, Dennis Westphal can navigate through the pages, but it is unclear for blind or visually impaired persons whether these pages are already directly editable or only become editable after pressing the Enter key. There is no feedback from TYPO3, so the screen reader remains mute here.

Next, Dennis Westphal tries to create a new content element. The sentence “Create new content item” is hidden from screen reader users, it cannot be accessed and is therefore not read aloud. Instead, Dennis Westphal now tabs through a search window and several tabs before finally arriving at the content elements. For every content type there is a button with an icon and text. The icon is announced by the screen reader as a graphic, but it does not contain any relevant information.

After 17 clicks, Dennis Westphal arrives at the desired content element Text - A normal text element with heading and body text. Sighted users can grasp the bulleted list more easily here. The lack of consistency is worth mentioning: the content elements aren’t arranged alphabetically, nor do they follow a pattern that is comprehensible to end users, such as frequently used. The user-friendliness here has room for improvement for all users.

In the content element Create page content, Dennis Westphal can focus the input fields for heading, subheading and the rich text editor. However, the visible labels are not attached to the fields; the screen reader only reads out "input field" without naming the purpose and function.

Findings Test 2

What Dennis Westphal impressively illustrated with his Usabilitally-Test is similar to the user experience of Matthias Henke. Due to the missing announcement of context changes, actions and labels, prior knowledge by the user is assumed. It is therefore mandatory for vision-impaired users to learn (by heart), either through training, through colleagues or by trying out which field stands for which action. There is still potential here for improving the accessibility.

Based on the above-mentioned criteria for an accessible operation of a CMS, the following points are mentioned that result from the case studies Dennis Westphal (in parts also with Matthias Henke) and that offer possibilities for improvement in terms of accessibility for TYPO3:

  • Adding labels to form fields has a high impact on the level of accessibility and usability of any CMS.
  • All visible elements with relevant function should be able to be controlled with the keyboard, and be accessible.
  • Graphics that do not carry information should be hidden for assistive technologies.
  • Buttons that are composed of a graphic element (icon) as well as text, it serves the purpose of accessibility to focus on the button as a whole, instead of having two elements with individual focus and voice output “button graphic” and “button content”.
  • After search fields have been accessed, understood and operated, the search results should also need to be accessible by keyboard and  readable by a screen reader.
  • Any context change should also be interpretable for screen readers. When does a menu item open or close, did the action of a button finish, is a page editable, is the search completed and the result list loaded, etc.


Dennis Westphal says of his user experience: “Thanks to a brief introduction in advance, I knew roughly what to expect. If I had gone to the backend as a new user without this introduction, or if something fundamental had changed in the meantime, for example the order of the form fields, I would have been lost. I hope it becomes a standard to provide meaningful labels for all form fields and buttons, and they are tested on a regular basis.”

Overall Findings and Conclusions 

  1. TYPO3 is suited to be operated in the backend by editors with visual impairments due to a multitude of possibilities. Optimizations found are included in the optimization process of TYPO3 as a ticket.
  2. Prior training is necessary regardless of any impairments. Help with this should be provided by the TYPO3 Documentation for Editors.

How Can I Help to Achieve Even More Accessibility With TYPO3? 

Every third Friday of the month, the TYPO3 Accessibility Team meets at 2pm central European time in a video call via Slack, channel #accessibility. There is a technical exchange and questions can be addressed. You can contact the team in the #accessibility channel or via the e-mail address accessibility(at)typo3.org.

Join the Accessibility Team

Appendix: What About Accessibility in the Frontend?

Accessibility Score of the TYPO3 Frontend by Lighthouse Testing

The Web Almanac has published a review of various CMSs on its website using the open source technology Lighthouse from 2021. The accessibility score of pages with the CMS TYPO3 is 84 out of 100. For each test step, only fulfilled or not fulfilled was evaluated, i.e. no gradual evaluation took place. As soon as an element on the page has not been consistently implemented in an accessible manner and thus violates a test criterion, the entire test step has been considered as not fulfilled.

Conclusion: TYPO3 and Accessibility in the Frontend

It is also important to note, that the accessibility of the TYPO3 frontend is in a large part dependent on the template created by the developers, as TYPO3 does not come with a complete default frontend rendering template. An accessible website (the part visible to visitors) is supported by TYPO3, but was not the focus of the backend tests. Quality and assurance are the responsibility of the website's service provider, not the content management system.

If you want to have an accessible TYPO3 website, make sure the agency you plan to work with supports creating accessible sites.

On the BIK BITV website, there is also a list of websites successfully tested as accessible according to the BIK BITV.

About the Author

Alexa Kreßmann, Accessibility Consultant: Since October 2021, I have been working at coding. powerful. systems (CPS GmbH) in the accessibility team.  I advise internally and externally on digital accessibility, test websites for BITV/WCAG and provide training. At CPS, we work together in interdisciplinary teams, and our goal is to enable digital participation for all people in the spirit of integrated communication.

Additional contributors for this article
  • Translator : Claudia Nölker
  • Proofreader : Felicity Brand
  • Reviewer : sebastian-kreideweiss
  • Content Publisher : Mathias Bolt Lesniak