Accessibility

This statement applies to the Alltra marketing website — the pages at alltra.app that anyone can reach without signing in, including this one, the product pages, the Alltra Guide, the support pages and the legal documents.

It does not cover the signed-in Alltra application. That is a separate surface built on a separate component library, it has not been through the same assessment, and we are not going to imply otherwise by staying silent about the distinction. It also does not cover content hosted by third parties that we link to.

The Web Content Accessibility Guidelines (WCAG) define requirements for making web content more accessible. This website is partially conformant with WCAG 2.2 level AA.

"Partially conformant" means that most of the standard is met but some parts are not. We are not claiming full conformance, because the assessment described below found defects that are still open. Those defects are listed in section 5, by name, rather than summarised.

The site was assessed on 15 August 2026 by Alltra, internally. It has not been audited by a third party.

The assessment covered fifteen routes and used the following methods:

• Inspection of the rendered HTML for landmarks, heading structure, accessible names on interactive controls, form labelling and text alternatives for images.
• Contrast ratios calculated from the resolved design-token values against the actual background each colour is used on, rather than estimated by eye.
• Review of the focus, keyboard and reduced-motion behaviour defined in the stylesheets.
• Review of the criteria added in WCAG 2.2, including target size, dragging movements and focus visibility.

What we did not do matters as much. We have not tested this site with screen readers or other assistive technology, so nothing here should be read as a claim about how it behaves in JAWS, NVDA, VoiceOver or TalkBack. We have not carried out testing with disabled users. The assessment covered the site's default rendering; it did not separately cover every theme. We would rather say so than let a reader assume a level of verification we have not reached.

The following were checked across every route in scope and pass:

• Every page declares its language, exposes main, header, navigation and footer landmarks, and begins with a skip link so keyboard users can jump past the navigation.
• Every image carries a text alternative, and images that are purely decorative are marked so assistive technology skips them rather than announcing a filename.
• Every interactive control has an accessible name. Icon-only buttons carry their own label rather than relying on the icon.
• Every form field has a real, associated label, so clicking the label focuses the field and a screen reader announces it.
• Fields that ask for your name or email address declare what they are, so a browser or assistive technology can offer to fill them in for you.
• When a form field is rejected, the field itself is marked as invalid and the reason is linked to it, so the explanation reaches you at the field rather than as a lump at the top of the page.
• Keyboard focus is always visible: a two-pixel accent outline at 3.94:1 against the dark page background, above the 3:1 the standard requires of a focus indicator, and form fields show a full accent border rather than a faint ring.
• Body text clears the 4.5:1 minimum comfortably — 17.29:1 for primary text and 8.43:1 for secondary text against the page background.
• Animation is not forced on anyone. Every animated panel on the site honours the operating system's "reduce motion" setting and renders a still frame instead.

These are the defects the assessment found that are still open. They are listed with the criterion they fall under so you can judge the severity for yourself rather than take our word for it.

• Our lightest grey text — used for small print such as the copyright line in the footer — has a contrast ratio of 3.76:1 against the page background, below the 4.5:1 that WCAG 2.2 AA requires for text this size (criterion 1.4.3). Icons drawn in that same grey are non-text, where the requirement is 3:1, so those pass.
• Text set in our accent blue, which is how links inside a paragraph are marked, reaches 3.94:1 against the dark background rather than the 4.5:1 required (criterion 1.4.3). The same colour used as a focus outline or a border is non-text and clears its own 3:1 bar.
• Every field on the contact and support ticket forms is required, and nothing says so until you submit. Errors are reported correctly once they happen — the problem is that you have to cause one to learn the rule (criterion 3.3.2).
• The scrolling strip of broker logos on the home page pauses when you hover a mouse over it, but there is no equivalent that works from the keyboard or on a touch screen (criterion 2.2.2). It does stop completely if you have asked your system to reduce motion.
• The changelog page has no top-level heading, and two pages skip a heading level, which makes navigating by headings less predictable than it should be (criterion 2.4.6).

We are not putting dates against these. A published date we then miss is worse than none, and this statement is updated when a fix ships rather than on a schedule. If one of them is blocking you now, say so in a message and it moves up.

A few decisions are worth naming, because they are the reason most of section 4 passes rather than happy accidents.

• Content is server-rendered. The text of every page is present in the markup before any JavaScript runs, so a reader that does not execute scripts still gets the page.
• The step-by-step illustrations in the Alltra Guide are built from real interface markup rather than screenshots, and they are hidden from assistive technology with the explanation carried in the surrounding text. A picture of a form is not something a screen reader should try to walk through.
• Colour is not used as the only way of conveying information; anything indicated by colour is also indicated by text or shape.
• The site is built with standard HTML elements — real buttons, real links, real lists, real form fields — in preference to elements given a role afterwards.

If you cannot complete something on this site because of an accessibility barrier, contact us and we will get you the same outcome another way. That includes signing up, getting support, and reading anything published here in a different format.

This is not a courtesy. If our site is the reason you cannot do something, the fix is ours to find, and in the meantime the work still needs doing.

If you contact us about an accessibility problem and are not satisfied with our response, you are entitled to escalate it. In the United States, complaints about disability discrimination may be brought to the U.S. Department of Justice Civil Rights Division. Your local jurisdiction may provide its own route, and using it does not require our agreement.