Sign in
Start free

Legal

Accessibility Statement

Last updated

1. What this statement covers

GrantCookie is a cookie consent management platform for websites. This statement is about the accessibility of our own website and application. It sets out the standard we aim to meet, what we can and cannot yet say about how far we meet it, the limitations you may come across, and how to tell us when something does not work for you.

In this statement:

  • “GrantCookie”, “we”, “us” and “our” mean GrantCookie, the provider of the service.
  • “The website” means the public pages at grantcookie.com.
  • “The application” means the pages at app.grantcookie.com, where customers register, sign in and use the service.
  • “The service” means the cookie consent management platform we provide to customers through the website and the application: the cookie scanner, the consent banner, the per-market rules, the consent log, the cookie policy generator and the integrations, including the JavaScript API, together with related support.
  • “A customer” is a person or organisation that holds an account in the application.
  • “A visitor” is a person who reads the website, or opens the application without signing in.
  • “An end user” is a person who visits a customer’s website where the banner runs.
  • “A working day” is any day from Monday to Friday, including public holidays.
  • “You” means anyone who uses the website or the application, whether as a visitor or signed in to the application.

This statement covers the website and the application. It does not cover sites run by other people that the website or the application links to. Where the website or the application takes you to a page run by another company, that company is responsible for the accessibility of its page.

This statement makes no claims about the consent banner that customers show to end users on their own websites. Each customer chooses the banner’s layout, colours, fonts and copy, and those choices affect how accessible the banner is on that customer’s website, for example its colour contrast. Customers who need information about the banner for their own accessibility statement can ask us using the details in section 6.

2. Our commitment

We want everyone to be able to use the website and the application, including people who use a screen reader, a screen magnifier, speech recognition software or a keyboard alone. The same standard applies to the website and to the application, and we will treat an accessibility barrier as a defect to be fixed.

To support this, we will:

  • include accessibility in the design and review of new pages and screens
  • check new pages and screens with a keyboard alone and with a screen reader before we release them
  • record every accessibility problem we find or are told about, and work to fix it as part of normal development work
  • keep a direct route open for reporting a barrier, described in section 6
  • update this statement when we publish an assessment of the website and the application, as section 9 explains

3. The standard we aim to meet

We aim to meet the Web Content Accessibility Guidelines (WCAG) version 2.1 at level AA. WCAG is published by the World Wide Web Consortium (W3C) at www.w3.org/TR/WCAG21. It defines three levels of conformance: A, AA and AAA. Meeting level AA means meeting every level A and level AA success criterion.

4. Conformance status

We have not yet published an assessment of the website or the application against the standard in section 3. Until we do, we make no claim that either of them conforms to it, fully or partially, and you should expect that some content may not meet it.

4.1 Known limitations

The limitations below are not the findings of an assessment. They describe the kinds of problem you are most likely to meet until we have assessed the website and the application, so that you know what to expect and how to get help.

  • Pages and screens. A page of the website or a screen in the application may not yet meet every design rule in section 5. For example, a form field may lack a visible label, a control may be hard to reach with a keyboard, or text may have a colour contrast below the required ratio.
  • Images. An image may have a text alternative that is missing, or that does not describe the image fully.
  • Documents provided as files. If we provide a document as a file, such as a PDF, it may lack tagging, a defined reading order or text alternatives for images. If you need a document in another format, ask us using the details in section 6.

If a limitation stops you from doing something, tell us using the details in section 6, and we will work with you to find another way to get the same information or complete the same task.

5. Design rules we aim to meet

This section sets out the rules we aim to meet when we design and build pages of the website and screens of the application. They are targets, not the results of an assessment. Where a page or screen does not meet one of them, it falls under the limitations in section 4.1, and we would like to hear about it.

5.1 Keyboard navigation

  • Every link, button, menu, form field and dialog should be usable with a keyboard alone.
  • Focus should move through a page in the order in which the page is read.
  • Nothing should trap keyboard focus. When a dialog opens, focus should move into it, and when it closes, focus should return to where you were.
  • Keyboard shortcuts should not rely on a single letter or character, so that they cannot conflict with shortcuts in your assistive technology.

