Web audit

A product link in the footer is present on all 16 checked pages. It responds with a 302 redirect to a documentation page, which in turn answers 404 Page Not Found.

Why this class is dangerous: a one-level link check sees the 302 and counts the link as alive — the defect is only visible when you follow the whole redirect chain.

About the severity: coverage is maximal (16 of 16 pages), but the destination is technical documentation rather than a conversion path, so Medium instead of High. There is a cumulative effect to keep in mind: a 404 in the footer of every page affects search-engine assessment and the impression of the developers this link is aimed at.

Collapsed accordion answers are hidden visually — opacity 0 and height collapsed to 1px — but remain in the accessibility tree and in tab order: display and visibility are not changed, aria-hidden and inert are not set.

On the FAQ page, 18 links inside collapsed answers accept focus. A keyboard user loses their place: the focus ring sits on a transparent element and cannot be seen.

Expected: a collapsed section gets hidden or inert, or display: none.

axe-core reports color-contrast (impact: serious) on all 16 pages, 506 nodes in total. The affected text is regular paragraph copy styled by a single site-wide style preset — a systemic setting, not a handful of stray elements.

All 16 pages lack main, nav, header, footer and their ARIA equivalents, as well as a “Skip to content” link.

Consequence: a screen-reader user cannot jump to the main content and has to listen through the page header every time.

axe reports link-name (serious) on all 16 pages. These are badge links to external resources — review platforms and a service status page — containing only an image, with no text and no aria-label.

A screen reader announces such a link as just “link”, with no way to know where it leads.

On four pages the preview image of an embedded video is an img element without an alt attribute.

In one of the FAQ answers the link fields are swapped: the visible link text is a raw application URL, while the actual href contains a 419-character paragraph of the answer text.

The link looks perfectly valid — highlighted in blue — but clicking it leads to a non-existent address, even though the answer explicitly invites the reader to click it.

A documentation link redirects to a help-center article that answers 404. Same class as F-1: a one-level check sees the 301 and misses the defect.

The contact-sales form has 5 visible fields and 11 hidden honeypot fields. The honeypots are built correctly — aria-hidden, tabindex -1, positioned off-screen — but one of them has the same name as the visible required message field. On submit, two values are sent under one key: the user’s text and the honeypot’s empty string.

What follows depends on how the receiving side reads the request, which cannot be seen from outside. If the body is parsed naively (take the value by key), then a honeypot emptiness check endangers either the delivery of real submissions or the honeypot itself. If the fields are collected explicitly by element references, the name collision has no effect.

So this is not a confirmed defect but a spot the owner should verify: the cost of the mistake is silently lost leads, the cost of checking is a few minutes. Renaming the honeypot field is worth doing either way.

All 16 pages log the same fetch error about a missing user field in a response.

The honest caveats: the source is the site-builder’s bundle, not the site’s own code; the message is formatted, meaning the exception is caught and handled; the likely cause — requesting the user’s name for an anonymous visitor — is expected for a guest.

So this is not a defect but input for two owner decisions: report it to the site-builder vendor, and account for it in diagnostics — constant console noise masks real errors when they appear.

The manifest is linked from a third-party JSON hosting service and answers 403. Installing the site as an app doesn’t work, and the icon and theme colour defined in the manifest have no effect.

Method note: this finding comes from a live browser session — a headless browser does not request the app manifest on normal page load, so automated scans miss this class entirely.

The home page logs 5 internal component-props dumps to the console — internal component names and parameters are visible to any visitor. The other 15 pages don’t have these.

Additionally, every page carries the site-builder’s editor-mode message, and on three pages a third-party review widget logs that it found no images for its selector — the widget didn’t render its pictures there.

Four pairs of links overlap by bounding box: three around a single link in a hints block (overlaps up to 175×18 px) and one separate case in the footer (54×13 px). The other 15 pages have no overlaps.

Caveat: an 18 px vertical overlap equals the line height, which is typical for links wrapping onto two lines — some of these pairs may be the same measurement artifact described in our false-positives triage. Needs visual confirmation before being raised with the owner; hence Low.

On the security page, a link inside a paragraph differs from the surrounding text only by colour. A user with a colour-vision deficiency cannot tell it apart from regular text.

One page has two h1 elements. Two pages jump from h1 straight to h3, and one page from h2 to h4.

The “Sign in” and “Support” links — two on each of the 16 pages, 32 in total — carry cross-domain analytics linking parameters with hard-coded values of a client identifier and session marks. The values are static: identical for every visitor, not substituted by the analytics script at click time as the linking mechanism expects.

Decoded timestamps point to February and March 2025 — the markup contains identifiers of two specific visitors captured over a year ago, handed to everyone who clicks these links since.

Two consequences. Funnel measurement: the transition from the marketing site into the app is exactly the joint cross-domain linking exists for; right now every visitor arrives in the app under the same borrowed identifier, so end-to-end attribution does not work. Privacy: the analytics identifiers of two real people are published in the source code of every page.

Three input fields of the contact-sales form measure 200×16 px. The AA minimum is 24×24 px — an 8 px shortfall in height. These are not in-text links covered by the inline exception, but standalone controls of the primary sales form.

The header of all 16 pages also has a “Sign in” link at 45×16 — same class, same shortfall.