Skip to main content
Latchkey home

Understanding your coverage

What LatchKey cannot do

Know what a scan can reach, what needs human review, and how to use your results with confidence.

Automated results are one part of accessibility testing

Pages we cannot scan at all

Access barriers can prevent a scan from reaching your page. Review the failure reason before retrying.

Canvas-rendered apps

If your UI is drawn into a <canvas> (a map, a design tool, a charting app, a game), there is no accessibility tree for automation to inspect. We detect this and fail the scan honestly rather than returning an empty report.

Anything behind CAPTCHA

We do not solve CAPTCHAs. Tools that claim to are usually violating the target site's terms. Use session paste, or allowlist the scanner.

Bot-protection interstitials

Cloudflare, Akamai and similar services serve a challenge page instead of your app. We report that we never saw your page, rather than auditing the interstitial.

Accounts with mandatory 2FA

We never handle one-time codes. Log in yourself and paste the session instead. That path works with SSO, 2FA, and magic links.

Parts of a page we cannot see

A scan captures a bounded view of the page. Check the report for content that was not scanned.

Cross-origin iframes

Embedded payment forms, chat widgets, video players and analytics frames are opaque from the parent page. We list every one we skipped in the Not scanned section of each report.

Closed shadow roots

A component that attaches a closed shadow root is invisible to automation by design. We count them so you know they exist.

Content below a very long scroll

We scroll a bounded number of times. An infinite feed will not be fully covered, and the report says exactly where we stopped.

State you have to interact to reach

Modals you have not opened, validation errors you have not triggered, and menus you have not expanded are not scanned in this version. Interaction simulation is planned, not shipped.

Things automation cannot judge

Use manual testing and feedback from people with disabilities to assess these areas.

  • Whether alt text is any good. We can tell you an image has no alt attribute. We cannot tell you that alt="image" is useless.
  • Keyboard traps and focus order. axe checks some focus properties; it does not tab through your app.
  • Whether reading order matches visual order. A CSS-reordered layout passes every automated check and confuses every screen reader.
  • Whether your error messages make sense when read aloud out of context.
  • Cognitive load, plain language, timing. Whole WCAG sections are unreachable by machine.

Where our fix suggestions stop

We would rather ask than guess

When a model cannot tell what an icon button does from the surrounding page, it returns a question instead of a label.

This is deliberate and it is the hardest part of the product. A confident wrong aria-label gets shipped and silently misleads screen reader users for years. A missing one is caught by the next audit. So refusal is a feature here, not an error, and you will see it regularly.

A suggestion is a starting point a developer reviews, not a patch to apply blind. We show you the current markup next to the suggested markup precisely so you can judge it.

Fix code is generated by a model running on whichever inference endpoint this deployment is configured for. On a self-hosted endpoint neither the fix nor the page content it came from leaves your infrastructure; on Ollama Cloud both are processed by a third party.

Build on what your scan finds

Review skipped content, validate suggested fixes, and plan human testing for the experiences automation cannot assess.

Understand your resultsDiscuss human testing