How Daylight scores and scans websites

The Sonde Score is a number from 0 to 1000 that measures how accessible a website is. Like a credit score, higher is better, and the method is published in full on this page. The 1000-point scale separates sites finely, and it avoids suggesting that the number is a percentage of checks passed.

The score is calculated per page scanned, so sites of any size can be compared fairly. A 50-page site with 100 findings and a 5-page site with 10 findings get the same score when their findings have the same mix of severities. A score of 500 means the site’s weighted findings per page exactly equal the sensitivity value in the formula below.

Score = round(1000 × S / (S + P / N))

S is the sensitivity, set to 750. P is the sum, over every finding, of its severity weight. N is the number of pages scanned.

Dividing the weighted total by the number of pages removes the effect of site size. The curve then maps that per-page value onto the 0 to 1000 scale. It approaches zero but never reaches it, so every site gets a score that still distinguishes it from others.

Each finding carries the weight of its severity. A critical finding counts forty times as much as a low one.

Severity	Weight	What it means	Example findings
Critical	10	Blocks some people from using the site at all	Keyboard traps, a missing page language, form controls without labels
High	3	Creates a significant barrier	Images without alternative text, text with too little color contrast
Medium	1	Makes the site harder to use without blocking access	Skipped heading levels, links whose purpose is unclear
Low	0.25	An opportunity to follow best practice	Redundant ARIA attributes, minor landmark issues

Score	Band	What it means
900–1000	Excellent	Exemplary accessibility practice, with few or no findings.
750–899	Strong	Good accessibility, with a few areas to improve.
550–749	Progressing	Accessibility work is visible, and key areas still need attention.
350–549	Needs attention	Significant barriers exist, and fixing them in priority order is recommended.
0–349	Getting started	Major accessibility gaps that need action now.

The Element Compliance Rate (ECR) is the share of a site’s page elements that have no accessibility findings. The Sonde Score measures how serious the problems are; the ECR measures how widespread they are. Read together, they show both.

ECR = (total elements − elements with findings) / total elements × 100

Total elements counts every element in each page’s document. Elements with findings counts each distinct element, identified by its CSS selector, that has at least one accessibility finding. A page with 500 elements, 12 of them with findings, has an ECR of 97.6%.

Section 508 is the US law that requires federal agencies to make their technology accessible. Its 2017 refresh adopted the Web Content Accessibility Guidelines (WCAG) 2.0 at Level AA as its technical standard. WCAG 2.1 Level AA includes everything in 2.0 Level AA and adds more, so Sonde scans against WCAG 2.1 AA. Each finding names both the WCAG success criterion and the Section 508 provision it falls under.

Learn more about Section 508 · Read the WCAG 2.1 specification

Every finding in a Daylight report comes from fixed rules. No AI model or large language model is involved in producing a finding. Running the same scan twice gives the same results, so after fixing a problem you can rescan and confirm the finding is gone.

Each finding records the rule or probe that detected it, the page element that triggered it and, where possible, the location in the source code responsible. When a VPAT rates a criterion “Does Not Support”, that rating comes from a repeatable rule, not from a probability estimate.

Sonde’s methodology page explains the principles that keep its analysis honest, for Daylight and for every other Sonde product.

Each scanned site has a downloadable VPAT (Voluntary Product Accessibility Template). The Information Technology Industry Council publishes this format, and government and enterprise buyers use it to check whether a product meets accessibility requirements.

Daylight’s VPAT covers all 50 WCAG 2.1 Level A and Level AA success criteria, with the matching Section 508 provision for each. Every criterion gets one of four ratings: Supports, when no violations were found; Partially Supports, when violations appear on some pages; Does Not Support, when they appear on every page; and Not Evaluated, when judging it needs a person rather than an automated test.

Learn more about the VPAT format

Each scanned site also has a downloadable assessment results file in OSCAL (Open Security Controls Assessment Language), a machine-readable format that NIST developed for security and compliance assessments.

Government agencies and their contractors use OSCAL more and more for FedRAMP authorization packages, continuous monitoring and supply-chain risk management. Daylight’s file follows OSCAL’s Assessment Results model, so governance, risk and compliance tools and procurement workflows can read the findings directly.

Learn more about OSCAL at NIST

Every leaderboard row has a status. Most read “complete”: the crawler reached the site, rendered its pages in a real Chromium browser and ran every probe against them. A few read “incomplete” and show a dash instead of a Sonde Score. On those sites the scan reached the server, but the server did not return pages Sonde could analyze.

