Item logo image for AMASAMYA - Accessibility Audit Tool

AMASAMYA - Accessibility Audit Tool

ExtensionDeveloper Tools25 users
Item media 1 (screenshot) for AMASAMYA - Accessibility Audit Tool

Overview

Blind-first WCAG 2.2 audit tool. Scheduled crawls post regressions to Slack, Teams, or your webhook. Diff on every run.

AMASAMYA (v5.2.0) 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 whole interface is keyboard- and screen-reader-first; every audit finding includes specific remediation guidance and a link to the relevant WCAG technique. WHAT IT AUDITS Live web pages. Paste a URL or click the toolbar button on any tab. AMASAMYA runs a full WCAG 2.2 audit on the active page covering colour contrast, ARIA validation, focus management, structural semantics, and the broader interaction patterns the standard requires. Beyond the structural checks, AMASAMYA also runs visual-behaviour audits that most other tools skip. It applies a 200% zoom to the page and detects content that clips or introduces horizontal scrolling. It parses any dark-mode stylesheet rules the page declares and verifies the contrast of every colour pair the dark palette specifies. It heuristically flags copy that names a UI element by colour alone, asterisk-only required-field markers with no programmatic indicator, and unlabelled small coloured shapes that look like status dots. It checks every interactive target against the AAA recommendation of forty-four by forty-four CSS pixels in addition to the AA minimum. Whole websites (Site Crawl, v4.2.0). Instead of auditing one page at a time, point AMASAMYA at a sitemap or paste a list of page addresses and it walks up to 200 pages of a site in one run. Three pages are audited in parallel for real-world speed, with a 10-second fetch timeout so unresponsive origins do not hang the crawl. Per-page findings stream into the AMASAMYA web platform, which groups the same issue across pages so a single template-level fix can address every page it affects. Four export shapes are available: HTML grouped report, CSV by template, CSV by page, and JSON raw for tooling handoff. Auth-walled pages are labelled and skipped rather than misreported as clean. Documents. Upload a file at the linked AMASAMYA web platform and the tool audits its accessibility. The supported formats include PDFs, Microsoft Office files, EPUB books, and OpenDocument files. Findings are format-specific because the underlying remediation differs from one format to the next. 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. Reports can be exported. A standalone Android auditor app that runs the same style of WCAG audit against native Android apps via the AccessibilityService API is in closed beta on Google Play and will publish publicly soon. TRACK CHANGE OVER TIME (Audit Diff and History, v4.3.0) Every audit you run is saved on your device, up to 10 audits per URL, with an 8 MB total soft cap and automatic eviction of the oldest audits when over. Nothing is transmitted anywhere. When you audit a URL you have audited before, AMASAMYA automatically compares the two and shows a diff. The diff has four verdicts. New: a failure that was not present in the last run. Regressed: an element that was passing or only a warning before is now failing. Unchanged: a failure that was there last time and is still there. Resolved: a failure from the last run that is no longer present. Every row on the findings table gets one of these badges, and a one-sentence summary is announced through the polite live region so a screen-reader user hears "Compared to your last audit on 2026-07-01: 5 new, 2 regressed, 1 unchanged, 3 resolved" without having to navigate to a summary card. A new Diff CSV export writes only the actionable rows (new and regressed) in a format directly consumable as a ticket-import file for Jira, Linear, or GitHub Issues. No hand-filtering required. A History section in the side panel lists every past audit for the current URL with a Load button per row. Loading an older audit swaps the current view to that run and re-computes the diff against whatever came immediately before it, so you can walk backwards through the change history of the same URL over time. Per-URL and clear-all buttons let you wipe history when you no longer need it. History is separate from your Baseline; clearing one does not touch the other. SCHEDULE CRAWLS THAT RUN THEMSELVES (Scheduled Crawls, v5.2.0) Instead of running a Site Crawl manually, save a schedule from the new Schedules tab on the AMASAMYA web platform and the extension runs the crawl on its own. Frequencies are daily, every Monday, or every Friday, at a time you choose in HH:MM local to the machine running the extension. Save from the platform; the extension picks up the schedule immediately and registers a chrome.alarms entry that fires at your chosen time. Chrome must be open at some point during the schedule window for the alarm to fire. If Chrome was closed when a scheduled run should have happened, the extension detects the miss on the next browser start and runs a single catch-up per schedule. A weekend of closed browsers gets one catch-up per schedule, not a flood of overlapping runs. Every scheduled run applies the v4.3.0 diff engine to each URL against that URL's own prior audit, and produces four counts: new, regressed, unchanged, resolved. The counts are recorded on the run and included in the webhook payload if you have one configured. Three webhook shapes are supported. Slack incoming webhook, which posts an attachment with colour-coded fields (red if any regression, amber if only new failures, blue for a clean run). Microsoft Teams MessageCard, with the same fields formatted for Teams channels. Generic JSON POST for a self-hosted intake or a Zapier or Make endpoint. A Test button on the schedule form fires a sample payload immediately so you can verify your webhook URL before saving. Run history is stored per user in your own tenant of the AMASAMYA platform: last twenty runs per schedule, viewable from the Schedules tab, with the four verdict counts on every row. Runs that fire while the platform tab is closed buffer in the extension and flush to your platform account on the next platform visit, so no run is lost when the platform tab was closed at fire time. HOW TO USE IT After installation, open any web page you want to audit. Press Alt + Shift + 1 on any operating system, or click the AMASAMYA toolbar button. The AMASAMYA side panel opens on the side of your Chrome window and fills with audit findings within five seconds. The side panel automatically moves keyboard focus to itself when it opens, so your next Tab press stays inside AMASAMYA rather than escaping to browser chrome. Tab and Shift+Tab cycle within the panel. To close the panel, activate the Close button or press Escape; both actions raise a confirmation dialog so an accidental Escape does not lose your findings. If Alt + Shift + 1 does not work on your system, you can reassign it. Open chrome://extensions/shortcuts in the address bar, find AMASAMYA in the list, and bind any combination that is free on your machine. The side panel reads the shortcut Chrome actually has bound and shows it in the empty-state hint, so if the binding changes you always see the accurate chord. To use Scheduled Crawls, sign in at amasamya.akhileshmalani.com, open the new Schedules tab, and create a schedule. The extension picks it up as soon as you save. VISION AI MODULES (optional, bring your own API key) Focus Indicator Narrator. Uses a Vision AI provider you configure to describe what the keyboard focus indicator looks like at every focusable element on the page. Lets a blind tester independently verify visual focus indicators without sighted help. Visual Layout Auditor. Captures the page at four viewport widths and uses Vision AI to detect layout shifts and reflow failures across breakpoints. Reports differences relevant to WCAG 1.4.10 Reflow and 1.4.4 Resize Text. State Change Watchdog. Runs locally with no AI calls. Monitors the page in real time for dynamic content additions, dialog focus failures, and ARIA state changes that a screen reader user would otherwise miss. Three providers are supported: Google Gemini (with a generous free tier), Anthropic Claude, and OpenAI GPT-4o. DESIGNED BLIND-FIRST The Chrome side panel UI is fully operable with major Windows, macOS, and Android screen readers. Every audit finding is announced with its role, severity, and remediation in a logical reading order. The v4.3.0 diff summary (what changed since the last audit of the same URL) is announced through the polite live region on every audit-complete. From v4.3.1 onwards, rapid announcements during Site Crawl no longer drop; each message drains sequentially so JAWS and NVDA speak every one before the next arrives. Progress and per-page completion during a Site Crawl are spoken through the same live region so a screen-reader user hears the run's status without navigating the table. Text input fields for URL entry are wrapped in a role that tells JAWS and NVDA to pass arrow keys straight to the field, so cursor navigation works normally instead of ejecting focus. Exported reports use semantic headings and properly labelled regions so the report file is itself accessible. The v5.2.0 Schedules panel on the AMASAMYA web platform follows the same pattern. Create and edit forms use fieldsets and radio groups because NVDA and JAWS handle those more predictably than native selects, time is two number inputs rather than the flaky native time picker, and every save, toggle, delete, and webhook-test outcome routes through a scoped polite or assertive live region so you hear the result without navigating back to a status area. PRIVACY Your data stays on your device. Audits run locally in your browser. Audit history (v4.3.0) is stored in your browser's local storage; no history data is transmitted anywhere. No page content is ever sent to AMASAMYA servers, because there are none. The optional Vision AI modules send screenshots directly from your browser to the provider you have chosen, using your own API key. Keys are encrypted at rest with a non-extractable WebCrypto master key and never leave your device. The full privacy policy is linked below. Scheduled Crawls (v5.2.0) add two new outbound flows, both under your control. First, the webhook POST goes directly from your browser to the URL you configured, using no AMASAMYA infrastructure. Second, scheduled-run summaries (page count and the four verdict counts) sync to your own account on the AMASAMYA platform for cross-device viewing. Full findings from scheduled runs stay on your device in the same 10-audit-per-URL history AMASAMYA already keeps; only the small numeric summary crosses over. PERMISSIONS The activeTab and scripting permissions let AMASAMYA run audits on the tab you are currently viewing, on demand only. The sidePanel permission opens the Chrome side panel where audit results are displayed. The tabs permission reads the current tab's URL and title so reports can be labelled with the page they came from, and lets Site Crawl open one background tab per audited page. The storage permission persists your Vision AI provider preference, any API key you choose to enter, and (from v4.3.0) the on-device audit history for the diff feature. The alarms permission (new in v5.2.0) is required for Scheduled Crawls. It lets the extension register a chrome.alarms entry per schedule you save from the platform so the crawl fires at your chosen local time. The debugger permission is used only by the Visual Layout Auditor module, to emulate viewport widths via the Chrome DevTools Protocol. Chrome's mandatory "is being debugged" banner provides visible consent every time the feature runs. The host_permissions all_urls scope is required because the user, not the extension, decides which page is audited. The extension only ever reads or modifies the active tab on explicit user invocation. Detailed permission justifications and threat-model disclosure are in the privacy policy. WHO BUILT THIS AMASAMYA is built and maintained by Akhilesh Malani, a blind Accessibility Architect and independent product builder based in Chennai, India. Akhilesh has been a screen-reader user for 16+ years and works as an Accessibility Architect at Virtusa Systems in his day role. AMASAMYA is built in personal capacity, unaffiliated with any employer, fully self-funded, with no investor influence on the privacy or feature roadmap. The toolkit is multi-surface: this Chrome extension is one part, alongside a companion web platform at amasamya.akhileshmalani.com and a standalone Android auditor app in closed beta on Google Play. LINKS Web platform: https://amasamya.akhileshmalani.com Privacy policy: https://amasamya.akhileshmalani.com/privacy Contributors page: https://amasamya.akhileshmalani.com/credits Portfolio and blog: https://akhileshmalani.com

Details

  • Version
    5.2.0
  • Updated
    August 12, 2026
  • Offered by
    Akhilesh Malani
  • Size
    152KiB
  • Languages
    English
  • Developer
    AMASAMYA
    Murugesh Nagar Chennai, Tamil Nadu 602024 IN
    Email
    akhilesh.malani@gmail.com
  • Non-trader
    This developer has not identified itself as a trader. For consumers in the European Union, please note that consumer rights do not apply to contracts between you and this developer.

Privacy

Manage extensions and learn how they're being used in your organization

AMASAMYA - Accessibility Audit Tool has disclosed the following information regarding the collection and usage of your data. More detailed information can be found in the developer's privacy policy.

AMASAMYA - Accessibility Audit Tool handles the following:

Authentication information
Website content

This developer declares that your data is

  • Not being sold to third parties, outside of the approved use cases
  • Not being used or transferred for purposes that are unrelated to the item's core functionality
  • Not being used or transferred to determine creditworthiness or for lending purposes

Support

For help with questions, suggestions, or problems, please open this page on your desktop browser

Google apps