Alternative text on images and graphics
Basic principle
All non-text content must have an accessible name. Non-text content includes all font icons, images, SVG elements, non-standard usages of extended ASCII characters, or CSS used to construct interactive element graphics.
Different types of graphics require different implementations; the most common is the img element and the alt attribute. All graphics require some form of alternative text, however.
Note: This requirement does not mean must have text; it means must be explicitly defined. An empty alt attribute specifically defines the alternative text for an image as empty. This is different from a missing alt attribute, which leaves alternative text undefined. Some icons and images may be decorative.
Decorative graphics may include:
- Graphics used purely ornamentally.
- Supplemental graphics associated with links or buttons where the link or button has a name already defined.
Testing
Tools: Browser inspector, screen reader (recommended)
- For each non-text graphic, inspect the image using the browser inspector.
- In the inspector, determine whether the image has an accessible name.
- If yes, determine whether the accessible name is appropriate.
- If the image is inside a control, identify whether the control already has a name. If the control already has a name, this image may be decorative.
- If the image is decorative, verify that it is hidden from screen readers. For
imgelements, this is done viaalt="". For font icons or extended ASCII, this is done usingaria-hidden="true"on a wrapping element. The wrapping element must not be interactive. Forsvg, this is done usingaria-hidden="true"on thesvgelement or a wrapping parent that is not interactive.
- Verify accessibility of extended ASCII characters if present.
- Extended ASCII characters will not display text in the browsers accessibility inspector. Most characters have a standard reading value, but not all. If a theme uses ASCII characters in the design, use the article How Screen Readers read Special Characters as a reference to know what the screen reader will say, or (recommended) listen to the element with a screen reader.
- If the read text would not be appropriate in context, verify the character is wrapped in a
spanthat either hides the character or provides it with a more appropriatearia-label, depending on context.
WCAG resources
Resources
WCAG Success Criteria for alternative text on images and graphics
By giving a meaningful image the proper alternative text, you meet WCAG success criterion 1.1.1 Non-text Content (level A).
Related pages in this documentation
- 7 Quick wins in Start with accessibility.
- Alternative text for images in the content in Standards and best practice, Content and images.
- Images as links in Standards and best practice, Content and images.
- Alternative text for images, SVGs and icons in development in Standards and best practice, Frontend code.
- First published: October 10, 2025
- Last updated: August 04, 2026
- Edit article: Improve it on GitHub
- Contributors: Amber Hinds, Joe Dolson.
Other pages in: Theme accessibility-ready guidelines
-
Skip to Content Link
The requirements for a Skip to Content link on accessibility-ready themes.
-
Meaningful landmark roles and names
Accessibility-ready themes requirements for meaningful landmark roles and names
-
Keyboard navigation support
The requirements for keyboard navigation in accessibility-ready themes
-
Controls with accessible names, roles, and states
Accessibility-ready theme requirements for accessible controls
-
Labeled form fields
Accessibility-ready theme requirements for how to label form fields
-
Headings with meaningful structure
Accessibility-ready theme requirements for how to use headings
-
Underlined links in text
Accessibility-ready theme requirements for how to indicate links in text
-
No ambiguous link text
Accessibility-ready theme requirements for ambiguous link text
-
Sufficient color contrast of text and UI controls
Color contrast requirements in accessibility-ready themes
-
Accessible audio, video, and animations
Support for audio, video, and animations in accessibility-ready themes
-
Support for reflow, resize, and text spacing changes
Requirements for handling reflow, resize, and text spacing in accessibility-ready themes
-
No unexpected changes of context
Requirements for changes of context in accessibility-ready themes
-
No links opening new windows or tabs without warning
Requirements for opening new windows or tabs in accessibility-ready themes
-
Content on hover or focus is accessible
How to handle content revealed on hover or focus in accessibility-ready themes
-
Accessibility statement
Accessibility Statement requirements for Accessibility-ready themes
-
Must not recommend or require inaccessible plugins
Accessibility-ready themes must not recommend or require inaccessible plugins.
-
Screen reader text supported
How screen reader text must be supported on an accessibility-ready theme
Back to: Theme accessibility-ready guidelines
Quick links and main topics
Quick links
Disclaimer: This documentation is intended to help the WordPress community understand and implement accessible practices. It is not a replacement for the official Web Content Accessibility Guidelines. Please read the full disclaimer.