Methodology
What our scanner checks, and what no automated tool can
Trust starts with honesty about limits. Here is exactly how a Scanority report is produced.
1. Page selection
We map your site and select the homepage plus up to three subpages with the highest purchase risk: a product page, a category page and the cart, when we can find them.
2. Rendering
Each page is fetched in a real browser, so content rendered by JavaScript is included. We then remove the site's own scripts and analyse the rendered markup and styles in an isolated sandbox.
3. Testing
We run axe-core by Deque, an open-source engine widely used in the industry, limited to rules mapped to WCAG 2.0/2.1 levels A and AA. Each finding is stored with its rule, impact, WCAG criterion, page and an example element.
4. Risk index
Findings are weighted by impact (critical, serious, moderate, minor), by how many elements are affected, and by whether the rule typically blocks a purchase (button and link names, form labels, contrast, product images). The index is High, Medium or Low.
Known limitations
- Automated testing covers roughly 30–40% of WCAG criteria. Keyboard operation, focus order, meaningful alt text and screen reader flow need manual testing.
- Contrast over background images and gradients may be reported as "needs review" rather than as a violation.
- Interactive states (open menus, modals, checkout steps after login) are not reached in the free scan.
- The report is not a compliance certificate or legal advice.
Rules today. More context tomorrow.
We plan to use AI to assess image context, content and purchase journeys — to highlight more areas needing verification.
AI is not yet part of this scan. We will not claim a higher coverage percentage without measurement. More findings do not mean a compliance certificate.
Why we publish this
Because a tool that sells accessibility should not overpromise. If our own site has a barrier, please tell us at accessibility@scanority.com.