Accessibility makes your blog usable by people with disabilities, whether visual, motor, cognitive, or auditory. It’s the right thing to do, it’s increasingly a legal requirement, and it genuinely benefits every reader through better usability, better SEO, and a better mobile experience. This post is the practical accessibility setup for a WordPress blog.

A blog post with high-contrast text, clear headings, and visible focus states on interactive elements

What accessibility actually means

Accessibility, often abbreviated a11y, means your site is usable by:

  • Blind users, who rely on screen readers.
  • Low-vision users, who need large text and high contrast.
  • Color-blind users.
  • Users with motor disabilities, who may navigate keyboard-only or by voice control.
  • Users with cognitive disabilities, who benefit from clear language and predictable layouts.
  • Deaf users, who rely on captions for video content.

The governing standard is WCAG, the Web Content Accessibility Guidelines. Most legal frameworks currently target WCAG 2.1 Level AA, though WCAG 2.2 is now the current W3C recommendation and adds several new success criteria worth knowing about, even if your jurisdiction’s law hasn’t caught up to it yet.

Why accessibility matters now

  • Legal exposure: ADA lawsuits are common in the US, alongside the EAA in Europe and similar laws elsewhere.
  • Audience size: roughly 15% of the global population lives with some form of disability.
  • SEO: accessibility-compliant sites tend to rank better, since Google rewards the same UX signals that accessibility work improves.
  • Mobile: many accessibility patterns also help small-screen users generally, disabled or not.
  • Voice search: well-structured, semantic content is easier for voice assistants to parse correctly.

Theme choice matters

Some themes are accessibility-ready, a status declared explicitly in their theme metadata. Many others simply aren’t, regardless of how polished they look.

Look for these specifically:

  • A proper heading hierarchy.
  • Skip links, meaning “Skip to content” links for keyboard users.
  • Visible focus styles on interactive elements.
  • Genuinely semantic HTML.
  • ARIA landmarks where appropriate.
  • Sufficient color contrast built into the default palette.

Aurora was built with these fundamentals in mind from the start, alongside other accessibility-conscious themes like the WordPress default themes, Astra, Kadence, and GeneratePress.

If your current theme isn’t accessibility-ready, switching to one that is often ends up easier than retrofitting accessibility onto a theme that was never structured for it.

Headings hierarchy

Headings should describe your page’s actual structure, not just create visual emphasis:

  • H1: the page title. Exactly one per page.
  • H2: major sections of the content.
  • H3: subsections within an H2.
  • H4 to H6: deeper nesting, rarely needed on a typical blog post.

Don’t skip levels, and don’t use headings purely for visual styling. Use them for structure, and let CSS handle appearance separately.

Screen readers let users navigate a page by jumping between headings. A broken heading structure breaks that navigation entirely, even if the page looks fine visually.

Image alt text

Every meaningful image needs alt text describing what’s actually in it.

Good alt text

  • Describes the image itself, not the filename.
  • Stays concise, from a few words to one full sentence.
  • Doesn’t start with “Image of” or “Picture of,” since screen readers already announce it as an image.
  • Includes the key visual information a sighted user would notice.

Bad alt text

  • Left empty when the image is actually meaningful.
  • Just “image1.jpg.”
  • Stuffed with keywords instead of a real description.
  • “Click here” or other meaningless filler text.

Decorative images

Purely decorative images, like background patterns or dividers, should have empty alt text (alt="") so screen readers skip over them entirely rather than announcing something meaningless.

Complex images

Charts, infographics, and complex diagrams need either detailed alt text or a full text alternative somewhere in the surrounding content.

Color contrast

WCAG 2.1 AA requires:

  • 4.5:1 contrast for normal-size text.
  • 3:1 contrast for large text, meaning 18pt or 14pt bold and up.
  • 3:1 contrast for UI elements like buttons and form fields.

Useful tools for checking this:

  • The WebAIM Contrast Checker, which is the industry-standard free tool for this.
  • Chrome DevTools, which has a built-in contrast checker in its color picker.
  • The WAVE browser extension.

Common failures worth checking for specifically: light gray text on a white background, low-contrast button colors, and link colors that sit too close to the surrounding body text.

Keyboard navigation

A simple test: can you use your entire site without touching a mouse?

  • The Tab key should move through every interactive element in a logical order.
  • Enter should activate buttons and links.
  • Escape should close modals.
  • Focus must always be visible, shown as a ring or border around whatever element is currently focused.

Common failures to watch for:

  • Dropdown menus that simply don’t open via keyboard.
  • Modal dialogs that trap focus incorrectly, leaving users stuck.
  • Custom JavaScript controls that bypass keyboard support entirely.
  • CSS that hides focus rings (outline: 0) without providing any visible replacement.

Link text

Link text needs to make sense on its own, out of context. Screen readers can list every link on a page in isolation, and a list of “click here” repeated a dozen times is useless to navigate.

