How an OpenSiteCheck report is made.

1. How we check that a URL is safe to scan

Before a scan starts, we check that the URL points to a normal public website and cannot lead the scanner into a private network. These checks protect our service; they are not a security guarantee for the website being scanned.

URL format

We accept only HTTP and HTTPS URLs. We remove fragments and reject URLs with usernames, passwords, unusual ports, excessive length, or local-only hostnames.

Website address

We check every network address returned for the hostname. If any address belongs to a private, local, test, or other blocked range, we reject the URL.

Safe connection

The scanner checks the public address again when it connects and sends traffic through a restricted proxy. This prevents a URL from passing the first check and then switching to a private address.

Browser requests

The browser allows only ordinary public HTTP or HTTPS page requests. It blocks unsupported methods, service workers, unusual URL types, and requests that fail our public-address checks.

Redirects and files

Redirects and files loaded by the page must pass the same public-URL checks. Sitemap and robots files also have limits on size, redirects, and loading time.

Public does not mean appropriate to submit. A public page can still contain personal or sensitive information. Do not submit logged-in, private, confidential, personal, or sensitive URLs.

2. How pages are selected

Each plan sets the page limit and how pages are found. The limit is the number of URLs OpenSiteCheck will try, not a promise that every page will load.

We keep discovered links on the same website, skip files such as PDFs and images, remove fragments and duplicates, and follow the site's robots.txt instructions. A URL you enter yourself is still checked as requested. If one page fails, we mark it incomplete and continue the rest of the report.

3. How each page is checked

Each page opens in a clean Chromium browser session at a desktop size of 1280 by 800 pixels. After the page loads and its scripts have a moment to finish, we run a local copy of axe-core.

axe-core runs automated checks linked to parts of WCAG 2.0, 2.1, and 2.2 at Levels A and AA. These checks do not cover every requirement at those levels.

The report records the axe-core version and the WCAG rule groups selected. We may save a screenshot of the first page, but screenshots are not sent to the AI model.

4. How problems are ordered and graded

Problems are ordered by severity: critical, serious, moderate, then minor. When two problems have the same severity, the one affecting more elements appears first. These labels help you decide what to fix first; they do not measure legal risk.

The most serious problem sets the grade. The grade is not a percentage, WCAG level, accessibility certificate, legal conclusion, or comparison with other websites. An A does not mean that a page is accessible.

5. How we group repeated problems

One automated check can find the same problem on many elements. OpenSiteCheck keeps every affected element, then groups the ones that appear to share the same underlying cause. This avoids repeating the same suggested change for every matching element.

To decide what belongs together, we compare the check result, failure details, element type, classes, ID, and inline styles. For problems such as color contrast, this helps us recognize elements that probably come from the same component or shared style.

Grouping reduces repeated advice, but one code change may not fit every framework or page. The report still lists the location and HTML for every affected element.

6. What AI does and does not do

For each group of related problems, OpenSiteCheck first looks for a matching suggestion saved from an earlier scan. Saved suggestions are kept for 90 days. If no match exists and AI is available, an AI model drafts one explanation and a before-and-after code example.

The AI request can include the page URL and title, details about the problem, element locations, the number of matches, one short HTML example, and up to four more examples. It does not include the complete page source, screenshot, browser cookies, account password, or payment data.

Suggestions are examples, not automatic fixes. The model does not edit your website or test its answer in your framework. A developer must review, adapt, and test the suggestion, then scan again.

7. What the report records

A completed report records the starting URL, pages we tried to check, final page URLs, page titles, loading results, page errors, scan date and time, page totals, axe-core version, WCAG rule groups, problem counts, affected-element counts, and grade.

The paid HTML and PDF downloads contain the same report data. The HTML file works without logging in and keeps its interactive navigation. The PDF uses the same report content in a fixed layout for reading and printing.

The public sample clearly identifies itself as an example. Its .test addresses, code, counts, dates, and suggestions are invented and fixed. It does not use a customer record or live website.

8. What the report does not cover

An automated scan sees one version of the page at one desktop screen size. It can find only the problems that the selected axe-core checks can identify in that view.

• Not every WCAG requirement: many requirements need human judgment, knowledge of the content, or testing with assistive technology.
• Not complete journeys: logged-in areas, checkout, error messages, dialogs, menus, and changing content may not appear in the page view we check.
• Not every device or setting: the scan does not by itself establish keyboard usability, zoom and reflow quality, mobile behavior, or screen-reader experience.
• Not every content type: PDFs, mobile apps, video captions, audio descriptions, and private documents need separate evaluation.
• An unreachable page does not pass: if a page is blocked, times out, or cannot be opened, we mark it incomplete.
• Not legal advice: the report cannot certify WCAG conformance or determine compliance with a law or contract.

Security checks, delayed content, location, personalization, cookie choices, and page errors can also change what the browser sees.

9. Privacy and retention

Account and paid scans can store the URLs submitted and found, final URLs, page titles, loading results, a screenshot of the first page where available, check details, element locations, short HTML examples, counts, grades, errors, and AI suggestions. We use this information to create the report and account history.

We do not save an anonymous report to an account. We may still keep records used to prevent abuse and saved fix examples under the published schedule. Completed or failed scans, scan-usage records, and saved AI fixes are normally deleted after 90 days. The Privacy Policy explains the different retention periods for accounts and purchases.

Production AI requests use only the limited problem details described above. The AI services are configured not to train on or retain that content. The Privacy Policy names the current providers, their locations, and how they handle data.

Users can request access, correction, report removal, or account deletion. An authorised website representative can also use the report takedown process.

10. What to do with the results

1. Confirm the problem.Open the affected page and find the original component or page code behind each result.
2. Fix the source, not only the example.Adapt the suggestion to your site's framework, styles, content, and shared components.
3. Test the behavior.Use keyboard, zoom, responsive layouts, and relevant assistive technology; include real user journeys.
4. Run the automated check again.Confirm that the original problem is gone and that the change did not introduce another one.
5. Ask a specialist when you need a formal answer.A qualified human audit is the right next step for a formal WCAG assessment or legal obligation.