Concrete CMS Accessibility Checklist 2026 | WCAG 2.1 AA & EAA
Last updated: 2026-05-26
Concrete CMS (the open-source PHP platform formerly known as concrete5) is built around in-context editing: editors click directly on a published page to add and arrange blocks inside areas that the theme defines. That model is friendlier to non-technical staff than a separate dashboard, but it also means the accessibility of a Concrete site is decided in three places at once - the blocks editors drop in, the theme that wraps them, and any add-ons installed from the marketplace. The version 9 default theme, Atomik, was rebuilt on Bootstrap 5 with accessibility in mind, so a fresh install starts in a much better place than older Elemental-themed sites; but the moment you switch to a purchased theme, install community add-ons, or let editors paste formatted content into the Content block, those gains can evaporate. The recurring problems are predictable. The Content block uses a rich text editor (Redactor in v9), and editors routinely pick heading levels by how big the text looks, skipping levels or stacking multiple H1s, which breaks the document outline screen reader users rely on. The Image block has an alt text field, but it is optional, so informative images ship with empty alt. The Image Slider and Gallery blocks add carousels and lightboxes whose keyboard and screen reader support depends entirely on the theme and version. The Auto-Nav block generates navigation from the page tree, and its dropdown behaviour, landmarks, and skip link depend on how the theme renders it. The built-in Form block can emit fields without persistent labels or properly associated error messages. This checklist walks through each of those surfaces so a Concrete CMS site can pass a WCAG 2.1 AA, EN 301 549, or EAA audit.
Common Accessibility Issues
The Content block's rich text editor (Redactor in Concrete CMS 9) lets editors apply heading styles from a dropdown, and most pick a level because it looks the right size rather than because it fits the page outline. The result is pages that skip from H1 to H4, stack several H1s when multiple Content blocks each open with one, or use bold paragraphs that look like headings but carry no heading semantics. Screen reader users who navigate by heading then get a broken or missing outline.
Establish one H1 per page (usually the page title rendered by the theme) and have editors use H2 and H3 in order inside Content blocks, never choosing a level for its size. Style headings with the theme's CSS so the correct level can still look right. Briefly train editors to read the document outline, and review key templates with a headings-list tool (the HeadingsMap extension or a screen reader's headings list) before launch.
Concrete's Image block and the File Manager both expose an alternate text field, but it is optional, so editors frequently leave it blank and informative images reach screen reader users as nothing or as a filename. The Image Slider (Gallery) block compounds this: each slide needs its own alt text, and decorative slide images that are not marked decorative add noise.
Fill the alt text field on every informative image - describe what the image communicates, not 'image of'. Set alt text on each slide in the Image Slider block, and leave alt empty only for genuinely decorative images so they are correctly hidden. Set a team rule that no image is published without an alt decision, and spot-check the File Manager for assets missing descriptions.
The Image Slider block and many marketplace gallery/lightbox add-ons render carousels and modal viewers whose controls are reachable only with a mouse, auto-advance without a pause control, and expose slide changes to no one using a screen reader. Keyboard users cannot reach next/previous controls or close the lightbox, and auto-rotation can move content out from under people who need more time.
Prefer a slider configuration (or add-on) that provides keyboard-operable previous/next buttons, a visible pause/stop control for any auto-advancing carousel, and focus management for lightboxes (focus moves in, Escape closes, focus returns). If the bundled slider cannot do this, replace the carousel with a static grid of images or a simpler accessible gallery. Test the whole interaction with the keyboard only and with a screen reader before relying on it.
The Auto-Nav block builds navigation from the page hierarchy, but how it renders - whether inside a nav landmark, whether there is a skip-to-content link, and whether dropdown submenus open and close with the keyboard - is controlled by the theme. Purchased and older themes often output hover-only dropdowns with no aria-expanded state and no skip link, leaving keyboard and screen reader users unable to use the menu reliably.
Confirm the theme wraps primary navigation in a <nav> landmark, adds a skip-to-content link as the first focusable element, and renders submenus as keyboard-operable disclosures (Enter/Space to open, Escape to close, aria-expanded reflecting state). The Atomik theme handles much of this; for custom or marketplace themes, fix the navigation template so the markup is a real list of links with proper landmarks and keyboard behaviour.
The built-in Form block (and several marketplace form add-ons) can be configured with placeholder-style prompts instead of persistent labels, and validation errors are often shown as a generic message at the top of the form rather than tied to the field that failed. Placeholders disappear on focus and are not reliable labels, and an unassociated error message cannot be navigated to or announced in context.
Give every form field a persistent visible label, not just a placeholder. Mark required fields clearly (in text, not colour alone) and associate each error with its field using aria-describedby and aria-invalid. Provide an error summary that receives focus or is announced via a live region on failed submission. Verify the rendered form markup rather than trusting the block's default output.
Concrete CMS's strength is its marketplace of themes and add-ons, but quality varies widely. A purchased theme may use poor colour contrast or non-semantic markup, and a custom block or slider add-on may ship div-based controls with no roles, states, or keyboard support. Because these components are reused across the whole site, one inaccessible add-on becomes a site-wide barrier.
Evaluate themes and add-ons for accessibility before buying: check colour contrast, run axe DevTools on the demo, and Tab through any interactive components. Favour the maintained Atomik theme and well-supported add-ons, keep them updated, and re-audit after installing anything that renders front-end markup. Treat third-party components as code you are responsible for, not a black box.
Concrete CMS-Specific Tips
- Start from the version 9 Atomik theme where you can - it was rebuilt on Bootstrap 5 with accessibility in mind and handles landmarks, navigation, and skip links far better than older Elemental-based sites.
- The Content block is where editors create most accessibility problems: train them to choose heading levels by structure (one H1, then H2/H3 in order) rather than by visual size, and style headings with CSS so the right level still looks right.
- Make alt text non-negotiable. The Image block and File Manager both expose an alt field but never require it, so set a publishing rule and spot-check the File Manager for assets shipped without descriptions.
- Be cautious with the Image Slider and any marketplace gallery/lightbox add-ons - test keyboard operation, a pause control for auto-advance, and lightbox focus management before relying on them, or replace the carousel with a static grid.
- Audit purchased themes and add-ons before launch and after every install: run axe DevTools on the demo, check colour contrast, and Tab through interactive components, because these are reused across the whole site.
- Verify the rendered Form block markup (persistent labels, error association) rather than trusting defaults, and remember that the dashboard editors use daily should also be usable by staff who rely on a keyboard or screen reader.
Recommended Tools
axe DevTools (browser extension)
Deque's free browser extension runs WCAG checks on any rendered Concrete CMS page - use it on theme demos before you buy and on key templates after each add-on install.
WAVE Evaluation Tool
WebAIM's WAVE extension visually flags missing alt text, contrast failures, and heading-structure problems directly on the page, which makes it easy to review editor-created Content blocks.
HeadingsMap
A browser extension that shows a page's heading outline at a glance, ideal for catching the skipped levels and stacked H1s that the Content block's editor produces.
Concrete CMS: Where Accessibility Is Won or Lost
| Plugin / Tool | Surface | Built-in Behaviour | What You Must Check or Fix |
|---|---|---|---|
| Content block 1.3.1 | Redactor rich text with heading styles | Editors must choose heading levels by structure, not size | |
| Images 1.1.1 | Optional alt field on Image block and File Manager | Require an alt decision on every informative image | |
| Image Slider 2.1.1 | Carousel/lightbox blocks (support varies) | Keyboard controls, pause for auto-advance, lightbox focus | |
| Auto-Nav 2.4.1 | Navigation generated from the page tree | Nav landmark, skip link, keyboard-operable dropdowns | |
| Themes / add-ons 4.1.2 | Marketplace components of varying quality | Audit contrast, semantics, and keyboard support before use |
Frequently Asked Questions
Is a Concrete CMS site accessible out of the box?
A fresh Concrete CMS 9 install using the default Atomik theme starts in a reasonable place - Atomik was rebuilt on Bootstrap 5 with accessibility in mind, so landmarks, navigation, and skip links are handled better than on older Elemental-themed sites. But out-of-the-box defaults only get you so far. The accessibility of a real site depends on the content editors create in blocks (especially heading structure and alt text), the theme you actually ship (a purchased theme can undo Atomik's gains), and any add-ons you install. So Concrete gives you a good starting point, not a finished accessible site.
How do I fix heading structure in the Content block?
Treat headings as document structure, not styling. Each page should have one H1 (usually the page title the theme renders), and Content blocks should use H2 and H3 in order beneath it without skipping levels. The common mistake is editors choosing a heading from the Redactor dropdown because it is the right size; instead, choose the correct level for the outline and let the theme's CSS make it look right. Review pages with a headings-list tool like HeadingsMap or a screen reader's headings list to catch skipped levels and multiple H1s.
Are the Image Slider and gallery add-ons accessible?
Not automatically. The Image Slider block and many marketplace gallery or lightbox add-ons render carousels and modal viewers whose keyboard and screen reader support varies a lot. Common failures are mouse-only previous/next controls, auto-advancing slides with no pause button, and lightboxes that trap or lose keyboard focus. Before relying on one, Tab through every control, confirm an auto-advancing carousel can be paused, and check that a lightbox moves focus in, closes on Escape, and returns focus. If it cannot do those things, switch to an accessible alternative or replace the carousel with a static image grid.
Does Concrete CMS meet WCAG 2.1 AA and the EAA?
Concrete CMS can be built to meet WCAG 2.1 AA, EN 301 549, and the European Accessibility Act, but the platform does not guarantee it - conformance is a property of your specific site, not the CMS. The Atomik theme and core blocks give you accessible building blocks; you reach AA by using them correctly (real heading structure, alt text on informative images, keyboard-operable navigation and sliders, labelled forms) and by auditing the themes and add-ons you add. Run automated checks with axe or WAVE plus a manual keyboard and screen reader pass, then document the result in an accessibility statement.
Further Reading
- Wcag Explained Plain English
- Alt Text Guide
- Accessible Navigation Guide
- Image Carousel Accessibility Lawsuits
- Accessible Forms Guide
- Hamburger Menu Accessibility Fixes
Other CMS Checklists
- Drupal Accessibility Checklist
- Joomla Accessibility Checklist
- Wordpress Accessibility Checklist
- Typo3 Accessibility Checklist
Get our free accessibility toolkit
We're building a simple accessibility checker for non-developers. Join the waitlist for early access and a free EAA compliance checklist.
No spam. Unsubscribe anytime.