Gutenberg Accessibililty – How Accessible Is the WordPress Editor

The Gutenberg Block Editor introduced a block-based way to create content in WordPress, allowing text, media, and layouts to be added visually without writing code. This made content creation more flexible and approachable for a wide range of users.

However, the accessibility of the editor has been a concern since its introduction. This refers to the ease with which people with disabilities can create and edit content in Gutenberg. This guide examines the editor’s accessibility and offers tips for creating accessible content.

A Brief History of Gutenberg and Accessibility

The Gutenberg Block Editor became the default WordPress editor in 2018.

It replaced the Classic Editor with a block-based approach that lets content creators build pages using individual content blocks instead of a single text field. This shift made it easier to create rich layouts without code, but it also introduced new accessibility challenges.

This led accessibility experts to raise serious concerns.

In October 2018, the WordPress Accessibility Team published a report noting that the editor interface was difficult to use for people relying on keyboards and screen readers, and described parts of the experience as an accessibility regression compared to the Classic Editor.

Some of the early issues included:

• Inconsistent keyboard navigation
• Complex, non-native interaction patterns
• A steep learning curve for screen reader users
• High cognitive load due to multiple toolbars and changing contexts

These concerns were reinforced by independent testing. In early 2019, an accessibility audit commissioned by WPCampus found “significant and pervasive accessibility problems” in Gutenberg and confirmed that the editor did not initially meet all WCAG 2.1 success criteria.

These early accessibility concerns helped bring greater attention to the needs of users relying on assistive technologies. Since then, accessibility improvements have been steadily incorporated into the block editor, making Gutenberg more usable over time.

---

The Current State of Gutenberg Accessibility

Gutenberg has improved a lot since its early releases. Many accessibility issues raised in 2018 and 2019 have been addressed through ongoing updates and community feedback.

However, some challenges persist. These are largely tied to the editor’s core design, which is built around independent blocks with custom interaction patterns. Below are some of the most common issues, though this is not an exhaustive list.

Issue #1. High cognitive load from the block-based interface

The block-based design introduces many moving parts at once. Each block can have controls in a top toolbar, additional options in menus, and settings in the right sidebar.

For non-visual users, this creates a heavy mental load. Controls are not in one consistent place, and their location changes based on the selected block. Remembering where to find things becomes harder without visual context.

---

Issue #2. Confusing keyboard expectations due to writing flow

Gutenberg supports a feature called writing flow.

Arrow keys can move between blocks, not just within text. For keyboard and screen reader users, this can break expectations. Pressing the Up or Down Arrow may suddenly move focus into another block or even an empty one, without warning.

This kind of silent context change makes it harder to stay oriented. It increases frustration, especially when working on long posts with many blocks.

---

Issue #3. Focus loss after interface updates

Gutenberg relies heavily on dynamic updates. Blocks re-render, panels open, and toolbars change as users interact with the editor.

When these updates occur, keyboard focus is not always restored in a predictable way. Users may suddenly land in a different part of the editor, such as the sidebar or top toolbar, without any clear signal that focus has moved.

A screen reader user demonstrated this issue while exiting a toolbar. After pressing Escape, focus appeared to disappear entirely. The screen reader announced confusion about where focus went, and no clear location was communicated. The user was left unsure whether they were still inside the editor, inside content, or somewhere else altogether.

---

Issue #4. Sidebar controls are hard to locate without sight

The settings sidebar holds many important options, but opening it does not always move focus to the new panel. Keyboard users may activate the sidebar but remain focused elsewhere. They must then Tab through many elements to reach controls that have already opened.

---

Classic Editor vs Gutenberg: Accessibility Comparison

The Classic Editor is built around a single text area with one consistent toolbar, which makes keyboard navigation and screen reader use more predictable.

Gutenberg replaces this with individual blocks, each with its own controls and interaction patterns, increasing flexibility but also adding complexity for users.

Below is a comparison of the Classic Editor and Gutenberg from an accessibility perspective.

	Classic Editor	Gutenberg Block Editor
