Ace the Audits.
Lose the Bugs.
Walk into your next audit with fewer surprises. Pie tests your app, checks each screen it reaches and hands your team a short list to fix.
Between audits
Broken in March. Found Next January.
Catch a problem when it ships, not at next year’s audit. An accessibility audit is right the day it lands. When a March release drops a button’s label, nobody looks again until the next one.
- the problem waits with an audit alone
- 10 months
- releases before the next audit
- 48
- when Pie can flag it, if a test reaches that screen
- Next run
Where it looks
A Scanner Needs a Path. Your Tests Already Walk It.
Get past the login with no scripts. Give Pie a test login and it explores your app, drafts the tests in plain English and checks each screen those tests visit.
What comes back
Not a Wall of Findings. A Short List to Fix.
Start on the fix, not the sorting. Pie groups repeat findings into one problem, ranks what matters and says what to change, in plain words.
A sample run on a sample store
- Your developer gets it.The WCAG rule, what it means for a real user, and the change to make.
- One problem, one line.A mistake repeated across screens shows up once. Your team reads a list, not a log.
- A fix you can review.With Fix PRs, Pie opens the proposed change. Merging stays your team’s call.
What gets checked
Pie Checks the Rules. And Whether They Make Sense.
Stop paying an auditor to find missing labels. Pie checks each rule on the screens its tests reach, then judges what a rule can’t, like whether an error says how to fix it. Your auditor keeps the calls that need a person.
| The rule | Does it make sense? | |
|---|---|---|
| Images | Does it have alternative text? | Does that text describe the image? |
| Buttons and links | Does it have a name? | Does the name say what it does? |
| Forms | Does each field have a label? | After a mistake, does the error say how to fix it? |
| Color | Does the text meet the contrast ratio? | Your auditorCan someone with low vision read it? |
| The whole page | Are the page title and language set? | Your auditorCan someone finish checkout with a screen reader? |
The basics
New to Accessibility Testing? Start Here.
Get up to speed in eight short answers, from what it is to what the law asks. The guide goes deeper.
Accessibility testing checks whether people with disabilities can use your app, whether they rely on a screen reader, a keyboard, zoom or voice control. It’s measured against WCAG.
It has two halves. Automated checks find what a machine can detect, and people using assistive technology judge the rest.
Our guide to accessibility testing covers how it works and where automation stops.
The Web Content Accessibility Guidelines, published by the W3C. Its rules sit at three levels, A, AA and AAA, and AA is the usual target.
Each rule has a number. WCAG 1.4.3, for example, asks for a contrast ratio of at least 4.5 to 1 on normal text, so two people can check it and get the same answer.
Often, yes, and your lawyer should say how it applies to you.
In the US, the Department of Justice’s guidance says businesses open to the public must make their online goods and services accessible, and it treats WCAG as helpful guidance rather than one set standard.
In the EU, the European Accessibility Act covers products and services including e-commerce and banking.
Low contrast text, on 83.9% of home pages in WebAIM’s 2026 scan of the top million. Then missing image alt text at 53.1%, missing form labels at 51%, empty links at 46.3% and empty buttons at 30.6%.
A machine can find all five, so they shouldn’t be the first thing your auditor finds.
An audit is people, usually specialists, checking your app against WCAG with assistive technology and writing up what they find. It’s thorough, and it’s a snapshot.
Automated testing is a machine running rules each time it’s asked. It’s narrower, and it repeats. A team with a WCAG duty usually needs both, the audit for judgment and the automated checks for what ships in between.
It depends how you count. Deque’s own 2021 study of its axe tools put automated testing at 57% of issues by volume. Counted by WCAG rule the share is lower, because many rules need human judgment.
WebAIM adds a warning worth keeping, that finding no errors doesn’t mean a page is accessible.
No rule we know of sets a schedule, so it usually comes down to change. A redesign or a big release is a good reason for a new audit, and so is a customer contract that asks for a current report.
In between, automated checks watch what ships.
iOS and Android have their own screen readers, VoiceOver and TalkBack, and their own accessibility settings, so a web scan can’t speak for a native app.
Pie tests iOS apps on the iOS Simulator (a simulator .app build) and Android apps on the Android Emulator (an .apk), and the check reports findings from both.
Security
Yes, Security Will Ask. Here’s What to Tell Them.
- You Pick the Test Account.Pie signs in with the test login you give it. A setup script can call your test API to create the data first.
- We Never Use Your Source Code to Train AI Models.Source code here means the files and code changes in your repositories.
- Logins Reach Pie’s Agents Only While a Test Runs.You keep them in Pie’s credential settings.
- Pie Has a SOC 2 Type 2 Report.Our most recent report is available on request. Data is encrypted in transit.
FAQ
Did we miss a question?
Email us directly →
Compliance is your auditor’s and your lawyer’s call, and it takes people testing with assistive technology.
Pie’s part is checking the screens its tests reach, both the rules and whether the result makes sense, so your audit starts with fewer open problems.
Keep the audit, because it judges what automated checks can’t. Keep a scanner if your developers like one. axe-core is free and exact about the rules it runs.
Pie adds checks on the journeys its tests walk, with nobody scripting the path.
With people, or with a tool built for it. Some testing platforms offer screen reader testing on real devices.
Pie checks what a screen reader relies on, like names, roles and labels, and says why a problem matters to someone using one.
Then Pie hasn’t looked at it yet. The check covers the screens tests reach, and each run says how many test journeys finished, so you can see how far it got.
Describe a test in plain English to reach that screen, and Pie drafts it.
Your team decides. Dismiss it, or use Create fix and Pie opens a proposed change as a pull request in a repository you connect. Merging stays your team’s call.
A VPAT comes from an audit, so that one’s for your auditor. You can export a run’s findings as a report to share with them.
We turn it on with you during the beta. A regression suite you already run in Pie can check accessibility too, on each screen its tests visit.
Customers use it on real apps today, and what it checks and how it reports can still change. We’ll walk you through what it covers on the demo.
Yes. Pie tests iOS apps on the iOS Simulator (a simulator .app build), Android apps on the Android Emulator (an .apk), and web apps in a browser, and the check reports findings from each.
Book a demo. We’ll look at your app and your release schedule and give you a quote.
Find It Before Your Auditor Does.
Pie checks the rules and whether they make sense. Your auditor keeps the calls that need a person.