Accessibility Statement

KleipData is committed to making its websites, digital services and data-intelligence platform accessible to as many people as possible.

KleipData is operated by Computerko Limited.

We design and develop our digital services with accessibility in mind and aim to meet the Web Content Accessibility Guidelines (WCAG) 2.2 Level AA standard.

Accessibility is considered as part of the design, development and ongoing improvement of KleipData rather than as a separate feature added after development.

This Accessibility Statement applies to the principal KleipData digital services, including:

• the KleipData public website at kleipdata.co.uk;
• the KleipData customer portal;
• the KleipData developer portal;
• KleipData API documentation;
• account and administration interfaces operated by KleipData; and
• other KleipData-hosted web interfaces that link to this statement.

Customer-specific or white-labelled deployments may contain additional:

• branding;
• content;
• integrations;
• documents; or
• third-party functionality

provided or configured by the relevant customer.

Where a customer-controlled service publishes its own accessibility statement, that statement may additionally apply to that deployment.

KleipData aims to conform to the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA.

WCAG is an internationally recognised accessibility standard covering principles including:

• perceivable content;
• operable interfaces;
• understandable information and controls; and
• robust compatibility with assistive technologies.

Our accessibility work is intended to support people with a range of access needs, including people with:

• visual impairments;
• hearing impairments;
• motor impairments;
• cognitive or learning disabilities;
• neurological conditions;
• speech impairments; and
• combinations of different access needs.

KleipData is being designed and developed with WCAG 2.2 Level AA as its target accessibility standard.

At the date of this statement, KleipData has not yet completed a comprehensive independent accessibility audit of all production interfaces.

We therefore do not currently claim that every part of the KleipData service is fully compliant with WCAG 2.2 AA.

This statement will be updated following formal accessibility testing to record the appropriate compliance status and any identified non-conformities.

The absence of a known issue from this statement should not be interpreted as confirmation that no accessibility issue exists.

We design KleipData so that, as the service develops, users should be able to:

• navigate the website and principal interfaces using a keyboard;
• use the service without relying solely on a mouse or pointer device;
• zoom page content without unnecessary loss of information or functionality;
• resize text using browser or operating-system controls;
• understand page headings and information hierarchy;
• identify links, buttons and interactive controls;
• receive meaningful labels for form fields;
• understand validation and error messages;
• use appropriate assistive technologies;
• distinguish text and important interface elements through adequate contrast;
• navigate content in a logical order;
• identify the purpose of controls;
• understand tables and structured information;
• use forms without relying solely on colour to communicate meaning; and
• access the service across commonly used screen sizes and devices.

Actual support can depend on the particular browser, operating system, assistive technology and area of the Platform being used.

KleipData aims to make interactive functionality usable through a keyboard.

This includes, where applicable:

• navigation menus;
• links;
• buttons;
• forms;
• dialogs;
• search interfaces;
• account settings;
• case-management controls;
• tables;
• filters; and
• other interactive elements.

Keyboard focus should be:

• visible;
• logically ordered; and
• not unnecessarily trapped within a component.

Where we identify a component that cannot reasonably be operated using a keyboard, we will assess and address the issue.

We aim to structure KleipData interfaces so that assistive technologies can interpret them appropriately.

Our development approach includes consideration of:

• semantic HTML;
• accessible names;
• form labels;
• heading structures;
• landmarks;
• status messages;
• meaningful link text;
• table headings;
• alternative text;
• accessible dialogs; and
• appropriate use of ARIA where necessary.

ARIA is not intended to replace appropriate native HTML functionality where a suitable native element is available.

KleipData is intended to support browser zoom and text resizing without unnecessarily hiding important information or preventing users from completing core tasks.

Users should generally be able to use the zoom and text-sizing features provided by their browser, operating system or assistive technology.

We aim to avoid layouts that require a specific fixed text size to remain usable.

KleipData aims to maintain sufficient contrast between:

