Scope and limitations

Automated testing covers a great deal of ground quickly and repeatably. Knowing exactly where that coverage ends is what makes the results worth acting on — so this page sets out the boundaries of what the Detector measures today: first the ones that apply across the product, then the specifics of each checkpoint.

Two principles shape the whole list:

• Precision first. The Detector is tuned so that a reported issue is a real issue. When something cannot be measured with confidence — a control it cannot pinpoint, a colour it cannot resolve — it is left out of the report rather than guessed at.
• Automation plus review. A scan is a fast, consistent first pass over the whole page. The areas listed below are the ones where a manual review adds the most, and where we are extending coverage next.

---

Across the product

Sites that block automated access

Some sites use WAF or antibot protection (Cloudflare, DataDome, Akamai, Imperva, PerimeterX, Vercel and others) that refuses any automated browser at the network level, so the page never loads. Most of these blocks are driven by the reputation of the shared egress IP rather than by anything about the browser itself. In recent rounds of travel sites, roughly 1 in 4 were protected this way.

When it happens, the scan says so: the result comes back as an explicit error naming the provider, the HTTP status and a screenshot of the block page, so a protected site is never mistaken for a clean one. (This applies to the current async engine; the legacy sync path is being decommissioned.)

A floating overlay that mounts over a control mid-scroll can also be captured in place of the control.

The page as it is scanned

• The page is evaluated as it stands when the scan runs. Content that appears later, or a screen change in a single-page application, is not re-evaluated.
• What is on screen at that moment is what gets measured. Controls inside closed accordions, tabs, menus, unopened modals or later carousel slides are reached by the booking-flow tests, which open panels as a visitor would, but not by the general page-wide checks.
• Content that only appears after scrolling or several interactions is outside the general review for the same reason.

Colour and background

• Light mode. Contrast is measured against the light theme.
• Gradients and background images are analysed — where there is no single background value to compare against, the Detector falls back to visual analysis of the rendered element. Complex layering is where that becomes an approximation: overlays, background-blend-mode, filters and background-attachment: fixed produce a final colour built from several stacked layers, so the reported value is a close reading rather than an exact one.
• Translucency is resolved by compositing the colour over what sits behind it. Where the background cannot be established, a white backdrop is assumed — accurate on a light page, less so on a dark one.
• Colour notations the engine does not yet interpret (modern colour-mixing syntax, for example) are skipped rather than approximated.
• CSS context. A contrast finding names the colours and the ratio, not the specific declarations — selectors, properties, values — behind them.

Left to the browser and the operating system

These are deliberate exemptions, not gaps in the analysis:

• Native focus rings. The browser adapts them at paint time and they are exempt from author contrast requirements, so they are treated as visible.
• System dropdowns. Windows, macOS and Android paint these with their own theme, so the colours written in the page are not what the user sees, and a developer could not change them.
• Controls left entirely at browser defaults — a plain unstyled checkbox or text field — are not contrast-checked, since the appearance is the browser's to decide.

Visual effects outside the measured element

• Focus styling drawn on a child element or a pseudo-element. Where the focus effect lives on an inner "state layer" (the standard Material Design pattern) or on ::before / ::after, the focus checks measure the control itself and do not reach it. Text contrast is not affected by this — that analysis does resolve pseudo-element and shadow DOM content.
• Animated focus cues. The page is held still before measuring so that transitions do not blur the comparison, which means a ripple or expanding effect is not captured.
• Text rendered inside images or SVG is read as a graphic, not as text.

Keyboard

• Tab and Shift + Tab drive focus navigation. Arrow keys (↑ ↓ ← →), Home / End and Page Up / Page Down are not part of the walk today.
• Custom widgets — comboboxes, dropdown menus, switches, date pickers — are covered inside booking flows, where the tests open and walk through each panel. The general page-wide checks do not yet cover them.
• Keyboard activation is checked for the controls listed in Generic Activation Command; coverage for elements that are not natively interactive is being defined.

Scale and consistency

• Long lists are sampled. After a set number of controls of the same kind, and with a time budget per item and per run, the checks stop probing more of the same — so one unresponsive panel cannot stall a scan.
• AI-assisted steps are used in several checks. The findings themselves are stable; the wording of an explanation and the depth of a suggested fix are generated per run and vary slightly.
• Sites that rebuild themselves between visits, or where pop-ups and consent banners appear mid-scan, can give slightly different results from one run to the next.
• Repeated controls are grouped, so an issue that affects a row of identical buttons is reported once, with its occurrences listed, rather than as many separate findings.

---

By checkpoint

1.1.1 — Non-text Content

⚠️ Not currently in production. The image classification models this checkpoint relied on were discontinued. Integration is planned for an upcoming release.

• Classification follows the accessible name: an image without one is treated as decorative, since there is no alternative text to evaluate. See Image Classification.

1.3.1 — Info and Relationships

• Region names are checked for presence, not quality. Two navigations called "nav 1" and "nav 2" satisfy the rule, though they tell the user little.
• The main region is checked for existence, not for whether the content inside it is genuinely the main content of the page.
• Headings are checked for nesting. Whether the levels also run in a sensible order is a separate question, and because the rendered page is read rather than the source, nesting the browser repairs on its own is reported as the user experiences it.
• Visual headings are identified by appearance, which is a judgement call: a heading styled very subtly may not be picked up, and a boldly styled pull quote or price may be.
• Browsers and screen readers vary in how they expose and announce regions, so a page can behave slightly differently than the report suggests.

1.4.1 — Use of Color

