Accessibility statement

1. What this statement covers

This statement is published by Kalotect Ltd, trading as Kalotect, a company registered in England and Wales with company number 17517329. In it, “we”, “us” and “our” mean Kalotect, and “you” means anyone using our website or the client portal.

It covers two places:

• our website at kalotect.com; and
• the client portal at portal.kalotect.com, including the pages on which you sign in. In the portal our clients approve work, answer our questions, read the summaries and actions from our meetings with them, follow their projects, and see their site’s uptime and speed, their documents and invoices, their modules and social posts, their tickets and their Ledger.

This statement describes the portal as it stood on the day it was last reviewed, which is given at the end. We are adding to the portal, and a part added after that day has not yet been tested against the standard. We add each new part to this statement once we have tested it. Until then, if a new part does not work for you, tell us and we will give you another way to do what you need.

It does not cover:

• the websites we build for our clients. Each belongs to the client whose site it is, and so does its accessibility statement. What we promise about the accessibility of a site we build for you is set out in our terms and your engagement schedule, not here;
• the pages on which you pay an invoice by card or set up a Direct Debit, which our payment provider, Stripe, runs on its own site. If Stripe’s page does not work for you, tell us and we will give you another way to pay, such as by bank transfer; or
• our staff console, which only the people who work for us use. We build it to the same standard.

We want as many people as possible to be able to use our website and the portal, whatever device they use and however they use it.

2. Using our website and the portal

You should be able to:

• change colours, contrast levels and fonts using your browser or device settings;
• zoom in with your browser, because our pages rearrange themselves to fit a narrow screen rather than run off the side of it;
• reach everything using only a keyboard, with a focus ring you can always see and that is never hidden behind a header, and a link at the top of every page that skips straight to its content;
• use buttons, menus, form controls and links on a line of their own on a touch screen without needing precision, because we make each of them at least 44 pixels high;
• stop animation by asking your device for reduced motion, after which our pages show everything still, our mark included;
• read in a light theme or a dark one. Both follow your device’s setting, and on our website you can also choose with the switch in the header; and
• sign in to the portal without a password to remember or a puzzle to solve, using a passkey or a link sent to your email address.

We build our pages to work with screen readers and speech recognition software: we use standard HTML, every form field has a label, and every page has one main heading with the headings below it in order. But no person has yet tested every page with a screen reader or with speech recognition software, so we do not yet claim that every page works with them. If one does not, tell us.

We write in plain English, in short sentences, and use a plain word where there is one. Figures in the portal, such as your site’s uptime and speed, are given in words and in tables, and colour never carries a meaning on its own.

If you have a disability, AbilityNet has advice on making your device easier to use, at mcmw.abilitynet.org.uk.

3. How far we meet the standard

We work to the Web Content Accessibility Guidelines (WCAG) version 2.2, at level AA. WCAG is the international standard for making websites accessible. We apply it in both themes, on desktops and on phones.

Our website is partially compliant with WCAG 2.2 AA. We know of nothing on it that fails the standard, but we have not yet tested every page, so we cannot say that every page meets it. The pages not yet tested are listed below.

The client portal is partially compliant with WCAG 2.2 AA, because of the three things listed in the next section, and because some of its pages have not yet been tested.

4. What does not meet the standard yet

These are the parts of the portal that we know do not meet the standard, or may not, and what we are doing about each.

• A pulsing dot. At the top of every page of the portal, a small dot beside your site’s status pulses gently for as long as the page is open, to show that the status is live. It stops if your device asks for reduced motion, but there is no control on the page itself to stop it. This does not meet success criterion 2.2.2 (pause, stop, hide). We are changing it so that it stops on its own within five seconds.
• Time limits. To protect your account, the portal signs you out twelve hours after you signed in with an email link. If you signed in with a passkey, it signs you out twelve hours after you last used it, and thirty days after you signed in at the latest. Before you pay an invoice, set up a Direct Debit, start a module, export your Ledger, add or remove a passkey, or change your settings or who can sign in, it asks you to confirm it is you if you have not done so in the last ten minutes. Cancelling a module does not ask: it takes one click, as our terms of business say. A sign-in link works for fifteen minutes. The portal does not warn you before one of these limits runs out, or let you extend it, so if you are part way through something you may need to sign in again and start it again. This may not meet success criterion 2.2.1 (timing adjustable). We are adding a warning before you are signed out, with a way to stay signed in.
• Documents shared as files. Some documents we share with you in the portal are files, such as a proposal as a PDF or a report as a Word document. We do not yet check every file against the standard before we share it, so some may not work well with a screen reader or when enlarged. This may not meet several success criteria, including 1.3.1 (info and relationships). If a document does not work for you, ask, and we will send it in a form that does, as described below. We are adding an accessibility check to the way we prepare documents.

