Alt Text vs Captions vs Image Descriptions: The Differences in WordPress and What Each One Is For

WordPress lets you attach four different pieces of text to an image: alt text, caption, description, and title. They serve different jobs for different audiences, get rendered in different places, and have different impacts on accessibility and SEO. Most “what’s the difference between captions and descriptions” articles cover the surface; this guide covers what each one actually does — including the parts that matter for screen reader users, search engines, and image-heavy WordPress sites.

Quick reference — what each one does

If you only want the short answer:

Field	Audience	Where it appears	Required for
Alt text	Screen readers, search engines, visitors with broken images	alt attribute on the <img> tag (not visually displayed)	Accessibility (WCAG), SEO image search
Caption	All visitors	Visible below the image as a styled text element	Editorial context, photo credits
Description	Attachment page, RSS feeds, some plugins, screen readers (in some configurations)	The image’s WordPress attachment page; not visible inline by default	Long-form image documentation, internal organization
Title	Mouse hover tooltip (browsers), sometimes screen readers	Hover tooltip on the image	Largely deprecated for accessibility purposes

The longer answer — and the why behind each — is the rest of this guide.

Alt text — what it actually is

The alt attribute on an HTML image tag is short text that describes the image’s content or function. Screen readers read it out loud to visitors who can’t see the image; browsers show it when the image fails to load; search engines use it to understand what the image is about.

Where it lives in WordPress:

• In the media library, under the “Alternative Text” field for each image
• Rendered as <img src="..." alt="Your alt text here"> in the final HTML
• For block editor users: editable directly in the image block sidebar under “ALT TEXT (ALTERNATIVE TEXT)”

What good alt text looks like:

• Describes the image’s content concisely (typically 125 characters or fewer, the limit at which some screen readers truncate)
• Conveys the function the image serves on this specific page — the same image needs different alt text in different contexts
• Avoids redundancy with surrounding text — if the caption already says “Photo of black cat on a couch”, the alt text shouldn’t repeat the same wording
• Skips meta-phrases like “Image of” or “Picture showing” — screen readers already announce that the element is an image

Examples:

<!-- Functional alt text in context -->
<img src="puzzle.jpg" alt="The puzzle piece labeled 'cache invalidation' that completes the diagram">

<!-- Descriptive alt text for a content image -->
<img src="storefront.jpg" alt="Brick-fronted bookstore on Charing Cross Road, with floor-to-ceiling shelves visible through the windows">

<!-- Wrong — meta-phrase + generic description -->
<img src="storefront.jpg" alt="Image of a store">

<!-- Decorative image (background image, divider, ornament) -->
<img src="divider.svg" alt="" role="presentation">

Decorative images use empty alt text. When an image is purely decorative — a divider line, an ornament, a background graphic — alt="" (empty) tells screen readers to skip it entirely. Don’t write “decorative image” as the alt text; the empty value is the correct signal.

Captions — what they actually are

A caption is visible text displayed below (or beside) an image. WordPress wraps it in a <figcaption> element inside a <figure> element, which screen readers and search engines understand as associated with the image.

Where it lives in WordPress:

• In the media library, under the “Caption” field
• In the block editor: editable directly in the image block, with the caption appearing below the image after publish
• Rendered as <figure><img src="..."><figcaption>Your caption</figcaption></figure>

What captions are for:

• Editorial commentary — the reader’s experience of the image is enriched by reading the caption
• Photo credits — attribution to the photographer or source
• Quotations, dates, locations associated with the image
• Brief context that doesn’t belong in the surrounding article body

What captions are not for:

• Substituting for alt text. The two serve different audiences. Alt text is for users who can’t see the image; captions are for users who can.
• Lengthy descriptions of the image’s content. If you find yourself describing what’s in the image in the caption, that information probably belongs in the surrounding article text instead.

Example:

<figure>
    <img src="market-square.jpg" alt="Cobbled square with three-story tenement buildings, photographed at sunset">
    <figcaption>Kraków's Main Square at sunset, October 2024. Photo: Anna Lewandowska</figcaption>
</figure>

The alt text describes what’s in the image for users who can’t see it; the caption gives editorial context that adds value for users who can see it.

Descriptions — what they actually are

The description field in WordPress stores long-form text about the image. By default, it doesn’t appear in the post where you embed the image — it appears on the image’s attachment page (the page WordPress generates for each individual media file).

