How to use an ac­ces­si­ble CMS (Contao, Plone, and papaya)

Since the EU Ac­ces­si­bil­i­ty Act took effect, creating ac­ces­si­ble websites with a CMS is no longer optional — it’s essential. If a content man­age­ment system is equipped with the right features, you can meet EU legal re­quire­ments, improve user ex­pe­ri­ence and optimize content for search engines.

Why should a CMS enable ac­ces­si­ble content?

Digital ac­ces­si­bil­i­ty affects not only a website’s technical in­fra­struc­ture, but also the content it publishes. To ensure that digital in­for­ma­tion is ac­ces­si­ble to all visitors, content must be designed so it can be used with screen readers, Braille displays or by keyboard nav­i­ga­tion.

The content man­age­ment system (CMS) you choose plays a central role. While the ac­ces­si­bil­i­ty of the CMS interface itself is important, it’s equally important to consider how well the CMS supports editors in creating ac­ces­si­ble content. A CMS is con­sid­ered “ac­ces­si­ble” in this context if it provides guidance, struc­tur­al guide­lines and val­i­da­tion tools that make it easy to produce ac­ces­si­ble websites. Typical examples include:

• Input fields for alt text on images
• Alerts for missing heading structure
• Tools for creating ac­ces­si­ble tables and forms
• Automatic checks for contrast or semantic errors

An ac­ces­si­ble CMS reduces the risk of editorial errors, supports com­pli­ance with legal re­quire­ments and ensures equal access to in­for­ma­tion for all users.

What guide­lines define web ac­ces­si­bil­i­ty?

The re­quire­ments for ac­ces­si­ble content in the EU are defined by several legal and technical standards. Under the EU Ac­ces­si­bil­i­ty Act, many busi­ness­es — including US companies offering goods or services in the EU — must ensure that their websites and digital products meet ac­ces­si­bil­i­ty re­quire­ments.

These reg­u­la­tions are based on the in­ter­na­tion­al Web Content Ac­ces­si­bil­i­ty Guide­lines (WCAG), developed by the World Wide Web Con­sor­tium (W3C). WCAG 2.1 and 2.2 outline four key prin­ci­ples for ac­ces­si­bil­i­ty in relatio to a CMS and beyond:

• Per­ceiv­abil­i­ty: In­for­ma­tion needs to be presented so every user can un­der­stand it, such as through text al­ter­na­tives for images and adequate contrast.
• Op­er­abil­i­ty: The interface needs to be useable with various input methods, such as a keyboard.
• Un­der­stand­abil­i­ty: Content should be clearly struc­tured, easy to read and written in plain language.
• Ro­bust­ness: Content needs to work reliably with a wide range of devices and assistive tech­nolo­gies.

For editors, this means using a logical heading hierarchy (H1 to H6), adding de­scrip­tive al­ter­na­tive texts and link texts, writing in clear language and main­tain­ing a logical nav­i­ga­tion structure. A CMS that supports these re­quire­ments not only makes creating content sig­nif­i­cant­ly easier but also ensures the content fully complies with legal standards.

Which CMSs are well regarded for ac­ces­si­bil­i­ty?

Not all CMS platforms are equally suited to producing ac­ces­si­ble 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 par­tic­u­lar­ly well regarded for ac­ces­si­bil­i­ty. Below is an overview of their key features:

Contao

Contao is a CMS designed for ac­ces­si­ble and se­man­ti­cal­ly clean code from the outset. It offers:

• Ac­ces­si­ble templates: Many themes are WCAG and BITV compliant and designed to be fully re­spon­sive.
• Struc­tured content elements: Editors work with modules that ensure clear, semantic output.
• Alt text support: Images, videos and other media can easily be given text al­ter­na­tives.
• Form modules: Built-in modules support required field markings, keyboard nav­i­ga­tion and error handling.

