Accessibility checklist for buying compliance software

Compliance systems are used by people with different abilities, devices and working environments. If a worker cannot complete a training acknowledgment, a supervisor cannot review a RAMS with a keyboard, or an auditor cannot read an exported record, an attractive feature list will not solve the operational problem. Accessibility belongs in the procurement test, not only in an after-purchase support ticket.

The legal position depends on the buyer and use case. GOV.UK guidance on public-sector websites and apps explains the 2018 accessibility regulations, WCAG 2.2 AA and accessibility statements for covered public bodies, with important scope and exemptions. Other organisations still need to consider duties such as reasonable adjustments. This article does not claim that every private internal tool is subject to the same public-sector web rules.

Identify the tasks users must complete

List the actual journeys: uploading a certificate, reviewing an overdue action, completing a worker form, reading a site instruction, approving a contractor record and retrieving evidence. Note which users operate on a phone, shared device or desktop, and where they may have poor lighting, noise or limited connectivity. Invite people who use assistive technology to test the journeys where possible; a score from an automated scanner cannot represent their experience.

For each task, state what success looks like without relying on one interaction method. Can it be completed with a keyboard? Is focus visible and logical? Are labels and errors understandable? Can a screen reader identify controls and status? Does zoom or reflow preserve the task? Are uploaded documents and generated reports accessible as well as the platform shell?

Ask the supplier for evidence, then verify it

Request a current accessibility statement, recent testing scope, known issues and remediation plan. Ask whether the evidence covers the specific modules and devices you will buy. A statement about a marketing website says little about a contractor dashboard. W3C's WCAG overview describes the web standard; a vendor's unsupported “WCAG compliant” claim is not a substitute for testing the current interface.

Give the supplier a short scenario and ask it to demonstrate on the relevant device with assistive technology. Record failures by task impact. A decorative contrast issue and an inaccessible save button have different consequences. Note workarounds, their burden and whether the buyer would control the fix. If a future release is offered as the answer, ask for a dated commitment and a retest point.

Put accessibility into the contract decision

Define which standard and scope apply to your organisation, what testing evidence the supplier must provide and how issues will be reported and resolved. Public-sector buyers should obtain their own accessibility and procurement advice. GOV.UK guidance recommends including accessibility in the request for quotation and contract evaluation. Assign an internal owner for the accessibility decision; do not assume the supplier's statement transfers legal responsibility away from the buyer.

Plan for accessible onboarding and support. Can users obtain instructions in a usable format? Is an alternative process available if an essential workflow fails? Does the helpdesk understand accessibility incidents? A platform may pass a scripted demonstration while real users still struggle with long forms or inaccessible attachments.

Recheck after configuration and updates

Test the configured product, not only a clean demo tenant. Roles, forms, branding, document templates and integrations can change the experience. Save the test scripts and results so a later release can be checked against them. Ask how the supplier informs customers about material changes and known barriers. Accessibility is an ongoing service concern rather than a certificate purchased once.

If considering Complys, see how it works and request a demonstration of the exact journeys your users need. No assertion is made here that Complys meets a particular WCAG level or provides tested assistive-technology support; that needs current product evidence and user testing.

Example: the upload task passes, but the review task fails

A supplier demonstrates that a worker can upload a training certificate using a keyboard. The buyer then asks a reviewer who uses a screen reader to locate the file, read the rejection reason and return it for correction. The reviewer can open the record but cannot tell which button applies to the attachment and which applies to the whole worker profile. The task has failed even though the first half worked. Log the exact screen, role, device, assistive technology and step where the barrier occurred. Ask the supplier whether the fix is in the current release, a configuration change or a future plan. Retest the complete upload–review–correction journey rather than accepting a screenshot of a changed button.

Procurement questions for the contract owner

Which user journeys and modules were tested against WCAG 2.2, and by whom? How recent was the test? What known defects remain and what is their impact on essential tasks? How will users report barriers, what is the response route and who owns remediation? Are documents created by the platform covered, or only the web interface? If the organisation configures forms, who checks that those forms remain accessible? Record the answers as evidence, not only supplier assurances.

Avoid a one-number verdict

Accessibility is not a single percentage. A low-severity issue in a rarely used settings screen and a blocked emergency-report form carry different operational consequences. Classify findings by affected users and task impact, agree interim alternatives where needed and set a retest date. This makes the procurement decision transparent without pretending that any automated tool can establish the whole experience.