Accessible from the first release. Fixed at the source.
An audit tells you what is broken. We fix it. Our engineers build new websites that are accessible on
day one, and correct the ones you already run: sign-in and KYC journeys, trading portals and mobile
apps, changed in your code, re-tested with a screen reader and signed off criterion by criterion.
What we build and fix
Every surface your customers touch.
We work where the barriers are: in the templates, components and screens your
customers use every day, not in a layer on top of them.
New accessible websites
Designed and built accessible from the first release: real headings and landmarks, full keyboard
use, labelled forms, readable contrast and content a screen reader can follow. Every page is
audited before launch.
Remediation of the site you have
We correct the template or component behind each barrier, so one fix carries to every page that
uses it, whether the site is hand-coded, built on a framework or run from a content system.
Login, sign-up and KYC
One-time passwords, CAPTCHAs, session time-outs, document upload and e-sign: the steps where a
customer is most likely to be locked out before they begin.
Trading and investing portals
Watchlists, live prices, charts, order tickets and confirmation dialogs, made usable by keyboard
and screen reader without drowning the user in updates.
Mobile apps
Native Android and iOS, cross-platform and web-view apps, fixed for TalkBack and VoiceOver,
larger text, touch target size and screen-reader focus order.
Design systems and component libraries
Fix the button, the modal and the form field once in your library, and every product built on it
inherits the fix with its next release.
What a fix looks like
Before and after, in your code.
Each change we make names the WCAG criterion, the element and what a screen reader
says before and after. The examples below are typical of what we change.
Websites
Fix the template, and every page follows.
Most barriers on a large site come from a handful of templates and components. We trace each
finding to its source and fix it there, so a site of ten thousand pages can be
corrected through a few dozen changes, not ten thousand edits.
Clickable areas become real buttons and links, reachable by keyboard
Headings, landmarks and reading order a screen reader can follow
Images, icons and charts given text that says what they mean
Visible focus, readable contrast and text that reflows when enlarged
Sign-in is the one journey every customer must finish, and the one most often built against
them: codes that cannot be pasted, timers that cannot be extended, errors that appear on
screen but are never spoken.
One-time passwords that can be pasted and filled from the message (3.3.8)
Time limits a user can extend before the session ends (2.2.1)
Errors announced the moment they appear (4.1.3)
CAPTCHAs with an alternative that does not depend on sight (1.1.1)
Document upload, selfie and e-sign steps usable without a mouse
<label for="otp">6-digit code</label> <input id="otp" inputmode="numeric" autocomplete="one-time-code" aria-describedby="otp-err"> <p id="otp-err" role="alert"></p> Code fills from the message. "Invalid code" is spoken.
Illustrative example of a change and its note.
Trading portals
Live markets, without the noise.
A trading screen changes many times a second. Announce every tick and a screen reader becomes
unusable; announce nothing and the user trades blind. We decide, screen by screen, what is
spoken, when, and what is left for the user to ask for.
Price changes stated in words, not only in red and green (1.4.1)
Live updates spoken politely, and only for what the user is watching
Order confirmation dialogs that take focus and return it (2.4.3)
Charts with a data table or summary a screen reader can read (1.1.1)
Keyboard shortcuts that never clash with screen-reader keys (2.1.4)
Order ticketBuy confirmation
Before · 2.4.3, 1.4.1
<div class="modal show">Confirm order</div> <span class="green">2,938.70</span> Focus stays behind the dialog. "Up" is a colour only.
After · fixed in the dialog and price components
<dialog aria-labelledby="confirm-title"> <h2 id="confirm-title">Confirm order</h2> ... </dialog> // opened with showModal() <span>2,938.70 <span class="sr-only">up 1.04%</span></span> Focus moves into the dialog and back to Buy.
Illustrative example of a change and its note.
Mobile apps
Every button named, every screen in order.
On a phone, the screen reader is the whole interface. We fix the app where TalkBack and
VoiceOver read it: names, roles, focus order and grouping, in whichever framework the app is
written in.
Icon buttons with names: "Buy", not "Button" (4.1.2)
Focus order that follows the screen, and lands inside bottom sheets
Text that grows with the phone's text size without being cut off (1.4.4)
Touch targets large enough to hit (2.5.8)
Hardened and secured apps tested on builds you authorise
We start from an audit: ours, or the one you already have. Every barrier
is located on the screen and in the code that produces it.
Fix plan by component
Findings are grouped by the template or component behind them,
and ordered by the barrier each fix removes, so the first changes unlock the most customers.
Fix in your code
Our engineers make the changes in your repository for your team to
review, or work alongside your developers. Nothing is injected from outside your codebase.
Re-test on the same element
Each fix is checked again on the element that failed,
with keyboard and screen reader on desktop and phone, before it is called fixed.
Sign-off
A re-audit report with a position on every WCAG 2.2 A and AA criterion, and
the evidence behind it, ready for your regulator, auditor or buyer.
Keep it fixed
Checks added to your release pipeline and scheduled monitoring, so the
next release does not undo the last one.
Ways to work with us
As hands-on as you need.
We fix it
Our engineers make every change in your codebase, under your review, and hand back a site or app
that has been re-tested and signed off.
We fix it with you
We pair with your developers, review their changes and re-test them, so your team learns the
patterns while the backlog comes down.
We build it
A new website or portal designed and built accessible from the first release, audited before
launch and handed over with its accessibility notes.
Design system first
We fix your component library at the root, so every product your teams build on it starts
accessible.
What you receive
Working code, and the proof that it works.
Code changes in your repository, each with a note naming the criterion, the element,
and what a screen reader says before and after.
Corrected components in your design system or shared library, ready for every
product that uses them.
Re-test evidence for every fix, on desktop and phone.
A signed re-audit report with a position on every criterion, for regulators,
auditors and procurement.
Release checks and monitoring that catch a regression before your customers do.
Developer guidance written for your stack, so new work starts accessible.
Why fix the code
The code is what screen readers, auditors and regulators read.
A fix that lasts
A barrier corrected in the template stays corrected on every page and in every release. Nothing
depends on a script loading first.
The visitor menu is comfort, not a fix
Our accessibility menu lets visitors adjust text, contrast and motion. It works alongside fixes in
the code; it does not replace them, and we never present it as if it did.
Better for every customer
Clear structure, real labels and forgiving forms make journeys faster for everyone, on every
device and connection.
Readable by AI agents too
The same structure that lets a screen reader understand a page lets AI assistants and agents read
your content accurately and act on it.
Where we work
In the stack you already have.
Web
HTML, CSS and JavaScript; React, Angular, Vue and Next.js; WordPress and other content systems;
server-rendered and single-page apps.
Mobile
Native Android and iOS, Flutter, React Native, and hybrid apps that run web views inside a
native shell.
Signed-in and secured
Portals behind login, two-factor sign-in and secured trading apps, tested on test accounts and
builds you authorise.
Questions we are asked
Before you start.
Do you need access to our code?
To fix it, yes: we work in your repository or a copy of it, through your normal review. If you
prefer, we write the change list and your developers make the changes while we re-test.
Will the fixes change how the product looks?
Rarely, and only where the look is the barrier, such as low contrast or a missing focus outline.
Any visible change is agreed with your design team first.
We already have an audit report. Can you work from it?
Yes. We verify each finding on the live site or app, then fix what is real, so effort is not
spent on findings that no longer apply.
How is remediation priced?
From the audit findings, per component and journey, agreed before work begins. New builds are
quoted per project.
Send us your audit, or let us run one.
Tell us the site, portal or app. We will come back with the components in scope, a fix
plan and a fixed price.