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.

SELF-ASSESSED, NOT INDEPENDENTLY AUDITED. The position taken below for this website comes from our own testing, carried out in September 2026, and the nine defects it found have since been fixed — they are listed at the end of that section rather than quietly removed, so you can see what was wrong and when. No independent audit has taken place. We therefore make no conformance claim at all for the platform, and the claim we make for this website is qualified accordingly. We would rather publish a specific list of our own failures than a conformance claim we cannot evidence — 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: partially conformant with WCAG 2.2 AA. "Partially conformant" means the site conforms in most respects but not in all, and the exception we know about is listed below. This position is self-assessed by our own development team, not independently audited, and it should be read as our own account of our own site rather than as third-party assurance. Automated tools alone find perhaps a third of real issues and none of the ones that matter most, so the assessment behind it combined automated checking with manual keyboard and screen reader testing.

What we have built in:

• Semantic HTML with real headings, landmarks and lists, so the page structure is available to a screen reader. Every page has a single main landmark, including the ones rendered without JavaScript.
• A "skip to content" link, the first thing the Tab key reaches on every page, so the main navigation can be bypassed.
• Keyboard operability throughout, with a visible focus indicator on every control.
• Text that reflows and remains readable when zoomed and on a small screen. The navigation is reachable at every window width, including the zoom levels between the wide and narrow layouts.
• Light and dark themes. Text meets the 4.5:1 contrast requirement in both, with the one exception listed below.
• Reduced-motion support: animation is suppressed where the operating system asks for it.
• Alternative text on images that carry meaning, and decorative icons marked so assistive technology skips them rather than announcing them as unlabelled graphics.
• The mobile navigation menu behaves as the modal dialog it announces itself to be: opening it moves focus into it, Tab stays inside it, Escape closes it, and closing it returns focus to the button that opened it. While closed it is removed from the tab order entirely.
• Moving between pages without a full reload updates the page title, moves keyboard focus to the new content, and announces the new page — the three things a browser does on a conventional page load and a single-page application has to do for itself.

Known issues. Stated with the success criterion each fails, because a statement that claims no known issues is read as one that has not been tested, and rightly so.

• Small text inside the illustration on our home page (1.4.3 Contrast (Minimum), level AA). The stylised product screenshot on the front page is built from real HTML rather than being an image, and several of its 9-11px labels sit at between 2.6:1 and 4.2:1 against their background. Nothing on the site depends on reading them — the same information is in the prose around it — but they are real text and we are not going to argue the exemption. Fix due 31 October 2026.

Fixed since this statement was first published, and recorded here because a defect list that only ever grows is not a credible one: the absence of a skip link (2.4.1), a hidden navigation menu that could still be reached by keyboard (2.4.3), a secondary text colour at 3.3:1 in both themes (1.4.3), a search field with its focus indicator suppressed (2.4.7), a page title that did not change during in-site navigation (2.4.2), navigation that was neither announced nor given focus (2.4.3), a window-width band between the two layouts where no navigation was shown at all (1.4.4), a menu marked up as a dialog that did not behave as one (2.4.3), and around forty decorative icons that assistive technology announced as unlabelled graphics. All nine were found by the September 2026 self-assessment and corrected on 6 September 2026.

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: not assessed, and we make no conformance claim. The platform has not been tested against WCAG 2.2 AA as a whole, by us or by anyone else. We will not state a level we have not tested for, and we would ask you to treat any supplier who states one without evidence with the same scepticism.

What the platform does provide today, from the way it is built rather than from a conformance test:

• 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 where an assessment should start: complex field types, drag-and-drop interactions, charting in dashboards, and the workflow builder are the areas most likely to fall short. 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

What we have done: a structured self-assessment of this website against WCAG 2.2 AA in September 2026, carried out by our own development team. It combined automated checking with manual keyboard testing and screen reader testing, and it is the source of both the conformance position and the defect list above. It is not an independent audit and we do not present it as one.

It found nine failures, and all nine were fixed the same week rather than being written down as a plan. Two of them are the sort a checklist misses and are worth naming as evidence of what the assessment actually involved: keyboard focus could enter a navigation menu that was invisible on screen, and at one narrow band of window widths — the band you land in at 125% browser zoom on a common laptop — the site showed no main navigation at all. Neither is visible to an automated scan, and the second affects people using a zoom setting for exactly the reasons this page exists.

What we have not done: commissioned an independent accessibility audit, of either this website or the platform. We intend to, and the platform is the priority — it is the part a buyer is actually procuring, and it is the part for which we currently make no claim. We have not committed to an auditor or a date, and we would rather say so here than name one we have not engaged. Our own testing finding and fixing nine failures is a reason to expect an independent one to find more, not fewer.

Ongoing, alongside that: automated checking as part of development, manual keyboard testing of new interface work, and screen reader testing with NVDA on Firefox and VoiceOver on Safari.

A VPAT or an EN 301 549 conformance statement will be produced once an independent audit has reported, and will be available on request. Several buyers ask for one by name and we would rather issue it than explain its absence — but issuing one off the back of our own testing would be exactly the overclaim this page exists to avoid.

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 5 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 6 September 2026 and last reviewed on 6 September 2026, when the nine defects found by our self-assessment were fixed and this page was rewritten around the result. It is reviewed at least annually, whenever a significant change is made to this website or to the platform interfaces it describes, and whenever an item moves on or off the list above.

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