Alt text and accessibility: what WordPress publishers need to know
Alt text exists for accessibility first. Before it became an SEO signal, the alt attribute was designed to provide a text alternative for users who cannot see images — people using screen readers, people on slow connections where images fail to load, and people who have disabled image loading in their browsers.
That origin matters because it shapes what good alt text actually looks like. Writing for accessibility and writing for SEO are not always the same thing, and WordPress publishers who optimize only for search engines often produce alt text that fails the people who need it most.
What WCAG says about alt text
The Web Content Accessibility Guidelines (WCAG) 2.1, at level A (the minimum compliance level), require that all non-text content has a text alternative that serves an equivalent purpose. This is Success Criterion 1.1.1 — Non-text Content.
In practice, this means every meaningful image must have an alt attribute that describes its content or function. Decorative images must have an empty alt attribute (alt="") so assistive technology can skip them. Images that serve as links must have alt text describing the link destination, not the image appearance.
WCAG does not prescribe a specific format, length, or keyword strategy. It cares about whether the alt text provides an equivalent experience for users who cannot see the image.
Where SEO alt text and accessible alt text diverge
An SEO-optimized alt text aims to reinforce the page's target keyword and help the image appear in Google Image search results. An accessible alt text aims to describe the image so a screen reader user understands what sighted users see.
These goals often overlap. A product image with the alt text "Men's waterproof trail running shoe in carbon grey" is both keyword-relevant and descriptively useful. But they can also diverge. An alt text like "trail running shoe keyword trail shoe waterproof" serves SEO intent (poorly, since Google discourages this) while being useless for accessibility.
The best approach is to write alt text for the human reader first. If the result naturally includes relevant keywords, that is a bonus. If it does not, do not force them in.
How automated tools affect accessibility
Any plugin that generates alt text automatically — whether from SEO keywords, titles, or image names — produces alt text that is contextually relevant but not image-specific. A focus keyword applied to all images on a page means every image gets the same alt text. For SEO coverage, that is usually acceptable. For accessibility, it is a compromise.
A screen reader user navigating a blog post with five images, all carrying the alt text "indoor herb garden tips," receives no information about what each individual image shows. They know the images relate to the topic but cannot distinguish between them.
This is an honest trade-off. Bialty and similar contextual tools solve the coverage problem — ensuring no image has an empty alt attribute — but they do not solve the precision problem. For images where individual descriptions matter for accessibility, manual overrides or dedicated image-description workflows are still necessary.
The practical accessibility workflow for WordPress
The realistic approach for most WordPress publishers is a tiered strategy.
Tier 1: eliminate empty alt attributes. Use an automated tool like Bialty to ensure every image has some alt text. Even a page-level signal (title or keyword) is better than an empty attribute from an accessibility standpoint, because it gives screen reader users at least a topic context.
Tier 2: add specific descriptions to critical images. For images that carry unique information — infographics, charts, photographs that illustrate a specific point, product photos with important visual details — write or commission individual alt text descriptions. Use Bialty's metabox override to apply these per page or product.
Tier 3: mark decorative images correctly. Images that serve no informational purpose (background textures, dividers, visual fillers) should have alt="" to tell screen readers to skip them. Bialty's per-post disable option can handle pages where all images are decorative.
Tier 4: test with a screen reader. The only way to truly validate accessibility is to experience the page as a screen reader user does. Run VoiceOver (macOS), NVDA (Windows), or JAWS on key pages and listen to how the alt text is read. This reveals problems that no automated audit can catch.
Common accessibility mistakes with alt text
Writing alt text that starts with "image of" or "picture of" — screen readers already announce the element as an image, so this prefix is redundant. Using filenames as alt text without cleanup — IMG_4582.jpg conveys nothing to anyone. Leaving alt attributes entirely absent (not just empty) — this causes some screen readers to read the image URL aloud, which is the worst possible experience. And applying identical alt text to every image on a page — technically compliant but practically useless for navigation.
Where Bialty stands on accessibility
Bialty is an SEO coverage tool, not an accessibility-first tool. Its contextual injection model ensures that no image goes without an alt attribute, which is the minimum accessibility requirement. But the alt text it produces is derived from page-level metadata, not from the visual content of each image.
For sites where accessibility compliance is a legal or ethical priority, Bialty serves as the coverage base layer. The manual, human-written descriptions serve as the precision layer on top. Together, they produce a site that has no empty alt attributes and has meaningful descriptions where they matter most.
That combination — automated breadth plus manual precision — is the only approach that scales without sacrificing the people who need alt text the most.