Accessibility statement
Last reviewed September 24, 2026
AccessGuard checks other people's websites for accessibility problems, so our own site has to be usable by everyone who comes to it. This page says what we hold ourselves to, how we check it, and where we know we still fall short.
In short
- Standard
- WCAG 2.2, Level AA
- Status
- Partially conforms: some parts do not fully conform yet, and they are listed under known limitations.
- How it was assessed
- By us, not by an outside auditor: automated axe tests on every change and keyboard checks by hand.
- Relies on
- HTML, CSS, JavaScript and WAI-ARIA
- Report a problem
- [email protected]
- Next review
- Whenever we change how we test, or a limitation is fixed or found
1. What this covers
- The public website at getaccessguard.com, including the free audit and the check pages.
- The AccessGuard app you use after signing in.
- The PDF reports AccessGuard produces.
It does not cover the websites AccessGuard scans, which belong to other people, or services run by others that we send you to, such as the Lemon Squeezy checkout where you pay.
We work to WCAG 2.2 at Level AA and treat a failure on our own site as a bug to fix before other work. No automated tool can show that a site fully conforms, ours included, so we say how we test and what we have found instead.
2. How we test
Automated, on every change
- axe, the open source accessibility engine, checks each changed page in Chrome.
- It checks at a desktop width of 1440 pixels and a phone width of 390 pixels.
- It checks light and dark themes, where the page has both.
- A second check makes sure nothing scrolls sideways on a phone.
A change is not released while axe reports a failure. We also scan our own pages with AccessGuard's scanner. Automated checks find some of the ways a page can fail, not all of them, so a clean result means nothing is obviously broken rather than that every criterion is met.
By hand
When we add or change something you can operate, we check it with a keyboard: that it can be reached with the Tab key, that you can see where focus is, and that it works without a mouse. For the controls where this matters most, that check is a test that runs with every change.
3. Known limitations
These are the problems we know about today. Our automated tests do not catch them, so they are listed here until they are fixed. None has a date for a fix yet.
PDF reports are not tagged
WCAG 1.3.1 Info and Relationships. A report's text is real text, so it can be selected, searched and read aloud, but the file does not mark up its headings and tables. A screen reader cannot move through it by heading or read a table cell with its column.
What to do instead: every finding in a report is also in the app, as an ordinary web page.
Pictures of scanned pages are described only in part
WCAG 1.1.1 Non-text Content. The free audit and the app show a picture of the scanned page with each finding outlined and numbered. Its text alternative says what the picture is for, not everything in it.
What to do instead: the numbers on the picture match the list of findings next to it, which is text and says everything the outlines show.
Not yet tested routinely
We do not yet test with screen readers, in browsers other than Chrome, at high zoom levels or with changed text spacing as a matter of routine (WCAG 1.4.4, 1.4.10 and 1.4.12 among others). There may be problems there we have not found.
What to do instead: email [email protected] about anything that gets in your way, and we will help you do it another way while we fix it.
4. Report a problem
If something on our site or in the app is hard or impossible for you to use, email [email protected] with the page you were on and what went wrong. If it helps, say which browser and assistive technology you use.
A person reads every report. We will reply to tell you what we are going to do about it, and if the problem stops you doing something you need, we will help you do it another way while we fix it.