Where it lives in WordPress:

• In the media library, under the “Description” field
• Used as the body content of the image’s attachment page (e.g., /your-site.com/?attachment_id=123)
• Some plugins display it elsewhere (galleries, image previews)
• Indexed by some search functions

What descriptions are for:

• Long-form documentation of the image — context, history, technical details that don’t fit in a caption
• Internal organization for image libraries — searchable metadata for finding images later
• Accessibility for visitors landing on the attachment page (rare but possible)

What descriptions are not for:

• Inline display on the post where the image is embedded (unless a plugin or theme is configured to surface them)
• Standalone accessibility (only a fraction of users ever reach attachment pages)
• SEO of the post the image is embedded in (Google typically reads the post page, not the attachment page)

For most WordPress sites, descriptions are the least-used of the four fields. They become important on sites with substantial image libraries (stock photography, e-commerce product catalogs, historical archives) where long-form metadata helps content management.

Title — what it (no longer) does

The image title field in WordPress generates the title attribute on the rendered image tag. Browsers show it as a tooltip when the user hovers over the image with a mouse.

Why most accessibility guides recommend leaving it blank:

• Screen readers handle the title attribute inconsistently — some read it, some don’t, some read it after the alt text (creating redundant audio)
• Touch devices have no hover state, so the tooltip never appears
• The information almost always belongs in the alt text, caption, or surrounding article body instead

WordPress historically populated the title field from the filename when you uploaded an image. This is rarely useful content for users; the recommended pattern is to clear it (or leave it blank) and let the more meaningful fields do their work.

For accessibility-focused sites, the standard practice in 2026 is: alt text yes, caption yes, description as needed for image library organization, title field empty.

The decision matrix — when to use which

Use this to translate your situation into specific field usage:

You have an editorial image that adds visual context to a paragraph:
– Alt text: describe what’s in the image
– Caption: editorial context, photo credit if applicable
– Description: skip
– Title: skip

You have a functional image (icon, illustration that makes a specific point):
– Alt text: describe the function (what the image communicates, not just what it looks like)
– Caption: skip
– Description: skip
– Title: skip

You have a decorative image (ornament, divider, background):
– Alt text: empty (alt="")
– Caption: skip
– Description: skip
– Title: skip

You have an infographic or chart with information not duplicated in body text:
– Alt text: concise summary of the data the chart presents
– Caption: explanation that adds value
– Description: the full breakdown of the data, structured as text (also belongs on the page body)
– Title: skip

You have an e-commerce product image:
– Alt text: descriptive (color, style, key features) — these alt texts are read by screen readers AND indexed by Google Images
– Caption: optional, usually skip
– Description: full product description (typically managed elsewhere in WooCommerce)
– Title: skip

You’re building an image library for internal use:
– Alt text: required regardless of internal/external use
– Caption: optional
– Description: yes — long-form metadata for searchability
– Title: skip

WordPress-specific implementation patterns

Block editor (Gutenberg)

In the block editor, click an image block to reveal the sidebar with:

• Alt text — under the block settings; the most prominent field
• Caption — appears directly below the image; click below the image to edit
• Title — available in the image’s advanced settings panel
• Description — edit in the media library directly, not via the block

The block editor’s prominence of the alt text field is intentional — it’s the field most users skip and most needs filling.

Classic editor

In the classic editor, click an image then click the pencil icon to open the image details modal with all four fields editable. The same fields exist; the UI is just more compact.

Bulk editing via the media library

For sites with large image libraries that need bulk alt text or description updates, the Media Library’s list view shows the fields editable per-row. For very large bulk updates, plugins like Bulk Edit Images or WP-CLI commands are more efficient:

# Update alt text for a specific attachment
wp post meta update 123 _wp_attachment_image_alt "New alt text"

# List all attachments missing alt text
wp post list --post_type=attachment --meta_query='_wp_attachment_image_alt=""' --format=csv

# Bulk update via a CSV import
wp media import images.csv --feature=alt_text

Adding image alt text programmatically

When uploading images via code, set the alt text explicitly:

$attachment_id = wp_insert_attachment( /* ... */ );
update_post_meta( $attachment_id, '_wp_attachment_image_alt', 'Your alt text' );

The alt text is stored as post meta on the attachment post, with the meta key _wp_attachment_image_alt.

Accessibility, WCAG, and what screen readers actually read

