Skip to main content
🦅 AccessHawk PRO

Your Title II compliance evidence system — document remediation tracking, continuous site monitoring, review decisions of record, the Screen Reader Studio, statements and workplans.

Leave blank if you were given a password only.

Your login was provided with your AccessHawk Monitoring subscription. Need one? See plans.

🦅 AccessHawk PRO
Engine v2.1 · local storage

Monitored sites

Documents first. Every crawl inventories and audits your entire PDF library alongside the pages — for most municipalities that library is the largest single body of Title II work, and it is the part the DOJ rule covers most explicitly. Then: every page in your sitemap, every internal link found along the way. Each scan is stored as a dated snapshot, and every decision your team records against a finding is kept with it. That record — not the score — is what demonstrates good-faith progress.

Scanning…

No sites yet — add your first above. Try your own city or a neighbor's.

report

–

Every PDF linked from the site, audited at byte level. For most municipalities this is the largest single body of Title II work — and the part no scanner-first competitor puts in the base product.

Document — open its full checklistResultFindingRemediation status

No PDFs were found on this site. If you publish documents somewhere we didn't crawl — a records portal or an agenda system on another domain — add that domain as a second monitored site.

Automated testing score

0–100, weighted by severity and normalised per page. It measures what automated testing can see — roughly a third of WCAG. It is not a compliance percentage and we will never present it as one.

Reported elements

Counted, never scored — the same census the WAVE extension reports. Features are things the site does right; structure and ARIA describe how much semantic scaffolding exists to work with.

Where the problems are

Score history

Page Issues Report

Every page we scanned, with its own error and alert counts. The home page is listed first; everything else follows your chosen sort. Open any row for a full page report.

Issues are grouped by check and ordered by severity. Record a decision for all issues on any finding at one time — that decision is what turns a scan into evidence.

The record of what your team decided about each finding, who decided it, and when. This is the artefact a DOJ complaint response or a council briefing actually needs — a scan alone shows a problem, this shows a process.

Stored with this browser's data and stamped on every decision you record from now on.

Decision log

ScopeFindingDecisionReason / noteReviewerWhen

No decisions recorded yet. Open the Findings or Documents tab and record what your team concluded about each item — including the ones you decide not to fix, and why.

Page report

Open the live page ↗

The page, as sighted visitors see it

Screen Reader Studio

