Web accessibility and SEO are different disciplines, but a handful of fixes serve both: text alternatives for images, descriptive link text, real HTML links and readable text work for a screen reader user and for a crawler from the same markup. Making those fixes once is efficient. Accessibility compliance is not a ranking guarantee, and neither WCAG nor Google's pages say otherwise. The topic matters for content editors, site owners, SEO specialists and developers.
Two readers, one source file
The goals differ. Accessibility aims to make a page usable by people with different abilities, devices and assistive technologies. SEO aims to make a page findable, crawlable and understandable to search systems. The shared ground is that both depend on a page whose structure is readable by machines.
Why the same markup helps both
A screen reader uses the HTML structure of the page, and so does a search crawler. A text alternative on an image, descriptive words inside a link and a correctly marked heading carry information for both. The W3C states the overlap directly: the W3C's Understanding page for success criterion 1.1.1 (Opens in a new tab) says text alternatives support the ability to search for non-text content and to repurpose content in a variety of ways.
Where the two do not overlap
Not every SEO task helps accessibility, and not every accessibility task has a documented search effect. Crawl budget, canonical URLs and sitemaps are technical SEO topics outside the scope of the accessibility criteria discussed here. Keyboard operation, focus indicators and form labels matter to users but are not documented as separate search signals in the WCAG or Google guidance. Claiming a search benefit for them would be unsupported.
| Topic | Accessibility source | Search source | Documented overlap? |
|---|---|---|---|
| Text alternatives for images | WCAG 1.1.1, Level A | Google: alt text is the most important image metadata | Yes |
| Link text and markup | Meaningful link wording helps users | Google: a element with href, descriptive anchor text | Yes |
| Text contrast | WCAG 1.4.3, Level AA | Google's link and image pages do not cover contrast | Accessibility documented, search effect not |
| Captions for prerecorded media | WCAG 1.2.2, Level A | No statement in the official pages | Accessibility documented, search effect not |
| Decorative images | Null alt so assistive technology skips them | No separate rule in Google's image page | Accessibility decision |
Keeping expectations honest
Bringing a page up to WCAG does not promise higher rankings; neither WCAG nor Google's pages say it does. The accurate framing is that accessibility fixes help readers, and several of them match practices Google recommends in its own documentation. Knowing which ones overlap lets you plan the work once instead of twice.
Alt text decisions
Images are where the two bodies of guidance agree most clearly. WCAG 1.1.1 asks for text alternatives for non-text content; Google's image guidance calls alt text the most important attribute for providing more metadata about an image. The same sentence does two jobs, but it is written for different reasons.
Informative images
According to the Understanding page, the intent of the criterion is to make information conveyed by non-text content accessible through a text alternative. That alternative can be presented through speech, visual text or braille. For standard images, charts, audio and animations, the alternative carries the same information, using short and long descriptions as needed.
Google's image guidance (Opens in a new tab) says alt text helps screen reader users and acts as anchor text when an image is a link. It also tells publishers to avoid filling alt attributes with keywords, because that creates a poor user experience and may cause a site to be seen as spam. A useful alt text reads as if you were describing the picture to someone who cannot see it: what it shows and what role it plays on the page.
Questions about licensing and sourcing of images are a different task; see the article on article image alt text and stock image licensing. For the technical side of appearing in image search, image SEO for Google is a separate starting point.
Decorative images
WCAG 1.1.1 says content that is purely decorative, used only for layout, or not meant for users should be implemented so that assistive technology ignores it. The Understanding page adds that alternative text on such content only distracts screen reader users. Listed techniques include null alt text on images and CSS-based decoration. The takeaway is that not every image needs alt text; for an image that carries no information, an empty alt is the right decision.
Images added through CSS
Google reads images from the src attribute of img elements and states that it does not index CSS images. If an image carries meaning, putting it in as a CSS background creates a problem for both accessibility and search, since a CSS background has no place for a text alternative. A sound split is meaningful pictures as img elements and pure decoration in CSS.
Complex charts and diagrams
WCAG 1.1.1 allows short and long descriptions together for content such as charts. Practical suggestion: give the chart a brief alt text that says what it is and its main takeaway, and put the detail in a table or paragraph on the page. That way a reader who cannot see the chart still reaches the data, and the data exists as real text; Google's image guidance notes that it extracts information about an image's subject from the content of the page.
Decision rule: what goes in the alt attribute?
- Does the image carry information? Write a short alt text for that information.
- Is the image the only content of a link or button? The alt text should say where the link goes or what the button does.
- Is the image purely decorative? Leave alt empty (alt="") and, where possible, add it through CSS.
- Does the image contain text? Repeat the text in the alt attribute, or better, use real text.
- Is it a chart or diagram? Use a short alt text plus a fuller description on the page.
Link text and crawlable markup
Google's link best practices (Opens in a new tab) state that Google generally crawls links that are a elements with an href attribute. Other formats are usually not parsed. The page lists examples it does not recommend: a span with an href, an element that navigates through onclick alone, and javascript: values inside href.
Anchor text that works alone
The page asks for anchor text that is descriptive, reasonably concise and relevant to both the current page and the target page. Its test is to read the anchor text on its own and ask whether it tells you where the link leads. It names "click here", "read more", "website" and "article" as generic wording to avoid, and it also warns against stuffing keywords into anchor text.
The same test happens to catch a problem that screen reader users meet: a list of links that all say "read more" does not tell them which is which. No accessibility criterion is cited for this point; the Google test simply catches the same weakness. For where headings sit in a page, the guide on heading structure for SEO and accessibility is a companion, and the readable content formatting guide covers the text around links.
Image links and empty links
For an image link, Google uses the image's alt text as anchor text. The good example on the page is an alt that says what the link does; the bad example is an empty alt. An empty alt can be right for a decorative image, but if that same image is the only content of a link, the link loses its name. The page also says that when an a element is empty, Google may fall back to its title attribute.
| Case | Weak version | Better version |
|---|---|---|
| Generic link text | Click here | Short words that name the destination |
| Empty link | An a element with no text | Meaningful anchor text |
| Image link | alt="" | An alt that describes what the link does |
| Script-only navigation | onclick or javascript: instead of href | A real a element with a resolvable href |
| Keyword stuffing | A long, overloaded phrase | Concise words that fit the topic |
Contrast and readable text
Contrast is a measurable accessibility criterion. According to the Understanding page for 1.4.3 (Opens in a new tab), Level AA requires a contrast ratio of at least 4.5:1 for text and images of text, with 3:1 for large-scale text. Large-scale text is defined as at least 18 point, or 14 point bold, and the page notes that thin or unusual fonts may need more contrast.
How the numbers work
The page says the ratios are thresholds and that computed values are not rounded, so 4.499:1 fails the 4.5:1 requirement. A color pair that looks like "about 4.5" in a design tool should therefore be confirmed with a checker that reports the exact value. The requirement applies to the text wherever it appears, even if the color pair is used in only one section.
What is excluded
The page lists incidental text as having no contrast requirement: text in an inactive user interface component, pure decoration, text not visible to anyone, and text that is part of a picture with significant other visual content. Text that is part of a logo or brand name also has no requirement. If a logo works as a user interface component, though, it still needs enough contrast when the low contrast is an author choice and not a brand requirement.
Contrast and search: what the official pages state
WCAG does not claim that contrast affects search results, and Google's link and image pages do not mention contrast. Saying that contrast improves rankings would therefore be unsupported. The supported statement is narrower: contrast makes text more readable for people with low vision, as the Understanding page explains, and a search effect is not documented.
Text inside images
Criterion 1.4.3 also covers images of text, so text inside an image must meet the same ratio. Real HTML text keeps the color adjustable and lets assistive technology and crawlers read it. Putting headings and buttons into pictures is therefore a risky choice.
Captions, transcripts and media
Audio and video need separate attention, and the line between what is documented and what is not matters most here.
What WCAG asks for
The Understanding page for 1.2.2 (Opens in a new tab) covers captions for prerecorded media at Level A. Its stated intent is to enable people who are deaf or hard of hearing to watch synchronized media presentations. Captions go beyond dialogue: they identify who is speaking and include non-speech information conveyed through sound, including meaningful sound effects. The page compares captions with dialogue-only subtitles, which convey less.
Transcripts and search
The 1.2.2 page has no note about transcripts and does not list other benefits such as search or use in noisy places. The statement that captions improve video SEO is therefore not supported by WCAG, and Google's link and image pages do not address video captions. Practical suggestion: if a page carries text next to an audio or video item, readers who prefer text and users of assistive technology both benefit. If you care about search effect, look for a dedicated source or measure it yourself.
A title and description for media
WCAG 1.1.1 asks for a text description or title for time-based media so that users know what the media is. This is a simpler requirement than captions: every video or audio item should have a short title and a one-sentence description on the page.
| Media | Accessibility need | Search effect in these sources |
|---|---|---|
| Prerecorded video | Synchronized captions (WCAG 1.2.2, Level A) | No statement |
| Time-based media in general | A title or text description saying what it is (WCAG 1.1.1) | The 1.1.1 page says text alternatives support searching non-text content |
| Audio only | A text alternative; detail in the relevant criterion | No statement |
An audit routine for editorial teams
To turn these overlaps into a workflow, the routine below helps a small team review existing pages. No official page gives durations or priorities, so the plan gives order and criteria, not a calendar.
Step by step
- Choose the pages that matter most: the most visited, or the ones that bring in business.
- Sort each page's images into three groups: informative, linked, decorative.
- Write or fix alt text for informative images; leave alt empty on decorative ones.
- Read each link text on its own and fix generic wording.
- Check that links are real a elements with resolvable href values.
- Measure the contrast of body text and button text with a tool and review large text separately.
- Check videos and audio for captions and a short title or description.
- Record each fix and the guideline behind it.
Example scenario: a nonprofit's report library
Example scenario: a nonprofit publishes annual reports and a short video library. The team reviews its most visited report page. The cover image has no alt text, a chart exported as a picture carries the file name as alt, and a small logo image is the only content of a link to the donation page, with an empty alt. Link text across the page reads "download" and "more". The explainer video has no captions. The team writes a brief alt for the cover and a short one for the chart, moving the underlying figures into an on-page table. It gives the logo link an alt that names the donation page. It rewrites link text to name each report. It adds the video's captions to the production backlog, and a title and description to the page now.
Setting priorities
Ask two questions of each fix: how many readers will notice it, and how long will it take? Alt text and link text fixes are quick. Contrast may require a design system change. Captions are a separate job per media item. Do the quick fixes first and turn the design system change into planned work.
| Fix | Effort | Source behind it |
|---|---|---|
| Add or correct alt text | Low | WCAG 1.1.1, Google image guidance |
| Rewrite link text | Low | Google link guidance |
| Empty alt or CSS for decoration | Low | WCAG 1.1.1, Google image guidance |
| Fix contrast | Medium, depends on the design system | WCAG 1.4.3 |
| Add captions | Separate per media item | WCAG 1.2.2 |
Who owns what
Alt text and link writing can sit with the editor; contrast and real link markup with the designer and developer; captions with whoever produces the media. A short pre-publish checklist joins these duties: has each image been classified, are links meaningful, were colors measured, are captions ready. A checklist like this prevents problems that would otherwise be found and fixed after launch.
Repeating the audit
One audit does not last. New content and design changes bring the problems back. Tying the audit to trigger events, such as a content update or a design change, creates less wasted work than a fixed calendar. Check the current WCAG and Google pages before relying on specific wording or limits, because both can change.
Quick checklist
- Every informative image has a short alt text without keyword stuffing.
- Decorative images have an empty alt, or are added through CSS.
- Images that are the only content of a link have alt text that describes the link.
- Links are a elements with resolvable href values.
- Link text reads clearly on its own.
- Text and background colors meet the contrast thresholds.
- Prerecorded videos have captions.
- Audio and video items have a short title or description on the page.
Common mistakes and how to spot them
These mistakes come from applying the rules the wrong way round. Each has a sign and a simple check.
Image and link mistakes
- Filling alt with the file name. Google suggests short but descriptive file names, yet alt text should describe the image and not copy the name.
- Giving different images the same alt text, which makes them indistinguishable.
- Leaving alt empty on an image that is the only content of a link.
- Adding a meaningful image as a CSS background, which Google does not index and which has no place for a text alternative.
- Writing a link without an href.
Contrast and media mistakes
- Accepting "close enough" contrast without measuring; the page says 4.499:1 fails 4.5:1.
- Applying the large-text threshold to text that is below the defined size.
- Treating faded text as exempt when it is not a logo.
- Publishing video without captions and assuming readers can work it out.
| Mistake | Sign | Quick check |
|---|---|---|
| Missing alt text | A screen reader reads the file name or nothing | Inspect the alt attribute of every img element |
| Generic link text | The same phrase repeats in a list of links | Read each link text on its own |
| Low contrast | Faded text is hard to read on a bright screen | Measure the color pair with a contrast tool |
| Uncaptioned video | Content is unclear with the sound off | Watch the video muted |
Catching problems before publication
Practical suggestion: add three questions to the pre-publish checklist. Has each image on the page been classified as informative, linked or decorative? Does each link text make sense when read alone? Have the color pairs been measured? These questions help catch these mistake types before release. What remains, such as captions and complex charts, needs its own workflow.
Automated tools and human judgment
Practical suggestion: automated checkers can flag a missing alt attribute, an empty link or a low-contrast pair, but they cannot decide whether an alt text describes the image well. A person who knows the page makes that call, and the same applies to deciding whether link wording names its destination. Treat tool output as a starting point and human review as the closing step.
Frequently Asked Questions
Does accessibility directly affect SEO?
Neither WCAG nor Google says that accessibility compliance raises rankings. What they show is overlapping practice: text alternatives, descriptive link text and real HTML links appear in both WCAG and Google's documentation. WCAG compliance is not a ranking guarantee.
Does every image need alt text?
Every image needs a decision, not necessarily text. WCAG 1.1.1 says purely decorative content should be implemented so that assistive technology ignores it, and lists null alt text as one technique. Informative images need a text alternative. If an image is the only content of a link, Google uses its alt text as the anchor text, so it should not be empty.
Should I put keywords in alt text?
Google's image guidance says to avoid filling alt attributes with keywords, because it creates a poor user experience and may cause a site to be seen as spam. Write alt text as a short description for someone who cannot see the image.
What makes link text good?
Google's link guidance asks for anchor text that is descriptive, reasonably concise and relevant to both pages. Read the text on its own; if it does not say where the link leads, make it more specific. Avoid generic wording and keyword stuffing.
What contrast ratio does WCAG 1.4.3 require?
Level AA requires at least 4.5:1 for standard text and 3:1 for large-scale text, defined as at least 18 point or 14 point bold. Values are not rounded, so 4.499:1 does not meet 4.5:1. Logos and brand names are among the exceptions.
Do captions help a video rank?
The WCAG 1.2.2 page presents captions as access for people who are deaf or hard of hearing and says nothing about search ranking. A ranking benefit is not documented on the official pages, so treat captions as an accessibility requirement.
Conclusion
The shared ground between accessibility and SEO is narrow but real: text alternatives for images, descriptive and crawlable links and measured contrast are recommended in the documentation of both fields where they overlap. For contrast and captions, the official pages document the accessibility need and say nothing about search, so work on them as accessibility requirements and make no ranking promises. WCAG compliance is not a ranking guarantee, and the wording of both sets of pages can change.
If you want help turning these fixes into new or revised content, you can look at the content writing service at Akua Adforce; scope and terms are on the product page.
Post a comment
Please log in to leave a comment. Login