Accessibility at Solves, in plain English.
A support tool should be usable by everyone on your team and everyone who reads about it. Here is how we build the Solves website towards the WCAG 2.2 AA target, stated honestly: server-rendered HTML that works without JavaScript, visible keyboard focus, support for reduced motion, semantic structure and a palette designed for contrast. Solves is a pilot, this work is ongoing, and we say plainly what is in place and what is still coming.
No conformance badges, no over-claiming. We describe what is built and what is in progress.
The short answer
Our accessibility commitment
We want the Solves website to be usable by as many people as possible, including people who navigate by keyboard, who use a screen reader or other assistive technology, who prefer less motion, or who need larger or higher-contrast text. We build the site towards the WCAG 2.2 AA target and treat barriers as bugs to be fixed.
We want to be clear about what that target means. Building towards WCAG 2.2 AA means we use those success criteria as the standard we are working to meet across the website. It does not mean we are claiming conformance, and it does not mean every page is perfect today. Solves is a pilot, accessibility is ongoing work, and we have not commissioned a formal audit or sought a certification. Where something is not yet right, we would rather say so and fix it than paper over it with a badge.
This statement covers the public Solves website (the marketing and information pages). The signed-in product is being built to the same intent, and we are improving it as the pilot continues. If you hit an accessibility barrier anywhere, in these pages or inside the product, we want to hear about it, and there is a simple way to report it further down this page.
What is in place
How the site is built for access
Concrete things that are true of how the Solves website is built today, not aspirations.
Works without JavaScript
Pages are server-rendered HTML, so content, links and navigation work with JavaScript off or blocked. We use progressive enhancement, adding script only on top of an already working page, so a failed script never leaves you stranded.
Semantic structure
Pages use real landmarks and a logical heading order, so the document outline makes sense to a screen reader and to anyone skimming. Links and buttons are proper, named elements rather than unlabelled controls.
Visible keyboard focus
The site is built to be operated by keyboard, and the element you are on shows a visible focus ring through a dedicated focus-visible token, so you can always see where you are as you tab through a page.
Reduced-motion support
If your device prefers reduced motion, the homepage animations respect that and do not play. Motion is decorative, never essential, so switching it off removes no information or function.
Descriptive link text
Links describe where they go, such as read our security page, rather than leaving a bare web address or a vague click here, so the destination is clear out of context and to assistive technology.
Contrast in mind
The colour palette was chosen with text and background contrast in mind, and we avoid using colour alone to carry meaning. We are still checking individual combinations against the WCAG 2.2 AA contrast target as ongoing work.
Saying it straight
What we do not claim
It is easy for an accessibility page to over-promise. We would rather be useful than impressive, so here is what we are not saying about the Solves website, and why.
Not certified, not audited
We have not commissioned an independent accessibility audit and we hold no accessibility certification, so we do not display conformance badges. We describe the concrete practices that are genuinely in place and let you judge them, rather than implying a verified rating we have not earned.
No conformance claim
We do not say the site is WCAG compliant or fully accessible. We say we build towards the WCAG 2.2 AA target, because that is the honest description of work in progress on a pilot. We expect to find issues, and we treat each one as a bug to be fixed rather than a reason to soften the claim.
Limited testing, so far
We build to accessibility good practice, but we have not yet run a broad programme of screen-reader and assistive-technology testing across every page and combination of tools. That work is part of the ongoing effort. Reports from people using real assistive technology are some of the most valuable feedback we can get, which is why we make it easy to send one.
Reporting a problem
How to tell us about an accessibility barrier
Note what happened
Jot down what you were trying to do and what got in the way, for example a control you could not reach by keyboard, text that was hard to read, or focus that disappeared.
Note your setup
Tell us the page you were on and the browser, device and any assistive technology you were using, such as a screen reader or magnifier. That detail helps us reproduce the issue quickly.
Get in touch
Send it through our contact page. We read every report, treat accessibility barriers as genuine bugs, and will let you know what we find and what we plan to do about it.
Found an accessibility barrier?
Please get in touch through our contact page with the page you were on and the browser or assistive technology you were using, and we will investigate. The more detail you can give, the faster we can put it right.
FAQ
Accessibility questions, answered
Is Solves WCAG compliant?
We do not claim compliance, and we will not. We build the Solves website towards the WCAG 2.2 AA target, which means we treat those success criteria as the bar we are working to meet rather than a box we have ticked. Solves is a pilot, accessibility work is ongoing, and we have not commissioned a formal audit or certification. We would rather describe what is genuinely in place and what is still in progress than imply a conformance level we cannot evidence.
Does the site work without JavaScript?
Yes. The Solves website is server-rendered HTML, so pages, links and core content load and work with JavaScript switched off or blocked. We use JavaScript only to enhance an already working page, an approach called progressive enhancement, so a script that fails to load does not leave you with a blank or broken screen. The reading and navigation experience does not depend on client-side rendering.
Can I use the site with a keyboard?
The site is built to be operated by keyboard, using semantic links and buttons in a logical reading order. When you tab through the page, the element you are on shows a visible focus ring, so you can always see where you are. If you find a place where keyboard focus is lost, trapped or hidden, that is a bug we want to hear about, and you can report it through our contact page.
Does Solves respect reduced-motion settings?
Yes. If your device or browser is set to prefer reduced motion, the animations on the Solves homepage respect that preference and do not play, so movement is not forced on people who find it uncomfortable or distracting. We keep motion decorative rather than essential, so turning it off never removes information or function.
How do I report an accessibility problem?
Please get in touch through our contact page and tell us what you were trying to do, the page you were on, and the browser or assistive technology you were using. That detail helps us reproduce the issue and fix it. We read every report and treat accessibility barriers as genuine bugs, not nice-to-haves, so the more you can tell us the faster we can put it right.
Is the colour palette designed for contrast?
The Solves palette was chosen with text and background contrast in mind, so body copy and important controls are designed to stay legible. We also avoid relying on colour alone to carry meaning. We are still checking individual combinations against the WCAG 2.2 AA contrast target as part of ongoing work, so if any text is hard to read on your screen, please tell us where through the contact page.
Help us make Solves easier to use
If something on the site is hard to use, tell us. We treat accessibility barriers as bugs and fix them.