5.2 Focus states

  • Every element that can receive keyboard focus should show a visible focus indicator.
  • The browser’s default focus outline should be removed only where we replace it with an indicator that is at least as visible.
  • The focus indicator should have enough contrast against the colours around it to be seen.

5.3 Colour and contrast

  • Normal text should have a contrast ratio of at least 4.5 to 1 against its background. Large text, and the parts of icons and controls that you need to see in order to use them, should have a ratio of at least 3 to 1.
  • Colour should never be the only way meaning is shown. Links, errors, required fields and states such as “selected” should also be shown with text, an icon, an underline or a change of shape.
  • No content should flash more than three times in any one second.

5.4 Text resizing and reflow

  • Text should follow the text size you choose in your browser or operating system.
  • Pages should stay usable when text is enlarged to 200 per cent.
  • When you zoom in, or use a narrow screen, content should reflow into a single column, so that you do not need to scroll sideways to read a line of text.
  • Text should be real text, not text inside images, except in logos.

5.5 Reduced motion

  • When the “reduce motion” setting in your operating system or browser is on, decorative animation should be removed or reduced to a simple fade.
  • Anything that moves, scrolls or updates automatically for more than five seconds should have a way to pause or stop it.
  • Animation should not carry information that is not also available as text.

5.6 Structure, labels and language

  • Every page should have a title that describes its purpose.
  • Headings should be used in order, and regions such as the main content and the navigation should be marked up so that you can move between them.
  • Link text should make sense on its own, without the surrounding sentence.
  • Every form field should have a label that stays visible. Errors should be described in text next to the field and announced to screen readers.
  • Images that carry information should have a text alternative. Purely decorative images should be hidden from assistive technology.
  • The language of each page should be declared in the page code, so that screen readers use the right pronunciation.
  • Native HTML elements should be used wherever they exist, with WAI-ARIA attributes added only where native HTML cannot express the meaning of a control.

6. Feedback and reporting a barrier

If you find something on the website or in the application that you cannot use, or that is harder to use than it should be, tell us.

Email support@grantcookie.com and put “Accessibility” in the subject line so that we recognise the message.

It helps if your message includes:

  • the address of the page, or the name of the screen in the application
  • what you were trying to do
  • what happened, and what you expected to happen
  • the browser and device you were using, and any assistive technology, if you are happy to tell us
  • how you would like us to reply, including any format you need

You do not need to tell us about any disability or health condition. If you choose to, we use that information only to deal with your message. Our privacy policy explains how we handle the personal data in your message.

We reply within one working day. Once we have looked into the problem, we will tell you what we found, what we will do about it and, where we can, when. If we cannot fix the problem quickly, we will work with you to find another way to get the same information or complete the same task while we work on it.

6.1 Content in another format

If you need content from the website or the application in another format, for example as plain text, ask us at the same address with the same subject line. We will tell you in our reply how soon we can provide it.

6.2 If you are not satisfied with our reply

If you are not satisfied with our reply, reply to it and ask for the matter to be reviewed. We will look at it again and tell you the outcome and the reasons for it.

Depending on where you live, you may also be able to complain to a public body that enforces accessibility or equality law. Nothing in this statement limits that right.

7. Compatibility with browsers and assistive technology

We aim for the website and the application to work with:

  • the current version and the previous major version of the widely used desktop and mobile browsers
  • screen readers in common use on desktop and mobile devices
  • screen magnification and browser zoom
  • speech recognition software
  • operating system settings for large text, high contrast and reduced motion

We do not aim to support browsers that no longer receive security updates from their maker.

If a combination of browser and assistive technology that you rely on does not work with the website or the application, tell us using the details in section 6.

8. Technical specification

The accessibility of the website and the application relies on HTML and CSS, and on JavaScript where a page uses it, working with your browser and any assistive technology you use. If you turn JavaScript off, a feature that relies on it may not work. When we publish an assessment, we will list the technologies it relied on.

9. Assessment

We have not yet published an assessment of the website or the application, whether by self-evaluation or by an external audit. When we do, we will update this statement to say how and when the assessment was carried out, what it covered, what it found and which conformance status it supports.

10. About this statement

This statement was prepared on 28 September 2026. We review it whenever the website or the application changes in a way that affects what it says, and when we publish an assessment. The “Last reviewed” date at the top is updated every time we review this statement, including reviews that find nothing to change.