Image Dimensions and Aspect Ratio: Preventing Distorted Presentation

What this check actually means

Provide intrinsic width/height or a stable aspect ratio and avoid stretching assets away from their natural proportions.

Keep intrinsic dimensions and rendered aspect ratio consistent so images are not stretched. Provide width/height or an equivalent reserved aspect ratio to reduce layout shifts, and verify that responsive CSS does not override one dimension incorrectly.

Expected behavior and decision boundary

Expected state: Keep intrinsic dimensions and rendered aspect ratio consistent so images are not stretched. Provide width/height or an equivalent reserved aspect ratio to reduce layout shifts, and verify that responsive CSS does not override one dimension incorrectly. 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

Keep intrinsic dimensions and rendered aspect ratio consistent so images are not stretched. Provide width/height or an equivalent reserved aspect ratio to reduce layout shifts, and verify that responsive CSS does not override one dimension incorrectly.

<img src="example.webp" alt="Concise description of the image's relevant purpose" width="1200" height="800">

[...document.images].map(i => ({src:i.currentSrc, alt:i.getAttribute('alt'), w:i.naturalWidth, h:i.naturalHeight}))

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.

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.