How to use an accessible CMS (Contao, Plone, and papaya)

Since the EU Accessibility Act took effect, creating accessible websites with a CMS is no longer optional — it’s essential. If a content management system is equipped with the right features, you can meet EU legal requirements, improve user experience and optimize content for search engines.

Why should a CMS enable accessible content?

Digital accessibility affects not only a website’s technical infrastructure, but also the content it publishes. To ensure that digital information is accessible to all visitors, content must be designed so it can be used with screen readers, Braille displays or by keyboard navigation.

The content management system (CMS) you choose plays a central role. While the accessibility of the CMS interface itself is important, it’s equally important to consider how well the CMS supports editors in creating accessible content. A CMS is considered “accessible” in this context if it provides guidance, structural guidelines and validation tools that make it easy to produce accessible websites. Typical examples include:

• Input fields for alt text on images
• Alerts for missing heading structure
• Tools for creating accessible tables and forms
• Automatic checks for contrast or semantic errors

An accessible CMS reduces the risk of editorial errors, supports compliance with legal requirements and ensures equal access to information for all users.

What guidelines define web accessibility?

The requirements for accessible content in the EU are defined by several legal and technical standards. Under the EU Accessibility Act, many businesses — including US companies offering goods or services in the EU — must ensure that their websites and digital products meet accessibility requirements.

These regulations are based on the international Web Content Accessibility Guidelines (WCAG), developed by the World Wide Web Consortium (W3C). WCAG 2.1 and 2.2 outline four key principles for accessibility in relatio to a CMS and beyond:

• Perceivability: Information needs to be presented so every user can understand it, such as through text alternatives for images and adequate contrast.
• Operability: The interface needs to be useable with various input methods, such as a keyboard.
• Understandability: Content should be clearly structured, easy to read and written in plain language.
• Robustness: Content needs to work reliably with a wide range of devices and assistive technologies.

For editors, this means using a logical heading hierarchy (H1 to H6), adding descriptive alternative texts and link texts, writing in clear language and maintaining a logical navigation structure. A CMS that supports these requirements not only makes creating content significantly easier but also ensures the content fully complies with legal standards.

Which CMSs are well regarded for accessibility?

Not all CMS platforms are equally suited to producing accessible content. Some excel in frontend output, while others focus on editorial control or semantic precision. Among open-source CMSs, Contao, Plone and papaya CMS are particularly well regarded for accessibility. Below is an overview of their key features:

Contao

Contao is a CMS designed for accessible and semantically clean code from the outset. It offers:

• Accessible templates: Many themes are WCAG and BITV compliant and designed to be fully responsive.
• Structured content elements: Editors work with modules that ensure clear, semantic output.
• Alt text support: Images, videos and other media can easily be given text alternatives.
• Form modules: Built-in modules support required field markings, keyboard navigation and error handling.

Extensions such as SiteCockpit add features like color contrast controls, font size adjustments and accessibility reporting directly in the CMS. This makes Contao a solid option for public institutions, educational facilities or NGOs.

Plone

Plone is a Python-based CMS that has met high accessibility standards for years. Used worldwide by universities, government agencies and organizations with strict accessibility needs. Plone meets WCAG 2.1 at compliance level AA, meaning many accessibility aspects are already integrated as standard. A VPAT document (Voluntary Product Accessibility Template) is available for these requirements.

Editorial benefits of this CMS include:

• Semantic structure: The content structure strictly adheres to HTML5 standards.
• Workflow management: Content can be checked for compliance before publication.
• Access control: Enables accessible teamwork with defined roles.

Plugins like the Plone All in One Accessibility Widget add options for font sizes, contrast settings and keyboard navigation. This makes Plone ideal for complex, accessibility-focused portals.

papaya CMS

papaya CMS is a modular, XML-based CMS known for its clear separation of content, layout and logic. This structure supports fine-grained control over semantically correct and accessible HTML outputs, making it suitable for complex projects with high editorial demands.

• Strict content structuring: Separates content, layout, and logic so that the HTML output follows correct semantic standards, making it easier for assistive technologies to interpret.
• Accessibility-focused templates and modules: Includes layouts and components built according to WCAG guidelines, reducing the need for extensive custom coding.
• Multilingual content management: Organizes and delivers content in multiple languages while maintaining accessibility features such as consistent navigation and properly translated alternative text. papaya CMS has been used for award-winning accessible projects, but accessibility depends heavily on developer expertise and template design rather than prebuilt EU Accessibility Act compliance plugins.

How do you check if content in the CMS is accessible?

Creating accessible content doesn’t end with entering it into the CMS. Ongoing monitoring is essential to identify and resolve barriers early. To test the accessibility of a website, it’s a good idea to use a combination of automated tools and manual testing.

Automated tools

• axe DevTools: A browser add-on that detects WCAG-related errors and provides detailed guidance for fixes.
• WAVE (Web Accessibility Evaluation Tool): Highlights accessibility barriers directly in the browser — ideal for a quick editorial review of content such as alternative text and heading structures.
• Google Lighthouse: Generates accessibility scores and provides specific recommendations on structure, colors, usability and more. It can also be run as part of Google PageSpeed Insights in Chrome DevTools, via the command line or as a Node module.
• Evinced: Uses AI and machine learning to detect complex barriers. It also provides detailed developer reports and integrations for DevOps environments.

Manual tests

Automated scans won’t catch every issue. This means that manual checks should include:

• Keyboard navigation: Ensure full navigation and page usage via Tab/Shift with visible focus indicators.
• Screen reader tests: Use NVDA (Windows), VoiceOver (macOS/iOS) or JAWS to verify semantic accuracy, focus order and reading sequence.
• Contrast & color simulation: Tools like WebAIM Contrast Checker or Color Oracle help test color contrast and simulate visual impairments.
• Form testing: Check label associations, error messaging, focus behavior and input field accessibility.
• Visual and zoom review: Ensure the layout works at high zoom levels and that horizontal scrollbars appear when needed. What’s more, maintaining an internal accessibility guide and providing regular training sessions will strengthen your team’s skills over the long term.