Ex­ten­sions such as Site­Cock­pit add features like color contrast controls, font size ad­just­ments and ac­ces­si­bil­i­ty reporting directly in the CMS. This makes Contao a solid option for public in­sti­tu­tions, ed­u­ca­tion­al fa­cil­i­ties or NGOs.

Plone

Plone is a Python-based CMS that has met high ac­ces­si­bil­i­ty standards for years. Used worldwide by uni­ver­si­ties, gov­ern­ment agencies and or­ga­ni­za­tions with strict ac­ces­si­bil­i­ty needs. Plone meets WCAG 2.1 at com­pli­ance level AA, meaning many ac­ces­si­bil­i­ty aspects are already in­te­grat­ed as standard. A VPAT document (Voluntary Product Ac­ces­si­bil­i­ty Template) is available for these re­quire­ments.

Editorial benefits of this CMS include:

• Semantic structure: The content structure strictly adheres to HTML5 standards.
• Workflow man­age­ment: Content can be checked for com­pli­ance before pub­li­ca­tion.
• Access control: Enables ac­ces­si­ble teamwork with defined roles.

Plugins like the Plone All in One Ac­ces­si­bil­i­ty Widget add options for font sizes, contrast settings and keyboard nav­i­ga­tion. This makes Plone ideal for complex, ac­ces­si­bil­i­ty-focused portals.

papaya CMS

papaya CMS is a modular, XML-based CMS known for its clear sep­a­ra­tion of content, layout and logic. This structure supports fine-grained control over se­man­ti­cal­ly correct and ac­ces­si­ble HTML outputs, making it suitable for complex projects with high editorial demands.

• Strict content struc­tur­ing: Separates content, layout, and logic so that the HTML output follows correct semantic standards, making it easier for assistive tech­nolo­gies to interpret.
• Ac­ces­si­bil­i­ty-focused templates and modules: Includes layouts and com­po­nents built according to WCAG guide­lines, reducing the need for extensive custom coding.
• Mul­ti­lin­gual content man­age­ment: Organizes and delivers content in multiple languages while main­tain­ing ac­ces­si­bil­i­ty features such as con­sis­tent nav­i­ga­tion and properly trans­lat­ed al­ter­na­tive text. papaya CMS has been used for award-winning ac­ces­si­ble projects, but ac­ces­si­bil­i­ty depends heavily on developer expertise and template design rather than prebuilt EU Ac­ces­si­bil­i­ty Act com­pli­ance plugins.

How do you check if content in the CMS is ac­ces­si­ble?

Creating ac­ces­si­ble content doesn’t end with entering it into the CMS. Ongoing mon­i­tor­ing is essential to identify and resolve barriers early. To test the ac­ces­si­bil­i­ty of a website, it’s a good idea to use a com­bi­na­tion 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 Ac­ces­si­bil­i­ty Eval­u­a­tion Tool): High­lights ac­ces­si­bil­i­ty barriers directly in the browser — ideal for a quick editorial review of content such as al­ter­na­tive text and heading struc­tures.
• Google Light­house: Generates ac­ces­si­bil­i­ty scores and provides specific rec­om­men­da­tions 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 in­te­gra­tions for DevOps en­vi­ron­ments.

Manual tests

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

• Keyboard nav­i­ga­tion: Ensure full nav­i­ga­tion and page usage via Tab/Shift with visible focus in­di­ca­tors.
• Screen reader tests: Use NVDA (Windows), VoiceOver (macOS/iOS) or JAWS to verify semantic accuracy, focus order and reading sequence.
• Contrast & color sim­u­la­tion: Tools like WebAIM Contrast Checker or Color Oracle help test color contrast and simulate visual im­pair­ments.
• Form testing: Check label as­so­ci­a­tions, error messaging, focus behavior and input field ac­ces­si­bil­i­ty.
• Visual and zoom review: Ensure the layout works at high zoom levels and that hor­i­zon­tal scroll­bars appear when needed. What’s more, main­tain­ing an internal ac­ces­si­bil­i­ty guide and providing regular training sessions will strength­en your team’s skills over the long term.