This post is part of a series where we explain Web Content Accessibility Guidelines (WCAG), an internationally recognized standard for measuring website accessibility. For more posts in this series, visit our Web Accessibility WCAG 2 Knowledge Base.
When building a WordPress website, accessibility often begins with ensuring that all content is understandable to every user, regardless of their method of accessing the site. WCAG 1.1.1 Non-text Content is one of the foundational accessibility requirements, and it’s the first checkpoint in the WCAG guidelines, ensuring that all visual and non-text elements have an equivalent text alternative.
In this article, we’ll break down what WCAG 1.1.1 means, why it’s important, common mistakes in WordPress, and how you can meet this success criterion using WordPress tools and best practices.
What is WCAG 1.1.1 Non-text Content?
The Success Criterion 1.1.1 Non-text Content (Level A) states:
All non-text content that is presented to the user has a text alternative that serves the equivalent purpose, except for the specific situations [outlined in the guidelines].
Web Content Accessibility Guidelines 2.2
In plain language: Any content that isn’t text—such as images, icons, charts, buttons, or audio—must have a text alternative so that users who can’t see, hear, or perceive it in the intended way can still access the same information or functionality.
The exceptions (content that doesn’t need a text alternative) are:
- Controls and input fields
- Videos with their own text alternatives.
- Images that are part of a test.
- Content that creates a specific sensory experience.
- Captchas
- Images that are purely decorative.
These exceptions are described in greater detail below.
Article continued below.
Stay on top of web accessibility news and best practices.
Join our email list to get notified of changes to website accessibility laws, WordPress accessibility resources, and accessibility webinar invitations in your inbox.
Why WCAG 1.1.1 Matters for WordPress Websites
Laws around the world, like the Americans with Disabilities Act and the European Accessibility Act, require websites to be accessible. These laws apply to WordPress websites for organizations in both the private and public sectors.
Many WordPress sites rely heavily on images, media, and visual design elements. Without proper text alternatives:
- Screen reader users won’t know what an image or icon represents.
- Users with low vision may not be able to see graphics or visual cues.
- Users who can’t hear audio content will miss important information.
- Assistive technology users may be distracted by decorative elements that aren’t properly hidden.
Text alternatives are powerful because they can be read aloud, displayed visually, converted to braille, or translated into other languages, ensuring your WordPress content is truly accessible.
Providing text alternatives also has the added benefit of making your website more readable by search engines, which can help with indexing and ranking. Text alternatives can help bring more people to your website and ensure that they all stay on it with the ability to access all the content.
How to Meet WCAG 1.1.1 in WordPress
Use Meaningful Alt Text for Images
Images are one of the most common types of non-text content in WordPress, and they require thoughtful alt text to meet accessibility requirements.
In the Block Editor, each image block includes an “Alt text” field in the sidebar settings. This is where you should write concise, descriptive alt text that conveys the purpose of the image in its context.
If you use other WordPress page builders, the alternative text will be edited in a different spot, but they all have support for adding alternative text. Reference documentation for your builder if you cannot find the alt text field.
When writing alternative text for images, make sure you concisely communicate the key visual information in the image. It’s best to keep the alternative text tweet length or shorter.
For example, the image above might be described in this way, “A group of five diverse students in the library; three are smiling and looking at a laptop while a young man and woman high-five behind them.”
Avoid including text like “image” or leaving the field blank for meaningful images, as these approaches fail to provide equivalent information to users who rely on assistive technologies.
Learn more about writing good alternative text:
- Webinar: when and how to write alternative text
- Accessibility Checker documentation on writing alt text
- Guidance on alt text length
Hide Decorative Images from Assistive Technology
Not all images need alt text. Decorative elements—such as flourishes, borders, or purely aesthetic icons—should be hidden from assistive technology to prevent cluttering the user’s experience. In WordPress, you can do this by leaving the alt text field empty for decorative images.
Many themes and the Block Editor automatically add alt="" in this case, which instructs screen readers to skip the image. This ensures that only relevant information is conveyed. If you want an image with empty alternative text to also be ignored by accessibility auditing tools like Accessibility Checker, also add role="presentation".
Note if you are custom coding in WordPress: it is not correct to leave out the alt attribute completely. This will cause the screen reader to read the file name or announce the image as unlabelled. Missing alt attributes are an accessibility failure.
Make Icons and SVGs Accessible
Icons and SVGs often carry essential meaning, such as indicating actions (like edit or delete) or statuses (like success or error). When an icon conveys meaning, provide an accessible name so that screen reader users can understand its purpose. This can be done using attributes like aria-label, aria-labelledby, or title, depending on the context. If using an image block to insert the icon, the alternative text field can be used.
On the other hand, if an icon is purely decorative—used for visual enhancement only and not intended to communicate anything to the user—it should be hidden from assistive technology. The best way to do this is by adding aria-hidden="true" to the SVG or its container. This ensures screen readers skip over it and focus only on meaningful content.
Add Text Alternatives for Audio and Video Thumbnails
For audio and video content, a text alternative helps users identify what the media contains. In WordPress, this could mean adding a caption to a video block or including a transcript link in the post content. While WCAG 1.2 covers detailed captioning and description requirements, 1.1.1 ensures users can understand what the media is before they play it.
For example, a video thumbnail that shows before the video loads might include a description such as “Load Video: Accessibility in WordPress”.
Ensure Image and Icon Buttons Have Accessible Labels
Icon-only buttons, such as a search icon or hamburger menu, are common in modern WordPress designs. These controls must have accessible names so their purpose is clear to all users.
To ensure accessibility, every interactive icon must have a clear, programmatically associated label that describes its function. This allows assistive technologies to convey the purpose of the button to users who cannot see or interpret the visual icon.
In some cases, the WordPress theme or plugin may already add accessible labels using techniques like:
- Visually hidden text (e.g., using a
.screen-reader-textclass) placed inside the button but hidden from visual view. aria-labelto describe the button’s function.aria-labelledbyto reference another element that serves as the label.
If you’re adding icon-only buttons in a page builder, then you will need to provide the screen reader text or aria-label to provide meaning. There may be settings for doing this in the editor or you may need to insert this text with custom code.
The Screen Reader Text Format plugin is helpful if your website is built in the block editor.
Choose Accessible CAPTCHA or Alternatives
If your WordPress site uses CAPTCHA, it’s essential to provide multiple ways for users to verify they’re human. Many form plugins offer accessibility-friendly options such as audio CAPTCHAs. Using invisible CAPTCHA or honeypot fields is most recommended because they work in the background to block bots without the user needing to do anything.
WCAG 1.1.1 Exceptions
As noted above, WCAG defines specific exceptions for the Non-text Content success criterion. The Non-text Content success criterion requires that all non-text content be given a text alternative that serves the equivalent purpose, so that users who cannot perceive the content visually can still access the same information or function.
However, there are some cases where providing a complete text alternative is not appropriate or feasible, and that’s why these exceptions exist. Here’s an explanation of each and why it qualifies as an exception.
Controls and Inputs
When non-text content is part of a control, such as an image button or icon, it must have an accessible name that describes its purpose.
The purpose of controls or inputs is functional, not informational. Instead of describing every visual aspect of a button or slider, users only need to know what the control does (its accessible name).
Examples of this we commonly see on WordPress websites:
- Logos linked to the home page: alternative text should name the page being linked to, not describe the logo. I.e., “Equalize Digital home page” is correct, not “Blue Equalize Digital Logo”.
- A search button with a magnifying glass icon: alternative text should be “search”, not “magnifying glass”.
Time-Based Media
Time-based media includes audio and video content, such as podcasts or tutorials embedded in WordPress. These elements need a descriptive label so users know what they are before interacting, but it can be simplified.
Example: Video thumbnail labeled “Interview with CEO” which names the video rather than describing the CEO and setting shown in the thumbnail image.
Detailed captions and transcripts are addressed in later WCAG criteria, but 1.1.1 ensures the media is clearly identified.
Tests and Exercises
Some tests or exercises, such as a hearing test or a visual puzzle, cannot be fully represented in text without losing their function. If a visual item is the thing being tested, then describing it could defeat the purpose of the test.
For example, in a math test that asks a student to identify a shape visually. If a screen reader user received a text saying “triangle”, it would give away the answer.
In WordPress learning management (LMS) setups, if you are creating quizzes that rely on images in questions or answers, you have to be thoughtful about how images are described so that they don’t give screen reader users an unfair advantage over sighted learners.
Sensory Content
Sensory content is designed to create a specific experience, such as artwork, photography, or musical performances. In WordPress, galleries of artwork and audio players should include a brief description explaining the content’s purpose. However, it may not be possible to truly describe the mood or feelings that the content evokes.
While text can’t replicate the experience, it should explain why the content is there. For example, alt text on an image of an abstract painting might say, “Abstract swirling colors representing chaos.”
CAPTCHA
CAPTCHA is used to distinguish humans from bots, but visual or audio CAPTCHAs can be barriers for some users. This often requires presenting something that cannot be easily described in text (like warped letters), and providing accurate alternative text may allow bots to solve the problem as well, weakening security or spam-protection.
In WordPress forms, a CAPTCHA should have an alternative text description of its purpose such as “CAPTCHA.” There must also be an alternative verification method, like audio challenges.
Decoration, Formatting, and Invisible Content
Decorative elements, such as background patterns or spacer images, don’t need to be announced by assistive technology.
In WordPress, these should have empty alt attributes (alt="") or be added with CSS as background images. This prevents screen readers from announcing unnecessary details that could confuse users.
Testing 1.1.1 Compliance in WordPress
Using a WordPress Accessibility Checker Plugin
One of the easiest ways to test for WCAG 1.1.1 compliance in WordPress is with our Accessibility Checker plugin. This plugin scans your site content and flags any missing or empty alt text, as well as other accessibility issues. These are the issues related to 1.1.1 Non-text Content that Accessibility Checker flags:
- Image Missing Alternative Text
- Linked Image Missing or Empty Alternative Text
- Image Empty Alternative Text
- Image Long Alternative Text
- Low-quality Alternative Text
Because Accessibility Checker runs directly in the WordPress dashboard, it’s ideal for ongoing testing as you publish new posts and pages. Accessibility Checker will give you real-time feedback, track changes over time, and also provides automated fixes for common problems.
Testing with a Screen Reader
Screen readers like NVDA (Windows), VoiceOver (macOS and iOS), and TalkBack (Android) provide an authentic way to experience your site as a non-visual user would. By navigating through your WordPress site with a screen reader, you can confirm whether images, buttons, and other non-text elements have meaningful text alternatives. This method can reveal issues that automated tools might miss, such as unclear button labels or confusing icon descriptions.
Take an online course to learn screen reader testing
If you want to learn more about how to use a screen reader for accessibility testing, check out our online courses. These courses include detailed instructions on how to use a screen reader, what keyboard shortcuts to know, recommended settings for testing, and good and bad examples of multiple different components so you know what to listen for.
Inspecting Elements in Browser Developer Tools
Browser developer tools allow you to inspect the underlying code of your WordPress site. By right-clicking on an image or control and choosing “Inspect,” you can check for alt attributes, aria-labels, and whether decorative images are correctly marked with alt="". This manual review helps verify that accessibility best practices are implemented as intended, especially in custom themes or page builder layouts.
Start Making Your WordPress Site Accessible Today
WCAG 1.1.1 Non-text Content is one of the foundational steps to ensuring that your WordPress site is accessible. By providing meaningful text alternatives for non-text elements, hiding decorative content from assistive technologies, and regularly testing your site, you create a better experience for everyone.
Accessibility in WordPress doesn’t have to be overwhelming. Start with small, consistent steps. Review your existing content, update image alt text, and ensure controls are labeled. Then, keep accessibility in mind as you create new posts, pages, and designs.
To simplify the process, consider using tools like the Accessibility Checker plugin and learning how to test your website with a screen reader to identify issues before they become barriers. Each improvement you make moves your site closer to full WCAG compliance and a better experience for all visitors.
