Security and accessibility of your website at a glance
Our own scanner, clear findings and concrete solution proposals. Choose the package that fits your needs.
- π Proprietary scanner
- βΏ Accessibility included
- π Detailed report
- π οΈ Help pages for every finding
Online order
Get your customer account in just a few steps. You will receive the invoice by email.
plus β¬- VAT = β¬- total
For information on data processing, please see our privacy policy.
Invoice by email. Access to the customer area after payment is received.
Frequently asked questions
Everything important about scope, process and contract.
What makes the Security Website Check special?+
The scanner comprehensively examines websites, domains and infrastructure with proprietary analysis software:
- Website/domain scan
- Software scan (frontend & backend)
- DNS & email checks
- Web server checks (CSP, ...)
- Hosting, provider and CDN indication
- Form checks
- XSS checks
- Accessibility checks, global and page by page
- Cookie table
- Detailed report with findings and guidance
Which security checks are performed?+
π₯οΈ Software & infrastructure scan: Frontend and backend are checked for outdated libraries, insecure dependencies and known vulnerabilities in the technologies in use.
π URL reputation & abuse check: The domain is compared against known blacklists and abuse databases to detect phishing entries, malware associations or a poor spam reputation early.
π‘οΈ Web server check: Security-relevant HTTP headers are analysed, including Content Security Policy (CSP), Strict-Transport-Security (HSTS), X-Frame-Options and other protection mechanisms against common attack vectors.
π‘ DNS checks & email security: DNS configuration and email security protocols such as SPF, DKIM and DMARC are checked to prevent spoofing and unauthorised email sending in the name of your domain.
π Hosting & domain analysis: The hosting environment, IP reputation, ASN assignment and domain registration data are examined for anomalies.
π CVE vulnerability check: The software components in use are compared against the public CVE database, so that known and already documented security flaws are reliably identified.
π Form checks: Forms are checked for insecure transmission, missing CSRF protection and insufficient input validation.
β οΈ XSS security checks: The page is tested for cross-site scripting vulnerabilities, a common attack vector in which malicious code can be injected into other users' browsers.
πͺ Cookie check + LocalStorage & SessionStorage: Cookies are checked for secure flags (HttpOnly, Secure, SameSite). In addition, we analyse whether sensitive data is stored unprotected in browser storage.
Which accessibility checks are performed?+
π WCAG checks & best practices: The analysis tests your website for compliance with the current WCAG guidelines (including newer versions) and established accessibility best practices, from correct semantics to accessible interactive elements.
π¨ Contrast analysis: On the home page, all text and background combinations are checked for sufficient colour contrast so that content remains readable for users with low vision.
ποΈ Colour blindness check: Also on the home page, we simulate how the page is perceived by people with various forms of colour blindness and whether information is conveyed by colour alone.
π§ Heuristic checks: Experience-based rules detect context-sensitive barriers, such as navigation areas, forms or buttons without an accessible label that screen reader users cannot identify.
π Static checks: The source code is examined directly for objectively measurable errors, including duplicate IDs, broken ARIA references, incorrectly used aria-hidden, form issues, and CSS properties that impair reflow or text spacing.
π Every problem found is documented in the report:
π Location in the source code: You see exactly where in the HTML the problem occurs.
π¬ Message text: A concise description of the problem at a glance.
π Short explanation: What does this message mean in concrete terms?
π οΈ Extended guidance: A detailed description of the problem, its impact on affected user groups and concrete approaches to a solution.
π Dedicated help page: Every problem links to a dedicated page with further information and code examples.
How often can I scan websites?+
A website can be scanned as often as you like. The number of available scans depends on the package you choose. With Security-10 you can run 10 scans, and with Security-20 you can start 20 scans for any websites.
Can I upgrade to a larger package?+
Yes! Simply send us a message at the address from which you received your customer access after ordering (or to our general support address). We will quickly send you a price quote and switch the package for you.
Of course, it is cheaper to choose the right package right away than to start small and upgrade shortly afterwards.
What happens after I order?+
- Customer account: We set up your customer account.
- Link by email: You receive the link by email.
- Add websites: In your customer area you can add websites whenever you like.
- Scan: After you add a website, a scan starts.
- Security report: You receive a detailed report with:
- Findings and problems found
- Concrete solution proposals
- Recommendations for implementation
- Explanations & guides
Which websites and domains is the service suitable for?+
Our service is suitable for all kinds of websites:
- Company websites and online shops
- WordPress, Joomla, TYPO3 and other CMS
- Landing pages and microsites
- Blogs and portfolio sites
- Club and association websites
Requirements:
- The website must be publicly accessible (no password protection)
- No bot protection (if there is, we allow free re-scans)
How do I reach support?+
We are happy to help:
- π§ Email: service@it-logic.de
- π Hotline: +49 6126 700 38 58
We are glad to help with questions about your order, the report or technical implementation.
What are heuristic accessibility checks?+
π§ Definition: Heuristic checks analyse a website according to known rules of thumb (heuristics). They detect typical patterns that experience shows create barriers for people with disabilities, without having to test the page fully by hand.
π― Goal: To automatically find common, well-documented problems that a simple rule check alone would not detect, e.g. whether an element is present but not given an accessible name.
Which typical problems are detected heuristically?+
π·οΈ Missing accessible names: Navigation areas (<nav>), forms (<form>), page regions (<section>, <aside>) or embedded content (<iframe>) without a descriptive aria-label cannot be told apart by screen reader users, or are invisible to them.
π Unlabelled buttons & input fields: Buttons without visible text or aria-label, and input fields without an associated label, cannot be read out meaningfully by assistive technologies.
πΊοΈ Unrecognised landmarks: Elements with role="region" or role="search" without an accessible name are simply ignored by screen readers.
Which WCAG criteria are behind this?+
π WCAG 4.1.2 β Name, Role, Value: All controls and structural elements must have a recognisable name and an unambiguous role for assistive technologies.
π WCAG 1.3.1 β Info and Relationships: The structure and meaning of content must also be programmatically determinable, i.e. without visual perception, e.g. through correct landmark markup of forms and page regions.
How do heuristic checks differ from simple rule checks?+
βοΈ Simple rule checks are binary: "Is an alt attribute present? Yes/No."
π§© Heuristic checks go one step further: they consider the context, e.g. whether several <nav> elements exist on a page and therefore need distinguishable labels, or whether a button really has no accessible name even though it contains an icon.
How are the problems found fixed?+
π οΈ Concrete solution proposals: For every detected problem, a heuristic check provides 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 deep WCAG knowledge.
What are static accessibility checks?+
π Definition: Static checks analyse the HTML and CSS source code of a page directly, without running it in a browser. They look for clearly defined, objectively measurable patterns that demonstrably violate accessibility standards.
π― Strength: These checks deliver unambiguous yes/no results and can be fully automated. They form the foundation of any serious accessibility analysis.
What kinds of problems do static checks detect?+
π Structural HTML errors: Duplicate IDs in the document or deprecated HTML elements can cause assistive technologies to misinterpret content or not find it at all.
π Broken ARIA references: If aria-labelledby or aria-describedby points to an ID that does not exist in the document, the element remains without an accessible name for screen readers.
π« Incorrectly used aria-hidden: If aria-hidden="true" is set on focusable elements or even on <body>, content disappears completely for keyboard and screen reader users.
π Form problems: Radio and checkbox groups without <fieldset>/<legend>, input fields with autocomplete enabled for sensitive data, or generic link texts such as "click here" are common, easily fixed barriers.
Are CSS problems detected too?+
π¨ Yes, stylesheets are checked as well: Certain CSS properties can directly violate accessibility criteria.
βοΈ Reflow (WCAG 1.4.10): Excessive min-width values or overflow-x: scroll force users to scroll horizontally, which is a considerable 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 text spacing settings.
What is the difference between static and heuristic checks?+
π Static = rule-based & unambiguous: A problem such as "duplicate ID" or "missing <legend>" is either present or not. There is no room for interpretation.
π§ Heuristic = context-sensitive: Heuristic checks assess whether an element forms a barrier in combination with other elements, for example whether a <nav> exists but cannot be told apart on a page with three other navs.
π€ Complete together: Only the combination of both methods produces a reliable accessibility analysis.
Do static checks cover all WCAG requirements?+
β οΈ No, and it is important to know this: Static checks reliably detect all violations that can be checked automatically. According to estimates, that is about 30β40% of all possible WCAG problems.
π What they do not detect: Whether an alt text makes sense in terms of content, whether the reading order seems logical, or whether operating sequences are truly intuitive for keyboard users. This requires additional heuristic analysis or manual testing.
How does cancellation work?+
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 renews automatically for a further year at a time.
π‘ Fair and transparent: no hidden clauses and no automatic renewals without a way to cancel.
Do I need technical knowledge?+
No, not at all!
- You do not need to understand any technical details
- The security report contains explanations, guides and help texts
- Concrete recommendations for action instead of jargon
- Our support is available if you have questions
What do you offer for non-profit organisations?+
We are happy to offer you a lower price. Request an individual quote: service@it-logic.de
πΌ We support non-profit work!