Cloud API Tokens

Accessibility Statement

Our commitment to WCAG 2.2 Level AA, the measures we have taken, known limitations, and how to tell us when something does not work.

Last updated: November 4, 2026

Vaillant GmbH wants everyone to be able to find and claim a cloud or API credit offer on Cloud API Tokens (https://www.cloudapitokens.com), including people who use screen readers, keyboard navigation, magnification or voice control. This statement describes the standard we aim for, what we have done, what still falls short and how to reach us.

1. Our standard

We aim to conform to the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA, published by the World Wide Web Consortium in October 2023. We treat WCAG 2.2 AA as our benchmark because it is the standard referenced by the Department of Justice's 2024 rule under Title II of the Americans with Disabilities Act and is the standard most often cited in Title III litigation involving websites. The Site is tested against it before launch and after every significant design change.

2. Measures we have taken

  • Semantic HTML. Pages use native headings, lists, tables, buttons and landmarks so assistive technology can describe the structure. Offer cards are marked up so the credit amount, its conditions, its expiry and its verification date are read in a sensible order.
  • Keyboard navigation. Every interactive element, including the consent banner, the "Claim offer" link, filters, the account page and the submission form, can be reached and operated with a keyboard alone. Focus is visible at all times and is not trapped. A "Skip to content" link is the first focusable element on every page.
  • Color and contrast. Text meets at least a 4.5:1 contrast ratio against its background, and large text and interface components meet 3:1. Information is never conveyed by color alone; a verified offer has a text label as well as a green mark, and an expired offer is labeled in words.
  • Text and zoom. Text can be resized to 200% without loss of content, and pages reflow at 320 CSS pixels wide without horizontal scrolling.
  • Alternative text. Images that carry meaning have descriptive alt text. Provider logos are labeled with the provider name. Decorative images are hidden from assistive technology.
  • Reduced motion. We respect the prefers-reduced-motion setting; with it on, animations and transitions are disabled.
  • Forms. Every field has a visible label, errors are described in text and announced, and the form does not time out.
  • Tables of numbers. Pricing and quota comparisons use real table markup with header cells, so a screen reader can announce which provider and which column a figure belongs to.
  • Target size. Buttons and links meet the 24 by 24 CSS pixel minimum in WCAG 2.2 success criterion 2.5.8.
  • Consent banner. The banner is an accessible dialog with a clear heading, labeled controls and keyboard dismissal, and declining is as easy as accepting.

We test with automated tools (axe-core and Lighthouse) on every build, and by hand with VoiceOver on Safari, NVDA on Firefox and keyboard-only navigation on Chrome at least quarterly.

3. Known limitations

  • Third-party embedded content. Some pages embed content we do not control, such as ad units served by an ad network, a provider's pricing calculator, or a social media post. We cannot guarantee that embedded content meets WCAG 2.2 AA. Where an embed is inaccessible, the surrounding page gives the same information in text.
  • Provider logos from brand kits. Logos are supplied by the providers as image files. Where a logo contains text at low contrast, we provide the provider name in text next to it.
  • PDF program documents. Startup program guides, terms and application forms we link to may be PDFs produced by the providers that lack tags or reading order. Email us if you need the content of a linked PDF in another format.
  • Provider consoles. Once you follow an outbound link, you are in the provider's console or signup flow, which we do not control. If a provider's claim flow is inaccessible to you, tell us and we will describe the steps in text.
  • Analytics session recordings. Microsoft Clarity, when you consent to it, adds a script that some screen readers announce; it does not change page content.

We keep a list of open accessibility issues and their target fix dates and will publish it on request.

4. Compatibility

The Site is built to work with current versions of Chrome, Firefox, Safari and Edge, on desktop and mobile, and with the screen readers listed above. It does not require JavaScript to read offers; with scripts disabled, credit amounts, conditions and the link to the provider remain visible as text, though the consent banner and sign-in will not function.

5. Feedback and contact

If any part of the Site does not work for you, tell us. Email [email protected] with the page address, what you were trying to do, and the browser and assistive technology you were using. You can also write to Vaillant GmbH, Berghauser Str. 40, Remscheid, NW 42859, Deutschland, or call +49 2191 18-0.

We acknowledge accessibility reports within two business days and aim to fix barriers that block access to an offer or a form within five business days, and other issues within 30 days. If we cannot fix something quickly, we will give you the information you were looking for directly in whatever format works for you.

6. Formal complaints

If you are not satisfied with our response, you may file a complaint with the United States Department of Justice, Civil Rights Division, at civilrights.justice.gov, or, in Texas, with the Texas Workforce Commission Civil Rights Division.

7. Review

This statement was prepared on November 4, 2026 based on our own evaluation. We review it at least once a year and whenever the Site is redesigned.