• text and backgrounds;
• controls and surrounding content;
• interactive states;
• focus indicators; and
• other important visual interface elements.

We do not intend to use colour alone as the only means of communicating important information.

For example, where a status is communicated using colour, an appropriate:

• label;
• icon;
• text description; or
• other non-colour indicator

should also be provided where necessary.

KleipData contains forms for activities such as:

• enquiries;
• account administration;
• user management;
• searches;
• cases;
• API administration;
• support requests; and
• other Platform operations.

We aim to provide:

• meaningful labels;
• understandable instructions;
• clear required-field indicators;
• accessible validation;
• useful error descriptions; and
• logical keyboard navigation.

Where information is particularly important, users should not be required to infer an error solely from colour.

Some KleipData interfaces contain complex information, including:

• people searches;
• address history;
• associations;
• identity-verification results;
• KYC information;
• company information;
• property information;
• evidence;
• audit records; and
• reports.

We aim to present this information using accessible structures rather than relying exclusively upon visual layout.

Where appropriate, information should distinguish between concepts such as:

• facts;
• observations;
• matches;
• associations;
• inferences; and
• verification outcomes.

Accessibility should not require those distinctions to be removed.

Data-intensive interfaces may use tables.

Where tables are appropriate, we aim to:

• identify column and row headings appropriately;
• provide meaningful table structure;
• maintain a logical reading order;
• avoid using tables solely for visual page layout;
• make controls within tables keyboard accessible; and
• provide alternative representations where a complex visualisation cannot adequately communicate information to assistive technology.

Where KleipData uses charts, graphs or other visualisations, we aim to avoid making important information available only through a visual representation.

Where appropriate, we may provide supporting:

• text;
• data tables;
• labels;
• summaries; or
• accessible descriptions.

Informative images should have appropriate text alternatives.

Decorative images should not create unnecessary noise for users of screen readers.

Icons used as interactive controls should have an accessible name that describes their purpose.

An icon’s visual appearance alone should not be relied upon where its meaning would otherwise be unclear.

KleipData may use animation and motion to improve interface feedback and presentation.

We aim to avoid unnecessary animation that:

• interferes with use of the service;
• creates a barrier to understanding;
• flashes in a way that creates accessibility risks; or
• prevents a user from completing a task.

Where appropriate, we will respect device or browser preferences such as reduced motion.

Important information should not depend solely upon animation.

KleipData is designed for use across different screen sizes.

We aim to ensure that content can appropriately reflow on supported devices without requiring unnecessary two-dimensional scrolling for ordinary page content.

Some large data tables or specialist interfaces may require horizontal interaction because of the nature of the information displayed.

Where this occurs, we will seek to preserve usability and accessibility.

KleipData uses authentication and security controls to protect customer and Service Data.

We aim to implement these controls in a way that does not unnecessarily exclude users with disabilities.

This includes considering accessibility when implementing:

• login;
• multi-factor authentication;
• password management;
• session management;
• verification prompts;
• CAPTCHA or bot-protection mechanisms; and
• other security controls.

Security requirements will not intentionally be used as a reason to disregard accessibility where an accessible secure alternative can reasonably be provided.

KleipData also provides machine-to-machine access through APIs.

Although API responses themselves are generally consumed by software rather than directly through a graphical user interface, the associated:

• developer portal;
• API documentation;
• credential-management screens;
• Usage information; and
• integration guidance

are within our broader accessibility approach.

Customers building their own interfaces using the KleipData API remain responsible for the accessibility of the applications they create.

KleipData may allow customers to generate or access reports, exports or documents.

We aim to improve the accessibility of documents generated directly by KleipData where technically and operationally appropriate.

However, accessibility can be affected by:

• the selected output format;
• data supplied by the customer;
• templates;
• third-party content;
• customer branding; or
• subsequent editing after export.

If you cannot access information in a generated document, please contact us and request an alternative accessible format.

