Blog accessibility isn't a plugin you install once and forget. It's a set of editorial habits that decide whether a screen reader user, a keyboard-only reader, or someone with low vision can actually read what you publish. Most of it comes down to five things you control in every post.
This guide covers heading structure, alt text, link text, readable typography and contrast, and accessible embeds, with concrete examples and the WCAG criteria behind each. No theory dumps. Just what to fix and how to know it's right.
Heading structure: one H1, no skipped levels
Screen reader users navigate by headings the way sighted readers skim by scanning. Press a single key and a screen reader jumps heading to heading, building a mental table of contents. If your headings are a mess, that map is useless.
Three rules cover almost every blog post:
- One H1 per page, and it's the post title, not your site name. Many themes wrongly mark the logo as an H1.
- Don't skip levels. An H2 can be followed by an H3, but never jump from H2 straight to H4 because the heading looks the right size.
- Headings describe content, not style. Never pick H3 because you wanted smaller text. Use CSS for size; use heading level for meaning.
A common mistake: bolding a line of text to act as a subheading. Visually it reads as a heading, but to a screen reader it's just a bold sentence in the middle of a paragraph, invisible to heading navigation. Use a real <h2> or <h3> element instead. You can scan any post's outline in seconds with our heading checker to catch skipped levels and stray H1s.
Alt text: describe the purpose, not just the picture
Alt text is the text a screen reader announces in place of an image, and the text browsers show when an image fails to load. WCAG 1.1.1 Non-text Content (Level A) requires a text alternative for every meaningful image. The skill is writing alt text that conveys what the image does in context, not cataloguing every pixel.
Three categories cover most blog images
- Informative images (charts, screenshots, diagrams): describe the information. For a revenue chart, write "Bar chart showing revenue rising from $10k in January to $45k in June" rather than "chart."
- Decorative images (background flourishes, dividers): give them an empty alt attribute, alt="". This tells the screen reader to skip them. Leaving alt off entirely makes some readers announce the file name, like "DSC_4837.jpg."
- Functional images (an image used as a link or button): describe the destination or action, not the image, e.g. "Read the full case study."
Don't start with "Image of" or "Photo of" — the screen reader already announces that it's an image. And if an image sits next to a caption that already conveys the same information, an empty alt avoids forcing users to hear it twice. Bulk-check a published post with the alt text checker to find missing or weak alternatives.
Link text: make every link make sense on its own
Screen reader users can pull up a list of every link on a page and tab through them out of context. If your post has eight links that all say "click here" or "read more," that list is meaningless. WCAG 2.4.4 Link Purpose (In Context) (Level A) asks that the purpose of each link be clear from its text, or its immediate context.
Bad: "To learn about our pricing, click here." Good: "See our pricing plans." The link text itself names the destination.
- Avoid raw URLs as link text. A screen reader reading out "h-t-t-p-s-colon-slash-slash" is painful and uninformative.
- Don't use the same link text for different destinations. Two "Learn more" links going to different pages confuse the link list.
- Front-load the meaningful words so the link is identifiable from the first syllable.
If you genuinely need a short visible label like "Read more," extend it for assistive tech with a visually hidden span or an aria-label, e.g. aria-label="Read more about blog accessibility." The sighted reader sees "Read more"; the screen reader hears the full context.
Typography and contrast: readable by default
Plenty of blogs are unreadable not because of missing features but because the body text is light grey on white at 14px. Two WCAG criteria govern this.
Contrast (1.4.3 Contrast (Minimum), Level AA): body text needs a contrast ratio of at least 4.5:1 against its background. Large text — at least 18pt, or 14pt bold — needs 3:1, as do user interface components and graphical objects. A trendy light grey like #999 on white falls well short of 4.5:1 and fails. Check any color pair with our contrast checker before you commit to a palette.
Text spacing (1.4.12 Text Spacing, Level AA): your layout must not break when users override spacing. Specifically, content should still work with line height set to 1.5 times the font size, paragraph spacing to 2 times, letter spacing to 0.12 times, and word spacing to 0.16 times the font size. If increasing line spacing causes text to clip or overlap, you fail.
- Set body text to at least 16px and use relative units (rem) so browser zoom and user font-size settings work.
- Use real paragraph spacing, not single line breaks, so the rhythm survives reflow.
- Never disable pinch-zoom on mobile with user-scalable=no — that blocks a core accessibility feature.
Accessible embeds: videos, social posts, and iframes
Embeds are where blog accessibility quietly breaks, because the content lives in someone else's iframe. A few habits keep them usable.
- Give every iframe a title attribute describing its content, e.g. title="YouTube video: How to write alt text." Screen readers announce this; an untitled iframe is announced as just "frame."
- For embedded video, captions are not optional. WCAG 1.2.2 Captions (Prerecorded) (Level A) requires captions for prerecorded video with audio. Auto-captions are a starting point, not a finish line — review them for accuracy.
- Avoid autoplay with sound. Audio that starts on its own and runs longer than three seconds must have a pause or stop control (WCAG 1.4.2 Audio Control, Level A).
- For embedded social posts or code sandboxes, provide a text summary or link nearby, so the meaning survives even if the embed fails to load or is unreachable by keyboard.
Test embeds the way affected users do: unplug your mouse and try to reach and operate every interactive element with Tab, Enter, and arrow keys. If a video player or carousel traps focus or can't be reached, that's a blocker.
Why this matters beyond good manners
Accessibility overlaps heavily with SEO: semantic headings, descriptive alt text, and clear link text are exactly what search crawlers parse too. It's also increasingly a legal baseline. The European Accessibility Act (Directive (EU) 2019/882) applies from 28 June 2025 and, through the harmonised EN 301 549 standard, points to WCAG 2.2 Level A and AA as the technical benchmark; if your blog supports a covered product or service, those criteria apply. See our overviews of the European Accessibility Act and WCAG for the wider picture.
You don't need to memorize success criteria to ship an accessible post. Write one H1 and never skip levels, describe images by purpose, name your links, keep contrast at 4.5:1, and title and caption your embeds. When you're ready to verify a live post, run a free scan to catch what slipped through.