January 20, 2026 · reala11y team

Block Themes and Full-Site Editing: WordPress Accessibility

Block themes and full-site editing change how WordPress builds navigation, headings, and landmarks. Here are the common accessibility pitfalls and how to catch them.

Block themes and full-site editing (FSE) handed WordPress site owners something powerful: the ability to edit headers, footers, and templates visually, without touching a functions.php file. That power comes with a quieter trade-off. The structural decisions that used to live in a developer’s PHP templates now live in block markup that anyone can rearrange. Accessibility regressions that once required a code change can now happen with a drag.

This is not an argument against block themes. It is an argument for knowing where they tend to drift.

Navigation blocks: the markup is good, the defaults are not

The Navigation block generally produces sound markup. It wraps links in a <nav> element and, on mobile, renders a real <button> for the menu toggle with the right ARIA wiring. That is a meaningful step up from many classic-theme menus.

The pitfalls are in how it gets used:

• No accessible name when you run more than one <nav>. A header menu, a footer menu, and an in-content menu all emit <nav> landmarks. Screen reader users navigating by landmark hear “navigation, navigation, navigation.” Give each one a label so they are distinguishable.
• The mobile toggle’s label is editable — and easy to blank out. If a label gets cleared, the hamburger announces as an unnamed button. Confirm it still has accessible text.
• Submenu open/close state. Custom overlay menus sometimes ship without aria-expanded reflecting the real state. The core block handles this; third-party navigation blocks vary.

You can name a navigation region directly in the block’s markup:

<nav aria-label="Primary">…</nav>
<nav aria-label="Footer">…</nav>

Headings: the editor will happily skip a level

In a block theme, headings come from three places — the template, template parts, and post content — and none of them coordinate. The editor lets you set any block to any level, so a Heading block dropped at H4 under an H2 produces a skipped level (an H3 that never existed). Multiply that across reusable patterns and a single page can carry several breaks in its outline.

Two habits prevent most of this:

• Treat heading level as structure, not size. If H2 looks too big, restyle it; do not demote it to H4 to shrink it.
• Watch for multiple H1s. Some block themes render the site title as an H1 and the post title as an H1. One H1 per page is the safer convention.

Our WCAG guides walk through why heading order maps to WCAG 1.3.1 and who it affects.

Landmarks: template parts can quietly drop them

Landmarks are how assistive-technology users skip past the header straight to content. In a well-built block theme, the Header template part maps to banner, the Footer to contentinfo, and the post content sits inside <main>.

FSE makes these easy to lose:

• No <main>. If a custom template renders content as a bare Group block instead of the Post Content block inside a main wrapper, there is no main landmark to skip to — and no visible skip link target.
• Content outside any landmark. Blocks placed between the header and footer parts, but outside the content wrapper, become “orphaned” — present visually, invisible to landmark navigation.
• Duplicate banners. Pulling a Site Title or Logo block into the body can emit a second banner region.

A practical pre-publish pass

Before you ship a block theme or a redesigned template, walk it once with the keyboard and once with a structural lens:

1. Tab through every interactive element. Focus should be visible and move in a logical order. The mobile menu must open, trap focus sensibly, and close on Esc.
2. Check the heading outline. A browser heading-outline extension shows skips at a glance.
3. Confirm one <main> and one banner. View source or use the accessibility tree in your browser’s dev tools.
4. Name every navigation region.

This is also where honesty matters. Automated tooling — ours included — typically detects only about 30–40% of WCAG issues by criteria. A scanner reliably catches a missing <main>, a skipped heading level, or an unnamed <nav>. It cannot tell you whether your link text makes sense in context or whether your focus order is logical rather than merely present. That judgment is human.

Where reala11y fits

reala11y is a code-level remediation engine, not an overlay widget. It scans the rendered HTML your block theme actually produces, flags structural issues like missing landmarks and broken heading order, and applies safe, attribute-level fixes at the source — so screen readers and audit tools see the corrected page, not a JavaScript layer painted on top. The how it works page covers the scan-and-fix model in detail.

That distinction is not academic. WCAG 2.2 reached W3C Recommendation status on 5 October 2023, the European Accessibility Act became enforceable on 28 June 2025, and in April 2025 the FTC’s $1,000,000 order against accessiBe made clear that bolting a widget onto a page and calling it compliant is both legally and reputationally risky. Fixing the markup is the durable path.

The honest takeaway

Block themes and FSE are good for accessibility when you mind the structure they generate. Name your navigation regions, keep headings sequential, and make sure one real <main> exists on every template. A scanner will catch the mechanical failures and a tool like reala11y can fix many of them at the source — but pairing that with a keyboard pass and human review is what actually moves your site toward WCAG 2.2 AA conformance. There is no single switch that gets you there, and anyone selling one is selling the thing the FTC just fined.