Sonde is a polite crawler by design. It identifies itself with a Sonde User-Agent so operators can allow it, follows the Disallow rules and any Crawl-delay in robots.txt, and waits a randomized interval between requests so its traffic does not look like a stress test. When a site’s bot protection, such as Cloudflare, Akamai, DataDome, Imperva, F5 or PerimeterX, shows a challenge page, Sonde waits and retries once in a fresh browser tab. If the second attempt is also challenged, Sonde marks the scan incomplete and moves on rather than trying harder.

A scan is marked incomplete when no pages were analyzed, usually because every request was blocked; when a connection failure, timeout or browser crash ended the crawl before it reached representative pages; or when only one page came back although the sitemap or home page promised many more, which usually means a login wall or a challenge page was hiding the real content.

An incomplete scan is not a score of zero, and it is not a judgment about the site. It records that Sonde could not read the site from outside without signing in. A small number of public sites block bots so strictly that no polite automated browser can scan them cleanly. Daylight publishes that status honestly, and invites the site’s operator to contact Sonde so the review can be completed another way.

Site operators who want a complete Daylight scan can allow Sonde’s crawler on purpose. Sonde’s traffic is transparent: it does not disguise its browser, rotate IP addresses or try to bypass CAPTCHAs. Traffic that is polite is also easy to block, so the sections below say what Sonde sends, what it does not send, and how to recognize its requests.

What Sonde sends

Sonde sends only read-only GET and HEAD requests, to public addresses. It renders pages in headless Chromium, running their JavaScript and CSS the way a visitor’s browser does. It follows robots.txt Disallow rules and any Crawl-delay, and its sitemap and robots.txt requests use the same User-Agent as its page requests.

The User-Agent starts with the Sonde/0.1 product token, followed by the underlying Chromium User-Agent and a readable suffix, for example Mozilla/5.0 (…) Chrome/… Sonde/0.1 (+https://daylight.sonde.tech; Accessibility Auditor). Sonde sends fewer than ten requests per second to any one site, with a randomized pause between them.

In November 2026 the address in that suffix changed to the one shown above, when Daylight moved to its new domain. The Sonde/ product token did not change. A rule that matched the earlier address no longer matches; match the Sonde/ product token instead.

What Sonde does not send

Sonde limits how many requests it makes to one site at a time, and never turns its overall crawling capacity against a single host. It does not use proxies, rotating residential IP addresses or hidden network routes, so its traffic can always be traced to whoever runs the scan. It does not disguise its browser fingerprint, fake navigator properties, simulate mouse or keyboard activity, or use stealth browser plugins.

Behaviors a customer can turn on

Unattended and public scans, including every Daylight scan, never send a POST, PUT, DELETE or other request that changes data; never try to sign in, so they submit no credentials, session tokens or cookies harvested from third parties; and never submit forms, which they read but do not interact with. A scan run for a specific customer can turn these behaviors on.

How to allow Sonde

This guidance works with any bot-protection product. In order of preference:

1. Match the Sonde/ token in the User-Agent and allow GET and HEAD requests that match it. The version after the slash (0.1 today) will change between releases, but the leading Sonde/ will not.
2. If your bot protection can alert someone instead of blocking, send Sonde matches to a person for review rather than blocking them outright. Sonde answers operators at daylight@sonde.tech.
3. Combine the User-Agent match with a conservative rate limit. Sonde sends fewer than ten requests per second to a site, so faster traffic is not Sonde, even when it carries a Sonde/ User-Agent.

A caveat: the Sonde/ User-Agent token alone cannot prevent impersonation, because User-Agent strings are trivially spoofable. Treat it as one signal among several, together with a rate limit and, once Sonde publishes one, an allowed range of IP addresses. Do not rely on the User-Agent alone to decide what to allow.

Where Sonde’s traffic comes from

Sonde does not currently operate a stable public scanner egress. Many Daylight scans run on machines that contributors, customers or Sonde staff control, so the IP address a scan comes from cannot be known in advance, and allowing Sonde by IP address is not yet possible. When Sonde runs a hosted scanner, its traffic will come from *.sonde.tech and its address range will be published here. Until then, the User-Agent token and a rate limit are the strongest signals available.

Guidance for specific products

Cloudflare, Akamai Bot Manager, Imperva, F5, DataDome and PerimeterX each have their own rule editor, and the approach is the same in all of them: a custom rule that matches the Sonde/ token, allows GET and HEAD requests, and treats the source as a known good bot. Sonde will publish a tested rule for each product here as it validates them against actual customer dashboards. Until a rule has been checked end to end, with the rule deployed, the scan rerun and the scan completed, this section stays product-neutral.

The severity weights are being calibrated against a growing set of government website scans. The goal is a median score between 400 and 600, with most scores between 250 and 750. Once 15 or more further scans confirm that the scores are stable, the methodology will be fixed as version 1.0. Until then it is a work in progress, and the weights may change.