An accessibility checker that works on pages behind a login

axe-core, the same open-source rule engine behind axe DevTools and the accessibility category in Lighthouse. It ships inside the extension rather than being fetched at runtime, because Manifest V3 doesn't allow remote code. You get the same rule results you'd get from any other axe-based tool.

Yes, and this is the reason to run it here rather than in a URL-based checker. The audit runs against the page already open in your browser, so a staging site, an admin screen or anything else that needs a session works the same as a public page. Nothing is sent anywhere to be scanned.

Pick from All rules, WCAG 2.0 A, WCAG 2.0 AA, WCAG 2.1 AA or WCAG 2.2 AA, and turn axe's best-practice rules on or off separately. Changing either setting re-runs the audit, and the standard you chose is named on the exported report.

Contrast has its own tab. Every failing pair shows the measured ratio against the ratio WCAG requires at that font size, the element's selector and both colours. Where a fix exists, Hoverify suggests the nearest passing colour: it holds the hue and saturation you chose and walks the lightness only as far as it needs to, so the suggestion still looks like your palette. One click copies it. When no text colour can reach the ratio on that background, Hoverify suggests a background colour instead.

There are five simulations: protanopia, deuteranopia, tritanopia, achromatopsia and a low-vision blur. They apply to the page itself rather than to a screenshot, so you can keep scrolling and interacting while one is on.

Settings has a list of CSS selectors the audit leaves out, and #wpadminbar is in it by default. The WordPress admin toolbar never shows up in your results when you audit while logged in. Add a cookie banner or a chat widget the same way. The inspector's per-element audit uses the same list.

It does. The Forms and Links views in the Structure tab collect every control and link in the page, including the ones inside a closed menu or a collapsed details element and mark the hidden ones so you can tell which are on screen right now. A mobile menu full of unlabelled buttons gets caught without you opening it first.

The Focus view in the Structure tab lists every tab stop in order and, with badges switched on, numbers them on the page and joins them with a line. While the badges are up, pressing Tab follows that same order through the page instead of landing in Hoverify's own panel. The path you see drawn is the path a keyboard user gets.

No, and no automated tool will. Rule engines catch the machine-checkable failures: missing alt text, unlabelled controls, contrast, broken landmark and heading structure. That is a large share of what's wrong on most pages, but not all of it. Things like whether alt text is accurate, or whether a custom widget makes sense to a screen-reader user, still need a person. Treat the report as the fast first pass, not the certificate.

Yes. The export dialog offers Markdown, PDF, JSON, CSV and plain text. Markdown is the default. It goes to the clipboard and pastes straight into a ticket or a chat. The PDF opens as a styled report you save from the print dialog, which is the one to send a client. JSON, CSV and plain text you can copy or download; JSON is the raw audit data, for a CI pipeline or an issue tracker.

Yes. Every tool runs in the Firefox build, and the same license covers it. Chrome, Edge, Brave and other Chromium browsers are supported too.

The accessibility checker is part of Hoverify, a paid extension with a 14-day refund policy. That's the substitute for a trial, and the checker isn't sold as a standalone scanner. One license runs in 3 browsers at a time and nothing auto-renews. See the pricing.