The accessibility implications of these fields trace back to the Web Content Accessibility Guidelines (WCAG). The most relevant criteria:

• WCAG 1.1.1 Non-text Content (Level A): every non-text content (including images) must have a text alternative. Alt text is the standard mechanism.
• WCAG 1.4.5 Images of Text (Level AA): avoid images of text where the same content could be presented as actual text. If you must use an image of text, the alt text should contain the same text.
• WCAG 2.4.4 Link Purpose (in Context) (Level A): when an image is inside a link, the alt text (combined with surrounding text) must describe where the link goes.

What screen readers actually announce:

• For an image with non-empty alt text: “Image: [alt text content]”
• For an image with empty alt text (alt=""): nothing — the image is skipped entirely
• For an image with caption: alt text first, then the caption (since <figcaption> is read as part of the figure)
• For an image inside a link: alt text plus link context (the screen reader announces “Link” before or after reading the alt text)
• The title attribute may or may not be read, depending on the screen reader and user configuration

Common accessibility audit findings related to alt text:

• Missing alt text (the alt attribute is absent entirely): Level A failure
• Empty alt text on informative images (alt="" on an image that conveys information): Level A failure
• “Image of” / “Picture of” in alt text: not a failure, but flagged as poor practice
• Alt text identical to the filename: flagged as auto-generated content that probably isn’t meaningful
• Alt text longer than 125 characters: flagged in some audit tools (not strictly a WCAG failure, but bad practice — use a longer description field if longer text is needed)

For sites pursuing formal WCAG 2.1 AA conformance (often required for government, education, and healthcare in the EU and US), image alt text is one of the highest-impact areas to audit and fix.

SEO impact of each field

Search engines use the fields differently:

• Alt text — read by Google Image search and used as a strong signal for image content. Affects ranking in Google Images and in image results within general search.
• Caption — read by search engines as text content of the post. Affects general search ranking similarly to other body text.
• Description — only relevant if the attachment page itself ranks (rarely useful for most sites; the attachment page is usually weak content compared to the post the image appears on)
• Title — minimal SEO weight; modern search engines weight it lower than alt text and surrounding content
• Surrounding text — the paragraphs near the image are arguably the strongest SEO signal for what the image represents on the page

The pragmatic SEO recommendation: write meaningful alt text (helps both accessibility and SEO), use captions for genuine editorial value (helps content quality scoring), skip the title field, and use the description field for image library organization rather than SEO.

WAI-ARIA roles and image labeling — beyond alt text

For most images, the alt attribute is the right mechanism. For images that need more complex labeling, WAI-ARIA provides additional attributes.

role="img" for non-<img> elements that act as images

When you have a styled <div> background image or an SVG that conveys content, the element isn’t an <img> tag and won’t get alt text. Use role="img" plus aria-label to give the screen reader the same information:

<div role="img" aria-label="Animated loading spinner" class="spinner"></div>

<svg role="img" aria-label="Email icon">
    <use href="#email-icon"></use>
</svg>

For background images applied via CSS that are purely decorative, no ARIA is needed — the element is invisible to screen readers by default unless you specifically expose it.

aria-labelledby for images labeled by other on-page text

When the image’s label exists somewhere else on the page (a heading, a caption, a nearby paragraph), aria-labelledby references that element instead of duplicating the text in alt:

<h2 id="quarterly-results">Quarterly Sales Performance</h2>
<img src="chart.png" alt="" aria-labelledby="quarterly-results">

The screen reader uses the referenced element’s text as the image’s accessible name. This is appropriate when the heading or label is the most accurate description of what the image shows.

Combining alt and aria-describedby

For images that need both a short label (alt) and a longer description:

<img src="chart.png"
     alt="Bar chart of quarterly sales"
     aria-describedby="chart-detail">

<p id="chart-detail" class="sr-only">
    Q1 sales: $2.3M. Q2: $2.8M. Q3: $3.1M. Q4: $3.5M. Annual total $11.7M.
</p>

The screen reader reads the alt text first as the image’s name, then announces the description after — typically with a brief delay.

SVG-specific accessibility

SVG images get accessibility differently from raster images. The best practice:

<svg role="img" aria-labelledby="logo-title" width="120" height="40">
    <title id="logo-title">Acme Corporation</title>
    <!-- SVG content -->
</svg>

