Comprehensive audits & actionable guidance
The scanner comprehensively examines websites/domains/infrastructure using our own proprietary analysis software:
π₯οΈ Software & Infrastructure Scan: Frontend and backend are checked for outdated libraries, insecure dependencies and known vulnerabilities in deployed technologies.
π URL Reputation & Abuse Check: The domain is cross-referenced against known blacklists and abuse databases to detect phishing entries, malware associations or spam reputation early.
π‘οΈ Web Server Audit: Security-relevant HTTP headers are analysed β including Content Security Policy (CSP), Strict-Transport-Security (HSTS), X-Frame-Options and other protections against common attack vectors.
π‘ DNS Checks & Email Security: DNS configuration and email security protocols such as SPF, DKIM and DMARC are verified to prevent spoofing and unauthorised email sending in the name of the domain.
π Hosting & Domain Analysis: Hosting environment, IP reputation, ASN assignment and domain registration data are examined for anomalies.
π CVE Vulnerability Check: Deployed software components are matched against the public CVE database β already documented security vulnerabilities are reliably identified.
π Form Audits: Forms are checked for insecure transmission, missing CSRF protection and insufficient input validation.
β οΈ XSS Security Checks: The site is tested for cross-site scripting vulnerabilities β a common attack vector where malicious code can be injected into other users' browsers.
πͺ Cookie Check + LocalStorage & SessionStorage: Cookies are checked for secure flags (HttpOnly, Secure, SameSite). In addition, it is analysed whether sensitive data is stored unprotected in browser storage.
π WCAG Checks & Best Practices: The analysis checks your website for compliance with current WCAG guidelines (including newer versions) and established accessibility best practices β from correct semantics to accessible interactive elements.
π¨ Contrast Analysis: All text/background combinations on the homepage are checked for sufficient colour contrast so that content remains readable for visually impaired users.
ποΈ Colour Blindness Check: The homepage is simulated as it appears to people with various forms of colour blindness β and whether information is conveyed through colour alone.
π§ Heuristic Checks: Experience-based rules detect context-sensitive barriers β such as navigation areas, forms or buttons without accessible labels that are not identifiable for screen reader users.
π Static Checks: The source code is directly examined for objectively measurable errors β including duplicate IDs, broken ARIA references, incorrectly applied aria-hidden, form issues and CSS properties that impair reflow or text spacing.
π Every issue found is documented in the report:
π Location in source code β You see exactly where in the HTML the problem occurs.
π¬ Message text β A concise description of the problem at a glance.
π Brief explanation β What does this message mean in practice?
π οΈ Extended guidance β A detailed description of the problem, its impact on affected user groups and concrete solutions.
π Dedicated help page β Each issue links to a dedicated page with further information and code examples.
A website can be scanned as many times as you like. The number of available scans depends on the chosen package. With Security-10 you can run 10 scans, and with Security-20 you can run 20 scans for any websites.
Yes! Simply send us a message to the address from which you received your customer access after ordering (or to our general support address). We will send you pricing information promptly and switch your package.
Of course it is cheaper to choose the right package from the start rather than starting small and upgrading shortly after.
Our service is suitable for all types of websites:
Requirements:
We are happy to help:
For questions about your order, the report or technical implementation β we are here to help.
π§ Definition: Heuristic checks analyse a website using established rules of thumb (heuristics). They recognise typical patterns that are known from experience to create barriers for people with disabilities β without fully manual testing.
π― Goal: To automatically detect frequent, well-documented problems that a simple rule check alone would not find β for example whether an element exists but is not accessible by name.
π·οΈ Missing accessible names: Navigation areas (<nav>), forms (<form>), page regions (<section>, <aside>) or embedded content (<iframe>) without a descriptive aria-label are indistinguishable or invisible to screen reader users.
π Unlabelled buttons & input fields: Buttons without visible text or aria-label and input fields without an associated label cannot be meaningfully read out by assistive technologies.
πΊοΈ Unrecognised landmarks: Elements with role="region" or role="search" without an accessible name are simply ignored by screen readers.
π WCAG 4.1.2 β Name, Role, Value: All interactive and structural elements must have a recognisable name and a clear role for assistive technologies.
π WCAG 1.3.1 β Info and Relationships: Structure and meaning of content must also be programmatically detectable β without visual perception β e.g. through correct landmark markup of forms and page regions.
βοΈ Simple rule checks are binary: "Is an alt attribute present? Yes/No."
π§© Heuristic checks go a step further: they take context into account β for example whether multiple <nav> elements exist on a page and therefore need distinguishable labels, or whether a button truly has no accessible name even though it contains an icon.
π οΈ Concrete solution suggestions: For each identified problem, the heuristic check delivers directly actionable code fixes β for example adding aria-label="Main Navigation", linking a label to an input field via for/id, or hiding purely decorative elements with aria-hidden="true".
β No interpretation needed: The results are prepared so that developers can implement the corrections directly in the code β without in-depth WCAG knowledge.
π Definition: Static checks analyse the HTML and CSS source code of a page directly β without executing it in a browser. They look for firmly defined, objectively measurable patterns that demonstrably violate accessibility standards.
π― Strength: These checks deliver clear yes/no results and are fully automatable. They form the foundation of any serious accessibility analysis.
π Structural HTML errors: Duplicate IDs in the document or deprecated HTML elements can cause assistive technologies to misinterpret or not find content at all.
π Broken ARIA references: If aria-labelledby or aria-describedby references an ID that does not exist in the document, the element remains without an accessible name for screen readers.
π« Incorrectly applied aria-hidden: If aria-hidden="true" is set on focusable elements or even on <body>, content disappears entirely for keyboard and screen reader users.
π Form issues: Radio and checkbox groups without <fieldset>/<legend>, input fields with autocomplete enabled for sensitive data, or generic link texts like "click here" are frequent, easily fixable barriers.
π¨ Yes β stylesheets are also checked: Certain CSS properties can directly violate accessibility criteria:
βοΈ Reflow (WCAG 1.4.10): Excessively large min-width values or overflow-x: scroll force users to scroll horizontally β a significant problem for people with visual impairments who zoom in heavily.
π Text Spacing (WCAG 1.4.12): Fixed heights on containers cause text to be cut off as soon as users apply their own letter/line spacing settings.
π Static = rule-based & unambiguous: A problem like "duplicate ID" or "missing <legend>" is either present or not. No room for interpretation.
π§ Heuristic = context-sensitive: Heuristic checks evaluate whether an element forms a barrier in combination with other elements β for example whether a <nav> exists but is not distinctly labelled on a page with three other navs.
π€ Together comprehensive: Only the combination of both methods yields a reliable accessibility analysis.
β οΈ No β and this is important to know: Static checks reliably identify all automatically verifiable violations. Estimates suggest this covers about 30β40% of all possible WCAG issues.
π What they do not detect: Whether an alt text is meaningfully descriptive, whether the reading order feels logical, or whether interaction flows are truly intuitive for keyboard users β this additionally requires heuristic analysis or manual testing.
Contract term: The contract initially runs for one year.
Cancellation: You can cancel up to one month before the end of the term. Without cancellation the contract automatically renews for one additional year.
No, not at all!
We are happy to offer you a discounted price. Request an individual quote: service@it-logic.de