Last Updated
Accessibility is a continuous improvement process here at ApostropheCMS. Reference this page to stay up to date with where we are and how we test.
Our current work focuses primarily on the ApostropheCMS admin UI: the editing interface content teams use to create, manage, and publish content. That experience needs to work well for people who navigate by keyboard, use screen readers, or rely on other assistive technologies.
We have built a dedicated accessibility testing suite, corrected issues across the admin UI, and established ongoing checks to help us identify regressions. We also know automated testing cannot establish full accessibility on its own.
We have not yet published an Accessibility Conformance Report based on the VPAT. Establishing a repeatable process for producing and maintaining that documentation is a current priority, and this page will remain a source of truth for our work overall.
Today this page explains what we test, recent improvements, current limitations, and what we are working on next.
The ApostropheCMS admin UI is regularly tested through a dedicated accessibility suite that runs monthly in CI and on demand.
The suite uses axe-core rules mapped to:
WCAG 2.0 Levels A and AA
WCAG 2.1 Levels A and AA
WCAG 2.2 Level AA
axe best-practice rules
All four axe impact levels (critical, serious, moderate, and minor) are included.
In our July 1, 2026 full-suite run, the accessibility suite scored 99 out of 100. The only detected violation was one serious-level color-contrast rule affecting four elements in the User Settings interface. The remaining active tests returned no detected violations.
Previous monthly runs had returned 100 out of 100. The regression is being tracked for remediation and will be evaluated again in the next full-suite run.
These results describe what the test suite detected. They are not a formal finding of WCAG conformance, certification, or third-party approval.
We test the product interface we maintain: the core apostrophe package and several Pro modules. The tests exercise the real, running admin UI rather than static markup in isolation.
Area | What is covered |
|---|---|
Admin navigation | Logo, menus, create button, tray, locale switcher, user menu and context title |
Login | Login states across development and production environments |
Content managers | Pages, pieces, media and recently edited content |
Document editing | Editor modals, global settings, user settings and document and section templates |
In-context editing | Rich text, image and layout widgets edited directly on the page |
Workflow and versioning | Editorial workflows and document versions |
Design and preview | Styles editor, breakpoint preview, dashboard and update flows |
Icon-only buttons throughout the admin bar, subform editing controls, cell preview links and the styles editor back button received accessible names so assistive technologies can communicate what each control does.
We corrected several roles and attributes across the admin UI. For example, the rich-text toolbar now uses role="toolbar" rather than role="menubar", invalid and orphaned roles were removed, and the rich-text editing surface received an accessible name.
We also prevented third-party libraries from adding invalid ARIA attributes to the editor.
Several design tokens were updated to meet WCAG AA contrast requirements. Secondary text was changed from #818181 to #6f6f6f, increasing its contrast against white from 3.89:1 to 5.74:1.
We also added a darker success-state token so environment badges meet contrast requirements across supported environments.
The login page received a main landmark, a screen-reader-only heading, and appropriate navigation and content-information landmarks.
We removed duplicate landmark exposure in modals and corrected the screen-reader-only utility so content intended for assistive technologies is included in the accessibility tree.
Many of these improvements were released in ApostropheCMS 4.30.0 and 4.31.0. They build on earlier work including keyboard-accessible relationship fields, modal keyboard improvements, context-menu focus management, and accessible toggles and array editors.
We run axe-core through Cypress against the working ApostropheCMS admin UI. Every non-experimental rule is included, with no severity level filtered out.
Any exclusions are documented in the relevant test and apply only to test-fixture markup surrounding the product—not to the ApostropheCMS interface being evaluated.
Each test calculates a score based on the checks that pass.
A test can only receive 100 out of 100 when it has no detected violations. If even one check fails, the score is capped at 99, even when rounding would otherwise produce 100. The aggregate score follows the same rule.
The score is therefore a summary of what the test suite detected. It is not a conformance rating or a substitute for manual evaluation.
Automated scanning cannot verify every part of an interaction, so the suite also uses real browser input events to test behaviors such as:
whether keyboard focus indicators appear when someone navigates with a keyboard;
whether focus moves into an opened popup;
whether focus returns to the triggering control when a popup closes;
whether menu controls communicate their open and closed states correctly.
These behaviors can create significant barriers even when the underlying markup passes an automated scan.
Accessibility testing is part of our ongoing product maintenance rather than a one-time review. The accessibility suite runs monthly through GitHub Actions and can also be run on demand. It produces a detailed HTML report, and the team is notified in Slack when tests fail. The suite has continued to expand as we add and update admin UI surfaces.
Automated tools evaluate the machine-testable portion of accessibility standards. They cannot fully assess factors such as:
whether information is presented in a meaningful order;
whether instructions and labels are genuinely understandable;
whether an interface creates unnecessary cognitive difficulty;
how well a complete workflow works with a screen reader;
how people who use assistive technologies experience the product in practice.
Our browser-behavior tests extend beyond a standard automated scan, but they do not replace human evaluation.
We have not yet completed:
a structured manual audit using NVDA, JAWS and VoiceOver;
usability testing with people who use assistive technologies;
a formal third-party accessibility audit;
an Accessibility Conformance Report based on the VPAT.
Because that work is incomplete, we do not describe ApostropheCMS as WCAG certified, fully accessible, or formally conformant; that said, we are committed to both improvements in the accessibility of ApostropheCMS as well as the processes that get us there.
Accessibility work is not finished, and our current testing has known boundaries.
Our July 1, 2026 test run identified a color-contrast regression affecting four elements in the User Settings interface. The affected test passed 72 of 76 checks and scored 95 out of 100, bringing the aggregate suite score to 99 out of 100.
We are tracking the underlying contrast issue for remediation. The next full-suite run will confirm whether the correction has resolved the regression.
Popup menus in the ApostropheCMS admin UI currently support Tab navigation, focus management, Escape to close, and appropriate roles and state attributes. They pass the automated checks included in our suite.
However, they do not yet implement the full keyboard behavior described by the ARIA menu pattern, including:
arrow-key navigation between menu items;
Home and End navigation;
first-character typeahead.
Implementing this behavior requires changes to shared menu components used throughout the admin UI. We chose not to rush that system-wide change during the initial remediation work and are tracking it as a separate improvement.
Three tests are currently skipped because of one known nested-interactive issue affecting a card pattern in two Pro template-library modules.
An initial correction changed existing component behavior, so we deferred the work rather than release a risky or incomplete fix. The issue requires a more careful restructuring of the component and does not affect the core apostrophe package.
The suite covers the core package and the Pro modules listed above. Some controls maintained in separate Pro packages are tracked separately.
The tests cover the major managers, editors and in-context editing workflows, but they do not exercise every possible state or configuration of the admin UI.
Test results are also point-in-time measurements. Regular CI runs help us identify changes, but no automated result guarantees that an interface is free from accessibility barriers.
Our current accessibility priorities follow directly from the limitations we have identified:
correcting the User Settings color-contrast regression identified in the July 1 test run;
implementing the complete ARIA menu keyboard pattern;
resolving the deferred template-card issue;
conducting structured manual screen-reader testing across the admin UI;
developing a repeatable process for producing and maintaining Accessibility Conformance Reports based on the VPAT.
A VPAT-based report will require more than transferring automated test results into a document. We want the process to include the manual evaluation and supporting evidence needed to make the resulting report useful to customers and procurement teams.
We will update this page as that work progresses.
We do not currently publish a standard Accessibility Conformance Report based on the VPAT. That does not mean accessibility requirements should prevent us from having a conversation.
If your evaluation or procurement process requires a VPAT/ACR, accessibility questionnaire, testing information, or other documentation, tell us what your organization needs and when you need it. Our team will review the requirements promptly and work with you to determine the appropriate documentation and next steps.
If you encounter an accessibility barrier while using the ApostropheCMS admin UI, please tell us.
Details such as the affected workflow, ApostropheCMS version, browser and assistive technology can help us understand and reproduce the issue.
Contact, or open an issue on GitHub.
Accessibility reports help us improve the product for everyone, and fixes to the core admin UI are made available through regular ApostropheCMS releases.
