Accessibility isn’t just a buzzword—it’s a fundamental part of building inclusive websites. With WordPress powering millions of sites, ensuring every visitor can access your content is essential. That’s where WCAG 1.1.1: Non‑Text Content comes in. This key guideline ensures all non-textual elements—like images, icons, buttons, audio, and video—have a text alternative that conveys the same meaning.
Let’s start with the basics:
WCAG 1.1.1 (Level A) is crystal clear: “All non-text content that is presented to the user has a text alternative that serves the equivalent purpose.” Any image, icon, chart, or multimedia element must provide a text-based description to make the content perceivable across different modalities, from screen readers to braille displays.
Regulations like the Americans with Disabilities Act and the European Accessibility Act hold websites to these accessibility standards.
WordPress sites frequently rely on visual elements—images, audio, graphics—to tell stories or guide users. But without proper alternatives, these elements become invisible to users with disabilities.
Beyond accessibility, alt text helps search engines understand visual content, enhancing SEO and making your site more discoverable.
Here are some practical steps to provide Alt text for non-text content:
- Write Meaningful Alt Text for Images
Every image block in the WordPress editor includes an “Alt text” field. Use it to describe what the image means in its context—not just what’s visually present. Keep alt text concise—think tweet length at most.
Avoid “image of…” or leaving it blank for meaningful visuals. That falls short of equating the text alternative with the purpose provided by the image.
- Hide Decorative Images from Assistive Tech
Not all visuals are meant to convey meaning. Decorative flourishes or background patterns should use alt=”” so screen readers ignore them. Many themes and the Block Editor handle this automatically—just be sure the attribute exists.
- Make Icons Accessible
Icons and SVGs often carry functional meaning—like “delete” or “search.” These must have accessible names via aria-label, aria-labelledby, or visible but screen-reader-only text. For decoratives, use aria-hidden=”true” so users aren’t reading irrelevant content.
- Text Alternatives for Audio and Video
Media elements need context too. For example, adding a caption like “Briefing with our Director” to a video thumbnail gives users enough info to decide if they want to play it.
- Label Icon-Only Buttons Clearly
Common UI patterns—like a search icon or a food menu—must be explicitly labeled. Use hidden text or ARIA attributes to ensure that screen readers convey their purpose. Plugins like Screen Reader Text Format can assist you in block editor setups.
- Offer Accessible CAPTCHA Alternatives
CAPTCHAs can block bots—but they often exclude users with disabilities. Provide alternative options like audio challenges or invisible/honeypot fields that don’t interrupt the user experience.
Understanding Exceptions to the Rule
WCAG 1.1.1 does allow for some exceptions:
- Controls and inputs (e.g., image buttons) need an accessible name, not a full visual description (e.g., label “search,” not “magnifying glass icon”)
- Time-based media, like video or audio, demand descriptive labels—not full descriptions, which fall under later success criteria.
- CAPTCHAs need a purpose-based description and alternate access methods.
- Purely decorative content: use alt=””, CSS, or appropriate markup so assistive tech ignores it.
Testing Your Site’s Compliance
Use the Accessibility Checker plugin
This WordPress plugin scans for common issues like missing or empty alt text, long or low-quality alt text, and more. It provides real-time feedback within your editor.
Try a screen reader
Tools like NVDA, VoiceOver, or TalkBack let you experience your site from a non-visual perspective. This manual method catches nuances automated tools might miss.
Inspect your code
Use your browser’s developer tools to inspect images, icons, and controls. Check for presence of alt, aria-label, and proper markup—especially in custom themes or page builders.
WCAG 1.1.1 isn’t just a technical requirement—it’s the foundation of inclusive design. Start small: audit your media, add missing alt text, label icon buttons. Then use tools like the Accessibility Checker and screen readers to maintain accessibility as your site grows.
You do not know where to start? Contact us today for a free website audit.