Good examples

  • “Read our pricing page.”
  • “Download the e-book on starting a blog.”

Bad examples

  • “Click here.”
  • “Read more.”
  • “This.”

Forms

Forms specifically need:

  • A visible label on every input field.
  • Labels that are programmatically linked, using <label for="email"> and a matching input id.
  • Required fields clearly marked as such.
  • Error messages that are clear and get announced to assistive technology.
  • Buttons that clearly state what they do, like “Submit comment” rather than a bare “Submit.”

Fluent Forms, WPForms, and Gravity Forms all support accessibility reasonably well once properly configured, though none of them make a form accessible automatically without some attention on your part. Our guide to setting up a WordPress contact form covers the configuration details if you’re starting from scratch.

Quick tip: test your own contact form with the Tab key before you publish it. It takes under a minute, and it’s the single fastest way to catch a form field that’s invisible to keyboard users.
An accessibility audit dashboard showing contrast, alt text, and heading hierarchy checks

Video captions

Video content needs captions:

  • YouTube’s auto-captions exist, but need a manual review pass for accuracy before you trust them.
  • Uploading custom .vtt or .srt files produces meaningfully better accuracy.
  • Vimeo and Wistia both support uploaded caption files as well.

Captions help more groups than you might expect:

  • Deaf and hard-of-hearing users, obviously.
  • Non-native speakers following along.
  • People watching with the sound off, which is most mobile viewers.
  • SEO, since caption text gets indexed by search engines.

Skip links

A “Skip to main content” link appears when a keyboard user tabs into the page, letting them jump past the header and navigation menu straight to the actual content.

Most accessibility-ready themes include this by default. If yours doesn’t, you can add one through a small code snippet or a dedicated plugin.

ARIA landmarks

HTML5 landmark elements, like <header>, <nav>, <main>, <footer>, and <aside>, help screen readers understand your page’s overall structure at a glance.

Use them correctly and consistently. Avoid wrapping everything in generic <div> tags when a semantic element already exists for the job.

Animations and motion

Excessive motion on a page can trigger vestibular disorders in sensitive users.

  • Respect the prefers-reduced-motion media query in your CSS.
  • Avoid autoplay video that includes significant motion.
  • Provide pause controls for any ongoing animation.

Don’t rely on overlay accessibility plugins

A number of companies sell “accessibility overlay” plugins that claim to make your site accessible by adding a single floating widget.

The reality is less convenient: overlays don’t fix the underlying accessibility issues, can actively break assistive technology that was already working, and are widely criticized by the disability community itself.

Lawsuits often continue against sites even after an overlay is installed, since the overlay doesn’t address the actual barriers.

Real accessibility means real fixes to your markup and design, not a widget layered on top.

Accessibility plugins worth using

  • WP Accessibility: a free plugin that fixes common issues like missing skip links, weak focus styles, and missing ARIA landmarks.
  • Accessibility Checker: scans your content and reports specific issues to fix.
  • Sa11y: an editor-side accessibility checker that flags problems as you write.

These genuinely help, but none of them replace good underlying content and design decisions.

Auditing tools

  • WAVE: a browser extension that highlights accessibility issues directly on the page.
  • Axe DevTools: a Chrome and Firefox extension built for deeper auditing.
  • Lighthouse: built directly into Chrome DevTools.
  • Manual testing: use an actual screen reader, like NVDA (free, for Windows) or VoiceOver (built into Mac and iOS), to navigate your own site the way a blind visitor would.

Accessibility statement

Publish an accessibility statement on your site that covers:

  • Your commitment to accessibility.
  • Which standard you’re targeting, typically WCAG 2.1 or 2.2 Level AA.
  • Any known limitations you haven’t fixed yet.
  • How users can report accessibility issues they encounter.

This demonstrates good faith to visitors, and it genuinely helps your legal position if a complaint ever arises. It pairs naturally with the other legal pages covered in our guide to disclosure, privacy, and legal pages every blog needs.

Common quick wins

  1. Add alt text to every image going forward, starting today.
  2. Check contrast across your theme’s actual color palette.
  3. Make sure focus styles are visible on every interactive element.
  4. Add captions to your video content.
  5. Use a genuinely proper heading hierarchy.
  6. Make every link’s text descriptive on its own.
  7. Install the WP Accessibility plugin as a baseline safety net.

Even just these seven moves you significantly closer to real compliance without a major redesign.

What real accessibility work looks like

Accessibility means real users can actually use your blog, not just that a widget claims they can. It requires semantic HTML, descriptive alt text, sufficient color contrast, full keyboard navigability, video captions, and genuinely usable forms. Pick an accessibility-ready theme, use accessibility plugins to catch the common issues automatically, and audit periodically with WAVE or Axe. The WCAG 2.1 quick reference from the W3C is worth bookmarking for whenever you hit a specific edge case. Don’t lean on overlay plugins as a substitute for the real work. That work pays off in genuine audience reach, better SEO, and reduced legal exposure, all at once.