Editing model	Single text field	Multiple interactive blocks
Keyboard navigation	Linear and predictable	Fragmented across blocks and panels
Screen reader experience	Familiar form-style behavior	Requires learning block concepts and modes
Cognitive load	Low	High
Discoverability	Simple and consistent	Many controls are hidden behind menus
Focus management	Stable	Can shift unexpectedly
Learning curve	Low	Steep for many users

Overall, the Classic Editor was more accessible by default. Its simple structure, predictable behavior, and use of standard form controls made content creation easier for people with disabilities. Users could write, edit, and navigate content with fewer surprises and less cognitive effort.

---

How to Ensure Accessible Content with Gutenberg Block Editor

The Gutenberg Block Editor has improved significantly over time, but accessibility does not happen automatically. Even with a more accessible editor, the way blocks are used and content is structured plays a major role in how usable a page is for different users.

Accessibility is influenced by everyday content decisions, such as how media is described, how information is grouped, and how easy the content is to read and understand. These choices affect users who rely on screen readers, keyboards, or have cognitive or attention-related needs.

The sections below focus on common Gutenberg blocks and highlight practical ways to use them so that the content is clearer, more usable, and more accessible.

---

#1. Audio Block

The Audio block allows you to embed sound-based content such as podcasts, interviews, or announcements. To ensure this content is accessible, there are two key things to keep in mind when adding the block.

Add a descriptive caption

Without a caption, users have no context about what the audio contains before playing it. This can be confusing for screen reader users as well as sighted users scanning the page. A descriptive caption helps users understand the purpose of the audio and decide whether it is relevant.

Keep autoplay turned off

Autoplaying audio can interrupt screen readers and overwhelm users by playing sound without warning. It can also be distracting for users with cognitive or attention-related disabilities. Keeping autoplay turned off ensures users stay in control of when the audio plays.

Provide a transcript

Audio-only content should include a transcript so users can access the information without listening. Transcripts help deaf and hard-of-hearing users, as well as users who prefer to read or cannot play audio in their current environment.

Since the Audio block does not natively support transcripts, you can add the transcript as plain text below the audio player. You can also link to a separate transcript page or place it inside a collapsible section, such as an accordion.

---

#2. Buttons Block

The Buttons block is commonly used for calls to action such as downloads, sign-ups, or navigation. Because many users navigate pages by buttons, the button text should clearly indicate where clicking the button will take them or what action will happen next.

Use descriptive button labels

Buttons with vague labels like “Click here” or “Learn more” do not provide enough context on their own. Screen reader users often browse a page by jumping between buttons and may hear the same label repeated multiple times with no indication of what each button does.

---

#3. File Block

The File block is commonly used to share documents such as PDFs, reports, or resources for download. The file name plays a critical role in accessibility, as it communicates what the file is about to both screen reader users and sighted users.

Write file names that describe the content

Give files a clear, descriptive name before uploading so users can understand what the file contains. This helps them decide whether the file is relevant, similar to how clear link text or button labels work. Screen reader users often hear the file name before downloading the file.

---

#4. Image Block

The Image block is used to add visual content such as photos, illustrations, charts, and graphs. To ensure images are accessible, content creators need to be mindful of how images are described and how that information is presented to users who cannot see them.

Add meaningful alt text

Alt text allows screen readers to describe images to users who cannot see them. It should focus on the meaning or message of the image, not just its appearance, and avoid unnecessary visual details that do not add to understanding the content.

Avoid duplicating alt text and captions

When both a caption and alt text are provided, screen readers may announce the caption first and then read the image and its alt text. If both contain the same information, users may hear the same description twice.

To avoid repetition, use alt text and captions only when they provide different information. If the caption already explains the image, the alt text can be left empty. If the image needs a brief description and the caption adds context, use both without repeating the same content.

Add text explanations for charts and complex visuals

For complex images, use a brief alt text to identify the visual and provide a longer text explanation that communicates the key information shown. This explanation can be placed near the image or linked from a separate page, as long as the relationship is clear.

---

#5. Headings Block

Headings are one of the most important accessibility features on any page. They help sighted users scan and understand content quickly, and allow screen reader users to navigate by jumping between headings, rather than listening to the page from beginning to end.

