1,229 checks. Six screen widths. One approved scan.

Halo loads each page at 320, 375, 640, 768, 1024, 1440 px, from a small phone to a desktop. Most other tools test one width per scan, and you'd have to set up and run each extra width yourself. We checked each vendor's own public documentation.

• axe-core, and the tools that run on it (axe Monitor, Lighthouse and PageSpeed), test one width at a time and have no rule for reflow, focus visible, focus not obscured or keyboard traps.
• WAVE, Level Access and Pa11y test one width per scan; UserWay tests two fixed sizes. None tests 320 px by default.
• No vendor documentation we found runs all six widths in one automated scan.

See the full scanner comparison, with sources

• Pages wider than the screen

  Content that makes a phone scroll sideways (WCAG 1.4.10 Reflow). Halo measures it at every width, so a layout that holds at 375 but breaks at 320 or 640 is caught.

• Text running off the edge

  Buttons, cards and columns whose text starts on screen and ends past it. On our own site this was a call-to-action that ended at 356 px in a 320 px window.

• Text spacing

  Halo applies the WCAG 1.4.12 spacing settings and looks for clipped or overflowing text. axe-core and Siteimprove's documented rules only flag inline spacing styles; they don't apply the settings and look.

• Contrast on gradients

  Halo measures text over gradients, layered backgrounds, modern color spaces and chart labels. axe marks these "Needs Review" for a person, and WAVE doesn't test contrast over gradients or background images.

• Keyboard focus

  Halo presses Tab through the page at phone and desktop widths: is focus visible (2.4.7), hidden under a sticky header (2.4.11), or stuck in a trap (2.1.2)?

• Heading levels

  Skipped levels such as an h1 followed by an h3 (1.3.1), counting visually hidden headings that screen readers still read.

• Redirects, canonicals and duplicate titles

  The same pass checks that every listed URL loads itself, points its canonical at itself and has its own title, so accessibility and SEO problems surface together.

We ran it on our own site first. Halo's first pass on thanoslab.com raised 159 flags. 34 were real issues, and we've fixed them. The rest were false alarms, and each one became a lesson, so the next scan doesn't raise it again.

A scanner that cries wolf costs you time. Each of our agents has a section in one shared knowledge graph. When a scan raises something that turns out to be fine, we record why, and the check learns it. A person on our team approves every lesson before it goes live.

• Halo: A skip link still sliding into view isn't hidden. Halo waits 180 ms after each Tab before it measures.
• Halo: Focus that moves into a booking widget, video or map is not a keyboard trap. Those frames have their own tab order.
• Halo: Visually hidden text (screen reader only) is meant to be off screen. It is not a reflow failure.
• Halo: With stacked backgrounds, the top layer is the one behind the text. A decorative border layer underneath doesn't count.
• Halo: Chart text is painted with fill, not color, so Halo measures fill.
• Halo: A visually hidden heading still counts in the outline. An sr-only h2 between an h1 and an h3 is not a skipped level.
• Halo: 320 px plus text spacing together is stricter than WCAG asks, so it's reported as a warning, not an error.
• Halo: Tables and carousels in their own scroll area are allowed to scroll sideways.
• AEO/SEO: Search Console exclusions for redirects, noindex pages and canonical duplicates are expected. They aren't errors to fix.
• AEO/SEO: A Search Console status can be out of date, so the agent checks the live URL first.
• CSI: A 200 response alone doesn't mean a file is exposed. Many sites answer 200 for missing pages, so CSI needs the file's own content in the response.

Every scan is queued with its cost estimate and waits for approval before it runs. Every new lesson waits too. You get the depth of 1,229 checks without surprise bills or unreviewed changes.