Last updated: 11 June 2026. Updated when limitations are removed or added.
No automated accessibility tool, including AMASAMYA, catches every accessibility issue. Public research from Deque (the makers of axe-core) and from WebAIM puts the upper bound of automatable detection at roughly thirty to forty percent of WCAG conformance issues. The remaining sixty to seventy percent require manual testing, ideally including a real screen-reader user.
This page is the honest version of that statement for AMASAMYA specifically. The goal is that you finish reading it knowing exactly when AMASAMYA is enough on its own and when you need to pair it with something else.
Reminder. Passing every check AMASAMYA can make does not mean a page is WCAG conformant. It means AMASAMYA found nothing in the parts it can check. Manual testing remains required for full conformance claims.
Coverage of WCAG 2.2 today
The Chrome extension ships with 24 automated audit engines covering a meaningful subset of WCAG 2.2 success criteria at Level A and Level AA. The single-page audit cannot, by design, decide criteria that require cross-page comparison, real media inspection, or simulated user interaction.
What AMASAMYA does not currently auto-check
| WCAG SC | Why it is hard to automate |
|---|---|
| 1.2.4 Captions, Live | Requires inspecting a live audio stream as it plays. |
| 1.2.5 Audio Description, Prerecorded | Requires comparing video content against an audio-description track. |
| 1.4.5 Images of Text | Requires OCR or vision analysis to know if an image contains text rather than just a graphic. |
| 1.4.13 Content on Hover or Focus | Requires simulating mouse hover and keyboard focus on every element and timing dismissals. |
| 2.4.5 Multiple Ways | Requires comparing site-wide navigation, search, and sitemap availability across pages. |
| 3.1.2 Language of Parts | Requires deciding whether mixed-language inline content is correctly marked. |
| 3.2.3 Consistent Navigation, 3.2.4 Consistent Identification | Single-page audit cannot verify consistency across the page set. |
| 3.3.3 Error Suggestion, 3.3.4 Error Prevention | Requires actually submitting forms and inspecting the error UX that comes back. |
Some of these are on the roadmap. Site Crawl in the v4.2 extension release will add partial coverage for SC 3.2.3, 3.2.4, and 3.2.6 by comparing audits across pages. Vision AI integration already helps with SC 1.4.5 and SC 1.4.11 when the user has configured an API key.
Specific things to manually verify
Even within the criteria AMASAMYA does auto-check, certain edge cases produce false positives or false negatives. These are the ones to verify manually if your audit will be used for a conformance claim.
Colour contrast on layered backgrounds
The contrast engine reads the effective background of an element by walking the ancestor tree and blending semi-transparent layers. On heavily layered designs (cards stacked over hero images stacked over gradients), the computed background may not match what a human sees. Manually verify any borderline finding before reporting it as a definitive fail.
Form labels that are not nearby in the DOM
The forms engine prefers <label for>
associations and falls back to ancestor <label>
wrappers. Custom widgets that label inputs via
aria-labelledby pointing at distant elements are
correctly recognised; widgets that use ARIA live regions to
announce labels at runtime are not.
Dynamic content and SPAs
AMASAMYA audits the DOM at the moment you trigger the run. Single- page apps that load content lazily, virtualised lists that render only the visible window, and modals that open after user interaction are evaluated only in their current visible state. Trigger the audit again after each significant state change.
Custom focus indicators
The Focus Indicator Narrator module uses Vision AI to compare the focused and unfocused screenshots of each element. Without a Vision AI key configured, the focus-visibility engine falls back to CSS heuristics that miss visually rich custom focus rings. Configure a Vision AI key for accurate focus checks.
Mobile breakpoints
The Visual Layout Auditor emulates four viewport widths (320px, 375px, 768px, 1280px) and only one orientation. Tablet landscape, foldable phones, and ultra-wide monitors are not in the default sweep.
Limitations that come from the deployment model
Authenticated and CORS-strict sites
The platform's Web Audit feature cannot inject the audit engine into pages that strictly disable inline scripts via Content Security Policy, and cannot reach pages that block cross-origin access. On those sites, use the Chrome extension directly: it runs through a Manifest V3 service worker that bypasses page CSP.
iOS Safari and Firefox
The Chrome extension targets Chromium browsers (Chrome, Edge,
Brave, Arc, Opera). A Firefox port would require API translation
because Firefox does not implement chrome.sidePanel
or the same chrome.debugger semantics. iOS Safari
does not support extensions of this shape at all.
Languages and locales
The user interface, audit findings, remediation guidance, and export reports are in English only at present. Engines run correctly on pages written in any language, but the finding text will still be in English.
What this means in practice
For a credible accessibility audit of a production site or application, the realistic workflow is:
- Run AMASAMYA on representative pages (homepage, search results, product detail, checkout, account, error page).
- Run a second automated tool such as axe DevTools or WAVE on the same pages to catch what AMASAMYA misses and vice versa.
- Manually test with a screen reader (NVDA on Windows, VoiceOver on macOS / iOS, TalkBack on Android).
- Run a keyboard-only navigation pass without a mouse.
- Verify colour, motion, and timing-sensitive checks by hand.
AMASAMYA accelerates step one. The other steps remain. If a competitor product is telling you that step one alone is enough, they are selling you a story, not an audit.
How this list changes
Items move off this page when an AMASAMYA release adds coverage for them. The "Last updated" date at the top reflects the most recent change. The full release history lives in the ROADMAP file at github.com/accessitestai/AMASAMYA. If something is here that is no longer true, tell us on the feedback page.