Ghost is built around clean, content-first publishing, which gives you a head start on accessibility most platforms don't have. The default editor produces semantic HTML, themes are lean, and there's no plugin sprawl injecting inaccessible widgets. But "content-first" doesn't mean "accessible by default" — a beautiful theme can still ship a 2.5:1 gray-on-white byline, your H2s can skip to H4, and pasted images can land with no alt text at all.
This guide is a concrete walkthrough of Ghost accessibility for publishers: how to evaluate a theme, structure headings in the Koenig editor, write alt text that actually helps, fix vague link text, and check color contrast against WCAG 2.2. These are the issues that show up first in any audit and the ones you control directly from the admin panel.
Why Ghost accessibility starts with the theme
Your theme decides the accessibility ceiling of every post. Ghost themes are Handlebars templates, and the markup they generate is what screen readers, keyboard users, and assistive tech actually consume. A polished design can still hard-code low-contrast text, ship a logo image with no alt attribute, or build a hamburger menu that traps keyboard focus.
Before you commit to a theme — including the default, Source — run these checks on the live demo or your own install:
- Tab through the whole page with the keyboard only. Every link, button, search field, and menu toggle must be reachable, and the focus ring must be visible (2.4.7 Focus Visible, and 2.4.11 Focus Not Obscured added in WCAG 2.2). If focus disappears behind a sticky header, that's a fail.
- Confirm a skip link exists. Good Ghost themes include a 'Skip to content' link as the first focusable element so keyboard users bypass the nav (2.4.1 Bypass Blocks).
- Check the mobile nav toggle. It should be a real <button> with aria-expanded, not a clickable <div>. Toggle it with Enter and Space.
- Inspect the page landmarks: one <main>, a <header>, <nav>, and <footer>. These let screen reader users jump around.
- Verify the {{lang}} helper outputs a real <html lang> value (3.1.1 Language of Page) from your Ghost publication language setting.
If a theme fails these, you can often patch it by editing the .hbs templates and the theme's CSS directly, then re-uploading the zip. The fixes are usually small: adding a skip link to default.hbs, swapping a div for a button, or bumping a CSS color value. If you can't edit code, choose a different theme — themes from the official Ghost marketplace are generally a safer baseline.
Get heading structure right in the Koenig editor
Screen reader users navigate long articles by jumping between headings, so a broken hierarchy makes your content genuinely hard to read. The rule is simple: headings describe structure, not appearance. Don't pick H3 because you want smaller text.
In Ghost, the post title is your H1 — the theme renders it, and you should never add a second H1 inside the body. That means your in-content headings start at H2. The Koenig editor gives you H2 and H3 from the toolbar and the '/' command (type /h2 or /h3). Use H2 for main sections and H3 for subsections nested under them.
The mistakes to avoid:
- Skipping levels — jumping from H2 straight to H4. Levels must not skip going down (H2 → H3 → H4), though you can jump back up.
- Using a heading just to make a line bold or big. Use bold text or a CSS class instead.
- Turning a real section heading into plain bold paragraph text, which hides it from heading navigation entirely.
After drafting, view the rendered post and confirm the outline reads logically top to bottom. A free heading checker will flatten your page into its heading tree so you can spot a skipped level or a stray second H1 in seconds — faster than eyeballing the HTML.
Write alt text that does a job
Every image in the Koenig editor has an alt-text field — click the image, then the small 'Alt' button in its toolbar (or open the image card settings). Ghost does not generate alt text for you, and pasted or drag-dropped images arrive with the field empty. That empty field is the single most common accessibility gap on Ghost blogs.
Write alt text that conveys what the image contributes to the post, not a generic label:
- Informative image: describe the content and its point. 'Line chart showing newsletter signups doubling after the redesign' beats 'chart'.
- Decorative image: if it adds nothing — a background texture, a divider — leave the alt empty so screen readers skip it. An empty alt is correct here; a missing alt attribute is not.
- Image of text (a quote graphic, a screenshot of a tweet): put the actual words in the alt text so the meaning isn't lost.
- Captions vs alt: Ghost captions are visible to everyone and announced too, so don't just duplicate the caption in the alt — they should complement each other.
Keep descriptions concise (roughly a sentence) and skip 'image of' — screen readers already announce it as an image. Then review every published post for images that slipped out with no description, since an empty field is invisible until a screen reader hits it.
Fix vague link text and meet contrast minimums
Two issues sit at the heart of content accessibility, and you control both from the editor.
Descriptive link text
Screen reader users can pull up a list of every link on a page. If half of them say 'click here' or 'read more', that list is useless (2.4.4 Link Purpose). Select meaningful words for the anchor instead: link the phrase 'our 2026 pricing guide', not the bare 'here' after it. Ghost's default 'Read more' card links inherit the post title as context in most themes, but inline links in your prose are on you. Avoid pasting raw URLs as link text too — a screen reader reads the whole string aloud.
Color contrast
WCAG 2.2 requires a contrast ratio of at least 4.5:1 for normal text and 3:1 for large text (18pt, or 14pt bold) and for UI components and meaningful graphics. The usual Ghost offenders are theme-level, not content-level: muted gray metadata (author, date, reading time), placeholder text in the search and subscribe forms, and light-gray button labels. Many themes also style visited or hover link states with too little contrast.
You can't fix most of these from the post editor — they live in the theme's CSS, where you adjust the relevant color variables and re-upload. Test combinations with a contrast checker before you ship, and pay attention to your accent color: brand colors that look fine on a hero image often fail as small text on white. If you offer a dark mode, check it separately — passing in light mode tells you nothing about dark.
Why this matters beyond good practice
Accessibility is increasingly a legal baseline, not a nice-to-have. The European Accessibility Act (Directive (EU) 2019/882) applies from 28 June 2025, and its technical baseline is WCAG 2.2 Level A and AA via the EN 301 549 standard. If your Ghost publication sells subscriptions, courses, or products into the EU, it can fall in scope. In the US, the ADA names no specific WCAG version but is treated as pointing at WCAG 2.1/2.2 AA in practice, while Section 508 and Canada's AODA reference WCAG 2.0 AA.
The good news for Ghost users: a content-first platform plus disciplined headings, alt text, link text, and contrast gets you most of the way to AA. To see where you stand, run your site through a free accessibility scan with AccessScan, then work through the issues in your posts and theme CSS. For the legal side, the EAA overview covers who is in scope and what the WCAG 2.2 baseline means in practice.