We are not claiming that fixing any of these would be a disproportionate burden. We will fix each of them, and update this statement when we have.

If you find something we have missed, we would like to know. It is more useful to us than a compliment.

5. What we have not tested yet

We have not yet tested these pages against the standard, either with our automated check or by a person. We know of no problem on them, but we cannot say that they meet it:

• on our website: our terms, cookies, AI disclosure and accessibility pages, the pages for our services other than websites, each journal entry, each case study, the page you see after you send us a brief, and the page you see when a page cannot be found;
• the pages on which you sign in, choose an account, confirm it is you, accept an invitation, add a passkey or sign out; and
• in the portal: approvals, questions, projects, the Ledger, invoices, site health, search, social, modules, tickets and settings, the welcome you see on your first visit, and the page you see when a page cannot be found.

We have also not yet tested any page at the narrowest width the standard asks for, which is what a desktop screen shows when zoomed to four hundred per cent.

If one of these pages does not work for you, tell us, and we will help you do what you need another way while we put it right.

6. How we test

We check accessibility in three ways: with automated tests, by hand, and in the rules we design and build to. Much of this work, like much of our building, is done by AI agents (Claude, made by Anthropic) working in our code under our direction. We say so because who tested something matters to how far you can rely on it.

Automated tests. When we propose a change to our code as a pull request, our build pipeline opens pages in a browser at the size of a desktop screen and at the size of a phone, asks for reduced motion so that each page is measured at rest, and runs axe, an automated accessibility checker, against the WCAG 2.0, 2.1 and 2.2 rules at levels A and AA. It also checks that each page has one main heading, and that the portal pages it measures do not scroll sideways on a phone. Not every change to our code has gone through a pull request, and a change that did not was not checked this way. We are changing how we work so that every change is checked, and so that a change that fails the check cannot be merged.

That check covers the pages most people use: the home, work, web services, pricing, journal, about, privacy and start pages of our website, and the home, documents and meetings pages of the portal. We chose them as the pages most visitors and clients see first. The pages it does not yet cover are listed under “What we have not tested yet”.

Two further automated tests run on the same pull requests. Lighthouse, a tool from Google, must score our home, pricing and start pages at least 95 out of 100 for accessibility. A separate test checks the contrast of the colour pairs in our design system, in both themes, and fails if any falls below the level WCAG 2.2 AA asks for.

By hand. So far our keyboard checks have been an automated walk through each page with the keyboard, made in the review described at the end of this statement. We do not yet have a record of a person checking every page with a keyboard or with a screen reader, and some pages, including our not-found pages and the page that opens a sign-in link, have not been tried with a screen reader at all. We are putting that right, and will record who tested each page, with which screen reader, and when.

In the rules we build to. Buttons and controls on a line of their own are at least 44 pixels high, where the standard asks for 24. Whatever takes focus shows a focus ring and is scrolled clear of a header that stays on screen. Reduced motion removes every animation. Colour never carries a meaning on its own. Every form field has a label. Every image has a text alternative, or is marked as decoration; where an AI agent drafts the text, a person checks it before it is published.

Automated tests find only some kinds of problem, which is why checks by a person matter. We test the website and the portal ourselves. They have not been audited by an independent accessibility specialist, and we have not yet tested them with disabled people who use assistive technology every day. We want to do both before we claim more than we can show.

7. Telling us about a problem, and other formats

If something on our website or in the portal does not work for you, or you need information in another format, tell us in whichever way suits you:

