Accessibility Statement

Two different things, stated separately

Most accessibility statements cover a company's marketing website. That is the less important half. If you are evaluating us as a supplier, what you need to know is whether the applications your staff and your service users will actually use are accessible — and that is a different question with a different answer.

This statement covers both, in that order, and is explicit about which claims we have verified and which we have not.

DRAFT PENDING AUDIT. The conformance positions below are marked TODO_ because the independent audit they depend on has not yet taken place. This page deliberately makes no conformance claim until it has. An accessibility overclaim discovered after contract award is far more damaging than an honest statement of work in progress — and public sector buyers do check.

The standard we work to

We work to the Web Content Accessibility Guidelines (WCAG) version 2.2 at level AA. For public sector procurement the relevant reference is usually the European standard EN 301 549, which incorporates WCAG and adds requirements covering documentation, support and authoring tools.

The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 bind public sector organisations, not their software suppliers. In practice the duty reaches us anyway, because a public body cannot meet it using a product that makes it impossible. Treating that as someone else's problem is not a tenable position for a supplier of software to the NHS, and we do not take it.

EN 301 549 clause 11.8 covers authoring tools — software used to create content — and requires that they support the production of accessible output and preserve accessibility information. That clause is the one that most directly applies to a low-code platform, and it is the right one to hold us to.

This website

This statement applies to www.activemanage.co.uk, including our documentation site at /docs/.

Conformance status: TODO_WEBSITE_CONFORMANCE — one of "fully conformant", "partially conformant" or "non-conformant" with WCAG 2.2 AA, following an audit. Do not fill this in from an automated scan alone; automated tools find perhaps a third of real issues and none of the ones that matter most.

What we have built in:

• Semantic HTML with real headings, landmarks and lists, so the page structure is available to a screen reader.
• Full keyboard operability, with a visible focus indicator.
• Text that reflows and remains readable when zoomed, and on a small screen.
• Light and dark themes, both checked for contrast.
• Reduced-motion support: animation is suppressed where the operating system asks for it.
• Alternative text on images that carry meaning.

Known issues: TODO_KNOWN_ISSUES. List them specifically, with the WCAG criterion each fails and a date by which it will be fixed. A statement that claims no known issues is read as one that has not been tested.

One limitation we already know about and should state: this site is rendered in the browser using React, so a small amount of its content is assembled after the page loads. The full text of every page is present in the served HTML, so the page works without JavaScript, but this behaviour should be included in the audit rather than assumed to be fine.

The ActiveManage platform

This is the part that matters for procurement. The platform generates the interfaces our customers' users work in — forms, browse views, dashboards, and the end-user portal of the ITSM service desk — so the accessibility of those generated interfaces is our responsibility rather than our customers'.

Conformance status: TODO_PLATFORM_CONFORMANCE, pending the audit described below. In the meantime we will not claim a level we have not tested for.

What the platform does provide today:

• Generated forms use real form controls with programmatically associated labels, so a field's purpose is available to assistive technology rather than only visible on screen.
• Validation errors are associated with the field they relate to and are conveyed in text, not by colour alone.
• Browse views are rendered as data tables with proper header cells, so a screen reader can announce which column a value belongs to.
• The interface is operable by keyboard.
• Colour is not used as the only means of conveying status.

Where we are less certain, and what the audit is for: complex field types, drag-and-drop interactions, charting in dashboards, and the workflow builder are the areas most likely to fall short, and they are the areas an audit should start with. We would rather name them than let a buyer discover them.

The Architect Panel — the administrative interface used to design applications — is used by a small number of trained configuration staff rather than by the public. It is in scope for improvement but is a lower priority than the interfaces end users see, and we would treat a specific accessibility requirement for it as a reasonable adjustment to deliver rather than as a baseline commitment.

Where our responsibility ends

This is the honest part, and it is true of every low-code platform rather than being particular to ours. We control the components; our customers control how they are assembled and what goes in them. An accessible platform can be used to build an inaccessible application.

We support customers on their side of that line: guidance in our documentation, review of a configuration on request, and the evidence a public body needs for its own accessibility statement. Ask and we will help — this is not a boundary we hide behind.

How we test, and what happens next

Planned: an independent accessibility audit of TODO_AUDIT_SCOPE by TODO_AUDITOR, commissioned by TODO_AUDIT_COMMISSION_DATE and reported by TODO_AUDIT_REPORT_DATE. This statement will be rewritten around its findings, including the failures.

Ongoing, alongside that: automated checking as part of development, manual keyboard testing of new interface work, and screen reader testing with TODO_SCREEN_READERS — name what is actually used, for example NVDA with Firefox and VoiceOver with Safari.

A VPAT or an EN 301 549 conformance statement will be produced once the audit reports, and will be available on request. Several buyers ask for one by name and we would rather issue it than explain its absence.

Feedback and contact

If you find an accessibility problem on this website or in an application built on the platform, or you need information from us in a different format — accessible PDF, large print, easy read, audio, braille — email info@activemanage.co.uk and tell us what you need. We aim to respond within TODO_RESPONSE_DAYS working days.

If you are reporting a problem in an application run by one of our customers, contacting us directly is still useful. We will tell you whether it is something we can fix in the platform, and if it is not, we will raise it with the organisation that runs the service rather than sending you away.

A note on enforcement: the 2018 Regulations are enforced against public sector bodies, by the Equality and Human Rights Commission in Great Britain and the Equality Commission for Northern Ireland. We are not a public sector body, so that enforcement route does not apply to us — but where you are using a public service built on our platform, that body's own accessibility statement will set out how to escalate, and we support them in resolving what is reported.

About this statement

This statement was prepared on TODO_PREPARED_DATE and last reviewed on TODO_A11Y_REVIEW_DATE. It is reviewed at least annually, and whenever a significant change is made to this website or to the platform interfaces it describes.

Owner: TODO_RESPONSIBLE_DIRECTOR, ActiveManage Ltd, ActiveManage Ltd., Enterprise Centre, David Lane, Basford, Nottingham, NG6 0JU.