Use headings to create a clear outline

Headings should follow a logical hierarchy, starting with a single H1 for the page title, followed by H2s for major sections and H3s for subsections.

Correct structure:

• H1: Page title
• H2: Main section
• H3: Subsection within that section

Avoid skipping levels, such as jumping from H2 directly to H4, as this can confuse users navigating by headings.

Do not use headings for visual styling

Headings should not be chosen based on how large or bold they appear. Screen readers rely on heading levels, not visual size. Using a heading only to make text “look bigger” creates a misleading structure for assistive technology users.

---

#6. Paragraph Block

The Paragraph block is the most commonly used block for written content. How paragraphs are structured has a direct impact on readability and cognitive load, especially for users who rely on assistive technologies.

Keep paragraphs short

Long paragraphs can be difficult to process and navigate, particularly for users with cognitive disabilities, ADHD, dyslexia, or memory-related challenges. Break content into shorter paragraphs to help users understand information more easily and reduce cognitive load.

As a general guideline:

• Aim for 15–20 words per sentence where possible
• Keep paragraphs to 3–4 sentences or fewer
• Write at a Grade 6–8 reading level

---

#7. Table Block

The Table block is used to present structured data such as comparisons, schedules, or lists of values. While tables can be useful, large or complex tables can be difficult to navigate using assistive technologies.

Avoid large and complex tables

The current Gutenberg Table block does not support scope attributes, which are used to indicate whether a header applies to a row or a column. Without this information, larger tables are harder for screen reader users to understand.

As tables become larger or more complex, consider whether a table is the best format at all. In some cases, replacing a table with clear headings followed by structured lists communicates the same information more effectively.

When a table is still needed, keeping it small and adding a brief text summary before it can help screen reader users understand the relationships being presented.

Add a descriptive table caption

Without a caption, users, especially screen reader users, may start navigating a table without understanding its purpose, making rows and cells harder to interpret. Add a short, descriptive caption that explains what the table represents and what kind of information users will find in it.

Use the header section for column headings

By default, the Table block does not enable a header section, even when the first row contains column headings. Enable the header section in the block settings and place all column headings inside it so screen readers can identify them correctly.

---

#8. Video Block

The Video block is used to embed video content directly into a page. To ensure videos are accessible, users must be able to understand the content and control how it plays.

Add a descriptive video caption

The caption helps users understand what the video is about before playing it. Without a caption, users, especially screen reader users, may encounter a video player with no context. Add a short caption that clearly explains the purpose or topic of the video.

Add closed captions using text tracks

Use the Text tracks option to add closed captions or subtitles to your video. This helps users who are deaf or hard of hearing and supports viewers who cannot play audio or are watching in sound-restricted environments.

Keep autoplay turned off

Autoplaying video can interrupt screen readers and distract users by starting media without warning. Since the video block keeps autoplay turned off by default, leave it disabled and let users choose when to play the video.

Provide a transcript

Some users cannot access video content through audio or visuals alone. A transcript provides the information in text form. Add the transcript below the video or link to a separate transcript page, and clearly associate it with the video.

---

Support Accessible Content with Accessible Themes

Making your content accessible on its own is not enough. The theme used on your WordPress site also needs to be accessible. Otherwise, even well-written and well-structured content can become difficult or impossible for some users to access.

Themes control how content is displayed and navigated. This includes text contrast, focus indicators, and keyboard navigation. If a theme is not built with accessibility in mind, it can introduce barriers that accessible content alone cannot overcome.

Using an accessible theme helps ensure that content remains readable, navigable, and usable for a wider range of users. For more guidance, refer to our article on choosing an accessible WordPress theme. Or explore our list of the best accessible WordPress themes.

---

Wrapping Up

Gutenberg is not fully accessible at the moment, even though it has improved a great deal since its early releases. Many of the issues raised in 2018 and 2019 have been addressed over time, but the editor still presents some barriers for people with disabilities.

Accessibility remains an active focus within the WordPress project. The WordPress Accessibility Team and core contributors continue to make improvements, but progress is often slow due to the editor’s size, complexity, and ongoing feature development.