Accessibility Statement

Accessibility is not a feature we add at the end. It is the first rule we write by. Intelligent Singularity builds software meant to serve every human being, which means every human being must be able to read the page, press the button, fill in the form, and hear the result — whatever device they are using and whatever ability they have.

This statement explains the standard we follow, how we test ourselves against it, what we have already done, what we know is not finished, and how to tell us when something is wrong.

Our target standard

We aim to meet the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA across every public page of this website, and to reach Level AAA on text contrast whenever the typography allows. Where a local rule is stricter than WCAG — for example the European Accessibility Act, the United Kingdom Equality Act, or the Accessible Canada Act — we follow that stricter rule as well.

What that standard means in practice

• Every page uses semantic HTML first. ARIA is added only when the meaning would otherwise be missed.
• Every interactive element works from the keyboard, in a predictable order, with a visible focus outline that never hides under other elements.
• Every page ships a "skip to content" link as its first focusable item.
• Body text meets a contrast ratio of at least 7:1 against the background. Small supporting labels meet at least 4.5:1.
• All colour is designed to be understood even if it is read as greyscale. Meaning is never carried by colour alone.
• All motion honours the "prefers-reduced-motion" setting in your operating system, so animations pause when you ask them to.
• All forms use real labels connected to real inputs, with clear error messages and helpful hints underneath, and no placeholder-as-label patterns.
• All images used for meaning ship with concise alternative text. Images that are purely decorative are hidden from screen readers.
• All videos and audio clips carry captions and transcripts in every language the page is offered in.
• All fourteen languages we ship on day one render with fonts that include the full script, with no glyph fallbacks in the middle of a word.
• Right-to-left languages (Arabic and Urdu) are rendered in a proper RTL layout, not flipped or mirrored Latin blocks.

How we test

Every code change runs an automated accessibility scan, called axe-core, inside our continuous integration pipeline. If a single violation is found, the change cannot be merged.

Before every major release we also run manual tests with three screen readers (one on each major desktop and mobile operating system), with keyboard-only navigation, with the operating system set to 200 percent text size, and with high-contrast mode turned on. We record the recordings internally so our engineers can watch what a blind or low-vision visitor actually experiences.

Twice a year we hire an external accessibility reviewer who is a daily screen-reader user. Their report is published on /insights and the issues they raise become the first items in the next release plan.

What works well today

• Full keyboard operation on every page.
• Visible focus on every interactive element.
• Zero automated axe-core violations on the current build.
• Full support for browser-level zoom to 400 percent without horizontal scrolling.
• Full support for reader mode, print mode, and dark-to-light operating system switches.
• Fourteen shipping languages with per-script typography.

What we are still improving

Honest accessibility work is never finished. These are the items we know about and are working on right now:

• Adding audio description tracks to the small number of product trailer videos on partner domains.
• Adding long-form alternative text for the few infographics that summarise complex statistics, so they are also readable as a structured table.
• Moving our sign-language introduction (for the about page) out of draft and onto production.
• Continuing to widen the pool of external accessibility testers to include neurodivergent users and users with motor impairments.

Assistive technologies we test with

• Screen readers on desktop and mobile operating systems used by most of our global audience.
• Speech-to-text dictation and voice control tools on those same platforms.
• Switch access controllers used by people with limited hand movement.
• Magnifiers, high-contrast themes, and custom colour filters in modern browsers.

Low bandwidth and old devices

Accessibility also means being able to load the page at all. Every route on this site is designed to fit inside a fifty-kilobyte first-paint budget, gzipped, so it works on a slow mobile connection and on a phone that is five years old or more. Where a page must load something heavier, it loads on demand and only after you ask for it.

Report an accessibility problem

If you hit a barrier of any kind — a missing label, a trap, a contrast problem, a feature that does not work with your assistive tool — please write to accessibility@intelligentsingularityinc.com with the page address and a short description of what went wrong. You may attach a recording or screenshot if that is easier.

We reply within two working days and treat accessibility reports as high-priority bugs. When a fix is shipped, we credit the reporter in the release notes unless they prefer to stay anonymous.

Alternative channels

If the form is not an option for you, we welcome contact by email, by telephone, or by letter. Details are on the /contact page. Every channel is read by the same small team.

Your legal rights

Accessibility is both a moral commitment and a legal requirement in many places where we operate. If you believe a part of this website does not meet the law that applies where you live, you may contact your national accessibility regulator. Please consider writing to us first so we can fix the issue quickly.