See — and hear — any page the way a blind resident experiences it, without learning VoiceOver, NVDA, or JAWS. We simulate the announcements a screen reader makes from your markup, flag the moments that break, and show the four lists real screen reader users navigate by.

    The page, as sighted visitors see it

    A still mirror of the page — links and forms are disabled. The orange outline marks whatever the simulator is announcing right now. Some sites block their stylesheets from loading here, in which case you'll see the page unstyled but the highlight still tracks correctly.

    Scan configuration

    What standard you are being measured against, how to let our crawler reach a protected site, and exactly what the scanner does when it runs.

    Engine status

    Checking…

    Conformance target

    The DOJ Title II rule names WCAG 2.1 Level AA (28 CFR Part 35), which is why that is the default. Changing this changes which checks count toward your score and which findings appear — it is a real filter, not a label.

    Letting the crawler reach your site

    If your site sits behind a WAF, a bot filter, Cloudflare, Akamai, Imperva, or an IP allowlist, our requests may be challenged or blocked — which shows up as pages counted as “unreachable”.

    We cannot give you a single fixed IP address, and you should be sceptical of any scanner that claims one casually. AccessHawk runs on Cloudflare Workers, so requests leave from Cloudflare's shared edge ranges. Those ranges are large, published, and shared with a great deal of other traffic — allowlisting all of them would not be a meaningful security control for you.

    Allowlist by user agent instead. Every request we make is honestly identified. This is the string to match:

    Mozilla/5.0 (compatible; AccessHawkBot/2.0; +https://accesshawk.nythawk.com)

    We never spoof a browser user agent to get around a block. If a site is configured to refuse us, the honest outcome is a failed fetch you can see in the report, not a silent workaround.

    Rule examples

    Cloudflare WAF — custom rule, action Skip / Allow:

    (http.user_agent contains "AccessHawkBot")

    Apache:

    SetEnvIfNoCase User-Agent "AccessHawkBot" allow_scanner
    Require env allow_scanner

    If you must scope by network, Cloudflare publishes its ranges at cloudflare.com/ips — combine that with the user-agent match rather than relying on it alone.

    Rate: we fetch a handful of pages at a time with a 9-second timeout, and we honour redirects. We do not attempt logins, submit forms, or send anything destructive.

    Scanning pages behind a login

    We deliberately do not ask for your username and password, and this engine could not use them if you gave them to us. Engine v2.1 makes a plain HTTP request per page. It keeps no cookie jar, submits no forms, and runs no JavaScript, so there is no mechanism by which a credential could produce an authenticated session. A field that stored your CMS password in order to do nothing with it would be a liability for you and a false promise from us.

    Authenticated scanning needs a real browser session — a headless browser that can log in, hold cookies and drive the page. That is the same capability required to enable the ACT-conformant engines listed under Engine & ACT rules, and it is the next substantial piece of work on this product rather than something already shipped.

    What actually works today

    1. Scan the public site, which is what Title II is about. The DOJ rule covers the web content and documents you offer to the public. Resident-facing pages are almost never behind a login.
    2. Point us at a staging copy with authentication disabled. Add the host as a second monitored site. This is how internal intranets and staff portals get covered.
    3. Allowlist the bot user agent past the login for specific paths, if your platform supports it — most CMS platforms do via a bypass rule.
    4. Use the Screen Reader Studio and the Highlighter on a page you are already signed into. The Highlighter is a bookmarklet that runs in your own authenticated browser session, so it reaches anything you can see.

    When authenticated crawling ships, credentials will be stored encrypted, scoped to a single host, and usable only by the scanner — and we will say so here rather than in a marketing page.

    Exactly how a scan works

    Accessibility statement generator

    The DOJ rule expects entities to tell the public where they stand and how to get help. Fill this in and post the result on your site as /accessibility.

    Remediation workplan

    Turns your latest scan into a phased plan mapped to your federal deadline — the document you hand your council, vendor, or IT department.

    Highlighter

    See problems on your real website. Drag the button below to your bookmarks bar, then visit any page on your site and click it — every failing element gets outlined in red, with a panel listing what's wrong. Click again to turn it off. It runs entirely in your browser and sends nothing anywhere.

    1. Make sure your bookmarks bar is visible (⌘⇧B on Mac, Ctrl+Shift+B on Windows).

    2. Drag this button up to the bookmarks bar:

    🔦 AccessHawk Highlighter

    3. Go to any page on your website and click the bookmark. Outline colors: critical · serious · moderate.

    Note: a small number of sites with strict security policies (CSP) block bookmarklets — if nothing happens, use the Screen Reader Studio view of that page instead.

    Why this matters: reports say “form field without a label.” The highlighter shows you which field, on your actual page, in one click — the fastest way to hand a fix to whoever edits the site.

    Document report

    –

    Open the document ↗

    Accessibility checklist

    Each item is checked against the PDF's own structure. Failures name the specific remediation step.

    Review decision

    What we read

    Engine & ACT rules

    Every check this product runs, mapped to the W3C ACT rule it implements, with an honest statement of how completely it implements it. Published as machine-readable JSON at /api/act-rules so anyone — your procurement officer, your auditor, a competitor — can check it against the W3C ACT rules index without taking our word for anything.

    Engines

    EngineLicenseStatusNotes

    Check-to-rule mapping

    CheckCategoryWCAGACT ruleImplementation

    View the raw JSON ↗

    Admin console

    Create customer accounts, watch every monitored site, read leads captured by the marketing site, and trigger a monitoring pass manually.

    KV isn't bound yet — customer accounts, leads, and monitoring storage need the AH_KV binding on this Pages project.

    New customer

    Customers

    OrganizationEmailSites (latest score)Status

    Prospecting — bulk-scan a target list

    Paste government website addresses, one per line (every city in a county, say). Each gets a quick scan; you get a ranked list plus a ready-to-send outreach email per site.

    SiteScoreTop problemScanned

    Leads from the marketing site

    WhenEmailOrgSite scannedScoreWants monitoring