Decorative Images: How to Mark Them Without Adding Noise

What this check actually means

Use CSS decoration or alt="" for visuals that add no information; do not invent keyword text.

A decorative image should not add information beyond nearby text or interface meaning. Prefer alt="" on an <img> when it must remain in markup; CSS background images are also appropriate for purely decorative styling when no semantic image is required.

Expected behavior and decision boundary

Expected state: A decorative image should not add information beyond nearby text or interface meaning. Prefer alt="" on an <img> when it must remain in markup; CSS background images are also appropriate for purely decorative styling when no semantic image is required. Define the image role (informative, decorative, or functional) first; then make alt, link function, caption, and responsive asset consistent with that role.

Diagnosis: evidence to capture

Capture src, currentSrc, alt, link state, caption, intrinsic dimensions, rendered dimensions, and the image role (informative, decorative, or functional). For responsive images, record the candidate actually selected by the browser.

Alt text cannot be evaluated without page context. The same string may be correct for a repeated logo and wrong for distinct product angles, people, diagrams, or charts.

Technical implementation

A decorative image should not add information beyond nearby text or interface meaning. Prefer alt="" on an <img> when it must remain in markup; CSS background images are also appropriate for purely decorative styling when no semantic image is required.

<img src="divider.svg" alt="" width="640" height="20">

Capture src/currentSrc, alt, image role, link state, visible caption, and intrinsic/rendered dimensions. Evaluate alt text in page context; the same string can be correct for a repeated logo and wrong for a distinct product angle or chart.

Concrete decision example

Image role: decorative      -> alt=""
Image role: product view    -> alt="Black chair, side view"
Image role: link/control    -> accessible name describes destination/action

Start with image function. An audit that checks only “alt empty/non-empty” will systematically create false positives for decorative assets.

Common root causes

Common causes include CMS rules that force alt text on every asset without context, media-library descriptions reused across different placements, templates that treat decorative and informative images the same, responsive/lazy components that drop attributes, or editors describing file names instead of image purpose.

Edge cases and false positives

alt="" is correct for decorative images, so an audit must not flag every empty alt as an error. An image-only link, by contrast, needs a useful accessible name. For complex graphics, a huge alt string is often worse than concise alt text plus a visible HTML explanation.

Verification after the fix

| Check | PASS | FAIL | | --- | --- | --- | | Output | expected rule is visible in final HTML/HTTP/DOM | backend field looks correct but final output does not | | Scope | representative URLs from every affected template tested | only one example URL tested | | Source | shared root cause/owner is documented | manual per-page edits without root cause | | Regression | adjacent canonical/robots/accessibility/link rules still pass | fix creates a new defect in the same component | | Evidence | before/after values and test time are stored | only visual impression or screenshot |

Ownership and handoff

Content/SEO owner: defines the expected page purpose and whether the condition actually requires a change.
Developer/platform: fixes the shared template, routing, header, or component source.
QA: tests representative edge states and re-crawls/re-requests after deployment.
Release owner: records time, scope, and rollback point so monitoring signals can be tied to a specific change.

Acceptance criteria

PASS when the final technical state is reproducible on representative URLs, the shared root cause is fixed, intentional exceptions are documented, and a re-crawl/re-request shows no new regression in canonicalization, robots directives, accessibility, links, or rendering.

Worked operational example: defect → fix → proof

Symptom: the audit reports “Decorative Images: How to Mark Them Without Adding Noise” on multiple URLs.
Root cause: the repeated output originates in a template, component, CMS fallback, or infrastructure layer.
Fix: change that shared source instead of patching individual pages, and keep the change as small as possible.
Proof: store at least one before/after URL per template, the final HTTP/HTML/DOM output, and the re-crawl result. If an intentional exception remains different, document it so a future audit does not treat it as an unresolved defect.

For production systems, also include a regression sample: same locale, mobile/desktop when relevant, missing-data state, and one URL that was already correct. This proves whether the change stabilizes the generator rather than only the reported example.

1. Define the affected URL/template class and write the expected behavior before changing anything.
2. Capture raw HTTP/HTML; when client-side code changes output, also inspect the rendered DOM.
3. Evaluate image role, alt, currentSrc, link state, and dimensions together.
4. Trace the defect to its shared layer: DNS/CDN, routing, template, component, CMS field, or editorial content.
5. Implement the smallest systemic fix and preserve a rollback point first.
6. Test positive cases, missing/empty data, and at least one relevant edge state.
7. Re-crawl or re-request every affected template/URL class and store before/after evidence.
8. PASS: expected behavior is reproducible, no adjacent SEO/accessibility rule regresses, and the fix does not require manual per-page workarounds.