Accessibility Statement

_Last updated: 3 August 2026_

TrustRating exists so that everyone can check who deserves their trust — and "everyone" includes people who use screen readers, keyboards, voice control, magnification, high-contrast modes or reduced motion. This Accessibility Statement describes the standard we aim for, what we have done to meet it, where we currently fall short, and how to get help or complain if something blocks you. It applies to trustrating.ai, business.trustrating.ai and our embeddable widgets.

1. Our standard

We aim for conformance with the Web Content Accessibility Guidelines (WCAG) 2.2, level AA, published by the W3C, and we treat the principles behind them — perceivable, operable, understandable, robust — as design requirements, not afterthoughts. Where regulations apply to us (such as the European Accessibility Act for consumer-facing digital services and, for public-sector-style obligations, the EN 301 549 standard), this statement doubles as the declaration those rules expect.

What the four principles mean for this Service concretely: perceivable — nothing on TrustRating is conveyed only by colour, only by image or only by sound; scores are numbers and text as well as stars, statuses are labels as well as tints, and images that matter carry text alternatives. Operable — everything reachable by mouse is reachable by keyboard, nothing requires precise gestures or timing, and nothing traps focus. Understandable — pages declare their language, navigation stays where you learned it is, forms explain their errors next to the field that caused them, and we write plainly (this legal hub included — compare our Terms of Service with the industry norm). Robust — we build on standard HTML semantics first, so current and future assistive technologies can parse the Service without special-casing it.

2. What we have implemented

Structure and semantics. Pages use semantic HTML: real headings in a logical order, lists for lists, tables for tabular data, landmarks for navigation and main content, and labelled form controls. Interactive components carry appropriate ARIA roles and states only where native semantics are not enough — we treat ARIA as a repair tool, not a substitute for correct HTML, because misused ARIA makes pages less accessible rather than more. Page titles are unique and descriptive, so browser history and screen-reader window lists stay navigable.

Keyboard access. Every interactive element — navigation, search with its suggestion dropdown, review forms, star-rating inputs, dialogs, accordions, the cookie settings panel — is operable with a keyboard alone. Focus order follows the visual order, focus is visibly indicated, and dialogs trap and return focus correctly.

Colour and contrast. Our design tokens were chosen so that text meets or exceeds the WCAG AA contrast ratios against its background, in both the light interface and the dark bands. Colour is never the only carrier of meaning: scores come with numbers and text, statuses come with labels and icons, links are distinguishable by more than hue — a rule that matters to roughly one in twelve men, whose colour vision differs from the palette designer's, and costs nothing to everyone else.

Motion and animation. The Service uses decorative animation — floating cards, scroll-linked reveals, drifting gradients. All of it respects the "prefers-reduced-motion" system setting: if your operating system asks for reduced motion, animations are disabled or reduced to simple fades, and no content is ever available only through motion. Nothing on the Service flashes at seizure-inducing rates, nothing auto-plays with sound, and no animation blocks or delays access to the content beneath it.

Text and zoom. Layouts are responsive and reflow without loss of content or functionality at 400% zoom and at increased text spacing. Font sizes use relative units so browser text-size settings are honoured.

Images and media. Meaningful images carry alternative text; decorative illustrations are hidden from assistive technology. Star ratings expose their numeric value to screen readers rather than a row of unlabeled glyphs.

Forms and errors. Sign-up, review submission, claims and billing forms have programmatically associated labels, clear required-field indication, inline error messages tied to their fields, and no time limits that cannot be extended. The password fields include a strength meter announced to assistive technology. Destructive actions (deleting a review, closing an account) require explicit confirmation, and drafts of longer inputs survive accidental navigation, so a slip never destroys your work.

Language and readability. Pages declare their language for correct screen-reader pronunciation; interface copy avoids jargon, and where a term of art is unavoidable (TrustScore, verified badge) it is explained where it first matters — the help center and methodology page carry the fuller explanations in plain language.

Consistency. Navigation, search and the footer behave the same on every page; the legal hub you are reading now provides a consistent sidebar index of all policies, starting from the Terms of Service.

3. Known limitations

We are honest about the gaps we know of and are working on:

• Embedded third-party flows. Payment pages are provided by Stripe and NOWPayments on their own domains; their accessibility is governed by those providers. If a payment flow blocks you, contact us and we will complete the transaction with you through an accessible alternative (for example a manually issued invoice — see the Payments & Refunds Policy).
• User-generated content. Review text and images are written by users; we cannot guarantee that user-uploaded images include alt text or that reviews avoid formatting that reads poorly. Our editor encourages plain text, and you can report any specific barrier.
• Embeddable widgets. Widgets render inside iframes on third-party websites. We build them to be accessible in isolation (semantic markup, contrast, text alternatives), but the embedding site controls the surrounding context, and some host-page configurations can impair them.
• Data-dense admin and business dashboards. Some complex management tables and charts in the business panel are still being improved for screen-reader navigation; data in charts is progressively being complemented with accessible tables and text summaries.
• PDF documents. Generated documents such as invoices and reports are progressively being brought to PDF/UA-style tagging; where a document is not yet fully tagged, we will provide the same information in accessible HTML on request.
• Email clients. Our transactional emails are built with semantic table structure, real text and sufficient contrast, but email clients vary wildly in what they render; every email's essential action is always available as a plain text link, and everything an email tells you is also visible in your account, so no information lives only in an email.