• Links are evaluated where they sit within surrounding text and are distinguished by colour alone; links differentiated by other styling are outside this check by design. See Surrounding text.
• Colour-only focus states are detected when a solid colour changes on the control itself — background, border, outline, text or icon — including translucent colours. Focus styling that lives elsewhere is outside the current scope: indicators drawn on a child element or pseudo-element, ripples and animations, gradients, most uses of opacity, and cases where two colour properties change at once. Colour alone on focus documents each pattern, with a quick reference for reviewers.

1.4.3 — Contrast (Minimum)

• Gradient and image backgrounds are evaluated through visual analysis of the rendered element, as are elements whose content sits inside shadow DOM or is generated by ::before / ::after.

• Heavily layered backgrounds — image plus overlay plus blend mode or filter, or a background fixed to the viewport — give an approximate reading rather than an exact value, since the final colour is composed by the browser at paint time.

• Gradient text. Where a gradient is used as the text colour (background-clip: text), there is no single foreground value to measure.

• Hover and focus are evaluated on the element that carries the style; when the element reacting to the event is the parent of the text being analysed, that pairing is not yet resolved.

  Worked examples in Gradient limits.

1.4.4 — Resize Text

• Coverage per run. Long pages are processed in iterations with a step budget; pages with sticky sections consume more of that budget, so a very long page may be reviewed less exhaustively than a short one.
• Interaction accuracy. Opening menus and panels relies on the agent locating the control; a second, more capable model is called to resolve uncertain clicks. Hamburger menus have produced isolated false positives.
• Overwritten computed styles — a size declared in vh and later overwritten in rem — can be read as a scaling failure. See Text scaling.
• Framework re-rendering. React and Next-style components that reassign role, name or text content while re-rendering are a known source of false positives.

1.4.10 — Reflow

• Vision analysis drives the check, so edge cases can go either way.
• Rapidly changing content may not be captured as it settles.
• Visible elements are evaluated; content hidden or outside the viewport is not.
• Transparencies and complex visual effects affect overlap detection.
• Scroll bars are not visible in the screenshot the extension returns.

1.4.11 — Non-text Contrast

• Hover state. Background images, gradients, pseudo-element effects, slow CSS transitions and JavaScript-driven hover reduce precision. Disabled components, text contrast, focus contrast, active and visited states, and browser default hover colours are handled elsewhere or exempt. See Contrast on hover.
• Focus indicators over a non-uniform background are compared using the best-contrasting pair of colours, which keeps the check free of false alarms; an indicator that fails against only part of its background may pass.
• Radio buttons and checkboxes. Controls the site has not styled are left to the browser; fields already showing a placeholder, a value or a selected option are treated as identifiable by their text. Recognition relies on the control having a visible border, and the check resolves borderline cases in favour of passing.
• Icon-only controls. Buttons, links and tabs whose entire content is an icon are in scope. A control that also carries visible text is identified by that text instead, and photos, logos and image-only links are covered by 1.1.1 rather than here.
• Graphic elements. Elements that cannot be matched back to a specific part of the rendered page are left out of the analysis rather than reported approximately.

2.1.1 — Keyboard

Some elements are skipped by design, to avoid triggering unwanted actions during a scan: plain links, form fields, submit buttons, already-selected tabs, visually hidden elements, and elements with no standard keyboard interaction. See Keyboard operable implementation.

2.1.2 — No Keyboard Trap

• Arrow-key navigation and unexpected context changes on focus are covered by separate checks, not this one.

2.4.3 — Focus Order

• Collapsed elements are omitted in the normal state, since removing styles would place them directly after their trigger and misrepresent the order.
• Disabled and invisible elements are excluded, as are skip links moving focus to <main> — which is exactly what a skip link is for.

2.4.7 — Focus Visible

• Presence, not strength. This check confirms that a visible focus indicator exists; how clearly it stands out is measured under 1.4.11.
• Elements reachable by Tab are the ones examined.
• Very subtle indicators sit at the edge of what image comparison can separate from rendering noise; the current threshold is set to keep the check free of false alarms.
• Mastercard pages are handled with a direct screenshot instead of the usual style-cloning process.

4.1.2 — Name, Role, Value

• Name and role are read from the browser's accessibility tree, so the result reflects what a screen reader actually announces — including content inside shadow DOM and iframes.
• Disabled state is read from the disabled attribute, so a control that only looks disabled through styling is judged on what it actually announces.

4.1.3 — Status Messages

• Decorative spinners in carousels and lazy-loaded galleries are currently reported alongside genuine ones; refining that distinction is in progress.
• Where a message appeared is worked out from page structure rather than screen position. That matches the visual result on most pages; a toast placed far from its trigger in the page structure is the case being refined.

TabIndex

• The analysis covers elements present on the active page, with more semantic and contextual analysis planned.
• Where the intent behind a tabindex value cannot be established automatically, the auditor is asked to confirm it rather than the tool guessing.

Hospitality Booking

The booking-flow tests open each widget and audit inside it, which brings its own scope. In short:

• Inside the opened panels. Text in the surrounding page is covered by the page-wide contrast check, so the two do not double-report. Colour contrast
• Controls are identified from their appearance and behaviour rather than by clicking them, which would select a destination or trigger a search mid-check. A control that gives no outward sign of being one can therefore be missed. Keyboard navigation
• Operability findings are kept distinct from navigation ones: unreachable controls, typable text fields, ordinary links, submit buttons and system dropdowns are reported under their own rules, not as operability failures. Keyboard operability
• Traps are reported when focus is stuck on a single control. A loop between several controls is tracked separately, and where a page shifts mid-test the check stays silent rather than report something it could not confirm. Keyboard traps inside panels
• Widgets built in unusual ways are reported as "did not open", so it is clear the contents were not measured.