Some information displayed through KleipData may have been created, uploaded or configured by a Customer.

This may include:

• case notes;
• uploaded documents;
• customer logos;
• customer descriptions;
• attachments;
• custom links;
• reports;
• embedded resources; and
• other Customer Content.

KleipData may not control the original accessibility of all such material.

Where technically possible, we aim to provide the surrounding KleipData interface accessibly.

Customers should ensure that content they upload for use by other people is itself accessible where required.

KleipData may integrate with third-party products or services.

These may include:

• payment services;
• support tools;
• authentication providers;
• documentation services;
• communication services;
• embedded content;
• data-provider interfaces; and
• other third-party technology.

Although we consider accessibility when selecting and integrating services, KleipData does not necessarily control the accessibility of an independent third-party website or application.

Where a third-party component creates a material accessibility barrier within a KleipData workflow, we will consider:

• configuration changes;
• an alternative workflow;
• an alternative provider;
• another accessible means of completing the task; or
• other proportionate remediation.

At the date of this statement, KleipData has not completed a comprehensive independent WCAG 2.2 AA audit across all production interfaces.

There may therefore be accessibility issues that have not yet been identified or documented.

We are particularly conscious that complex data-intensive interfaces can present accessibility challenges involving:

• large tables;
• filtering controls;
• responsive data displays;
• modal dialogs;
• interactive visualisations;
• dynamic search results;
• focus management;
• status notifications; and
• generated reports.

These areas should form part of formal accessibility testing.

As specific accessibility issues are identified and confirmed, this section will be updated to describe:

• 1. the affected functionality;
• 2. the relevant WCAG success criterion where appropriate;
• 3. the impact on users;
• 4. any available workaround; and
• 5. the action being taken to remedy it.

Our accessibility programme includes or is intended to include:

• designing against WCAG 2.2 AA requirements;
• using reusable accessible interface components;
• automated accessibility testing;
• manual keyboard testing;
• screen-reader testing;
• colour-contrast testing;
• responsive-layout testing;
• accessibility review during development;
• testing important customer journeys;
• reviewing generated reports and documents;
• recording identified accessibility defects;
• prioritising remediation according to user impact; and
• periodically reviewing this Accessibility Statement.

Automated testing alone is not treated as sufficient to establish full WCAG compliance.

KleipData intends to assess representative customer journeys and components against WCAG 2.2 Level AA.

Testing should cover important activities including:

• accessing the public website;
• requesting a demonstration;
• signing in;
• navigating the portal;
• performing an authorised Search;
• reviewing Search Results;
• using case-management functions;
• using filters and tables;
• creating and managing users;
• managing API Applications;
• navigating API documentation;
• changing account settings;
• contacting Support; and
• managing Cookie Settings.

Following formal testing, this statement will be updated with:

• the date of the test;
• the testing method;
• who carried out the test;
• the confirmed compliance status; and
• material outstanding accessibility issues.

If you experience an accessibility problem while using KleipData, please tell us.

Contact:

Email: support@kleipdata.co.uk

Please include Accessibility in the subject line where convenient.

It is useful, but not mandatory, to tell us:

• the page or service you were using;
• what you were trying to do;
• what went wrong;
• your browser or device where relevant;
• the assistive technology you were using, if any; and
• the format or adjustment that would help.

Do not include:

• passwords;
• active API secret keys; or
• unnecessary sensitive personal information

in an accessibility report.

If information provided through KleipData is not accessible to you, you may ask us whether it can be provided in an alternative accessible format.

Depending upon the information and circumstances, an alternative might include:

• accessible HTML;
• structured text;
• an accessible electronic document;
• a data table;
• plain text;
• another electronic format; or
• reasonable assistance in accessing the relevant information.

Please contact:

support@kleipdata.co.uk

and explain the information you require and the format that would assist you.

We will consider requests reasonably and take account of:

