`. The actual content — the buttons, forms, and interactive elements that need to be accessible — never appears.
---
## How Authenticated Page Scanning Works
The correct approach is browser automation at the OS level, not JavaScript injection or cookie manipulation.
ADAGuard uses **Playwright** — the same browser automation framework used by Microsoft for end-to-end testing — to perform a full, real login:
1. Launch a real Chromium browser instance (not a headless HTML scraper)
2. Navigate to your login page
3. Detect the login form fields automatically (email, password, MFA if present)
4. Fill in the credentials you provide
5. Submit the form and wait for successful authentication
6. Capture the complete browser state: cookies (including httpOnly), localStorage, sessionStorage, auth tokens
7. Use that authenticated session to navigate to and scan any page in your app
Because this uses a real browser performing a real login, it captures the `httpOnly` session cookies that JavaScript-based approaches can never reach. The scanner is indistinguishable from a real authenticated user.
> 💡 **Why this matters technically:** `httpOnly` cookies are set by the server and intentionally hidden from JavaScript for security reasons. This is why every Chrome extension-based "cookie capture" approach fails — extensions can only see non-httpOnly cookies, which are typically tracking and analytics cookies, not session tokens. Playwright's storage state captures the full cookie jar including httpOnly cookies, because it operates at the browser level, not the JavaScript level.
---
## Step-by-Step: How to Scan a Password-Protected Page
Here's the exact process using ADAGuard:
**Step 1: Start a new scan and enter your app URL**
Enter the URL of a page inside your authenticated app — for example, `https://app.yourproduct.com/dashboard`. ADAGuard will detect that this page requires authentication.
**Step 2: Provide your login page URL and credentials**
Enter your login page URL (e.g., `https://app.yourproduct.com/login`) and your test account credentials. Use a dedicated test account — not your personal admin account.
> ⚠️ **Security note:** Credentials are used immediately to perform the login and then discarded. They are never stored in the database or logs. The only thing retained is the session state (cookies) needed to complete the scan.
**Step 3: ADAGuard performs the login automatically**
Playwright navigates to your login page, fills in the detected form fields, and submits. If your app uses multi-step authentication or 2FA, ADAGuard handles that flow too.
**Step 4: Configure your scan depth**
Choose how many pages to scan (up to 5,000 on Enterprise), whether to crawl internal links from the starting page, and which paths to exclude (e.g., `/logout`, `/delete-account`).
**Step 5: Review your authenticated scan results**
The scan runs with your full session active. Every page it visits is scanned with the real authenticated content — the actual UI your users see, not the login redirect.
---
## What Authenticated Scanning Finds That Public Scans Miss
When we run authenticated scans on SaaS products for the first time, these are the violations found most consistently:
**Missing form labels on app forms** — Settings pages, filter forms, and data entry screens almost always have more labelling issues than marketing forms, because they're built by product engineers rather than frontend specialists.
**Keyboard traps in modal dialogs** — App-level modals (confirmation dialogs, bulk action screens, onboarding flows) frequently have broken Tab order or missing Escape key handling. These never appear in a public scan.
**Dynamic content not announced to screen readers** — Toast notifications, loading states, live data tables, and inline validation errors need ARIA live regions. These are purely application-layer concerns, invisible to a static HTML scan.
**Low contrast in UI components** — Dark mode and compact UI designs in apps often fail contrast requirements. The design system used for the app is usually different from the marketing site.
**Inaccessible data tables** — App dashboards are full of tables. Without proper ``, `scope`, and `aria-label` attributes, they're unusable with a screen reader.
---
## Who Needs Authenticated Accessibility Scanning
**SaaS companies:** Your application is your product. If it's inaccessible, your users can't use it. That's ADA liability and churn risk simultaneously.
**Government contractors:** Section 508 compliance covers your internal tools and contractor-facing systems, not just public websites. Authenticated scanning is required.
**Healthcare and financial services:** Both sectors have strict federal accessibility requirements covering patient portals and customer account dashboards.
**Enterprise software vendors:** Enterprise procurement increasingly includes accessibility requirements (VPATs, ACRs). You can't produce a VPAT without scanning the actual product.
**Digital agencies:** Your clients' sites often include member portals, e-commerce accounts, and subscription dashboards. White-label reports from authenticated scans are a billable deliverable.
---
## Share This (Tweet-Ready Lines)
> *"Most accessibility scanners never see inside your app. They scan the login redirect, file a clean report, and call it compliance. That's not compliance."*
> *"httpOnly session cookies are invisible to JavaScript — which is why every Chrome extension-based accessibility 'cookie capture' tool fails at authenticated scanning. You need a real browser login, not JS injection."*
> *"Your SaaS dashboard has more accessibility violations than your homepage. You just can't find them because your scanner stops at the login screen."*
---
## Related Reading
- [How to Check If Your Website Is ADA Compliant (Step-by-Step)](/blogs/how-to-check-ada-compliance)
- [ADA Website Lawsuit: The $50,000 Letter Nobody Sees Coming](/blogs/ada-website-lawsuit-cost)
- [Your Last WCAG Audit Is Already Outdated — 9 New Rules](/blogs/wcag-2-2-changes)
**External references:**
- [DOJ 2024 Final Rule on Web Accessibility](https://www.ada.gov/resources/2024-03-08-web-rule/)
- [Section 508 ICT Standards and Guidelines](https://www.access-board.gov/ict/)
- [Playwright Browser Automation — Microsoft](https://playwright.dev)
---
## Scan Your Authenticated Pages — Free on Professional
Public page compliance is the baseline. Authenticated page compliance is where real accessibility work happens.
**[→ Start an authenticated scan at adaguard.io](https://adaguard.io)** — Starter plan and above include authenticated scanning. Professional plan ($129/month) covers up to 200 pages per scan with full session support.
No credit card required for your first scan.
---