Accessibility statement

Accessibility statement for Keystone

This statement applies to the Keystone operations platform — the agent application (/agent/*), the staff and requester portal (/me/*, /portal/*), and the trust administration shell (/admin/*). It does not cover the external documentation website beyond this handbook, nor third-party services that a trust chooses to integrate (for example its MIS or identity provider), which publish their own statements.

Keystone is supplied by Alresford Systems to multi-academy trusts and schools. Most of those organisations are public sector bodies and are themselves subject to the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018. This statement is the technical basis a customer trust can reference and extend when publishing its own statement; it is not a substitute for the trust’s own statement where one is required.

Our commitment

We want everyone who uses Keystone — staff, pupils, parents, governors, and helpdesk agents — to be able to do their work regardless of how they access it. We aim to meet WCAG 2.1 level AA across the application and to design new features to that standard from the outset rather than retrofitting it.

How accessible this platform is

We believe the platform is partially compliant with WCAG 2.1 AA: the core journeys conform, but we know some areas fall short (listed under Known limitations). We are deliberately stating this as partial rather than full compliance because we have not yet completed an independent audit of every product surface — claiming more than we have verified would itself be a failure of this statement.

What works well today:

• Keyboard operation — primary navigation, ticket and record workflows, forms, and the command palette are operable without a mouse. Interactive controls take a visible focus indicator from the shared design system rather than relying on the browser default.
• Structure and semantics — pages use headings, landmarks, lists, and labelled form fields so screen readers can convey structure. Status and tone (for example a declined leave request, an overdue compliance item) are conveyed in text, not by colour alone.
• Consistency — every product is built from one design system, so a pattern that is accessible in one area behaves the same way across the others. The portal — the surface most non-specialist users see — is the reference implementation.
• Automated checks in our pipeline — our end-to-end browser test suite runs automated accessibility assertions (axe-core) against key pages, so a regression that introduces a detectable WCAG violation can fail the build before release.

Known limitations {#known-limitations}

We are aware of, or have not yet ruled out, accessibility problems in the following areas. We will update this list as issues are confirmed, fixed, or found:

• Rich text editing. The rich-text editor used for ticket replies, knowledge-base articles, and notes is a complex widget; some of its controls and keyboard affordances may not yet fully meet AA. Plain alternatives (the text falls back to readable markup) exist for reading; authoring with assistive technology may be harder.
• Dense data tables and exports. Large registers (assets, people, compliance) and the generated PDF/spreadsheet exports have not all been verified for screen-reader table semantics and reading order.
• Charts and dashboards. Trend and KPI visualisations convey information graphically; we provide the underlying figures in text or tables in most but not yet all places.
• Audit in progress. A full WCAG 2.1 AA audit across all eight products is not yet complete. We are extending the automated accessibility checks described above to gate every product surface in continuous integration, and triaging the violations that surfaces. Until that work concludes we cannot certify full conformance.

None of the above is a reason to delay reporting a barrier you hit — please tell us (below); real reports are prioritised over the audit backlog.

Reporting accessibility problems

If you find a barrier that is not listed here, or you need content in a different format, please report it:

• Inside the app — use the in-app help/feedback option, or raise a ticket with your trust’s Keystone helpdesk describing the page, what you were trying to do, and the assistive technology or settings you use.
• Trust administrators can escalate confirmed accessibility defects to Alresford Systems through their normal support channel; we treat accessibility defects as a defined defect class, not a feature request.

We aim to acknowledge reports within five working days and will tell you the expected remedy and timeframe.

Enforcement procedure

The Equality and Human Rights Commission (EHRC) is responsible for enforcing the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 (the “accessibility regulations”). If you are not happy with how we respond to your complaint, contact the Equality Advisory and Support Service (EASS).

(Where the platform is operated by a public sector body, that body’s own published accessibility statement governs the formal enforcement route for its users; this section describes the regime that applies to it.)

Technical information about this platform’s accessibility

Alresford Systems is committed to making Keystone accessible in accordance with the accessibility regulations. This platform is partially compliant with the Web Content Accessibility Guidelines version 2.1 AA standard, due to the non-compliances and exemptions listed under Known limitations.

How we tested this platform

Compliance is assessed by a combination of:

• automated accessibility testing (axe-core) integrated into our end-to-end browser test suite and run in continuous integration;
• manual keyboard and screen-reader checks of the primary journeys (sign-in, raising and working a ticket, portal self-service) during development;
• design-system-level review, so a fix applies everywhere a pattern is reused.

This is a self-assessment. An independent third-party audit has not yet been carried out; commissioning one is part of the improvement plan.

What we are doing to improve accessibility

• Extending automated WCAG checks to gate every product surface in continuous integration, not only the primary pages.
• Triaging and fixing the violations that the broadened automated checks surface, prioritising portal and helpdesk journeys.
• Reviewing the rich-text editor and dense data tables against AA and remediating or replacing controls that fall short.
• Commissioning an independent audit once the automated baseline is green, and updating this statement with its findings.

Preparation of this statement

This statement was prepared on 19 May 2026. It is based on a self-assessment of the Keystone platform carried out by Alresford Systems. It will be reviewed and updated at least every 12 months, and sooner when a significant change is released or a confirmed issue materially changes the picture above.