• accessibility needs;
• information security;
• confidentiality;
• data-protection requirements;
• Supplier restrictions; and
• technical feasibility.

Where appropriate, we will consider reasonable adjustments to help disabled users access KleipData Services.

An adjustment may relate to:

• how information is provided;
• how support is delivered;
• an alternative accessible format;
• assistance with a particular process; or
• another reasonable means of reducing an accessibility barrier.

Accessibility requests will be considered individually because the appropriate solution can depend upon the user’s needs and the particular Service involved.

KleipData Support is available 24 hours a day, 7 days a week.

You can contact us by:

• live chat where available;
• email at support@kleipdata.co.uk; or
• telephone where arranged on request.

Accessibility-related requests may be submitted through the same support channels.

Organisations procuring KleipData may have their own accessibility requirements.

This is particularly relevant to:

• government departments;
• local authorities;
• other public bodies;
• educational organisations;
• regulated organisations; and
• organisations operating their own accessibility standards.

We welcome accessibility requirements during procurement or implementation so they can be considered as part of the relevant deployment.

A Customer’s own legal duties are not transferred to KleipData merely because it uses the KleipData Platform.

KleipData is a private-sector service supplied to both private and public-sector organisations.

Public-sector Customers may be subject to accessibility obligations applying to websites, applications or digital services they provide.

Where KleipData is configured, branded or integrated as part of a Customer’s public-facing service, accessibility responsibilities should be considered as part of the implementation.

Where appropriate, KleipData can work with the Customer to identify accessibility requirements relevant to the KleipData-controlled portions of the service.

KleipData may provide white-labelled or Customer-branded interfaces.

Accessibility of the underlying KleipData-controlled interface remains an important design consideration.

However, Customer changes can affect accessibility, including changes to:

• colours;
• contrast;
• logos;
• fonts;
• content;
• links;
• documents;
• embedded components; and
• third-party integrations.

Customers configuring branded deployments should select branding and content that preserve appropriate accessibility.

KleipData may impose technical limitations on customisation where necessary to maintain security, functionality or accessibility.

Digital services change over time.

New:

• pages;
• datasets;
• features;
• components;
• integrations;
• reports;
• workflows; and
• devices

may introduce new accessibility considerations.

For that reason, accessibility is treated as an ongoing product and service responsibility rather than a one-time certification exercise.

We may update this Accessibility Statement following:

• accessibility testing;
• introduction of new Services;
• significant Platform changes;
• identification or remediation of accessibility issues;
• changes to applicable standards;
• regulatory guidance; or
• user feedback.

The date of the latest review will be shown at the top of this page.

This statement was prepared on 30 August 2026.

It was last reviewed on 30 August 2026.

KleipData is currently working towards formal evaluation of its relevant digital interfaces against WCAG 2.2 Level AA.

A claim of full WCAG 2.2 AA compliance has not been made at this stage because a comprehensive accessibility audit confirming that status has not yet been completed.

Following formal testing, this section should be updated to identify:

• when the service was tested;
• what was tested;
• who performed the test;
• the methodology used; and
• the resulting compliance status.

If you:

• cannot access part of KleipData;
• need information in another format;
• have difficulty using a feature;
• identify an accessibility issue;
• require a reasonable adjustment; or
• have suggestions for improving accessibility,

please contact:

KleipData Operated by Computerko Limited 27 Old Gloucester Street London WC1N 3AX United Kingdom

Company Registration Number: 11125670

Email: support@kleipdata.co.uk

Please use Accessibility in the subject line where convenient.

Our objective is that accessibility should be considered throughout the KleipData experience — from the public website through to authentication, search, casework, data review, API administration, support and reporting.

Where we identify an accessibility barrier within a KleipData-controlled service, we will assess the issue and work towards an appropriate solution based on its impact, severity and technical context.

We welcome accessibility feedback because real-world use by people with different access needs is an important part of improving the service.