• by email to hello@kalotect.com;
• if you are a client, by raising a ticket in the portal and choosing “Something is not working”;
• by post to Kalotect Ltd, Lambourne House, London Road, Riverhead, Sevenoaks TN13 2DE; or
• by asking us, in any of these ways or through someone acting for you, to call you or to meet you. We will call you at a time that suits you, through Relay UK if you use it, or meet you in person. If you would like a British Sign Language interpreter for a call or a meeting with us, tell us and we will arrange one.

Tell us the page, what you were trying to do and what happened. If you use assistive technology and are happy to say which, that helps us find the problem sooner. You do not need to know which part of the standard is involved.

We will reply within two working days, and tell you what we are going to do and by when. If the problem stops you doing something, we will help you do it another way while we fix it.

If you need something on our website or in the portal in another format, such as large print, plain text, an accessible document or a document read to you, or captions, a transcript or a description of a video or image we have made for you to review, ask and we will send it within five working days.

If you need more time to answer a question in the portal because of a disability, or because you are waiting for something from us in another format, tell us before it expires. We will ask the question again with a later date. If the first one falls to its default before you have answered, your answer to the new one replaces it. An approval never falls to a default, so if you need more time to give one, tell us, and the work that depends on it waits for you.

8. If you are not happy with our response

Please tell us first, so that we have the chance to put it right. Telling us first does not stop the time limit for a court claim from running.

In England, Scotland and Wales, the Equality Act 2010 requires businesses that provide services to make reasonable adjustments, so that disabled people are not put at a substantial disadvantage. In Northern Ireland the Disability Discrimination Act 1995 applies instead, with a similar duty. We treat our website and the portal as part of the service we provide, and we apply that duty to them.

The Equality and Human Rights Commission (EHRC) enforces the Equality Act 2010 in England, Scotland and Wales. If you contact us with a complaint and you are not happy with our response, contact the Equality Advisory and Support Service (EASS), which gives free advice about discrimination, including how to take a complaint further. In Northern Ireland, the Equality Commission for Northern Ireland can help.

A claim to court about disability discrimination must normally be brought within six months of what it is about. Nothing in this statement limits any right you have under the law, including the right to take a claim to court.

9. Technical information about accessibility

Kalotect is committed to making its website and the client portal accessible. We are not a public sector body, so the Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 do not apply to us. We use the model accessibility statement published for those regulations as our guide all the same, because it asks the right questions and gives you the answers in a form you may already know.

Our pages are written in HTML, CSS and JavaScript, and rely on them to work with the assistive technology on your device. Each page declares its language as British English, so a screen reader reads it with the right voice.

10. What we are doing to improve

We are:

• running our automated tests on every change to our code, not only on those proposed as pull requests, and making a passing test a condition of merging a change;
• extending our automated check to every page of our website and the portal, and to the narrowest width the standard asks for;
• having a person check every page with a keyboard and with a screen reader, and recording who did it, with what, and when;
• stopping the portal’s status dot from pulsing for more than five seconds;
• adding a warning before the portal signs you out, with a way to stay signed in;
• checking every document against the standard before we share it as a file; and
• arranging to test the website and the portal with disabled people who use assistive technology.

We have not yet set a date for each of these. When we have, we will give it here, and we will update this statement as each is done.

11. Preparation of this statement

This statement was first prepared on 16 September 2026. This version was prepared on 8 October 2026, when we brought what it says about confirming it is you up to date, and takes effect on the date shown with its version number. It was last reviewed as a whole on 7 October 2026, against the website and the portal as they stood that day.

The website and the portal were last tested as a whole on 28 September 2026, in a review of their design against WCAG 2.2 AA. The review was carried out by an AI agent (Claude, made by Anthropic) working for us. It visited every page that five kinds of visitor could reach (a member of the public, two clients, a member of our staff and our owner), in both themes and at three screen widths, measured focus, the size of controls, contrast, layout and headings by machine, and walked through each page with the keyboard. We fixed each failure against the standard that it found. It did not include a person testing with a screen reader. Pages added since then have been tested only by the automated tests described above, where those cover them.

We review this statement whenever our website or the portal changes in a way that could affect it, and at least once a year.