What is an accessible CMS?
Clement Egger
An accessible CMS is a content management system designed to be usable by people with disabilities, including those using screen readers or keyboard-only navigation. It ensures that all content creation, editing, and publishing features comply with accessibility standards such as WCAG. This allows inclusive contributions from all users, not just accessible output.
Problem: most web accessibility compliance strategies focus on the accessibility of websites and applications, not so much on the tools themselves. Yet providing contributors with an accessible CMS is also one of the issues that these web accessibility strategies should address.
"The idea of digital accessibility is to take everyone into account. So it already means having a public site that complies with accessibility standards. But internally too, all our tools are supposed to be accessible. If one of our employees is blind, in theory he or she should be able to use and participate in all the actions he or she can do with a computer. So normally, Jahia's contribution should also be accessible, should meet accessibility standards."
Julie BARATCHART, Software Architect - Digital Accessibility Coordinator at UCANSS
Definition of an accessible CMS
An accessible content management system (CMS) is a platform that enables all users, including those with disabilities, to create, manage and consult web content without encountering obstacles. This implies that the CMS complies with accessibility standards such as the WCAG (Web Content Accessibility Guidelines) and the ATAG (Authoring Tool Accessibility Guidelines), thus guaranteeing an inclusive user experience.
The accessibility of a CMS is therefore assessed on 2 aspects:
- the accessibility of the tool (Part A of the ATAGs): navigation, editing, interface compatible with assistive tools. So the ability of all contributors, including people with disabilities, to use the CMS,
- assistance with the creation of accessible content (Part B of the ATAGs): checks, templates and input alerts. So the ability of the CMS to support editorial teams in the creation and management of accessible web content.
Main limits to CMS accessibility
Despite advances, several challenges remain:
- Non-accessible themes and extensions: The use of third-party themes or plugins can introduce barriers to accessibility.
- Complexity of interfaces: Some administration interfaces are difficult to use with assistive technologies, whether for technical reasons (missing or incorrect markup) or clarity of navigation.
- Lack of training: Content creators may not be trained in good accessibility practices.
- Insufficient validation checks: Lack of tools to automatically detect accessibility issues.
Many popular CMS have shortcomings when it comes to accessibility, particularly when it comes to keyboard navigation and compatibility with screen readers. While WordPress or Joomla are sometimes singled out for criticism on this point, the reality is that the CMS sector more broadly suffers from a significant deficit on the issue of digital accessibility.
ATAG: web accessibility rules dedicated to CMS
ATAG are accessibility rules for content editing tools, defined to help software publishers make their solutions more inclusive. This standard is structured in 2 parts: accessibility of content editing tools (A), and functionalities for making content accessible by editors (B). As some of these rules apply to non-web tools, we will concentrate here on the rules that apply more specifically to CMS.
| Part | Description |
|---|---|
| Part A | User interfaces for authoring tools comply with applicable accessibility guidelines |
| Fully automatic processes produce accessible content | |
| Editing views are perceptible | |
| Part B | Authors are helped to produce accessible content |
| Editing views are usable | |
| Authors are helped to improve the accessibility of existing content | |
| Editing views are comprehensible | |
| Editing tools promote and integrate accessibility features |
It would take too long to detail all the ATAG rules that determine whether a CMS is accessible or not, however here's an overview. To go further, you can consult the page dedicated to ATAGs on the W3C site.
Accessibility of content editing tools (part A)
This part of the ATAGs describes the "few" rules for designing an accessible CMS. We've selected and summarized the 7 main ones here.
This part of the ATAGs describes the "few" rules for designing an accessible CMS. We've selected and summarized the 7 main ones here.
| Principle | Requirement | Example / Concrete application |
|---|---|---|
| WCAG* compliance | The CMS interface must comply with WCAG (compatibility with screen readers, logical navigation, etc.). | Contrast, accessible navigation, clear visual feedback |
| Perceptibility | All elements must be perceptible to contributors, including non-textual content. | Alternative titles on icons and images in the interface |
| Understanding views | Views must reflect implicit information (status, errors, formats). | Underlining of errors, publication status icons, etc. |
| Keyboard navigation and editing | All elements must be accessible using the keyboard only | Drag-and-drop via shortcuts, navigation without keyboard traps, activatable shortcuts |
| Search in the editor | The search must be complete, ergonomic and accessibility-compatible | Inclusion of alternative text, highlighting, navigation between results |
| User preferences | Visual preferences must be independent of content rendering | Font, contrast, size customizable on the contributor's side |
| Documentation | The entire interface, including accessibility options, must be documented | Clear, accessible, readily available documentation |
*Details of WCAG rules in next part: RGAA and WCAG accessibility rules applied to CMS
Help with producing accessible content (Part B)
The part dedicated to the accessibility of CMS themselves is the most complex for software publishers to implement, and the one on which they are least compliant overall. On the other hand, in this 2nd area, certain CMS, including Jahia, offer functionalities that are beginning to approach compliance.
| Objective | Expected function | Example / Behavior |
|---|---|---|
| Automatic compliance | All automatically generated content must be compliant or editable | Alternative text generated on import, with the option of correcting it Tags editable in WYSIWYG editor |
| Preservation of accessibility data | When updated or duplicated, accessibility attributes must persist | The alt of an image remains present after replacement |
| Controlling published content | Avoid accessibility errors in final content | Restrictions or alerts if essential fields are empty |
| Contextual help | Author needs guidance when creating content | Warnings if no ARIA tag, HTML structuring help |
| Accessible templates | Providing compliant structures and components by default | Correct tags in templates, inclusive components |
| Detection and correction | Verification + ability to correct directly | Editor-integrated checker + suggested corrections |
| Workflow integration | Accessibility must be an integral part of the contribution experience | Function enabled by default, warning if disabled, fluid UX |
https://www.w3.org/TR/IMPLEMENTING-ATAG20/
RGAA and WCAG accessibility rules applied to CMS
The CMS accessibility rules defined in the ATAGs are therefore largely based on the more general rules of digital accessibility, defined in the WCAG (Web Content Accessibility Guidelines), the international standards established by the W3C.
The RGAA (Référentiel Général d'Amélioration de l'Accessibilité) is the French regulatory framework that defines the technical modalities for making digital services accessible to all, including people with disabilities. It is based directly on the WCAG, but goes a little further, and is therefore interesting to consider from a CMS accessibility perspective.
The RGAA comprises 106 digital accessibility criteria, divided into 13 themes. While not all 106 criteria apply to the uses of a CMS, a large proportion of them are nonetheless valid. Here are the main elements you should find in a 100% accessible CMS:
- Images and Multimedia: An accessible CMS must enable a user with a sensory disability to read the alternative text of an image or other media, and to obtain information about its format in the digital asset management (DAM) interface.
- Colors: Contrast in the CMS interface must be sufficient (contrast ratio of 4.5:1, at least), and information must not be conveyed through color alone. For example, information that a page is published should not simply pass through a green dot.
- Tables: Data tables in the CMS (user lists with their roles and permissions, for example) must be correctly tagged (<th>, <td>, <caption>...) and have the right WAI-ARIA attributes (aria-label, columnheader, rowheader...).
- Mandatory elements: Each page of the CMS interface must integrate certain elements essential to the proper operation of support tools (doctype tag, <title> tag, lang attribute).
- Information structuring: CMS interfaces must include structured titles and lists.
- Presentation of information: Information contained in the CMS must persist when style sheets are deactivated, text must remain legible, and functionality accessible, when font size is increased by up to 200%, and text spacing properties must be able to be redefined by the user without loss of content or functionality.
- Forms: Each contribution form field (content edit boxes) must include a label (WAI-ARIA aria-label attribute for example), or even be accompanied by contextual help specifying contribution expectations.
- Navigation: Navigation within the CMS interface must be able to be carried out in multiple ways to adapt to potential user disorders. For example, the CMS must include at least 2 navigation systems (navigation menu, "site" map, search engine), offer a coherent navigation order marked by a selection focus, keyboard shortcuts, or additional content (tooltips, for example) accessible via the keyboard.
- Consultation: CMS documentation must be accessible, it must be usable on screen in both portrait and landscape mode, offer alternatives to complex gestures (not just drag&drop to move an element, for example).
How to make your CMS accessible: 7 actionable steps
Even if no CMS is 100% accessible by default, several steps can help your teams move closer to full accessibility compliance, for both the interface and the content creation experience.
- Choose a CMS with WCAG and ATAG support
Select a solution that already follows accessibility standards (screen reader compatibility, keyboard navigation, correct roles/tags, etc.). - Use accessible templates and UI components
Avoid third-party plugins or themes that introduce visual or semantic accessibility issues. Rely on certified, inclusive design libraries. - Enable real-time accessibility checks
Make sure your CMS integrates automated validators that highlight missing alt texts, misused heading levels, or ARIA errors during content editing. - Support authors with contextual help
Use tooltips, field-level instructions, or inline alerts to encourage good practices (e.g., use of accessible titles, form markup reminders). - Ensure accessibility metadata persists
When duplicating or editing content, verify that attributes likealt,aria-labelorlangtags remain intact. - Train your editorial team
Provide accessibility training sessions to your content contributors. Many issues stem from a lack of awareness, not malice. - Publish an accessibility statement for your CMS
Even if your system isn't perfect, communicate your accessibility efforts transparently and encourage feedback from users.
To go further, discover our full guide: How to Make a Website Accessible