Compliance & GDPR

Real axe-core run against WCAG 2.0, 2.1 and 2.2 Level A and AA (tags `wcag2a`, `wcag2aa`, `wcag21a`, `wcag21aa`, `wcag22a`, `wcag22aa`) in Playwright Chromium — a comprehensive rule set instead of simple HTML heuristics, including the new 2.2 criteria such as Target Size (2.5.8). This detailed axe-core run executes in the monitoring daemon and in the free public BFSG tool; in the on-demand scan the accessibility score comes from Lighthouse instead. Every violation carries a rule ID, short title, description, impact severity (critical/serious/moderate/minor), the number of affected elements and a help URL to Deque University — the list shows up to 25 violations plus up to 15 rules from axe-core's `incomplete` output that are candidates for manual re-checking. Some 2.2 criteria — such as Consistent Help (3.2.6), Redundant Entry (3.3.7) and Accessible Authentication (3.3.8) — are inherently not automatically testable; there is no axe-core rule for them, so they appear in neither the violation nor the `incomplete` list and must be reviewed manually anyway from a legal standpoint. The evidence required in Germany since 28 June 2025 is collected automatically on a regular schedule.

If the measured axe-core score drops below 50, monitoring automatically raises an “accessibility_low” alert — severity warning, or critical below a score of 30. The alert states the score and the number of WCAG violations found and is delivered (like all alerts) over your configured channels. This surfaces a sudden regression, for example after a theme update.

From the current accessibility score XICTRAQ generates, on demand, a template for the accessibility statement (Markdown, downloadable). The conformance status is derived from the score: from 80 % “partially conformant”, below that “not conformant”. The template deliberately never issues “fully conformant” — an automated measurement covers only part of the WCAG success criteria and cannot establish full conformance. If no measurement exists for the website yet, no template is generated. The template follows the BITV 2.0 / Directive (EU) 2016/2102 structure and contains the mandatory sections: conformance status, non-accessible content, creation date, feedback / contact details and enforcement procedure. An adaptable starting template — not a finished legal document.

Distinct from the technical axe-core / WCAG scan, XICTRAQ now checks whether an accessibility statement is linked — and how deep it is in content. The statement text is searched for three building blocks of the EU model accessibility statement (Commission Implementing Decision (EU) 2018/1523, Annex, Section 1): a feedback / contact mechanism for reported barriers, a conformance-status statement (e.g. “partially conformant”), and a creation / last-updated date. If a building block is missing, an info/low hint appears. XICTRAQ does not check item by item the information that § 14(1) no. 2 BFSG with Annex 3 requires from service providers. This is a presence and content check only — not a legal review and not a replacement for the technical WCAG scan.

In addition to the imprint and privacy links, the content scan now also detects a terms / AGB link. At a glance you can see whether the usual mandatory and standard legal pages are linked at all. A missing terms link is an info/low hint — the content or legal validity of the pages is not assessed.

During the content scan, the HTML body is checked for five common risk patterns: external Google Fonts (fonts.googleapis.com / fonts.gstatic.com — GDPR risk per LG Munich I 3 O 17493/20), Google Analytics incl. gtag/ga.js, Facebook Pixel (fbevents.js / fbq call), a missing imprint link and a missing privacy-policy link. Findings feed into the privacy risk score and show up in the compliance tab with severity (high/medium).

For embedded services such as Google Maps and reCAPTCHA the finding is now derived from the actual browser network requests fired before any consent interaction — no longer from an HTML pattern match alone. If a tracker demonstrably loads over the network before consent, that remains a clear violation (high severity). If, however, the snippet is gated by a consent management platform (CMP) and only fires after consent, it is no longer counted as a hard violation but shown as an informational note “Check consent control (interaction test required)” — this removes false positives on sites that are correctly CMP-gated. When no browser network analysis is available, an HTML-only match is flagged as “low confidence”. Not legal advice — a technical indicator.

On demand (button “Check cookie banner”, around 60 seconds) Playwright loads the page in a fresh, cookie-free profile. Phase 1 (before any consent): accept and reject buttons are found via text patterns (DE + EN) and compared by area, background colour and above-the-fold position. Dark-pattern findings: “no_reject_button” (no reject, BGH I ZR 7/16), “reject_smaller” (reject < 60 % of the accept area), “reject_unstyled” (only accept has a coloured background), “reject_below_fold” and “buttons_not_identifiable” (banner visible but buttons in shadow DOM/iframe not locatable). In parallel every third-party tracker that loads over the network BEFORE consent is classified (e.g. Google Analytics, Google Ads, Meta Pixel) and reported as “tracker_before_consent”. Phase 2 (after clicking “Reject” + reload): if tracking still loads after reject, “reject_does_not_block” (critical) is set and banner_actually_blocks=false — the banner is theatre. Overall score 0–100.

Review badges (e.g. Trustpilot, Trusted Shops, ProvenExpert, eKomi) often load Google Fonts, Maps or Analytics themselves. Such sub-requests are attributed to the widget via the initiator chain (Chrome DevTools Protocol script stack) and reported separately as “tracker_via_trust_widget” — they do NOT deduct points from the page, because they belong to the third-party badge. This removes pre-consent false positives. Note: if you embed such a badge, a consent obligation may apply via the widget provider itself.

During content scan, the HTML body is searched for src= and href= attributes pointing at http:// (regardless of element type, e.g. images, scripts or stylesheets). Browsers block these on HTTPS pages — causing invisible layout errors. Count + list of findings shown in the dashboard.

The score is `points earned / points available × 100`, rounded to whole percent. Traffic light: from 80 green (low risk), from 50 amber (medium risk), below that red (high risk). With all ten criteria measured the total is 115 points — a missing imprint alone therefore costs roughly 13 percentage points. Below the ring the card lists every violation individually with its legal basis and point deduction.

A criterion has three states: met, violated — or not yet measured. As long as no full scan has run for a website, individual raw values are missing; those criteria appear in the card under “Not checked” and drop out of both numerator AND denominator. The score then explicitly refers only to the criteria actually measured, and the counter below states how many were checked. A missing measurement is never counted as a violation — a false finding with a legal citation and a point deduction would do more damage than an openly declared gap. If nothing has been measured yet, the traffic light stays grey and the ring shows a dash instead of a number.

SSL, CSP and domain expiry come from the automatic scan (every 24 hours on Free, every 6 hours on paid plans; the RDAP domain-expiry check runs daily on every plan). HSTS, cookies, imprint, privacy policy, Google Analytics and the Facebook pixel come from the full scan, which you start on demand; Google Fonts additionally from the daily cookie scan in the browser. The timestamp below the card states the oldest of these. The same score is recorded in the changelog whenever it moves by at least 10 points or across a traffic-light threshold.