Last updated 11 September 2026
Accessibility statement
This statement covers the website at accessibilitypro.app. It says what standard we work to, how the site is tested, where that testing stops, and how to tell us when something does not work for you.
1. The standard
We aim for the website to meet the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA.
2. What we claim, and what we do not
We do not claim full conformance. The testing described below is automated, and automated scanning reliably catches only 30 to 40% of WCAG 2.2 criteria. That is the same limit every Accessibility Pro report states for our customers' sites, and it applies to ours.
3. How the site is tested
- Scanned with its own scanner. On every push to the main branch, on every pull request against it, and once a day, Accessibility Pro scans four production pages: the home page, pricing, compliance and sign-in. The check fails if any critical or high-severity finding appears.
- The public GitHub Action. Every pull request also runs the published Accessibility Pro GitHub Action against the home page at WCAG Level AA, and fails on errors.
- Lighthouse. Pull requests that change front-end code run Lighthouse against a production build of the home, sign-in, pricing and benchmark pages. An accessibility score below 95 fails the check.
4. Keyboard and assistive technology
The first thing a keyboard user reaches on every page is a “Skip to main content” link. It stays hidden until it receives focus, and activating it moves focus into the main content, not just the scroll position. Buttons show a visible focus ring, links in the site footer are sized to at least 24 by 24 CSS pixels, and entrance animations are switched off when your system asks for reduced motion.
5. Known limitations
The automated checks in clause 3 cover public pages only. The dashboard, account and report screens need a signed-in account and a saved scan, so no automated gate reaches them today. Automated checks also cannot judge things such as whether alternative text is meaningful or whether a flow makes sense with a screen reader. If you find a barrier, on those screens or anywhere else, please tell us.
6. Reporting a problem
Email us at support@accessibilitypro.app Include the address of the page, what you were trying to do and what went wrong. If you use assistive technology, naming it and your browser helps us reproduce the problem. Questions that are not about a barrier go through the contact page
7. About this statement
This statement was prepared on 11 September 2026, from the site's own test configuration. It is updated when that testing changes.