AMASAMYA - Accessibility Audit Tool

AMASAMYA (v5.4.2) is a blind-first WCAG 2.2 accessibility audit tool, built and maintained by Akhilesh Malani, a blind screen-reader user, in personal capacity. The interface is keyboard- and screen-reader-first; every finding includes remediation guidance and a link to the relevant WCAG technique. WHAT IT AUDITS Live web pages. Click the toolbar button or press Alt + Shift + 1 on any tab. AMASAMYA runs 25 audit engines on the active page covering colour contrast, ARIA validation, focus management, structural semantics, and interaction patterns. Beyond structural checks, AMASAMYA applies a 200% zoom and detects content that clips or scrolls horizontally, parses dark-mode stylesheets and verifies the contrast of every declared colour pair, flags copy that names UI by colour alone, spots asterisk-only required-field markers with no programmatic indicator, and checks every interactive target against the AAA 44x44 CSS-pixel recommendation in addition to the AA minimum. Whole websites. Point AMASAMYA at a sitemap or paste a list of URLs and Site Crawl walks up to 200 pages in one run, three pages in parallel with a 10-second per-page timeout. Findings stream into the AMASAMYA web platform, which groups the same issue across pages so a template-level fix addresses every page it affects. Four export shapes: HTML grouped report, CSV by template, CSV by page, JSON raw. Auth-walled pages are labelled and skipped, not misreported clean. Documents. Upload to the linked AMASAMYA web platform for accessibility audits of PDFs, Microsoft Office files, EPUB books, and OpenDocument files. Findings are format-specific. Mobile apps. A structured manual-test checklist for iOS, Android, and WearOS. Each item names the WCAG criterion, the assistive technology to use, and the specific test method. A standalone Android auditor app that runs the same style of WCAG audit against native Android apps via the AccessibilityService API is live on Google Play as v1.3. TRACK CHANGE OVER TIME Every audit you run is saved on your device (up to 10 audits per URL, 8 MB soft cap, oldest evicted first). When you re-audit a URL, AMASAMYA compares the two runs and shows a diff with four verdicts: new, regressed, unchanged, resolved. Every finding row gets one of these badges. A one-sentence summary is announced through the polite live region so a screen-reader user hears what changed without navigating to a summary card. A Diff CSV export writes only the actionable rows (new + regressed) in a shape that imports directly into Jira, Linear, or GitHub Issues. A History section in the side panel lists every past audit for the current URL with per-URL Load and clear controls. SCHEDULE CRAWLS THAT RUN THEMSELVES Save a schedule from the Schedules tab on the AMASAMYA web platform and the extension runs the crawl on its own. Frequencies: daily, every Monday, every Friday, at a time you choose. Chrome must be open at some point during the window for the alarm to fire; missed runs get a single catch-up on the next browser start, not a flood. Every scheduled run applies the diff engine to each URL and produces the four verdict counts. Optional webhook posts to Slack, Microsoft Teams, or a generic JSON endpoint, with colour-coded fields for regressions vs new failures vs clean runs. A Test button on the schedule form fires a sample payload immediately so you can verify your webhook URL before saving. INDIAN STANDARDS AND VPAT Two national engines beyond the WCAG 2.2 international baseline. GIGW 3.0 for the Government of India Guidelines for Indian Government Websites: every finding is labelled by the exact GIGW clause. IS 17802 for the Bureau of Indian Standards accessibility standard for ICT products and services, the Indian equivalent of Section 508 and EN 301 549. This is the standard the SEBI accessibility mandate for regulated financial entities points at; auditing against it directly saves the manual clause-mapping step Indian financial-services audits currently repeat. VPAT 2.4 ACR exporter. One-click generation of a Voluntary Product Accessibility Template 2.4 Accessibility Conformance Report from any completed audit or Site Crawl, populated with your actual findings and ready to hand to procurement. Available for WCAG 2.2, Section 508, EN 301 549, GIGW 3.0, and IS 17802. NEW IN v5.4.0: INTERACTION SWEEP ENGINE Every static rule engine on the market (axe-core, HTML_CodeSniffer, IBM Equal Access, WAVE) looks at the DOM at a single point in time. That approach catches state-shaped failures like missing alt text and low contrast, but is architecturally blind to the interaction-shaped failures that make JavaScript-rendered sites unusable for screen-reader and keyboard-only users. The Interaction Sweep engine catches four such failure classes: Focus-accept sweep. For every focusable element in the tab order, the engine attempts programmatic focus and verifies document.activeElement lands where it should. Elements that decline focus surface as WCAG 2.1.1 Keyboard failures at Serious severity. This catches SPA route transitions where an element is still in the tab order after its ancestor has unmounted. Focus-indicator sweep. The engine snapshots outline, box-shadow, border, and background before and after focus for every focusable element. No change means no visible focus indicator, surfaced as WCAG 2.4.7 Focus Visible at Serious severity. This catches sites that ship outline zero via utility CSS frameworks without a :focus-visible fallback. Keyboard-trap sweep. For each focusable element, the engine focuses it and dispatches a synthetic keydown for Tab, Shift+Tab, and Escape. Any handler in the propagation path that calls preventDefault on those keys traps focus; the engine flags Tab and Shift+Tab traps as Critical failures against WCAG 2.1.2 No Keyboard Trap, and Escape swallowing as a Serious failure against WCAG 2.1.1. Synthetic keyboard events do not trigger the browser's native default behaviour, so the sweep observes preventDefault…