SilverStripe Accessibility Checklist 2026 | WCAG 2.1 AA & EAA
Last updated: 2026-07-17
SilverStripe is an open-source PHP CMS with a long history in government, higher education, and enterprise sites -- exactly the sectors where accessibility is not optional but a formal requirement, whether that is a national government web standard, Section 508, or the European Accessibility Act. It gives editors a page-tree model, a WYSIWYG content editor, and increasingly a block-based Elemental layout, all managed from a polished admin. The platform itself is capable of producing fully accessible output, but as always the front end depends on the installed theme and the habits of the people entering content. On real SilverStripe sites the recurring problems are familiar: images inserted through the HTML editor without alt text, theme palettes that fail contrast, heading levels picked in the WYSIWYG for size rather than structure, PDFs and Office documents uploaded to the Files area and linked without ever being made accessible, and forms built with the UserForms module whose fields, legends, and error messages were never properly labelled. Because so many SilverStripe sites are public-sector or public-facing, a single inaccessible download or unlabeled form can put an organisation out of step with its own legal obligations. This checklist covers each of these issues, with fixes an editor can make in the CMS and notes on where a developer needs to adjust the theme.
Common Accessibility Issues
When an editor inserts an image through SilverStripe's HTML editor (the WYSIWYG), the alt text field is optional and easily skipped, and images placed by URL or in older content often have no alt attribute at all. Screen reader users then encounter unlabeled images -- a particular problem on government and education sites where images frequently carry information such as charts, seals, or process diagrams.
Every time you insert an image, fill in the 'Alternative text (alt)' field in the image dialog with a concise, specific description; for images that convey data, describe the information, not just the picture. Mark purely decorative images with empty alt. Re-check published pages with WAVE, and audit your existing Files and pages for images added before this became a habit.
SilverStripe themes -- whether a vendor build or an in-house design -- often include light gray body text, pale link colors, or buttons whose label contrast falls under 4.5:1. On the large, information-dense sites SilverStripe typically powers, low contrast affects a lot of content at once and hits the older and low-vision audiences that public services must serve.
Audit body text, links, headings, and interactive elements with the WebAIM Contrast Checker and update the theme's CSS or SCSS variables until every combination passes 4.5:1 (3:1 for large text and UI components). This is a theme-level change for your developer, but fixing it centrally corrects the contrast across the whole site in one pass.
The SilverStripe content editor lets authors apply heading formats from a dropdown, and it is common to pick a level by how large it renders. That produces pages with duplicate H1s or outlines that skip levels, especially when several Elemental blocks each add their own heading. Screen reader users navigate by heading, so a broken outline makes long institutional pages hard to move through.
Use one H1 per page (usually the page title from the template -- check that editors are not adding a second in the body), then H2 and H3 in order for sections and sub-sections. In Elemental layouts, make sure each block's heading level fits the surrounding outline rather than always defaulting to H2 or H3. Style headings with CSS if the size looks wrong, and verify the outline with HeadingsMap.
SilverStripe sites, especially in government and education, publish large numbers of PDFs, forms, and Office documents through the Files area. These are frequently scanned images or untagged exports with no reading order, no headings, and no alt text, so they are unusable with a screen reader even when the surrounding web page is fine -- and the download is often the actual thing the user came for.
Before uploading, make source documents accessible: use real headings and styles, add alt text to images, set the document language and title, and run the accessibility checker in Word or Acrobat. Prefer publishing the content as an HTML page where possible, since HTML is far easier to make and keep accessible than a PDF. Where a PDF is unavoidable, ensure it is tagged and linked with descriptive text that states the format and size.
The UserForms module makes it easy to build forms in the CMS, but fields can end up relying on placeholder text, radio and checkbox groups can lack a grouping legend, and validation errors may be signaled by color alone. Screen reader and colorblind users then cannot reliably tell which field is which or what went wrong -- a serious problem on the application, enquiry, and service forms these sites depend on.
Give every field a visible, descriptive title (UserForms renders it as a label), group related radio buttons and checkboxes so they share a fieldset and legend, mark required fields with the word 'required', and make sure error messages are text tied to the field. Test the whole form with the keyboard and a screen reader, completing and submitting it without a mouse to confirm every label and error is announced.
SilverStripe-Specific Tips
- If your SilverStripe site is public-sector or education, map your obligations first -- a national government web accessibility standard, Section 508, or the EAA -- because these usually mandate WCAG 2.1 AA and cover documents as well as pages.
- Treat the Files area as part of your accessibility scope: PDFs and Office documents you link are content, and an untagged download fails just as surely as an unlabeled image.
- In Elemental block layouts, review the combined heading outline of a finished page rather than each block in isolation, since blocks that each start at H2 can produce a broken structure together.
- Publish an accessibility statement page (many public bodies are required to) that names your conformance target and gives a contact route for reporting barriers.
Recommended Tools
WAVE
Free scanner that flags missing alt text, contrast failures, empty links, and form-labeling problems on your published SilverStripe pages.
WebAIM Contrast Checker
Check your SilverStripe theme's text, link, heading, and button colors against the 4.5:1 ratio before rolling changes out site-wide.
HeadingsMap
Browser extension that reveals your page's heading outline so you can catch duplicate-H1 and skipped-level issues from the WYSIWYG and Elemental blocks.
Frequently Asked Questions
Is SilverStripe accessible enough for a government website?
SilverStripe is capable of producing WCAG 2.1 AA output and is widely used for public-sector sites, but the platform being capable does not make any given site compliant. Conformance depends on the theme your developer built, the habits of your content editors, and -- critically for government -- whether the PDFs and documents you publish are themselves accessible. Treat SilverStripe as a solid foundation that still requires an accessible theme, trained editors, and a documents policy to actually meet a government standard.
Do I need to worry about the PDFs on my SilverStripe site?
Yes. Documents you upload and link are part of your website's content, and accessibility standards -- including most government web standards and the EAA -- cover them. An untagged, scanned, or image-only PDF is unusable with a screen reader even if the page linking to it is perfect. Where you can, publish the content as an HTML page instead; where a PDF is genuinely needed, tag it properly and give it real headings, alt text, a title, and a language setting before uploading.
How do I make UserForms accessible?
Give every field a clear title so UserForms renders a proper label, group related radio buttons and checkboxes so they share a fieldset and legend, mark required fields with the word 'required' rather than color or an asterisk alone, and ensure validation errors appear as text tied to the field. Then test the finished form with only a keyboard and with a screen reader, completing and submitting it without a mouse, to confirm every label and error message is announced.
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.