The <title> element inside the SVG, referenced by aria-labelledby, becomes the accessible name. Screen readers also read <title> directly if present. Don’t rely on alt text on the surrounding wrapper — it doesn’t apply to inline SVG.

For purely decorative SVGs, mark them as hidden from assistive technology:

<svg aria-hidden="true" focusable="false">...</svg>

The aria-hidden="true" removes it from the accessibility tree entirely.

Schema.org markup for images

Search engines use schema.org structured data to understand images. The relevant type is ImageObject, which works alongside alt text rather than replacing it:

<script type="application/ld+json">
{
    "@context": "https://schema.org",
    "@type": "ImageObject",
    "contentUrl": "https://example.com/wp-content/uploads/storefront.jpg",
    "license": "https://example.com/license",
    "acquireLicensePage": "https://example.com/contact",
    "creditText": "Photo by Anna Lewandowska",
    "creator": {
        "@type": "Person",
        "name": "Anna Lewandowska"
    },
    "copyrightNotice": "© 2024 Acme Corporation",
    "caption": "Charing Cross Road storefront at sunset",
    "name": "Acme Books Storefront"
}
</script>

For WordPress sites, schema is typically managed by SEO plugins (Rank Math, Yoast) which handle image schema automatically based on the alt text and caption you provide. For custom schema implementations, the script above is the canonical format.

For most sites, focusing on alt text and captions has higher accessibility impact than adding ImageObject schema — but the schema does affect how Google understands and licenses your images in Image Search and Discover.

Image SEO beyond alt text

Alt text is one signal among several that affect how Google ranks images. The full picture:

• Filename — descriptive filenames (black-cat-on-couch.jpg) help Google understand the image even before parsing the page. WordPress preserves the original filename on upload; rename images before uploading where possible.
• Surrounding text — the paragraphs near the image are arguably the strongest signal for what the image represents on this specific page
• Alt text — the dedicated “what is this image” field
• Caption — supplementary context, weighted similarly to body text
• Image sitemap — for image-heavy sites, an XML image sitemap helps Google discover all images. SEO plugins (Rank Math, Yoast) generate this automatically; custom implementations follow Google’s image sitemap spec
• Image size and format — properly sized, modern format (WebP, AVIF) images are easier for Google to index and serve in search results
• loading="lazy" — lazy-loading is now native to WordPress; lazy-loaded images are still discoverable by Google, with no negative impact on SEO

For e-commerce sites specifically, product image SEO benefits significantly from descriptive filenames + meaningful alt text + structured data (Product schema, which includes image data) — the combination is what surfaces products in Google Image search and the shopping results carousels.

Open Graph and social sharing image alt text

When a page is shared on social platforms (Facebook, LinkedIn, X), the platform reads Open Graph tags to generate the share card. The image and its alt text are separate tags:

<meta property="og:image" content="https://example.com/share-image.jpg" />
<meta property="og:image:alt" content="Acme Corporation storefront at sunset on Charing Cross Road" />

Social platforms use og:image:alt for accessibility in their feeds — screen reader users on Twitter or Facebook hear the alt text when the share card is read. For WordPress sites, SEO plugins handle Open Graph tags automatically based on the featured image’s alt text — verify it’s actually being set by viewing the page source for the og:image:alt meta tag.

For Twitter specifically, additional cards (twitter:image:alt) parallel the Open Graph values.

Image accessibility for carousels, sliders, and galleries

Image carousels (multiple images cycling through a viewport) have specific accessibility considerations:

• Each image in the carousel needs its own alt text — not just one alt text for “the carousel”
• The carousel’s controls (next, previous, dot indicators) need accessible labels
• Auto-advancing carousels need a pause control (WCAG 2.2.2)
• The current image’s caption (if any) needs to be associated correctly

For WordPress slider plugins (Slider Revolution, Smart Slider, MetaSlider), check that each slide’s alt text is editable and being used in the rendered HTML. Some sliders historically rendered all images with the same alt text or skipped alt text entirely — verify in the actual page source.

For Gutenberg’s native Gallery block, each image’s alt text is set in the media library and used in the gallery rendering. For Image with Caption blocks inside the gallery, the caption appears below each image as expected.

Lazy loading and alt text

WordPress 5.5+ added native lazy loading via loading="lazy" on <img> tags. The lazy loading happens at the browser level and doesn’t affect alt text — the alt attribute is in the HTML from the start, just the image’s actual loading is deferred until visible.

