Most accessibility scanners default to crawling public pages. To scan web pages that require authentication, you need to provide the scanner with login credentials or session data so it can access content behind a login wall. Without this step, your scans will only cover the public-facing portion of your site, missing dashboards, account settings, forms, and other authenticated content where accessibility issues often appear.
This matters because authenticated pages typically contain the most interactive and complex functionality on a website. If your scan never reaches those pages, you have an incomplete picture of your site’s accessibility posture.
| Consideration | Details |
|---|---|
| Why it matters | Authenticated pages contain forms, dashboards, and account features that are often more complex than public pages |
| Common methods | Login credentials, session cookies, authentication tokens, or recorded browser sessions |
| Scan coverage | Scans only flag approximately 25% of issues; authenticated scanning improves coverage area but not detection depth |
| Key risk | Session expiration mid-scan can produce incomplete or inaccurate results |
Why Authenticated Pages Need Scanning
Public pages are often the simplest part of a website. The real complexity lives behind the login: user dashboards, profile editors, shopping carts, messaging systems, admin panels, and account management screens.
These pages tend to be more dynamic and interactive. They rely heavily on JavaScript, custom form controls, and state-dependent content. Accessibility issues in these areas directly affect the people who use your product or service the most.
If your automated scans only cover public content, you are scanning the lobby and skipping every room in the building.
How Do Scanners Access Authenticated Content?
Scanners need a way to prove they are a logged-in user. There are several common approaches depending on the tool you use.
Login credentials: Many scanners accept a username and password pair. The tool logs in through your site’s login form before beginning its crawl. This is the most common method, but it requires a dedicated account that the scanner can use without triggering multi-factor authentication or CAPTCHA.
Session cookies: Some tools allow you to paste in a session cookie from an already-authenticated browser session. The scanner uses that cookie to bypass the login step entirely. This works well for sites with complex authentication flows, but the cookie will expire. You need to time the scan accordingly.
Authentication tokens: For web apps and SaaS products that use token-based authentication (JWT, OAuth), some scanners can accept a bearer token. This is common in more technical configurations and is relevant for teams evaluating software or web app accessibility against WCAG 2.1 AA or WCAG 2.2 AA.
Recorded browser sessions: A few tools let you record a browser interaction where you manually log in, then replay that session during the scan. This is useful when your login flow involves redirects, SSO, or other non-standard patterns.
Steps to Configure an Authenticated Scan
The exact steps vary by tool, but the general process follows a consistent pattern.
First, create a dedicated scan account. Use a non-admin account that has access to the pages you want to evaluate. This keeps the scan contained and prevents accidental data changes. Disable multi-factor authentication and CAPTCHA on this account, or configure your scanner to work around them.
Second, configure your scanner with the chosen authentication method. If using credentials, enter the username, password, and login page URL. If using cookies or tokens, extract them from your browser’s developer tools and paste them into the scanner’s configuration panel.
Third, define the scan scope. Specify which URLs or URL patterns the scanner should crawl after authentication. Without scope limits, the scanner may crawl areas you did not intend, including admin functions or data-sensitive pages.
Fourth, conduct a short pilot scan. Start with a small set of pages to confirm the scanner is actually accessing authenticated content. Check the results for pages that should only be visible to logged-in users. If the results show only public content, the authentication configuration is not working.
What Can Go Wrong with Authenticated Scanning?
Session expiration is the most common issue. If your site’s session timeout is 15 minutes and the scan takes an hour, the scanner will lose access partway through. Extend session timeouts for the scan account, or use a token with a longer lifespan.
Login redirects can also break things. If your login page redirects through multiple URLs (common with SSO providers), the scanner may not follow the redirect chain correctly. Recorded browser sessions or cookie-based authentication often work better in these cases.
Another common problem: the scanner accidentally triggers a logout. Some sites log out a user when certain pages are visited or when a “sign out” link is encountered during a crawl. Exclude logout URLs from the scan scope.
Scans Are a Starting Point, Not a Finish Line
Even when configured correctly for authenticated pages, scans only flag approximately 25% of accessibility issues. Automated tools are good at identifying missing alt text, empty form labels, and color contrast problems. They cannot evaluate whether a custom dropdown is operable with a keyboard, or whether a screen reader can make sense of a dynamic dashboard.
A (manual) accessibility audit conducted by a qualified auditor is the only way to determine WCAG conformance. Scans and audits serve different purposes entirely. Accessible.org audits are always fully (manual), evaluating every page and interaction against the full WCAG standard.
Scanning authenticated pages gives you broader issue detection across your site. But the depth of that detection remains limited to what automation can catch. For ADA compliance or conformance with standards like Section 508 and EN 301 549, a scan is not a substitute for a thorough evaluation by a person.
Tips for Better Authenticated Scan Results
Use a staging environment when possible. Scanning production can introduce unexpected side effects, especially if the scanner submits forms or follows action links. A staging copy gives you the same content with lower risk.
Document your scan configuration. Record which authentication method you used, which account, which scope, and when the scan ran. This helps when comparing results over time and when coordinating with your remediation team.
Schedule regular scans. Authenticated content changes frequently. New features, updated forms, and redesigned dashboards introduce new accessibility issues. Regular monitoring keeps you informed.
Can I scan pages behind a login without disabling MFA?
It depends on the scanner. Most tools cannot complete multi-factor authentication flows automatically. The typical workaround is to disable MFA on the dedicated scan account, or to use cookie or token-based authentication that bypasses the login form entirely. Check your scanner’s documentation for supported methods.
Do I need separate scans for public and authenticated pages?
Yes, in most cases. Public pages can be scanned without any special configuration. Authenticated pages require a separate scan configuration with login credentials, cookies, or tokens. Running them as two separate scans also makes it easier to compare results and prioritize remediation work for each area.
Will scanning authenticated pages tell me if my site conforms to WCAG?
No. Scans only flag approximately 25% of issues regardless of how many pages they cover. Broader page coverage means more issues identified, but a scan cannot confirm WCAG 2.1 AA or WCAG 2.2 AA conformance. That determination requires a (manual) accessibility audit from a qualified auditor.
Authenticated page scanning closes an important coverage gap in your automated accessibility monitoring. It does not replace human evaluation, but it does give your team a more complete view of where automated issues exist across your entire site.
Contact Accessible.org for a thorough accessibility audit of your web pages, including authenticated content.
