Skip to main content
Fortress Web ComplianceFORTRESSWEB COMPLIANCE
← Home

How our scan works

No-cost scan: no email, signup or payment

Enter a public website URL. Initial results appear when the checks finish; the browser then discovers and checks additional pages while you keep the page open. Download the no-cost PDF without providing an email or creating an account. Account creation is optional for requesting further review.

Submitted-page checks

Google PageSpeed Insights uses Lighthouse mobile lab analysis on the submitted URL only, returning available accessibility, performance, SEO and best-practices scores. The snapshot shows up to 15 top Lighthouse recommendations, not every failed audit. Recent PageSpeed results may be reused for 30 minutes. These lab results do not measure real-user INP or guarantee search rankings.

Fortress checks the returned HTML for language, headings, image alt attributes, form-label signals, button names, skip-link patterns, zoom restrictions and other potential barriers. It also checks HTTPS and selected security headers, and looks for accessibility, privacy and contact links. These are signals, not a full security audit or legal policy review.

An initial sample of up to 12 linked pages supplies extra HTML and link checks. Mozilla's HTTP Observatory may supply a security-header grade when available. Public scans never use our paid WAVE account. WAVE is reserved for authenticated internal reviews.

Discovery and the 500-page limit

Discovery uses sitemap references in robots.txt, common sitemap locations and internal links. The sweep attempts up to 500 discoverable public HTML URLs on the same site, treating www and non-www as the same host. Additional pages receive Fortress HTML checks, not a separate Lighthouse or WAVE run on each page. Failed requests count as attempts. Login-only, unlinked, blocked and JavaScript-generated pages may be missed; this is not guaranteed whole-site coverage.

What the no-cost PDF contains

Website-health checks add metadata and canonical/indexing signals, JSON-LD syntax, social-sharing metadata, image delivery and layout-dimension signals, parser-blocking scripts, insecure resource references, missing accessibility references and in-page targets. Each review includes available HTML evidence, affected-page counts and suggested next steps. Confirmed HTML evidence means a source-level observation, not a confirmed user-facing defect; review signals require contextual validation.

The sweep respects available wildcard/FortressScan robots rules, fetches at most six same-site sitemap resources, follows at most five permitted redirects per page and excludes obvious action URLs. Sitemap pages without discovered incoming links are only potentially disconnected, never proven orphan pages. Duplicate metadata is compared only across fetched HTML pages. Coverage distinguishes assessed, unreachable and skipped pages; missing data never counts as a pass.

Forms are inspected but never submitted. The scan does not create accounts, attempt purchases, test private analytics/CRM connections, inspect backups, clear malware or certify legal privacy compliance. Tracking-script detection calls for a consent review, not a legal verdict. Rendered mobile, cross-browser and consent behaviour need separately authorized browser testing.

The PDF contains available submitted-page scores, top recommendations, grouped check explanations, website-section totals, affected URLs, suggested next steps and up to 25 broken or unreachable URL references. High, Medium and Review priorities are triage guidance, not validated impact or legal severity. Grouping is by check and page, not proof that findings come from one shared code component. A download made before the sweep ends includes only results completed so far.

Rescan comparisons

The latest sweep for up to five sites is saved in your browser only. A later sweep of the same URL compares flags on successfully fetched pages present in both runs. Missing and unreachable pages are excluded; a flag no longer detected is not proof that a barrier was fixed. Partial sweeps and the 500-page cap limit comparisons. This is not an account-wide history or a legal compliance record. Browser data can be cleared from the results view; private browsing and storage restrictions may prevent comparisons.

Deeper technical review

Our team can run open-source axe-core browser checks on selected public pages, including JavaScript-rendered content. These checks are separate from the public HTML sweep and do not automatically exercise registration or checkout flows. Manual keyboard and screen-reader review is still required. No paid WAVE or paid browser service is used by the public scan.

Up to six directly linked PDFs receive basic checks of the first 2 MB for tag, title, language and font markers. This does not establish correct tags, reading order, text extraction or PDF accessibility. The downloadable scan PDF itself has not had a complete PDF-accessibility evaluation; contact us for an accessible alternative.

What manual testing adds

Keyboard testing checks focus order, visible focus, menus, dialogs and forms. Screen-reader testing evaluates names, structure, announcements and interaction. Human review also assesses the meaning of alt text, reading order and issues that HTML pattern checks cannot determine. These tests require an agreed scope; they are not performed by the no-cost scan.

Ontario requires WCAG 2.0 AA for covered websites, subject to statutory limits and exceptions. We test to WCAG 2.2 AA, which adds newer criteria. Neither automated nor scoped manual testing guarantees legal compliance.

Accessibility responsibilities for your team

A developer-ready report helps your team plan fixes; it does not make the site compliant by itself. These responsibilities support WCAG 2.2 Level AA evaluation across the agreed pages and user journeys.

Design team

  • Colour contrast: Aim for at least 4.5:1 for normal text and 3:1 for large text, subject to criterion exceptions. Essential interface components and graphical objects generally need 3:1 non-text contrast.
  • Visible focus: Make keyboard focus clearly visible and ensure author-created content does not entirely hide the focused component.
  • Zoom and reflow: Support 200% text resizing without loss of content or functionality, subject to exceptions. Also evaluate reflow at a 320 CSS-pixel-wide viewport; text resizing alone is not a complete layout test.
  • Text alternatives: Specify meaningful alternatives for informative images. Decorative images should be ignored by assistive technology, usually with empty alt text.

Development team

  • Semantic structure: Prefer appropriate native HTML such as main, nav, button and heading elements to expose structure, names and roles. Generic containers are still appropriate for layout.
  • Keyboard operation: Make menus, dialogs, forms and other interactions operable without a mouse and without keyboard traps. Use Tab, Enter, Space and arrow keys as appropriate to the control’s interaction pattern.
  • ARIA when needed: Use correct roles, states and relationships for custom controls, such as aria-expanded, aria-live and aria-describedby. Prefer native semantics; extra ARIA is not automatically better and does not add keyboard behaviour.

Content and product team

  • Forms: Provide clear visible labels or instructions and programmatically associate them with inputs; give understandable error messages.
  • Link purpose: Use descriptive link text, or context that makes its destination clear, rather than ambiguous repeated “Click here” links.
  • Multimedia: Provide accurate captions for prerecorded synchronized video with audio and an equivalent text alternative for prerecorded audio-only content. Evaluate audio description and live-caption requirements against the applicable standard and exceptions.
  • Documents: Evaluate PDFs separately for applicable accessibility requirements, including tags, reading order, text alternatives, language and usable navigation. Tags alone do not establish accessibility.

QA and testing team

  • Automated checks: Use tools such as axe-core or an internal WAVE review to identify potential issues, then validate the findings. Automated results are not a conformance verdict.
  • Keyboard verification: Test scoped pages and complete key journeys using only the keyboard, checking focus order, visibility, entry and exit from controls, and absence of traps.
  • Screen-reader testing: Review key journeys using appropriate browser and screen-reader combinations, such as NVDA or JAWS on Windows, or VoiceOver on macOS/iOS.
  • Testing with people with disabilities: This provides valuable additional feedback and is recommended where possible; independent blind-user testing is not prescribed as a WCAG conformance requirement and is not currently included in Fortress’s service.

Sources: W3C WCAG 2.2 · W3C Understanding Conformance · WAI-ARIA Authoring Practices · Ontario website accessibility guidance.

Run the no-cost scan · Our Accessibility Statement

Not legal advice. We do not guarantee legal compliance.

Last updated: October 2026