For sites using JavaScript-based lazy loading (older plugins or custom implementations), verify the alt attribute is preserved on the lazy-loaded image. Some legacy lazy loaders use data-src for the image source and require the alt attribute to be on the eventual rendered <img> tag — not just on a placeholder.

Accessibility testing tools

Real accessibility testing happens with dedicated tools rather than manual inspection. For image accessibility specifically:

• axe DevTools (browser extension) — comprehensive accessibility checks including alt text presence and quality
• WAVE (browser extension and web tool) — visually annotates accessibility issues on a page, with image-specific flags
• Lighthouse (Chrome DevTools, also available as CI tooling) — automated accessibility audits including image alt text
• Equalize Digital Accessibility Checker (WordPress plugin) — integrates accessibility checks directly into the WordPress editor
• Pa11y (command line) — automated testing for CI/CD integration

For sites pursuing formal WCAG conformance, manual testing with a screen reader (NVDA on Windows, VoiceOver on macOS, JAWS) supplements the automated tools — automated tools can verify alt text is present but can’t judge whether the text is meaningful for the specific image’s function on the specific page.

Long descriptions for complex images

When an image’s content can’t be summarized in 125 characters of alt text — typically charts, infographics, complex diagrams — a longer description is needed. The patterns:

Option 1 — long description in the surrounding text:

<img src="quarterly-sales.png" alt="Bar chart showing Q1-Q4 sales, summarized in the table below">

<table>
    <caption>Quarterly sales, 2024</caption>
    <tr><th>Quarter</th><th>Sales</th></tr>
    <tr><td>Q1</td><td>$2.3M</td></tr>
    <tr><td>Q2</td><td>$2.8M</td></tr>
    <tr><td>Q3</td><td>$3.1M</td></tr>
    <tr><td>Q4</td><td>$3.5M</td></tr>
</table>

The alt text gives the screen reader user enough context to understand the image; the actual data is provided as accessible text content adjacent to the image.

Option 2 — aria-describedby linking to a longer description:

<img src="quarterly-sales.png" alt="Bar chart of quarterly sales" aria-describedby="sales-desc">

<div id="sales-desc">
    Q1 sales were $2.3M, growing to $2.8M in Q2, $3.1M in Q3, and reaching $3.5M in Q4.
    Total annual sales: $11.7M, a 15% year-over-year increase.
</div>

The screen reader reads the alt text first, then announces the additional description via the aria-describedby association.

Option 3 — longdesc attribute (deprecated, avoid):

The longdesc attribute is no longer supported by most screen readers and was removed from HTML5. Don’t use it.

AI-generated alt text — should you trust it?

Several plugins (Yoast, Rank Math AI, others) and platforms (Cloudinary, Google Vision) auto-generate alt text for images using AI vision models. The quality varies:

• Good: identifying obvious content (“dog on grass”, “woman smiling at camera”)
• Mediocre: identifying specific things (“dog” rather than “golden retriever puppy”; “smartphone” rather than “iPhone 15 Pro Max”)
• Poor: capturing the function the image serves on a specific page (AI sees what’s in the image, not why it’s there)
• Misleading: confidently labeling something incorrectly without flagging the uncertainty

For image-heavy sites where manual alt text isn’t feasible at scale, AI-generated alt text is better than nothing — but plan for human review of the most important images (homepage hero, key product photos, blog featured images). For accessibility compliance work specifically, auto-generated alt text typically fails formal audits.

Common mistakes and how to fix them

Mistake: Filling the alt text field with the image filename (alt="DSC_0123.jpg").
Fix: WordPress sometimes pre-populates from filename. Clear it and write descriptive alt text.

Mistake: Identical alt text and caption (“Black cat on a couch” / “Black cat on a couch”).
Fix: They serve different audiences. Alt text describes the image for non-sighted users; caption adds value for sighted users.

Mistake: Skipping alt text on “decorative” images, then leaving the alt attribute missing entirely.
Fix: Decorative images get alt="" (empty). Missing alt attribute is the only WCAG failure; empty alt text is correct for decorative content.

Mistake: Bulk-applying generic alt text (“Product image”, “Logo”, “Banner”) across many images.
Fix: Each image needs alt text specific to its content and function.

Mistake: Trusting AI-generated alt text without review for important pages.
Fix: Review and edit AI-generated alt text on key pages (homepage, top-traffic pages, product pages).

