How to use an ac­cess­ible CMS (Contao, Plone, and papaya)

Since the EU Ac­cess­ib­il­ity Act came into effect, creating ac­cess­ible 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­per­i­ence and optimise content for search engines.

Why should a CMS enable ac­cess­ible content?

Digital ac­cess­ib­il­ity affects not only a website’s technical in­fra­struc­ture, but also the content it publishes. To ensure that digital in­form­a­tion is ac­cess­ible to all visitors, content must be designed so it can be used with screen readers, Braille displays or by keyboard-only nav­ig­a­tion.

The content man­age­ment system (CMS) you choose plays a central role. While the ac­cess­ib­il­ity of the CMS interface itself is important, it’s equally important to consider how well the CMS supports editors in creating ac­cess­ible content. A CMS is con­sidered ‘ac­cess­ible’ in this context if it provides guidance, struc­tur­al guidelines and val­id­a­tion tools that make it easy to produce ac­cess­ible websites. Typical examples include:

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

An ac­cess­ible CMS reduces the risk of editorial errors, supports com­pli­ance with legal re­quire­ments and ensures equal access to in­form­a­tion for all users.

What guidelines define web ac­cess­ib­il­ity?

The re­quire­ments for ac­cess­ible content in the EU are defined by several legal and technical standards. Under the EU Ac­cess­ib­il­ity Act, many busi­nesses – including UK companies offering goods or services in the EU – must ensure that their websites and digital products meet ac­cess­ib­il­ity re­quire­ments.

These reg­u­la­tions are based on the in­ter­na­tion­al Web Content Ac­cess­ib­il­ity Guidelines (WCAG), developed by the World Wide Web Con­sor­ti­um (W3C). WCAG 2.1 and 2.2 outline four key prin­ciples for ac­cess­ib­il­ity in relation to a CMS and beyond:

• Per­ceiv­ab­il­ity: In­form­a­tion needs to be presented so every user can un­der­stand it, such as through text al­tern­at­ives for images and adequate contrast.
• Op­er­ab­il­ity: The interface needs to be useable with various input methods, such as a keyboard.
• Un­der­stand­ab­il­ity: 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­no­lo­gies.

For editors, this means using a logical heading hierarchy (H1 to H6), adding de­script­ive al­tern­at­ive texts and link texts, writing in clear language and main­tain­ing a logical nav­ig­a­tion structure. A CMS that supports these re­quire­ments not only makes creating content sig­ni­fic­antly easier but also ensures the content fully complies with legal standards.

Which CMSs are well regarded for ac­cess­ib­il­ity?

Not all CMS platforms are equally suited to producing ac­cess­ible 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­larly well regarded for ac­cess­ib­il­ity. Below is an overview of their key features:

Contao

Contao is a CMS designed for ac­cess­ible and se­mantic­ally clean code from the outset. It offers:

• Ac­cess­ible templates: Many themes are WCAG and BITV compliant and designed to be fully re­spons­ive.
• 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­tern­at­ives.
• Form modules: Built-in modules support required field markings, keyboard nav­ig­a­tion and error handling.

Ex­ten­sions such as Site­Cock­pit add features like colour contrast controls, font size ad­just­ments and ac­cess­ib­il­ity reporting directly in the CMS. This makes Contao a solid option for public in­sti­tu­tions, edu­ca­tion­al fa­cil­it­ies or NGOs.

Plone

Plone is a Python-based CMS that has met high ac­cess­ib­il­ity standards for years. Used worldwide by uni­ver­sit­ies, gov­ern­ment agencies and or­gan­isa­tions with strict ac­cess­ib­il­ity needs. Plone meets WCAG 2.1 at com­pli­ance level AA, meaning many ac­cess­ib­il­ity aspects are already in­teg­rated as standard. A VPAT document (Voluntary Product Ac­cess­ib­il­ity 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­lic­a­tion.
• Access control: Enables ac­cess­ible teamwork with defined roles.

Plugins like the Plone All in One Ac­cess­ib­il­ity Widget add options for font sizes, contrast settings and keyboard nav­ig­a­tion. This makes Plone ideal for complex, ac­cess­ib­il­ity-focused portals.

papaya CMS

papaya CMS is a modular, XML-based CMS known for its clear sep­ar­a­tion of content, layout and logic. This structure supports fine-grained control over se­mantic­ally correct and ac­cess­ible 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­no­lo­gies to interpret.
• Ac­cess­ib­il­ity-focused templates and modules: Includes layouts and com­pon­ents built according to WCAG guidelines, reducing the need for extensive custom coding.
• Mul­ti­lin­gual content man­age­ment: Organises and delivers content in multiple languages while main­tain­ing ac­cess­ib­il­ity features such as con­sist­ent nav­ig­a­tion and ac­cur­ately trans­lated al­tern­at­ive text. papaya CMS has been used for award-winning ac­cess­ible projects, but ac­cess­ib­il­ity depends heavily on developer expertise and template design rather than prebuilt EU Ac­cess­ib­il­ity Act com­pli­ance plugins.

How do you check if content in the CMS is ac­cess­ible?

Creating ac­cess­ible content doesn’t end with entering it into the CMS. Ongoing mon­it­or­ing is essential to identify and resolve barriers early. To test the ac­cess­ib­il­ity of a website, it’s a good idea to use a com­bin­a­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­cess­ib­il­ity Eval­u­ation Tool): High­lights ac­cess­ib­il­ity barriers directly in the browser – ideal for a quick editorial review of content such as al­tern­at­ive text and heading struc­tures.
• Google Light­house: Generates ac­cess­ib­il­ity scores and provides specific re­com­mend­a­tions on structure, colours, 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­teg­ra­tions for DevOps en­vir­on­ments.

Manual tests

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

• Keyboard nav­ig­a­tion: Ensure full nav­ig­a­tion and page usage via Tab/Shift with visible focus in­dic­at­ors.
• Screen reader tests: Use NVDA (Windows), VoiceOver (macOS/iOS) or JAWS to verify semantic accuracy, focus order and reading sequence.
• Contrast & colour sim­u­la­tion: Tools like WebAIM Contrast Checker or Color Oracle help test colour contrast and simulate visual impair­ments.
• Form testing: Check label as­so­ci­ations, error messaging, focus behaviour and form field ac­cess­ib­il­ity.
• Visual and zoom review: Ensure the layout works at high zoom levels and that ho­ri­zont­al scroll­bars appear when needed. What’s more, main­tain­ing an internal ac­cess­ib­il­ity guide and providing regular training sessions will strengthen your team’s skills in the long term.