One scan, six dimensions: accessibility, security, privacy, deceptive design, quality, and SEO, where accessibility-only checkers stop at one.
Free guest scan · up to 5 pages · no signup
How each mapping is qualified. “Direct mapping” means our rules cite the instrument in code; “Aligned framework” means it adopts criteria we test, clause-by-clause citation aside.
The rule catalogue is written directly against these documents, not a generic best-practices checklist.
The DOJ’s 2024 final rule makes WCAG 2.1 Level AA a binding target for state and local government web content. Public entities serving 50,000 or more people have been covered since April 24, 2026; entities under 50,000 and special district governments have until April 26, 2027.
Read the DOJ ruleCISA’s Secure by Design initiative asks software makers to ship with secure defaults. Missing security headers, outdated TLS, and mixed content are exactly the gaps it calls out.
Read the CISA principlesThe FTC has brought enforcement actions over manipulative design. Hidden recurring charges, hard-to-cancel flows, and pre-checked consent boxes are the patterns the Deceptive Design Risk dimension flags.
Read the FTC staff reportSitejar doesn’t just detect issues. Its SURE engine proposes the exact fix for each finding: reviewed, ranked, and ready for your developer or AI assistant.
Sitejar crawls your pages in a real browser, the same rendered page your visitors see, not just the raw HTML.
Every finding names its element in plain language and carries an honest confidence label: Confirmed, Likely, or Needs review. From your scan results you can export it, generate a structured accessibility statement, produce an executive report for leadership, or build a VPAT draft for procurement.
SURE proposes the exact change. Copy it, hand the export to your developer, or paste the generated prompt into your AI assistant.
Sitejar’s technical checks map to the leading digital compliance frameworks across the US, EU, UK, Canada, and Australia, across all six dimensions we scan.
WCAG 2.1 Level AA is the technical basis nearly every regional accessibility law inherits from: the ADA Title II rule, Section 508, EN 301 549 behind the European Accessibility Act, the UK’s public sector regulations, and Ontario’s AODA all point back to it. Sitejar’s accessibility rules map directly to WCAG success criteria, and every accessibility finding cites its regulatory basis: the WCAG criterion for technical checks, or the statutory requirement for statement transparency.
Read the official source for WCAG 2.1 at the W3CFederal accessibility obligations are set by the ADA and Section 508, with the DOJ’s 2024 Title II rule putting a dated WCAG target on state and local government web content. Security and consumer-protection expectations come from CISA guidance and FTC enforcement rather than a single web statute. State privacy laws add their own requirements on top.
What we detect for the US today: WCAG-based accessibility, plus security, privacy, deceptive-design, quality and SEO checks that apply everywhere, plus one California-specific privacy check: on a site that looks commercial, whether it offers a “Do Not Sell or Share My Personal Information” / “Your Privacy Choices” opt-out link (flagged for California under CPRA §1798.135). We do not yet run an auto-renewal disclosure check. That is on our roadmap, and we would rather say so than imply coverage we don’t have.
Every WCAG-based accessibility finding cites the specific WCAG 2.1 success criterion it tested, alongside the jurisdictional instruments that reference that criterion, including the DOJ’s 2024 Title II rule, which makes WCAG 2.1 Level AA a binding target for state and local government web content. Findings from best-practice checks cite the general WCAG standard only, because they map to no success criterion.
Read the official source for the ADA Title II web ruleSection 508 sets WCAG 2.0 Level AA as the benchmark for federal agencies’ information technology. Our checks target WCAG 2.1 Level AA, which contains all of 2.0 Level AA. We don’t test Section 508’s non-web provisions such as hardware, software, or documentation.
Read the official source for Section 508 laws and policiesOur security checks read response headers, the negotiated TLS configuration, and mixed content, concrete instances of the secure-defaults principle CISA’s guidance asks software makers to ship. That guidance is a set of principles rather than a testable specification, so this is alignment, not a clause-by-clause mapping.
Read the official source for CISA Secure by DesignPrivacy findings carry FTC Section 5 and data minimization as their reference. We check whether known trackers load before a consent choice is made, whether third-party cookies are set on first load, whether a privacy policy link exists, and whether a form asks for more data than its apparent purpose needs.
Read the official source for the Federal Trade Commission ActOn a site that shows commercial signals (a cart or checkout flow, a pricing page, or an embedded payment provider), we check whether it offers a “Do Not Sell or Share My Personal Information” or “Your Privacy Choices” opt-out link (the clear-and-conspicuous link CPRA §1798.135 requires) and flag the finding for California. We still do not verify the other CCPA mechanisms: opt-out preference signals such as Global Privacy Control, or consumer request flows.
Read the official source for the California Consumer Privacy ActThe Deceptive Design Risk dimension checks the patterns that report describes: pre-checked marketing opt-ins, consent banners where Accept is more prominent than Reject, rejecting that takes extra steps, costs that appear only inside a form, and countdown or scarcity widgets.
Read the official source for the FTC dark patterns staff reportYes, for the web criteria. Every WCAG-based accessibility finding cites the WCAG 2.1 success criterion it tested, alongside the instruments that reference that criterion, the DOJ’s 2024 ADA Title II rule among them. Section 508 sets WCAG 2.0 Level AA for federal information technology, which our WCAG 2.1 Level AA checks contain, though we do not test Section 508’s non-web provisions such as hardware or documentation, and Section 508 binds federal agencies and their vendors rather than private sites generally. A scan is evidence about those technical requirements, not a certification of legal compliance.
The European Accessibility Act has applied to in-scope products and services since 28 June 2025, and EN 301 549 is the harmonised standard behind it. Privacy obligations sit with the GDPR and the ePrivacy Directive, which govern how consent for tracking must be obtained.
Some Sitejar checks are specific to this region: our cookie-consent checks look for whether trackers load before a choice is made, and whether refusing is as easy as accepting, the mechanics ePrivacy Art. 5(3) and GDPR Art. 7 turn on. Findings that apply here are flagged in your report against those instruments. The tracker-before-consent check is deterministic (a Confirmed finding); the refuse-as-easy-as-accept checks are heuristics over what a page renders and carry a “Needs review” label rather than asserting a violation. We also check whether the site links to an accessibility statement (a transparency obligation the European Accessibility Act places on in-scope services under Art. 13(2) and Annex V) and flag its absence for the EU. Because publishing a statement is a legal requirement rather than a WCAG success criterion, that finding cites no criterion; it is deterministic (Confirmed) on the link’s presence, and never judges what a statement that exists actually says.
EN 301 549 is the European accessibility standard for information technology, and its web clause adopts WCAG 2.1 Level AA, exactly the criteria our accessibility rules test. We evaluate the web criteria only, not EN 301 549’s non-web clauses. Separately, we check whether the site links to an accessibility statement (the transparency obligation the EAA places on in-scope service providers under Art. 13(2) and Annex V) and flag its absence for the EU. That is a non-WCAG check on link presence, so it cites no success criterion.
Read the official source for the European Accessibility ActOur consent checks examine the mechanics these rules turn on: whether tracking scripts load before any choice is made, and whether a banner offers a visible reject control at all. Region-specific findings are now flagged with the instrument that governs them in each market (ePrivacy Art. 5(3) and GDPR Art. 7 here) via RegionScopes; some are multi-jurisdiction, such as the third-party-cookie-before-consent finding, which is flagged for the EU (ePrivacy Art. 5(3)), the UK (PECR Reg. 6) and California (CPRA §1798.100). We do not assess lawful basis, international transfers, or records of processing.
Read the official source for the General Data Protection RegulationFor web content, yes. EN 301 549 (the harmonised standard behind the European Accessibility Act) adopts WCAG 2.1 Level AA for the web, and those are the criteria our accessibility rules evaluate. We do not test EN 301 549’s non-web clauses, and a scan assesses technical requirements rather than certifying conformance.
UK public sector websites are covered by the Public Sector Bodies Accessibility Regulations, which set a WCAG-based accessibility requirement. The Equality Act 2010 applies more broadly but names no technical standard.
Some Sitejar checks are specific to this region: the same cookie-consent checks described under the EU tab are flagged for the UK against PECR Reg. 6 and UK GDPR Art. 7, which are separate instruments post-Brexit. Findings that apply here are flagged in your report; the tracker-before-consent check is deterministic (Confirmed), while the refuse-as-easy-as-accept checks are heuristics labelled “Needs review” rather than assertions of a violation. We also check whether the site links to an accessibility statement, which the Public Sector Bodies Accessibility Regulations require of public sector bodies (Reg. 8), and flag its absence for the UK. That obligation binds the public sector specifically; private sites fall under the Equality Act, which mandates no statement. The check is a non-WCAG, Confirmed test on the link’s presence and cites no success criterion.
The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations require public sector sites to meet an accessibility requirement that maps to WCAG 2.1 Level AA through EN 301 549, the criteria our accessibility rules test. They also require an accessibility statement (Reg. 8); we check whether the site links to one and flag its absence for the UK. That is a non-WCAG check on link presence, so it cites no success criterion, and the statement obligation binds public sector bodies specifically.
Read the official source for the Public Sector Bodies Accessibility RegulationsThe Equality Act names no technical standard. It requires reasonable adjustments for disabled people, and WCAG 2.1 Level AA is the benchmark UK practice points to. Our checks give you evidence about that benchmark; they do not determine whether an adjustment was reasonable.
Read the official source for the Equality Act 2010Our accessibility checks evaluate WCAG 2.1 Level AA, which is the accessibility requirement the Public Sector Bodies Accessibility Regulations point to through EN 301 549. The Equality Act 2010 names no technical standard, so a scan is evidence about the WCAG benchmark rather than an answer about reasonable adjustments or legal liability.
Ontario’s AODA sets a WCAG requirement for public websites in that province, while federally regulated organisations work to the Accessible Canada Act, whose information-technology standard adopts EN 301 549.
Sitejar’s Canadian coverage today is via WCAG-based accessibility. Region-specific privacy (PIPEDA) and consumer-protection detections are on our roadmap. We do not run any Canada-specific check yet, and no finding in your report will be flagged for Canada.
Ontario’s Integrated Accessibility Standards Regulation requires WCAG 2.0 Level AA for public websites. Our checks target WCAG 2.1 Level AA, which contains all of 2.0 Level AA, so the criteria the regulation names are among those we evaluate. We don’t test the IASR’s non-web requirements, and evaluating those criteria is not the same as certifying conformance with them.
Read the official source for Ontario’s Integrated Accessibility Standards RegulationFederally regulated organisations work to the Accessible Canada Act, whose information-technology accessibility standard adopts EN 301 549, which in turn adopts WCAG 2.1 Level AA for web content.
Read the official source for the Accessible Canada ActFor web content, yes. Ontario’s AODA regulation requires WCAG 2.0 Level AA and the Accessible Canada Act’s information-technology standard adopts EN 301 549, which uses WCAG 2.1 Level AA. Our accessibility rules evaluate WCAG 2.1 Level AA, which contains the 2.0 Level AA criteria. But a scan assesses technical requirements, it does not certify conformance.
The Disability Discrimination Act 1992 prohibits disability discrimination without naming a technical standard for websites. WCAG is the benchmark Australian government digital guidance points to in practice.
Sitejar’s Australian coverage today is via WCAG-based accessibility. Region-specific privacy and consumer-protection detections are on our roadmap. We do not run any Australia-specific check yet, and no finding in your report will be flagged for Australia.
The DDA names no technical standard for web content. WCAG Level AA is the benchmark Australian government digital guidance uses, and those criteria are what our accessibility rules evaluate, producing evidence about accessibility, not a conclusion about discrimination liability.
Read the official source for the Disability Discrimination Act 1992Indirectly. The Disability Discrimination Act 1992 names no technical standard for websites; WCAG Level AA is the benchmark Australian government digital guidance points to, and our accessibility rules evaluate WCAG 2.1 Level AA. A scan produces evidence about those criteria. Questions of discrimination liability are for legal advice, not a scanner.
Highlighted: United States
Sitejar helps you assess your posture against these frameworks. It does not certify compliance. No automated tool can.
Accessibility checkers stop at accessibility. One Sitejar crawl also covers security headers and TLS, privacy and trackers, deceptive design, technical quality, and SEO basics.
Every finding carries a clarity label (Confirmed, Likely, or Needs review) so you know how much to trust each result before acting on it. No automated tool can prove everything; ours labels what it cannot.
No injected script pretending to repair pages in the browser. Sitejar proposes source-level changes for your team to review and apply, so your site stays yours.
Scores are calibrated against real reference sites so comparable sites produce comparable numbers. That includes our own site, scanned in public regularly.
It depends on who you are and where you operate. Under the U.S. Department of Justice’s 2024 rule (28 CFR Part 35, Subpart H), state and local government web content must conform to WCAG 2.1 Level AA by fixed deadlines. Private businesses face ADA Title III case law, and other jurisdictions have their own laws (Section 508 for U.S. federal agencies, the European Accessibility Act, Ontario’s AODA). Sitejar is not a law firm and nothing on this site is legal advice. Talk to counsel about your specific obligations.
A guest scan crawls up to 5 pages of your site with no signup and reports across all six dimensions. You see full accessibility findings plus summary counts for the other five dimensions; a free account unlocks the full findings and saved scan history, and paid plans add deeper crawls, exports, and AI-generated fix suggestions.
No, and no automated tool honestly can. Many WCAG success criteria require human judgment that no scanner can verify. What Sitejar does instead: it evaluates your pages against the documented technical requirements of the standards, and gives every finding an explicit clarity label (Confirmed, Likely, or Needs review) so you know how much to trust each result before acting on it. Treat the scan as rigorous triage, not a certificate.
SURE (Semantic Unified Remediation Engine) is the layer that turns findings into concrete candidate fixes. Fixes are proposed only when appropriate for the finding type, and each fix carries a clarity label so you know how much review it warrants.
No. Overlays inject a script that tries to patch pages in your visitors’ browsers at render time, an approach disability advocates have widely criticized, because it masks issues without fixing the underlying code and can make assistive-technology behavior worse. Sitejar proposes code-level fixes for your developers (or AI assistant) to review and apply at the source, and changes nothing on your site by itself.
The rule catalogue is written against the technical requirements of WCAG 2.1 Level AA (the target the ADA Title II rule, Section 508, EN 301 549 for the European Accessibility Act, and Ontario’s AODA all reference), plus security-header and TLS guidance consistent with CISA’s Secure by Design principles and the deceptive-design patterns described in the FTC’s staff report on dark patterns.
Each dimension gets an independent 0–100 score. Scores are calibrated against real reference sites so that comparable sites produce comparable numbers, and the same score means the same thing on any site scanned.