Mistake: Writing very long alt text (3+ sentences) where a long description field or adjacent text would be more appropriate.
Fix: Alt text under 125 characters; longer content goes in the surrounding text or via aria-describedby.

Frequently asked questions

Do I need to fill in all four fields for every image?

No. Alt text is the most important (accessibility and SEO). Captions are optional and used when they add editorial value. Description is mostly for internal organization or attachment pages. Title field is generally best left blank in 2026.

What happens if I leave alt text blank?

The screen reader either announces “image” (with no description) or skips the image. For informational images, this fails WCAG accessibility requirements. For purely decorative images, the correct value is alt="" (empty string) — but explicitly empty, not missing.

How does Google use alt text in image search?

Google uses alt text as one signal for understanding what an image depicts. Combined with the surrounding page text, the filename, the page URL, and image-level signals (caption, schema markup), alt text contributes to image search rankings. For e-commerce and image-heavy sites, descriptive alt text is one of the highest-impact image SEO actions.

Do captions count for SEO?

Captions appear as text content on the page and contribute to overall content quality and contextual signals. Search engines read them like any other body text. They don’t get the specific “image content” weight that alt text gets, but they do contribute.

Should I use the title field at all?

In 2026, generally no. The title attribute creates a hover tooltip that doesn’t appear on touch devices, is read inconsistently by screen readers, and rarely conveys information that doesn’t belong elsewhere. Clearing it is the recommended pattern for accessibility-focused sites.

How do I make sure my alt text passes a WCAG audit?

Three things: every meaningful image must have non-empty alt text describing its function or content; every decorative image must have alt="" explicitly; no images should have the alt attribute missing entirely. Beyond that, write alt text that’s specific (not generic), context-appropriate, and concise (under 125 characters where possible).

What’s the right alt text for a logo?

For your own site’s logo, the company name is usually the right alt text — what the logo communicates to a screen reader user is “this is [Company] — typically used in a link to the homepage.” Example: alt="Acme Corporation" (not alt="Logo" or alt="Acme logo").

Should I include SEO keywords in my alt text?

Write alt text that accurately describes the image; if a keyword naturally fits the description, include it. Don’t stuff keywords artificially — search engines weight alt text relevance over keyword density, and keyword-stuffed alt text hurts both accessibility (it reads poorly to screen reader users) and SEO (Google penalizes obvious keyword stuffing). The pragmatic rule: write alt text for the user, not for the search engine.

Is there a character limit for alt text?

No hard technical limit, but practical guidelines exist. Most screen readers handle alt text of any length, but reading aloud very long alt text (3+ sentences) is a poor user experience. The common recommendation is under 125 characters — at that length some screen readers may break or truncate. For longer descriptions, use the surrounding page text or aria-describedby instead.

Should alt text use punctuation and capital letters?

Yes. Screen readers handle punctuation naturally (commas create slight pauses, periods longer pauses) and capitalization aids comprehension when the alt text is read aloud. Treat alt text like a brief, well-written sentence.

How do I handle alt text for images that are already accompanied by detailed text in the body?

Brief alt text that describes the image’s content; the body text provides the detail. Don’t repeat the full content in alt text — that creates redundancy for screen reader users.

What to do next

If you’re auditing an existing WordPress site for accessibility, the highest-impact image fields to fix are alt text on informative images (currently missing or weak) and ensuring decorative images have explicit alt="". For sites with hundreds or thousands of images, prioritize the most-trafficked pages and product images first; bulk-update lower-priority images afterward.

If you’re starting a new site or new content workflow, the discipline that prevents future audit findings: write meaningful alt text at upload time, in the moment you have the most context about why the image is there. Captions are optional; descriptions are mostly for your own organization; the title field stays empty.

If you’re working on WCAG compliance specifically — for government, education, healthcare, or commercial sites with accessibility legal exposure — pair alt text discipline with a full accessibility audit covering the rest of WCAG (color contrast, keyboard navigation, ARIA, form labeling). Alt text is one piece of a larger accessibility picture, and most compliance failures involve multiple criteria simultaneously.

The four image fields in WordPress aren’t redundant — each one serves a different job for a different audience. Filling them appropriately requires understanding what each one is actually for, which is the discipline that distinguishes sites that pass accessibility audits from sites that don’t.