Good design should work for more people.
Accessibility is part of how we build software, not something we add at the end. We share what we have tested, what we are still improving and where each app has limitations.
Three ideas we hold ourselves to.
These describe how we work. They are not certifications, and they are not a promise that every app will meet every need.
-
Considered
Accessibility informs our design decisions from the start, rather than being added at the end.
-
Tested
We use real-device checks to assess accessibility in practice, not only in theory.
-
Transparent
We publish known limitations alongside the work we have actually tested.
What we have tested, app by app.
Each report lists the features we assessed, how each one is rated, and any known limitations.
-
ScriptShelf
ScriptShelf accessibility report →
Version 1.1, tested 6 November 2026
-
FundGauge
FundGauge accessibility report →
Version 1.2, tested 5 November 2026
-
Their Turn
Their Turn accessibility report →
-
CarerHours
CarerHours accessibility report →
-
SinceLast
SinceLast accessibility report →
Reports for our other apps will appear here as their testing is recorded. Until then, we say nothing about them rather than guess.
What we aim for in every app.
We hold every app to the same standard. These are our aims. The app reports above show what we have confirmed for each one.
Text and readability
Text scales with your Larger Text setting, including the largest accessibility sizes, and never gets cut off.
Type size is a personal setting. An app should follow it rather than fight it.
Screen readers and assistive interaction
Every control has a clear label, and VoiceOver can reach it, read its state and operate it.
If a control cannot be found or understood without seeing it, it is not finished.
Colour and visual communication
Nothing depends on colour alone to carry meaning.
Status and warnings are also carried by words or shapes, so they survive colour blindness and bright sunlight.
Motion and comfort
Animation respects Reduce Motion.
Movement is there to help, never to be endured. When you ask for less, you get less.
Touch targets and input
Controls are big enough to tap reliably, and everything can be operated by voice.
Precision should not be a requirement. Larger targets and a clear name for each control help everyone.
Onboarding and purchasing
Purchase screens and first-run setup are held to the same standard as the rest of the app.
The first minutes of an app and the moment of paying are where people are most likely to give up.
Two layers, and we say which is which.
We check each app against a list of accessibility features and record a status for each one.
Testing tools and methods
While we build, we run automated tests and Apple's accessibility checks again and again. These help us catch problems early.
Automated checks do not replace trying the app by hand, and we do not treat them as if they did.
Manual testing on real devices
We try the app by hand, on a real device, with the assistive technology itself. A feature is only marked Tested once that hands-on step is done.
The app's report then shows the app version, date, iOS version and devices we used.
Testing coverage
Every feature in a report carries one of these labels. The label is the whole claim: nothing is rated higher than the checking behind it.
- Tested
- We have tested this on a real device and it works.
- Testing underway
- We are testing this now.
- Built in and checked
- Built into the app and covered by our automated tests and Apple accessibility checks. Not yet confirmed by hand on a real device, so we do not call it tested.
- Known limitation
- We know this does not work well yet. See the limitations below.
- Not yet assessed
- We have not looked at this yet.
- Does not apply
- This feature is not relevant to this app.
Known limitations and unverified areas
When we find a problem we cannot fix straight away, it is listed as a known limitation with a workaround where there is one.
Anything we have not looked at is labelled Not yet assessed. A report that lists no limitations does not mean there are none. We do not assume an app is accessible because the framework it is built on supports accessibility.
Something not working for you?
If you meet an accessibility barrier in one of our apps or on our website, we would like to know about it. Tell us which app or page, what you were trying to do, what went wrong, and the assistive technology you use. A real person reads every message, and what you tell us goes straight into what we fix next.