Kirby CMS Accessibility Checklist 2026 | WCAG 2.1 AA & EAA
Last updated: 2026-07-17
Kirby is a flat-file CMS loved by designers and small agencies because it stores content in files instead of a database and lets a developer build exactly the templates a client needs. That flexibility is its strength and, for accessibility, its risk: almost everything a visitor experiences -- the page structure, the color palette, the navigation markup -- is written by hand into templates and snippets, so accessibility depends heavily on whoever built the site rather than on defaults you can rely on. Meanwhile the day-to-day editor works in the Kirby Panel, adding images, writing text, and picking heading levels in KirbyText or Markdown, and nothing in the Panel forces an accessible choice. The result is that Kirby sites are only as accessible as the care put into them, and common problems cluster in a few predictable places: images uploaded through the Panel with no alt text, designer color palettes that look elegant but fail contrast, headings chosen by appearance in KirbyText, 'read more' link text, and contact or booking forms built with plugins whose fields never got real labels. For any Kirby site that sells to or serves customers in the EU, the European Accessibility Act now makes these barriers a compliance matter, not just good practice. This checklist walks through each issue with fixes an editor can make in the Panel and points out where a developer needs to touch the template.
Common Accessibility Issues
Kirby's Panel lets editors drop images into a page's files and place them in content, but alt text only exists if the blueprint includes an alt field and the editor fills it in. On many Kirby sites images are output in templates straight from the file object with no alt attribute at all, so screen reader users hear a filename or nothing where sighted visitors see the product, the team, or the hero image.
Ask your developer to add an 'alt' field to the image blueprint and to output it in templates (for example, alt attribute set from the file's alt field, empty string for decorative images). Then, as an editor, write a short, specific description for every meaningful image in the Panel and leave alt empty only for purely decorative graphics. Confirm on the live page with WAVE that each content image now carries appropriate alt text.
Kirby sites are typically bespoke designs, and designer palettes often favor pale gray body text, thin light headings, or brand-tinted buttons whose label color drops below the 4.5:1 ratio. It looks refined on a large calibrated monitor but becomes unreadable for older and low-vision visitors, and text placed over photographs is usually worse.
Check body text, headings, links, and button labels against their backgrounds with the WebAIM Contrast Checker and adjust the CSS custom properties or SCSS variables in the template until each combination passes 4.5:1 (3:1 for large text). For text over imagery, add a solid or gradient overlay. Because Kirby styling lives in the theme's CSS, this is usually a developer change -- but it is a one-time fix that protects every page.
Editors writing in KirbyText or Markdown insert headings with hash marks, and it is tempting to jump to a bigger or smaller level based on how it renders rather than where it sits in the page outline. That produces pages with several H1s or outlines that skip from H1 to H4. Screen reader users navigate by heading, so a scrambled outline turns a simple page into a disorienting list of sections.
Give each page a single H1 (often output automatically from the page title -- check the template so editors don't add a second one in the body), then use H2 for main sections and H3 for sub-points in order, without skipping levels. If a correctly leveled heading looks wrong, style it in CSS rather than switching levels. Verify the outline with the free HeadingsMap browser extension.
Kirby project and blog listings frequently repeat 'read more' or 'view project' as the linked text, and inline content often uses 'click here'. Screen reader users often pull up a list of all links to navigate; a column of identical 'read more' entries gives them no way to tell one destination from another.
In list templates, build link text from the item's title (for example, 'Read the article: <title>') so each link is unique and descriptive, and in body content link meaningful phrases instead of 'click here'. This is partly a template change and partly an editing habit; it also helps every visitor scan the page and improves how search engines read your links.
Forms on Kirby sites are usually built with a plugin such as Kirby Uniform or a hand-coded template, and it is easy to ship fields that rely on placeholder text, mark required fields with color or an asterisk alone, or show errors only in red. Screen reader and colorblind users then lose track of which field is which and which one caused an error, and a broken contact form quietly costs you enquiries.
Ensure every field has a visible label element tied to its input with matching for/id attributes (not just a placeholder), mark required fields with the word 'required', and render validation errors as text linked to the field with aria-describedby. Test the whole form with the keyboard alone -- Tab through every field and submit with Enter -- and confirm a screen reader announces each label and error.
Kirby-Specific Tips
- Because Kirby is template-driven, most structural accessibility (landmarks, skip links, alt attributes, heading output) is decided in the theme -- brief your developer to build these in once, and they benefit every page.
- Add an 'alt' field to every image blueprint so editors are prompted for a description in the Panel instead of relying on memory.
- Add a visible skip-to-content link and proper landmark elements (header, nav, main, footer) in the base template; Kirby gives you full control of the markup, so there is no excuse for missing them.
- If you serve or sell to customers in the EU, treat the European Accessibility Act as a real obligation and publish an accessibility statement page with a contact email so visitors who hit a barrier can reach you.
Recommended Tools
WAVE
Free scanner that flags missing alt text, contrast failures, and empty links on your published Kirby pages.
WebAIM Contrast Checker
Check your Kirby theme's text, heading, link, and button colors against the 4.5:1 ratio before finalizing the palette.
HeadingsMap
Browser extension that shows your page's heading outline so you can catch multiple-H1 and skipped-level problems from KirbyText.
Frequently Asked Questions
Is a Kirby site accessible by default?
No CMS is accessible by default, and Kirby especially so because it is a blank canvas -- it gives your developer complete control of the HTML rather than shipping a fixed front end. That means there is no built-in theme forcing good markup, but it also means nothing gets in the way of building an accessible site. Accessibility on a Kirby site is decided almost entirely by how the templates, blueprints, and CSS were written, so the quality of the build matters more than on a platform with rigid defaults.
Whose job is it to fix accessibility on a Kirby site -- the editor or the developer?
Both. Structural issues -- landmarks, skip links, whether image alt is even output, heading defaults, and color contrast in the theme CSS -- live in the templates and need a developer. Day-to-day content issues -- writing alt text in the Panel, choosing correct heading levels in KirbyText, and using descriptive link text -- are the editor's responsibility. The most reliable setup is a developer who builds accessible templates and blueprints once, and an editor who then fills them in with care.
Does the Kirby Panel force editors to add alt text?
Not on its own. Alt text only appears in the Panel if the image blueprint includes an alt field, and even then the field can be left blank. Ask your developer to add an alt field to your image blueprints and to output it in templates so editors are prompted for a description every time they place an image.
Further Reading
Other CMS Checklists
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.