Title: EMN FAQ & Accordion Block
Author: engelhardtmedien
Published: <strong>August 18, 2026</strong>
Last modified: August 18, 2026

---

Search plugins

![](https://ps.w.org/emn-faq-accordion-block/assets/banner-772x250.jpg?rev=3653467)

![](https://ps.w.org/emn-faq-accordion-block/assets/icon.svg?rev=3653467)

# EMN FAQ & Accordion Block

 By [engelhardtmedien](https://profiles.wordpress.org/beatcore/)

[Download](https://downloads.wordpress.org/plugin/emn-faq-accordion-block.4.4.4.zip)

 * [Details](https://wordpress.org/plugins/emn-faq-accordion-block/#description)
 * [Reviews](https://wordpress.org/plugins/emn-faq-accordion-block/#reviews)
 *  [Installation](https://wordpress.org/plugins/emn-faq-accordion-block/#installation)
 * [Development](https://wordpress.org/plugins/emn-faq-accordion-block/#developers)

 [Support](https://wordpress.org/support/plugin/emn-faq-accordion-block/)

## Description

Developed by [Engelhardt Medien](https://engelhardt-medien.de/), a digital webdesign
and graphics agency based in Nuremberg, Germany.

**Why this plugin?**

 * Schema.org `FAQPage` JSON-LD is generated automatically and tied directly to 
   the block’s mode — no separate schema plugin needed. This structured markup helps
   AI systems and assistants (ChatGPT, Perplexity, Gemini, and others) understand
   and surface your content, and gives search engines clean, standards-based context
   about your page — increasingly important as more traffic is driven by AI-powered
   search and answers. (Note: Google discontinued its visual FAQ rich-result snippet
   in Google Search in May 2026; the underlying structured data is still valid, 
   standard, and used elsewhere, e.g. by AI assistants.)
 * FAQ and Accordion mode are switchable independently per block instance.
 * Fast and lightweight — no external libraries, and assets only load on pages that
   actually contain the block.
 * Fully accessible, matching WCAG 2.1 Level AA for this interaction pattern — particularly
   relevant for websites operating in the European Union, where the European Accessibility
   Act has required many businesses to meet digital accessibility standards since
   June 2025.
 * WPML-compatible; translation-ready with translations delivered via translate.
   wordpress.org.
 * Works with your active theme’s own color palette and gradient presets.
 * Freely customizable — every visual aspect can be adjusted in the block editor
   sidebar, without touching any code.

EMN FAQ & Accordion Block adds a native Gutenberg block for building expandable 
question/answer sections. It works in two modes, switchable per block instance (
Accordion mode is the default for new blocks):

 * **Accordion mode** (default) – the same expandable UI without structured data,
   for general-purpose content (services, features, steps, etc.).
 * **FAQ mode** – automatically outputs valid Schema.org `FAQPage` JSON-LD structured
   data alongside the visible content. This structured data helps AI systems and
   assistants (such as ChatGPT, Perplexity, and Gemini) understand and surface your
   content when answering questions related to it, and provides search engines with
   clean, standards-based context about the page (note: Google discontinued the 
   visual FAQ rich-result snippet in Google Search in May 2026).

By default, opening one item automatically closes any other open item in the same
block — this can be turned off per block (under the “Type” panel) to allow multiple
items to stay open at once. The first item can also be set to already be expanded
when the page loads, again on a per-block basis (also in the “Type” panel).

**Design controls**

Every visual aspect can be adjusted directly in the block editor sidebar, without
touching any code:

 * Solid color or two-stop gradient backgrounds for both the question and the answer,
   including separate hover colors/gradients.
 * Border color, hover border color, border width, and border radius.
 * Independent top/right/bottom/left padding for both the question and the answer,
   and independent top/right/bottom/left icon padding — using WordPress’s own native“
   Dimensions” spacing control (including your theme’s own spacing presets, if defined),
   with the same unit choices as WordPress itself (px, %, em, rem, vw, vh).
 * One shared border color and width for all four sides. Border radius can be set
   per corner (using WordPress’s own native corner-radius control) or all at once.
 * All of the above native WordPress controls automatically and invisibly fall back
   to this plugin’s own equivalent, simpler control if a given native component 
   isn’t available on a specific WordPress version.
 * Padding and border settings each have a compact “⋮” reset-to-default menu.
 * Normal/hover color pairs (question background, question text, icon color, icon
   background) are grouped into a compact two-way switch instead of being listed
   one below the other.
 * Choice of icon: **plus/minus**, **chevron**, or **arrow** — freely selectable
   per block (the chevron and arrow rotate when an item is opened; the plus turns
   into a minus).
 * Icon color, icon background color (with separate hover colors), icon size, icon
   background radius, icon padding, and the spacing between the icon and the question
   text.
 * Icon position: left (default) or right of the question text.
 * Choice of HTML element for the question (div, p, or h2–h6), so it can match your
   document heading structure — with an optional custom font size override, set 
   independently for desktop, tablet, and mobile (any breakpoint left empty automatically
   falls back to the next larger breakpoint, and ultimately to your theme’s own 
   default size for that element).
 * Any color or gradient field can also use your active theme’s own color palette(
   e.g. Astra, or any theme that registers `editor-color-palette` / `editor-gradient-
   presets`), exactly like core WordPress blocks.
 * The answer area accepts any block available in your WordPress installation — 
   not just text: paragraphs, lists, images, headings, quotes, tables, galleries,
   columns, buttons, embeds, and any block added by other plugins/addons.

**Lightweight & fast**

Built with no external libraries or frameworks: a small, dependency-free editor 
script and a compact vanilla-JS frontend script. Nothing is loaded on pages that
don’t contain the block, and all output is plain HTML/CSS — no heavy runtime, no
bloat, and virtually no impact on page load time. All CSS and JavaScript ships pre-
minified and is served minified by default, keeping the amount of data sent to visitors
as small as possible (the original, readable source files are also included for 
transparency and are used automatically instead when `SCRIPT_DEBUG` is enabled).

Images, iframes (e.g. video embeds), and self-hosted videos placed inside a collapsed
answer are automatically served with native lazy-loading attributes (`loading="lazy"`/`
preload="none"`) as a reliable fallback, on top of WordPress core’s own automatic
lazy-loading — so media inside FAQ/accordion items that aren’t visible on load don’t
block the page. Existing `loading`/`decoding`/`preload` attributes (yours or another
plugin’s) are always left untouched. Media inside an item that is set to be open
by default is deliberately excluded, so it loads immediately like any other above-
the-fold content.

**Accessibility**

The expand/collapse interaction is built to be fully keyboard-operable and screen-
reader-friendly, in line with WCAG 2.1 Level AA for this type of disclosure widget:

 * Each question is reachable via Tab and operable with Enter or Space, in addition
   to mouse/touch.
 * Correct ARIA semantics are used throughout: `role="button"` and `aria-expanded`
   on the question, `aria-controls` linking it to its answer, and `role="region"`
   with `aria-hidden` and `aria-labelledby` (pointing back to its own question) 
   on the answer — all written directly into the server-rendered HTML, not added
   as an afterthought by JavaScript.
 * Decorative icons (plus/minus, chevron, arrow) are hidden from assistive technology
   via `aria-hidden`, since the open/closed state is already announced through `
   aria-expanded`.
 * A visible focus indicator is shown for keyboard users.
 * If an item is set to be open by default, it is rendered already expanded (correct`
   aria-expanded`/`aria-hidden` state and focusable content) directly in the initial
   HTML — no reliance on JavaScript running first.

No plugin can honestly certify a page as “100% accessible” on its own, since real-
world accessibility also depends on the content and colors you choose. What this
plugin guarantees on its own is the interaction pattern itself: correct roles/states,
full keyboard operability, a visible focus indicator, and screen-reader-friendly
markup, matching WCAG 2.1 Level AA for this type of disclosure widget. Final color
contrast (text against background, icon against its background) depends on the colors
you choose in the block settings — pick sufficiently contrasting colors (a ratio
of at least 4.5:1 for normal text) to keep the result compliant with WCAG AA.

**Security**

All styling attributes are re-validated and rebuilt on the server on every page 
load — via strict allow-lists for colors, gradients, numeric ranges, and HTML tags—
regardless of what is stored in the post content. This prevents malicious or malformed
attribute values from ever reaching the page’s HTML or CSS.

**Multilingual**

 * The plugin’s source strings are in German; fully translation-ready, with translations
   delivered automatically per-locale via translate.wordpress.org once contributed
   there — no bundled `.po`/`.mo` files, in line with how WordPress.org-hosted plugins
   handle translations.
 * Includes a `wpml-config.xml` for WPML compatibility, so only the question text
   itself is offered for translation — all styling attributes are copied as-is across
   languages.

## Screenshots

[⌊The FAQ/Accordion block in the editor.⌉⌊The FAQ/Accordion block in the editor.⌉[

The FAQ/Accordion block in the editor.

[⌊The custom styled plugin in Accordion mode in the frontend.⌉⌊The custom styled
plugin in Accordion mode in the frontend.⌉[

The custom styled plugin in Accordion mode in the frontend.

## Blocks

This plugin provides 2 blocks.

 *   FAQ / Accordion
 *   Accordion Item

## Installation

 1. Upload the `emn-faq-accordion-block` folder to the `/wp-content/plugins/` directory,
    or install the plugin directly through the “Plugins  Add New” screen in WordPress.
 2. Activate the plugin through the “Plugins” screen in WordPress.
 3. Edit any post or page, add the “FAQ / Accordion” block, choose FAQ or Accordion
    mode, and add one or more accordion items underneath it.
 4. Adjust colors, icon, spacing, and other options in the block settings sidebar on
    the right.

#### Updating from the old plugin

If you previously used the earlier “Custom FAQ Block” plugin, note that this is 
a separate plugin (different folder/slug), so installing and activating this one
does **not** automatically deactivate the old one — both would otherwise run side
by side. Please deactivate (and, once you’ve confirmed everything looks right, delete)
the old “Custom FAQ Block” plugin after activating this one; having both active 
at the same time can cause each plugin’s own frontend script to load together, which
stops the accordions from expanding. This plugin will show a notice in the WordPress
admin for as long as it detects the old plugin is still active. Content you already
published continues to display correctly either way.

## FAQ

### Does this plugin add any FAQ schema markup automatically?

Yes, but only when a block is set to “FAQ” mode. In that mode, the plugin outputs
a Schema.org `FAQPage` JSON-LD block based on the actual questions and answers in
that block. Blocks set to “Accordion” mode do not output this schema.

### Will my existing accordions break if I update the plugin?

No. Every markup shape produced by earlier versions of this plugin is explicitly
supported through WordPress’s block deprecation system, and legacy attributes (such
as the old single “padding” value) are automatically mapped to their modern equivalents
at render time.

### Can I use my theme’s own color palette in the color pickers?

Yes. If your active theme registers a color palette and/or gradient presets (via`
add_theme_support( 'editor-color-palette' )` / `add_theme_support( 'editor-gradient-
presets' )`), those colors and gradients are automatically offered in every color/
gradient field of this block, in addition to a fully custom color/gradient picker.

### Is this plugin compatible with WPML?

Yes, a `wpml-config.xml` is included that marks the question text as translatable
while keeping all styling attributes identical across every language.

### Which blocks can I use inside the answer?

Any block registered in your WordPress installation. There is no restriction to 
a fixed list — this includes every core block (paragraph, list, image, heading, 
quote, table, gallery, columns, buttons, embeds, and more) as well as blocks added
by other plugins or page-builder addons.

### Can multiple items be open at the same time?

By default, no — opening an item automatically closes any other open item in the
same block. This can be turned off per block via the “Automatically close other 
items” toggle in the Type panel, allowing several items to stay open simultaneously.

### Can the first item be open by default when the page loads?

Yes, via the “First item open on load” toggle in the Type panel (right above “Automatically
close other items”), on a per-block basis. It’s off by default, so existing content
keeps its previous, fully collapsed starting state after updating.

### Is this plugin accessible?

Yes. Every question is keyboard-operable (Tab, Enter, Space) and carries the correct
ARIA roles and states (`role="button"`, `aria-expanded`, `aria-controls`, `role="
region"`, `aria-hidden`, `aria-labelledby`) rendered directly into the HTML, matching
WCAG 2.1 Level AA for this interaction pattern. Decorative icons are hidden from
screen readers. Since colors are fully customizable, make sure the text/background/
icon colors you choose provide sufficient contrast (at least 4.5:1 for normal text)
to stay compliant. As with any plugin, “accessible” ultimately also depends on the
content you put inside it (meaningful link text, alt text on images, a sensible 
heading structure) — this plugin covers the interaction pattern itself, not the 
content you add.

### Are images and videos inside the answers lazy-loaded?

Yes. WordPress core already adds native lazy-loading to images and iframes automatically
on most pages (since WordPress 5.5/5.7). This plugin adds its own fallback on top
of that — applied directly when the block is rendered, so it also works in contexts
where WordPress’s own content filter doesn’t run (e.g. block-theme template parts,
widgets, or page builders that render the block directly). Any `loading`, `decoding`,
or `preload` attribute you or another plugin already set is never overwritten, and
media inside an item that’s set to be open by default is left to load immediately,
exactly like other above-the-fold content.

### Does the block check my FAQ content for common mistakes?

Yes. Whenever a block is set to “FAQ” mode, a “FAQ-Prüfung” (“FAQ check”) panel 
appears in the sidebar and flags, purely as an editorial aid: questions without 
text, questions without an answer, duplicate/very similar questions, an accordion/
FAQ block nested inside an answer (not supported in the FAQ schema), and unusually
short answers (under 40 characters — our own practical guideline, not an official
Google requirement). This check is informational only and never blocks saving or
publishing.

## Reviews

There are no reviews for this plugin.

## Contributors & Developers

“EMN FAQ & Accordion Block” is open source software. The following people have contributed
to this plugin.

Contributors

 *   [ engelhardtmedien ](https://profiles.wordpress.org/beatcore/)

“EMN FAQ & Accordion Block” has been translated into 1 locale. Thank you to [the translators](https://translate.wordpress.org/projects/wp-plugins/emn-faq-accordion-block/contributors)
for their contributions.

[Translate “EMN FAQ & Accordion Block” into your language.](https://translate.wordpress.org/projects/wp-plugins/emn-faq-accordion-block)

### Interested in development?

[Browse the code](https://plugins.trac.wordpress.org/browser/emn-faq-accordion-block/),
check out the [SVN repository](https://plugins.svn.wordpress.org/emn-faq-accordion-block/),
or subscribe to the [development log](https://plugins.trac.wordpress.org/log/emn-faq-accordion-block/)
by [RSS](https://plugins.trac.wordpress.org/log/emn-faq-accordion-block/?limit=100&mode=stop_on_copy&format=rss).

## Changelog

#### 4.4.4

 * Fixed a gap still appearing between the question and its answer in the editor
   preview when the question’s HTML element was set to a heading (h2–h6), even after
   the 4.4.1 fix for this: that fix’s margin reset for the new heading wrapper didn’t
   carry `!important`, so it could still lose to WordPress core’s or the active 
   theme’s own editor-only heading styles depending on load order/specificity — 
   the same class of conflict this plugin’s question-text color/font-size rule already
   had to work around the same way (see the comment above that rule). “div” and “
   p” were never affected.

#### 4.4.3

 * Fixed WPML not translating the question text at all (confirmed by a user report,
   on a site with no Custom XML Configuration override and 4.4.2 already installed):`.
   accordion-question-text` is changed back from `<span>` to `<div>` — the tag it
   had before 4.4, and the one WPML’s xpath-based translation for this field was
   already confirmed to work correctly with. Switching to `<span>` in 4.4 (for slightly
   cleaner, fully HTML5-valid markup when combined with the new native `<button>`,
   see 4.4’s changelog entry) turned out to break this in practice: even after correcting`
   wpml-config.xml`‘s xpath in 4.4.2 to match either tag, translations still weren’t
   written back. Rather than keep guessing at WPML’s exact xpath-matching behavior,
   this reverts to the exact, previously-proven-working `<div>` shape. `wpml-config.
   xml` additionally now matches `<div>` and `<span>` explicitly (so content saved
   during the brief 4.4–4.4.2 window, if any, still translates). If you added or
   edited questions while running 4.4, 4.4.1, or 4.4.2, please check their translations
   after updating to this version — for already-existing translations, WPML may 
   need the original question re-saved (even a trivial edit) before it re-picks-
   up the new content shape.

#### 4.4.2

 * **Security fix (stored XSS):** the editor-only “FAQ check” panel’s internal helper
   for measuring question/answer text length parsed HTML via `innerHTML` on a detached(
   not inserted into the page) element. Browsers still fetch resources referenced
   in HTML assigned this way (e.g. `<img src>`), which can trigger inline event-
   handler attributes such as `onerror` even though the element is never visibly
   attached to the page — verified directly in a real browser. Since this ran automatically
   on already-stored question/answer content every time a FAQ block was opened in
   the editor, malicious markup saved by any account with the `unfiltered_html` 
   capability (Administrators always; Editors too, by WordPress’s own default on
   single-site installs) could execute in the browser session of whoever next opened
   that post — including a higher-privileged user. Replaced with `DOMParser`, which
   parses into an inert, non-active document that never fetches resources or fires
   event handlers (also verified directly). This only ever affected the block editor(
   wp-admin); the public frontend was not affected, since this helper’s output is
   never used there.
 * Fixed WPML translations of the question text no longer reaching newly-saved accordion
   items after updating to 4.4: `wpml-config.xml`‘s `<xpath>` still looked specifically
   for a `<div class="accordion-question-text">`, but 4.4 changed this element to
   a `<span>` for newly saved content (see the 4.4 entry below). The xpath now matches
   the class on any element, so it keeps working for both the pre-4.4 `<div>` shape
   and the current `<span>` shape. If you’re on WPML and have added or edited FAQ/
   accordion questions since updating to 4.4, please re-check their translations
   after updating to this version.

#### 4.4.1

 * Fixed a gap appearing between accordion items in the editor preview whenever 
   the question’s HTML element (Type panel) was set to a heading (h2–h6): the new
   heading wrapper introduced in 4.4 didn’t yet have its browser-default margin 
   reset in the editor stylesheet (the frontend stylesheet already had this reset).“
   div” (the default) was never affected.
 * Fixed the question button showing a visible rounded corner where it meets the
   answer below it, and generally not respecting a “Border radius” of 0: some browsers
   apply their own default border-radius to native `<button>` elements (introduced
   in 4.4) independently of this block’s own border-radius setting. The button itself
   now always has `border-radius: 0` — only the outer item container (`.accordion-
   item`, via its own `overflow: hidden`) provides the rounded-corner look at the
   true outer edges, exactly as before 4.4.
 * Fixed a longstanding bug (present since the Normal/Hover tab UI was introduced,
   unrelated to the 4.4 changes above): switching between “Normal” and “Hover” for
   any color field that offers a “Color”/”Gradient” choice (question background,
   answer background) could keep the same “Color” or “Gradient” sub-selection for
   both instead of remembering each one independently, because both shared the same
   underlying editor component instance. Each is now correctly kept independent.

#### 4.4

 * Accessibility improvement: `.accordion-question` (the clickable question header)
   is now saved as a native `<button type="button">` instead of a `<div role="button"
   >`, and `.accordion-question-text` as a `<span>` instead of a `<div>`. This makes
   the markup fully valid HTML5 when the question is set to a heading (h2–h6) — 
   a heading element only permits phrasing content, and a `<div>` inside it (as 
   used through 4.3) is not valid, while a `<button>`/`<span>` are. Keyboard activation(
   Enter and Space), focus handling, and the correct implicit button role now also
   come directly from the browser instead of relying entirely on JavaScript. Existing
   content keeps working exactly as before without any changes needed or re-saving
   required — the previous `<div>`-based shape is preserved through WordPress’s 
   block deprecation system, so already-published questions keep validating against
   their actually-stored markup and keep rendering identically. Only newly saved/
   edited blocks pick up the native `<button>`/`<span>` markup going forward.
 * This release ships without a pre-minified `block.js` (`block.min.js`) — see the
   code comment above `emn_faq_accordion_asset_file()` for why. The plugin automatically
   falls back to the full, readable `block.js` in that case (this only affects the
   block editor’s JS payload size in wp-admin; there is no effect on frontend page
   weight or load time, since the editor script is never loaded on the public site).
   A future release will restore the minified file once it’s rebuilt through the
   normal build process.

#### 4.3

 * Accessibility fix: when the question’s HTML element is set to a heading (h2–h6),
   that heading now correctly wraps the entire clickable question button, instead
   of sitting inside it. Previously (up to 4.2), the heading ended up nested inside
   the `role="button"` element — the reverse of the W3C WAI-ARIA Accordion Pattern,
   which places the heading as the outer wrapper around the button. In practice 
   this meant screen-reader users navigating by heading shortcuts couldn’t jump 
   directly to a question. No visual change on the frontend (a CSS reset keeps the
   new wrapper element invisible in the layout), and blocks left on “div” (the default—
   unchanged unless you explicitly picked a heading level) or “p” are entirely unaffected.
   Nothing about the saved block content changes; this is applied purely at render
   time, so existing content needs no re-saving.

#### 4.2

 * Fixed WPML translations of the question text never reaching the frontend, even
   though the translation could be entered correctly in WPML’s own editor. The bundled`
   wpml-config.xml` used an element WPML doesn’t actually recognize for this field;
   it’s now declared using WPML’s real mechanism for content that lives directly
   in the block’s saved HTML (an `<xpath>` rule) instead. Translations entered before
   this update may need to be re-saved once in WPML’s translation editor to take
   effect, since the previous configuration never wrote them into the actual post
   content in the first place.

#### 4.1

 * Fixed the plus/minus icon staying on “+” when expanding an item in the block 
   editor’s own preview, instead of switching to “−” like it correctly already did
   on the live frontend — the editor preview now mirrors the open/closed state the
   same way the frontend script does.

#### 4.0

Summary of everything that changed since the 3.0 rebuild (see individual 3.x entries
below for full detail on each point). Nothing in this release changes stored data
or requires any action — every existing block keeps rendering and behaving exactly
as before.

 * **Design & editor controls:** the sidebar now consistently uses WordPress’s own
   native controls where available (spacing/dimensions control with theme presets,
   per-corner border radius, unit-aware fields for px/%/em/rem/vw/vh), each with
   an automatic, invisible fallback to this plugin’s own simpler control if a native
   component isn’t available on a given WordPress version. Repeated, similar settings(
   color pairs, single pixel values, two-way choices) were unified to consistently
   reuse the same handful of controls instead of each field being styled differently.
   Every resettable field now has a compact “⋮” reset-to-default menu, correctly
   aligned and positioned to match WordPress’s own panel design.
 * **New features:** gradient backgrounds, per-side padding for question/answer/
   icon, per-corner border radius, choice of icon (plus/minus, chevron, arrow) with
   full styling control, icon position (left/right), choice of HTML tag for the 
   question with responsive font-size overrides, “first item open on load,” “automatically
   close other items,” theme color-palette/gradient integration, and an in-editor“
   FAQ check” panel that flags common content mistakes.
 * **Accessibility:** full keyboard operability and correct ARIA roles/states written
   directly into the server-rendered HTML, matching WCAG 2.1 Level AA for this interaction
   pattern; native lazy-loading fallback for media inside collapsed answers.
 * **Security & WordPress.org compliance:** all styling attributes are re-validated
   server-side on every page load through strict allow-lists (colors, gradients,
   numeric ranges, HTML tags); removed deprecated PHP functions and bundled translation
   files in favor of translate.wordpress.org, in line with WordPress.org hosting
   requirements; JSON-LD output is built via `wp_json_encode()`, never string-concatenated.
 * **Backward compatibility:** every markup/attribute shape from earlier versions—
   including content from before this plugin stored its display mode as an attribute
   at all — is explicitly handled through WordPress’s block deprecation system and
   defensive server-side fallbacks, so existing content keeps rendering and behaving
   identically after updating.
 * **Build process:** fixed a release-process bug where the pre-minified CSS/JS 
   files shipped to production could get out of sync with source changes across 
   several point releases, silently shipping outdated styling/behavior to non-debug
   WordPress installs; the build now verifies minified output is rebuilt from current
   source before every release.

#### 3.11

 * Fixed the “⋮” reset menu floating one row above the field it belongs to on fields
   whose label is shown by the control itself instead of by the outer wrapper (border
   width, icon background radius, and the two newly added ones below) — it’s now
   overlaid on the same visual row as that label instead of getting its own (empty)
   row above it.
 * Added individual “⋮” reset points for icon size and icon-to-text spacing, matching
   the other sliders in the panel.
 * Removed the “⋮” reset menu from the border color field — the color picker already
   has its own built-in “Clear” action per swatch, so the extra reset was redundant.

#### 3.10

 * Fixed the actual cause of the “⋮” reset menu not aligning to the right in the
   editor sidebar: the plugin ships a pre-minified CSS file for production use, 
   and that minified file had gotten out of sync with several rounds of source CSS
   changes, so none of the previous alignment fixes were actually being loaded in
   a normal (non-debug) WordPress install. The minified editor and frontend stylesheets
   are now rebuilt from the current source so the fix actually ships.

#### 3.9

 * Fixed the “⋮” reset menu still not aligning to the far right on some panels —
   it’s now wrapped in its own dedicated element so its position no longer depends
   on internals of the underlying WordPress component.
 * Removed the “Edges” panel’s own now-redundant “Randfarbe und -stärke” section
   title — the border-width slider and the border-color Normal/Hover switch already
   show their own descriptive label, so the extra title was pure duplication. Each
   now has its own separate “⋮” reset menu instead of one shared one.
 * Reordered the Icon panel: icon position now comes right after icon type, before
   icon size (previously: type, size, position).
 * Fixed the icon’s own background radius field, which had a bug causing it to not
   reliably work — replaced with the same plain slider used by “Border width” and“
   Spacing between items”, instead of the more complex (and, as it turned out, unreliable)
   unit-aware slider introduced in 3.7.
 * Renamed the padding/spacing section title from “Maß” back to “Maße” (matching
   WordPress’ own exact wording) across all three padding panels (question, answer,
   icon).

#### 3.8

 * Unified the sidebar’s visual language so similar settings consistently look and
   behave the same way, instead of each one being its own slightly different “construction
   site”:
    - Fixed the question’s “Background” field showing its own label (“Background”)
      a second time directly below the already-visible Normal/Hover switch.
    - The border panel no longer uses a separate native border-width/color control;
      border width is now the same plain slider used for “Spacing between items”,
      and border color (normal/hover) uses the same Normal/Hover switch already 
      used for the question’s background and text colors.
    - Icon size and the icon-to-text spacing are now the same plain slider (with
      an editable number field built in) used for “Spacing between items”, instead
      of a plain number field.
    - Icon position (left/right) is now the same two-button switch used for Normal/
      Hover, instead of a dropdown.
 * As a general rule going forward: fields that represent the same kind of choice(
   a single pixel value, a normal/hover pair, a two-way choice) now consistently
   reuse the same control across the whole sidebar.

#### 3.7

 * Simplified the border/edges panel back to a single width and color for all four
   sides (no more link/unlink toggle for individual sides), per feedback that a 
   single shared value is what’s actually needed here — this also removes the small
   set of “per-side” attributes added in 3.6, since they’re no longer used by the
   UI.
 * Fixed several sidebar panels (Question/Answer/Icon padding, Border, Corner radius)
   showing the same label twice, once as this plugin’s own section title and once
   as WordPress’ native control’s own built-in caption (e.g. “Innenabstand” appearing
   twice). The plugin’s own section titles are now distinct from the native control’s
   own caption, matching WordPress’ own two-row panel header pattern (overall title
   on top, the specific control’s own label directly below it).
 * Fixed the “⋮” reset menu not aligning to the right edge of its row on some panels(
   stuck to the left, right next to the label) — it’s now reliably pushed to the
   far right regardless of other layout on the page.
 * The icon’s own background radius field now accepts the same units as WordPress
   itself (px, %, em, rem, vw, vh) alongside its slider, and has the same “⋮” reset
   menu as the other fields in this panel.

#### 3.6

 * Fixed a bug where choosing a theme spacing preset (“Use size preset”) for padding
   showed no visible effect in the editor preview (looked like zero padding), even
   though the frontend rendered correctly. The editor preview now converts the preset
   token to the same CSS variable WordPress’ own global styles use, matching the
   frontend behavior.
 * Reworked the border (“Edges”) panel’s linked/split sides control: a previous 
   implementation based on WordPress’s native multi-side border component (`BorderBoxControl`)
   had a recurring bug where entering different values per side (top/right/bottom/
   left individually) silently had no effect on either the editor or the frontend.
   This has been replaced with a self-built, fully-controlled link/unlink toggle
   backed by four independent instances of the same single-border control already
   used for the “all sides linked” case (proven reliable in earlier testing) — this
   class of bug can no longer occur, since there’s no dependency on the native component’s
   internal multi-side reconciliation anymore.
 * Native controls (padding, border radius) now show their own built-in label/caption
   row (matching WordPress’s own two-row panel header layout: an overall title with
   the “⋮” menu on the first row, the specific control’s own label on the second),
   instead of a hidden/generic label.
 * The “⋮” reset menu now uses a smaller, vertically-oriented three-dot icon matching
   WordPress’s own panel header icon, instead of a larger horizontal one, and got
   a bit more breathing room from the control below it.
 * The icon’s own background radius field is now a slider (matching the rest of 
   this panel’s fields), instead of a plain number field.

#### 3.5

 * Matched the “Dimensions” and “Border” sidebar panels even more closely to WordPress’s
   own native panels for core blocks (e.g. the Heading block), based on a direct
   comparison against WordPress’s actual rendered markup:
    - Padding now uses WordPress’s own native `SpacingSizesControl`, including its“
      Use size preset” toggle tied to your theme’s own spacing scale (if defined
      in theme.json) — exactly like core blocks. A previous, more conservative implementation
      deliberately avoided this control after an early version had a bug converting
      preset values; the underlying preset-token format is now recognized and handled
      correctly server-side.
    - The border control now uses WordPress’s own native `BorderBoxControl`, including
      the “linked/split sides” toggle, so each side of the border can genuinely 
      have its own width and color, exactly like core blocks. A 3.2 release had 
      a bug where switching to “split sides” and setting different values per side
      silently kept only one side’s value; that data flow has been rewritten and
      verified directly against Gutenberg’s own source code this time. Existing 
      single-color/width borders are completely unaffected.
    - Added a genuine corner-by-corner border radius control (WordPress’s own native`
      BorderRadiusControl`, top-left/top-right/bottom-left/bottom-right individually,
      with a link/unlink toggle), replacing the single all-corners radius field.
      Existing values are unaffected (used as the shared starting value for all 
      four corners).
    - All of the above keep the previous safe fallback approach: if a given native
      component isn’t available on a specific WordPress version, or fails to render
      for any reason, this plugin’s own previously-existing simpler control is used
      instead automatically, with no visible error.
 * Removed the “Outer spacing” option added in 3.2/3.3 entirely, per feedback that
   it kept misbehaving. “Spacing between items” (the gap between individual FAQ/
   accordion entries) is unaffected and unchanged.
 * Addressed WordPress.org plugin review feedback: removed the deprecated `libxml_disable_entity_loader()`
   call (the `LIBXML_NONET` flag already used elsewhere provides the relevant protection,
   and PHP 8.0+ disables external entity loading unconditionally regardless); removed
   the bundled `.po`/`.mo`/`.json` translation files (translations are now delivered
   exclusively through translate.wordpress.org, the standard mechanism for WordPress.
   org-hosted plugins); removed the `Contributors` field from this readme.

#### 3.4

 * Removed the “Outer spacing” option added in 3.2/3.3 entirely, per feedback that
   it kept misbehaving. “Spacing between items” (the gap between individual FAQ/
   accordion entries) is unaffected and unchanged.
 * Padding (question, answer, icon) and the border width/radius now accept the same
   units as WordPress itself — px, %, em, rem, vw, vh — using WordPress’s own native
   box-spacing and unit controls (with an automatic, seamless fallback to a plain
   pixel field on WordPress versions where those native components aren’t available).
   Existing values (previously always plain pixel numbers) keep working exactly 
   as before; they’re simply treated as “px” going forward.
 * Border width and radius, and question/answer/icon padding, now use WordPress’s
   native linked/unlinked spacing control, matching the “Dimensions” panel of core
   blocks.

#### 3.3

 * Fixed a bug introduced in 3.2 where switching the new native border control into
   its “split sides” view and entering different width/color values per side silently
   discarded every side except the first one, both in the editor preview and on 
   the frontend. The border control now uses WordPress’s single-border component
   instead of the multi-side one, which doesn’t offer a “split sides” view in the
   first place — this class of bug can no longer occur, and border settings match
   this block’s actual capability (one width/color for all four sides) exactly.
 * Fixed a bug introduced in 3.2 where switching the new native padding/margin controls
   to “Use size preset” silently reset the value to 0, because WordPress’s native
   spacing-preset system hands back a preset token rather than a plain pixel number,
   which this block couldn’t store. The padding/outer-spacing controls are now a
   self-built equivalent (link/unlink icon plus slider, matching the same visual
   language) that never offers presets in the first place, so this bug can no longer
   occur either.
 * Renamed the “Border” sidebar panel/fields to “Edges” (previously inconsistently
   labeled “Border” in places), matching WordPress’s own naming for this panel.
 * Replaced the “⋮ reset” menu implementation: it previously nested a full native
   WordPress panel-with-its-own-border inside this block’s own sidebar sections,
   which visibly shrank the available width for no benefit. It’s now a compact “
   ⋮” button using a plain, long-stable WordPress menu component, with no extra 
   panel chrome — this also applies the same compact reset menu to the icon padding
   control, which didn’t have one before.
 * Split the previous single “Outer spacing” concept into two clearly separate, 
   independent controls, per feedback that they were conflated: “Spacing between
   items” (the gap between individual FAQ/accordion entries — this is the exact 
   same setting/attribute this block has had since 3.0, now just using a clearer
   name and the native-style slider) and a new “Outer spacing” (a margin around 
   the entire FAQ/accordion block as a whole, all four sides, brand new, defaults
   to 0/no effect on existing content).

#### 3.2

 * Reworked the editor sidebar to be more compact and closer to WordPress’s own 
   native design language:
    - Question background/text (and their hover variants), plus the icon’s color/
      background (and their hover variants), are now grouped into a compact “Normal/
      Hover” switch instead of being listed one below the other.
    - The question and answer padding now use WordPress’s own native spacing control(
      linked/unlinked sides, slider + number field) instead of four separate plain
      number fields.
    - The border color/width now use WordPress’s own native border control, matching
      the look of core blocks.
    - Added a new, fully independent top/right/bottom/left outer spacing (margin)
      per item, replacing the previous single “spacing between items” value — the
      previous value is carried over as the new “bottom” spacing, so existing accordions
      keep their exact previous appearance after updating.
    - Padding, margin, and the border settings now have WordPress’s native “⋮” reset
      menu, letting you reset any of them back to their default in one click.
 * All of the above native WordPress components are used with an automatic, invisible
   fallback to this plugin’s own previously-existing controls if a given native 
   component isn’t available (e.g. on an older WordPress version) or fails to render
   for any other reason — the same safety approach already used for this plugin’s
   gradient picker since 3.0. Nothing breaks either way; worst case, a field simply
   keeps its previous appearance instead of the newest native one.
 * No stored data changes for anything other than the outer spacing (margin); every
   other setting keeps using exactly the same attributes as before, so existing 
   accordions/FAQs keep their exact appearance after updating.

#### 3.1

 * Added a “First item open on load” option (Type panel, positioned directly above“
   Automatically close other items”) — lets the first accordion/FAQ item start already
   expanded when the page loads, on a per-block-instance basis, exactly like the
   existing open/close behavior of individual items. Off by default, so existing
   content keeps its previous, fully collapsed starting state after updating.
 * Accessibility: each answer now also carries `aria-labelledby`, pointing back 
   to its own question, so screen-reader users navigating by landmark/region get
   a distinct, meaningful name for every answer instead of a generic, indistinguishable“
   region” repeated for each item.
 * Accessibility: fixed an edge case where an item rendered already open (see the
   new “First item open on load” option) could have its links/buttons/form fields
   inside the answer incorrectly excluded from keyboard (Tab) navigation until the
   item was manually closed and reopened once.
 * Added a lazy-loading fallback for images, iframes (e.g. video embeds), and self-
   hosted videos inside an answer (`loading="lazy"` / `decoding="async"` / `preload
   ="none"`), applied directly when the block is rendered — on top of WordPress 
   core’s own automatic lazy-loading, and independent of whether the block is output
   via `the_content` (so it also covers block-theme template parts, widgets, and
   page builders that render the block directly). Existing `loading`/`decoding`/`
   preload` attributes are never overwritten, and media inside an item open by default
   is deliberately left to load immediately.
 * Added a “FAQ-Prüfung” (“FAQ check”) sidebar panel, shown only when a block is
   set to “FAQ” mode, that flags common mistakes as an editorial aid: questions 
   without text, questions without an answer, duplicate/very similar questions, 
   an accordion/FAQ block nested inside an answer (not supported in the FAQ schema),
   and unusually short answers (under 40 characters — our own practical guideline,
   not an official Google requirement). Purely informational; never blocks saving
   or publishing, and has no effect on the saved markup or frontend output.

#### 3.0

 * Renamed the plugin from “Custom FAQ & Accordion Block” to “EMN FAQ & Accordion
   Block” to meet WordPress.org’s plugin-naming guidelines — cosmetic only, no functional
   change; all existing content, settings, and translations remain fully compatible.
 * Fixed a bug where the answer’s “Text” color setting had no visible effect in 
   either the editor preview or the frontend — only the answer’s background color
   was actually applied. The color picker itself worked correctly, but no styling
   rule ever read the resulting value. Existing pages that never set a custom answer
   text color are unaffected and keep inheriting their theme’s normal text color
   exactly as before.
 * Cleaned up the FAQPage JSON-LD output: the answer text no longer carries WordPress’
   own internal CSS classes and inline styles (e.g. `wp-block-paragraph`, `style
   ="margin-top:0px"`), only the small set of HTML tags Google’s own FAQPage documentation
   lists as supported (headings, paragraphs, lists, links, bold/italic, line breaks).
   The schema was already valid before, but this removes unnecessary markup noise
   for anything parsing it (search engines, AI assistants).
 * Rebuilt block architecture: all styling is now rebuilt server-side from sanitized
   attributes on every page load, independent of what is stored in the post content.
 * Added gradient background support (question and answer, including hover), configurable
   border width/color/hover color, and independent per-side padding for question
   and answer.
 * Added a choice of icon (plus/minus, chevron, arrow), with configurable icon color,
   background color, hover colors, size, background radius, padding, position (left/
   right), and icon-to-text spacing.
 * Added a choice of HTML element for the question (div/p/h2–h6) with an optional
   custom font size.
 * Added integration with the active theme’s color palette and gradient presets.
 * Added German and English translations, plus WPML compatibility via `wpml-config.
   xml`.
 * Hardened output sanitization (colors, gradients, HTML tags, and numeric ranges
   are strictly validated on every render).
 * Various editor UX improvements (clearer field grouping, dedicated “Add item” 
   control, consistent field label sizing).
 * The answer area now accepts any registered block (no longer limited to a fixed
   list), including blocks added by other plugins/addons.
 * Lightweight by design: no external libraries, a small dependency-free footprint,
   and assets that only load on pages actually containing the block.
 * Default mode for new blocks changed from FAQ to Accordion.
 * Added an “Automatically close other items” option (Type panel) — enabled by default,
   matching the previous fixed behavior; can be disabled to allow multiple items
   open at once.
 * Accessibility hardening: ARIA roles/states (role=”button”, aria-expanded, aria-
   controls, role=”region”, aria-hidden) are now written server-side directly into
   the rendered HTML, decorative icons are hidden from assistive technology, and
   the interaction pattern targets WCAG 2.1 Level AA.
 * All CSS and JavaScript is now shipped pre-minified and served minified by default
   for faster page loads; the original source files are kept alongside and used 
   automatically when `SCRIPT_DEBUG` is enabled.
 * Hardened rendering against a further edge case: a FAQ/Accordion block nested 
   inside another block’s answer no longer has its icon, HTML tag, or ARIA attributes
   incorrectly overwritten by the outer block’s settings.
 * Renamed the “Question – Colors” and “Answer – Colors” sidebar panels to simply“
   Question” and “Answer”, since they also contain the padding controls, not only
   colors.
 * Fixed an editor-only bug where the question’s “Text” and “Text (hover)” color
   fields visually changed the +/- / chevron / arrow icon’s color instead of the
   question text’s own color.
 * Hardened the question text color (normal and hover) on the frontend against being
   overridden by a theme’s own generic text-color styles, so it reliably reflects
   the “Text” / “Text (hover)” settings on every theme.
 * Fixed an editor-only bug where the custom question font size had no visible effect
   in the block preview.
 * Fixed a bug where a brand-new, unmodified block could show a different answer
   padding in the editor preview than on the actual frontend, because WordPress 
   omits attributes matching their default value when saving; the answer padding
   default remains 10px, matching the question padding, and is now applied consistently
   in both places.
 * Added separate desktop/tablet/mobile values for the question’s custom font size,
   each falling back to the next larger breakpoint (and ultimately to the theme’s
   own default) when left empty.
 * Fixed a design bug where a block directly following the answer’s last paragraph(
   e.g. a list) would stick to it with no spacing; the spacing removal now only 
   applies when that paragraph is truly the last element in the answer.
 * Moved the icon padding control directly below the icon background radius control
   in the Icon panel, ahead of the icon color fields.
 * Increased the default spacing between the icon and the question text from 8px
   to 14px for better legibility.
 * Added an admin notice that warns when the previous “Custom FAQ Block” plugin 
   is still active alongside this one, since running both at the same time can stop
   the accordions from expanding on the frontend (see “Updating from the old plugin”
   below).
 * Fixed a bug affecting content created with the very oldest plugin versions (before
   the icon got its own styling wrapper): the icon now reliably gets its color, 
   background, size, and spacing on the frontend as well, instead of appearing as
   plain “+” text with no spacing from the question.
 * Fixed a significant bug where a block created before version 3.0 that was left
   on its original “FAQ” mode (the default at the time) could silently lose its 
   FAQPage schema output on the frontend after updating, while still correctly showing
   as “FAQ” in the editor. For the very oldest content, the mode wasn’t even stored
   as an attribute at …

## Meta

 *  Version **4.4.4**
 *  Last updated **1 day ago**
 *  Active installations **Fewer than 10**
 *  WordPress version ** 6.0 or higher **
 *  Tested up to **7.0.4**
 *  PHP version ** 7.4 or higher **
 *  Languages
 * [English (UK)](https://en-gb.wordpress.org/plugins/emn-faq-accordion-block/) 
   and [English (US)](https://wordpress.org/plugins/emn-faq-accordion-block/).
 *  [Translate into your language](https://translate.wordpress.org/projects/wp-plugins/emn-faq-accordion-block)
 * Tags
 * [Accordion](https://wordpress.org/plugins/tags/accordion/)[block](https://wordpress.org/plugins/tags/block/)
   [faq](https://wordpress.org/plugins/tags/faq/)[gutenberg](https://wordpress.org/plugins/tags/gutenberg/)
   [schema](https://wordpress.org/plugins/tags/schema/)
 *  [Advanced View](https://wordpress.org/plugins/emn-faq-accordion-block/advanced/)

## Ratings

No reviews have been submitted yet.

[Your review](https://wordpress.org/support/plugin/emn-faq-accordion-block/reviews/#new-post)

[See all reviews](https://wordpress.org/support/plugin/emn-faq-accordion-block/reviews/)

## Contributors

 *   [ engelhardtmedien ](https://profiles.wordpress.org/beatcore/)

## Support

Got something to say? Need help?

 [View support forum](https://wordpress.org/support/plugin/emn-faq-accordion-block/)