Can visitors still use your website when images fail?

Choose a visitor action before changing the network

For this experiment, the action was identifying a portfolio item and opening its detail page. A screenshot alone could show that the pictures were missing, but it could not demonstrate that the remaining link worked. We recorded the visible labels and destinations, then activated the first link and checked the destination heading.

Choose the equivalent action for your site before you test it. A service business might ask whether a visitor can read the service name and find the inquiry route. A product page might need a separate review of essential image information. A test that preserves a navigation label does not prove that the missing picture was unimportant to the decision.

Write down the expected result as an observable behavior. For example: the project name remains visible, its link retains the same destination, and activating it opens the expected page. Avoid a pass condition as broad as “the site still works.” It hides the parts you did not inspect.

Fail one resource class and keep a comparison

Playwright supports intercepting requests and aborting them by resource type. Our experiment used fresh browser contexts for the normal and blocked cases. JavaScript and styles remained available. Only image requests were aborted in the blocked cases, and third-party requests were excluded in both cases to keep that condition consistent. We scrolled the homepage to exercise lazy-loaded content.

This is an image-failure simulation, not a slow-network benchmark. We did not compare download time, loading scores, or real-user performance. Both ordinary-motion cases at each viewport contained two video elements. We did not deliberately block media requests or test video playback failure. An experiment should name the failure it actually exercised rather than borrow a broader label from the page's design.

Keep the baseline and failed case at the same viewport and motion preference. If you change several conditions together, it becomes harder to explain which one produced a difference. Save the script and the observations so another reviewer can repeat the same bounded experiment.

A practical reproduction starts with a fresh Chromium context and ordinary motion enabled. Register a context route before loading the page; abort requests whose resourceType is image and continue other same-origin requests. Use a second fresh context with image requests allowed. Keep third-party exclusions identical, scroll through lazy-loaded sections, return to the page body, and press Tab until the chosen link receives focus. Record its label and destination, press Enter, and check the resulting heading. On your own site, choose a navigation task that does not submit a real inquiry or payment.

References: Playwright: Network request interception and aborting requests

Read the missing-image state honestly

At 1440 and 390 CSS pixels, the October 13 homepage samples retained the same four portfolio link labels and destinations. Each sample opened the first project detail page and showed its expected heading. We observed no page errors or horizontal overflow in those four cases.

The failed screenshots still looked broken. That is evidence to preserve, not crop out of the report. The thumbnails had visible error placeholders, and the portfolio illustration lost its pictures. A working action and a polished fallback are separate acceptance questions. The appropriate visual treatment depends on what the image communicates and how much space the layout reserves for it.

MDN describes image alternative text and the role of explicit dimensions. Text alternatives can communicate an image's purpose when it cannot load; dimensions can reserve its space. Neither replaces a review of the surrounding content and interactive control. In our portfolio list, visible project-name text remained alongside the missing decorative thumbnail. That observation is limited to the inspected list.

References: MDN: The image element, alternative text and dimensions

Ask for evidence at handover

A useful delivery report names the page, tested action, viewport, browser, failure condition, and observed result. Include one normal screenshot and one failed-state screenshot with the same framing. Record the destination reached, rather than reporting only that a click was attempted. Keep request counts separate from unique asset counts and performance measurements.

Ask which checks were omitted. Mouse or touch activation does not establish keyboard access. Programmatically focusing a link and pressing Enter can test activation, but it does not prove that a visitor can reach that link in a sensible Tab order or see its focus state. Our October 13 follow-up used actual Tab presses after returning focus to the page body: 34 presses on desktop and 28 at the narrow viewport reached the first project link in both normal and blocked cases. Enter then opened the expected detail page. Inspected screenshots showed an orange outline around the focused link. This is a bounded path check, not a full audit of focus order or keyboard accessibility. W3C explains why a visible focus indicator lets a keyboard user identify the active control. Screen-reader behavior and physical-device testing remain separate checks.

For a redesign, make the essential visitor tasks part of the agreed acceptance criteria. The related launch-review and animation articles below cover broader release questions and motion choices. Use this bounded experiment to ask what your website delivery review will actually demonstrate.

References: W3C: Understanding Focus Visible

Common questions

Sources and further reading

Primary references checked on October 14, 2026. Product claims belong to the cited provider; implementation recommendations reflect our judgment.

• Playwright: Network request interception and aborting requests
• MDN: The image element, alternative text and dimensions
• W3C: Understanding Focus Visible