None of these limitations is considered acceptable long-term; each is on the improvement roadmap in Section 8, and each has a workaround available through support today.

4. How we test

Accessibility checks are part of development: automated linting for common failures, manual keyboard walkthroughs of new features, colour-contrast verification against our token palette during design, screen-reader spot checks on the main user journeys, and regression checks when core components change. We also treat every accessibility report from a user as a defect with priority.

The journeys we test hardest are the ones that matter most, and this is what you should be able to expect from each. Searching for a company: the search field is labelled, suggestions are announced as they appear, arrow keys move through them, Enter selects, Escape dismisses. Reading a profile: the company name is the page's main heading, the score is announced as a number with its scale, reviews are a list with per-review headings, and the reply from a business is programmatically associated with the review it answers. Writing a review: the star rating is a radio-style input operable with arrow keys and announcing the selected value, the text area is labelled with its requirements, and submission errors name the field and the problem. Claiming a business: the multi-step flow announces progress, every step is completable by keyboard, and email/DNS instructions are plain text that can be copied. Subscribing and billing: plan comparisons are real tables with headers, prices are text (never images), and everything before the processor's own page is keyboard-complete. Managing cookies: the banner and the settings panel are dialogs that trap focus while open, restore it on close, and are fully operable without a pointer. If any of these journeys does not behave as described for you, that is a bug we want reported (Section 6).

5. Compatibility

The Service is built on standards-compliant HTML, CSS and JavaScript and is tested with recent versions of Chrome, Edge, Firefox and Safari, on desktop and mobile, in combination with the platform screen readers (NVDA and JAWS on Windows, VoiceOver on macOS and iOS, TalkBack on Android). Core content — company profiles, reviews, scores, legal pages — remains readable even when JavaScript fails or is disabled; interactive features require JavaScript.

We do not require any particular assistive technology, browser extension or overlay to use the Service, and we deliberately do not bolt on third-party "accessibility overlay" widgets: overlays routinely conflict with the tools disabled users actually run, and we prefer to fix the underlying markup. Users of high-contrast and forced-colours modes (such as Windows High Contrast) should find the interface usable, since we rely on semantic elements that those modes restyle correctly; if a component ever disappears in forced colours, report it — that is a defect by our own standards. Older browsers outside their vendor's support window may degrade visually, but degradation should never remove access to content; where it does, we treat it as a bug within reason.

6. Feedback and assistance

If you encounter a barrier — a control you cannot reach, text you cannot read, a flow you cannot finish — please tell us through the contact page or the help center and include the page address, what you were trying to do, and the assistive technology you use. We acknowledge accessibility reports quickly, aim to fix genuine blockers with priority, and will always offer you an alternative way to complete the task in the meantime (including handling it for you through support where feasible).

What "quickly" means in practice: you will get a human acknowledgement, not an autoresponder silence; a barrier that prevents completing a core journey (Section 4) is treated with the urgency of an outage; and when the fix ships we tell you, because you took the time to tell us. Reports can be made in whatever form works for you — there is no required template, and if writing is itself the barrier, say so and we will arrange another channel.

7. Enforcement and complaints

If you believe we have not responded adequately to an accessibility issue, you can escalate the complaint to the market-surveillance or equality body responsible for digital accessibility in your country; in EU member states these are the bodies designated under the European Accessibility Act's national implementations, and your national disability-rights organisation can usually point you to the right door. We would ask for the opportunity to fix the problem first — and we mean it: accessibility reports go to the same engineers who build the product, not into a queue we ignore. Nothing in this statement limits any right you hold under disability-equality law, and this statement itself is not a contract term that could waive one — it is a published commitment you are entitled to hold us to.

8. Continuous improvement

Accessibility is never "done". Our roadmap includes ongoing audits against WCAG 2.2 AA, improved chart alternatives in dashboards, and tagged PDFs for all generated documents. New features are assessed for accessibility before launch rather than retrofitted after complaints, and the shared component library that pages are assembled from is where most fixes land — repairing a component once repairs it everywhere it is used, which is how a small team keeps a large product honest.

This statement is reviewed and updated at least once a year, and whenever a significant feature changes what we can honestly claim. Claims here are meant to be checkable: if this page says a journey works with a keyboard and it does not, the page is wrong or the code is, and either way we owe you a fix. The "Last updated" date above reflects the most recent review.