BLOG · GHOST · EAA

Ghost Accessibility:
Making Publications EAA-Compliant

Theme fixes, content habits, and membership-flow checks that bring a Ghost site up to WCAG 2.2 AA — without rebuilding it.

Start Reading WCAG 2.2 Guide → →

Updated August 2026 · Reading time: 6 minutes

ghost-and-the-eaa

Ghost runs newsletters, paid publications, and membership sites — exactly the kind of services the European Accessibility Act covers when they operate commercially in the EU. Since 28 June 2025, e-commerce-like services and consumer-facing digital services must be perceivable, operable, understandable and robust (the four WCAG principles). For a Ghost publisher that means the theme, the article content, and crucially the signup and checkout flows all need attention. The good news: a modern Ghost install has fewer moving parts than most platforms, so reaching WCAG 2.2 AA is genuinely achievable.

theme-level-checks

Most Ghost accessibility problems live in the theme, not the core. Work through these:

🎨 Colour Contrast

Many magazine-style themes use light-grey text on white or text over gradient hero images. Body text needs 4.5:1; large headings 3:1; form inputs and icons 3:1. Fix in the theme CSS or custom settings once, benefit everywhere.

⌨️ Keyboard & Focus

Test tabbing through header navigation, post cards, and the member portal. Dropdown menus and card overlays are the usual traps. Ensure :focus-visible styles exist and are clearly visible.

🖼️ Images & Cards

Post-card thumbnails rendered as background-image divs carry no alt text. Prefer img elements fed from the post feature image, with meaningful alt text inherited from the post.

🔤 Typography & Zoom

Verify the layout survives 200% browser zoom and 320px width without horizontal scrolling (WCAG 1.4.10). Fluid type systems in newer themes handle this well; older ones break.

🧭 Structure

One h1 per page (the post title), logical heading levels inside articles, a skip-to-content link, and a proper lang attribute set by the theme.

koenig-content-habits

Ghost's Koenig editor produces clean HTML by default — better than most rich-text editors — but authors can still create inaccessible content:

Alt text: the image card prompts for alt text but nobody is forced to fill it. Make it an editorial rule: every informative image gets descriptive alt text; decorative images get explicitly marked as such.

Embeds: YouTube, Twitter/X and other embed cards inject iframes you do not control. Give embed cards a preceding sentence that describes what the reader will see/hear, since iframe content is opaque to your own markup.

Heading discipline: writers coming from Word use bold text instead of headings. Screen-reader users navigate by heading lists — an article with no real h2s is unnavigable.

Link text: avoid bare "here" and "this article". Link text should survive being read out of context.

Galleries and captions: ensure gallery images each have alt text, not just a collective caption.

membership-flows

This is the part unique to Ghost and easy to miss. Signup, login, checkout and account-management pages are user journeys, and under the EAA a payment flow that cannot be completed by assistive technology users is a compliance failure — not just a WCAG nitpick. Check that: email input and error messages are properly labelled and announced (error text associated with the field via aria-describedby); the Stripe checkout Ghost hands off to is configured with accessible branding settings; magic-link emails have meaningful link text ("Open your login link", not just "Click here"); and the member portal renders usable with keyboard alone. Test the full journey yourself with a screen reader once — it takes twenty minutes and reveals more than any automated tool.

verification-loop

A repeatable QA loop for a Ghost site:

1. Automated scan of home, a tag page, a full post, /#/portal and signup pages. Static scanners catch the mechanical layer fast — expect them to find contrast, alt-text, and heading issues on the first run.

2. Keyboard pass through nav, post list, article, comments (if enabled), and the complete signup-to-checkout journey.

3. Screen-reader sample: one article start-to-finish with VoiceOver or NVDA, plus the signup flow.

4. Statement: publish an accessibility statement with conformance status, known limitations, and a contact channel. Commercial publishers in scope of the EAA should have this visible from the footer.

5. Regression habit: re-run the automated scan after every theme update or new release — themes change more often than people expect, and regressions are silent.

Going Deeper

Start with a free automated scan of your Ghost site — it finds the mechanical WCAG failures (contrast, missing alt, heading order, unlabelled buttons) across all your key pages in one run.

Scan Your Ghost Site Free → → WCAG 2.2 Guide → →

Frequently Asked Questions

Does the EAA really apply to newsletters and blogs?

If the service is consumer-facing and commercial — paid subscriptions, e-commerce of digital products — yes. Free personal blogs generally fall outside the EAA, but WCAG-compliant publishing costs little and protects reach; there is rarely a reason not to fix the basics.

Is Ghost itself accessible out of the box?

Ghost core is reasonably solid: clean HTML output, labelled portal components, decent defaults. The dominant sources of defects are third-party themes and author content habits, which is why theme review and editorial rules matter more than platform choice.

My theme has no focus styles. Quick fix?

Yes — add :focus-visible { outline: 2px solid currentColor; outline-offset: 3px; } in Code Injection. It respects the theme palette and restores visible keyboard focus site-wide in one line.

Can I automate Ghost accessibility checking?

Partly. Automated tools catch roughly 30-50% of issues — contrast, missing alt, structure, labels. Keyboard operability, meaningful alt descriptions, and embed accessibility require human review. Combine both: scan automatically after each theme change, review manually per release.

Does fixing accessibility help SEO?

Several accessibility signals overlap with SEO: proper heading hierarchy, descriptive link text, alt text, fast semantic HTML, mobile-friendly layouts. Accessibility work tends to improve crawlability and rankings as a side effect, though it should be done for users first.