Easy Accordion Block 1.5.2 is out today, along with Pro 1.2.2.
There are no new design options in this one. It is a repair release. We went
through the front-end code line by line and found eight problems, some of
which have been there for a while. A few were quiet enough that you would
never notice them yourself, but a visitor using a screen reader would.
Here is what changed and why it matters.
Two accordions on one page confused screen readers
This was the worst one.
Every accordion panel gets an ID so the header can point at it. That ID was
built from the panel’s position in its own accordion, so the first panel was
always called esab-body-0. Put two accordions on the same page and you had
two panels sharing that name. Three accordions, three of them.
An ID is supposed to be unique on a page. When it isn’t, a screen reader
following a header to “its” panel can land on a completely different one. On a
long FAQ page with a couple of accordion sections, someone could open a
question and be read the answer to a different question entirely.
IDs are now unique across the whole page. If you set your own anchor on a
block, that is left alone.
While we were in there, panels also got proper labels, so a screen reader now
announces which section it has moved into instead of just “region”.
You can navigate with the keyboard
Before, you could tab to a header and press Enter or Space. That was it. To
reach the fifth question you tabbed through everything in the four above it,
including any links inside the open panels.
Now the arrow keys move between headers:
- Down arrow goes to the next header
- Up arrow goes to the previous one
- Home jumps to the first
- End jumps to the last
Enter and Space still open and close, as before. This follows the
WAI-ARIA Accordion Pattern,
which is what screen reader users expect an accordion to do.
Links inside a header no longer break the header
If you used the Pro option to link an accordion title, you ended up with a
link inside a button. Browsers and assistive tech both dislike that, because
it is ambiguous: activating it could reasonably mean “open the panel” or
“follow the link”.
Headers with a link now keep working as links, and a separate button handles
opening and closing. Nothing looks different. Clicking the header still opens
the panel like it always did. The difference is that a keyboard or screen
reader user now gets two clearly distinct controls instead of one confusing
one.
“Open All” got a lot lighter
The Open All and Close All buttons were doing far more work than they needed
to. The click handler was being attached once per item, and each copy then
looped over every item again.
On one of our test pages, a four-item accordion fired 36 animations for a
single click on Open All. It now fires one per panel. On a long FAQ list, this
was the difference between a smooth expand and a visible stutter.
Some of that count came from a second problem: an accordion nested inside
another one was being wired up twice, once by its parent and once by itself.
That is fixed too.
Search and Load More stopped fighting each other
Two bugs here, both in Pro.
Search was reading text from nested accordions, so a parent item could match a
word that only appeared in a child three levels down.
The bigger annoyance: if you had Load More turned on, searched for something,
then cleared the search box, every hidden item stayed on screen and the Load
More button disappeared. The only way back was a page refresh. Clearing the
search now puts things back exactly as they were.
Search also waits a moment before filtering as you type, announces the result
to screen readers, and clears when you press Escape.
Your content stays readable without JavaScript
Accordion panels are hidden with CSS and revealed by a script. If that script
did not load — a slow connection, a caching plugin doing something unexpected,
a blocked request — every answer on the page was invisible. Not collapsed.
Gone.
That is a bad failure for an FAQ page, and it is a bad failure for anything
depending on that content being findable.
Panels now stay visible when JavaScript is not available. Nobody, and nothing,
ends up looking at an empty page.
Accordions print properly
If someone printed a page with an accordion on it, they got the questions and
none of the answers.
Printing now expands every panel and hides the buttons, search box, and
toggle icons, which are not much use on paper. Handy for policy pages,
manuals, and course material.
Reduced motion is respected
If a visitor has “reduce motion” turned on in their operating system, panels
now open and close instantly instead of sliding. This is a real accessibility
setting for people who get motion sickness or migraines from animation, not a
preference toggle.
Google Fonts load properly, and you can turn them off
Two things were wrong here.
Font requests were being made too late in the page load, so the stylesheet
ended up at the bottom of the page instead of the top. That causes the flash
of unstyled text you may have noticed on first load.
And when a font was requested, every weight from 100 to 900 came with it, even
if you only used one. That is a few hundred kilobytes of font files nobody
asked for.
Fonts now load in the page head, and only in the weights you actually chose.
There is also a new switch to turn off Google Fonts entirely. If you are in the
EU and would rather not send visitor IP addresses to Google, or you already
host your fonts locally, you can now opt out. Developers can use theesab_disable_google_fonts filter.
One bad CSS rule no longer wipes out a whole block
The plugin checks the CSS it generates before printing it. That check was
all-or-nothing: if any single property looked unsafe, the entire block’s
styling was thrown away and your accordion rendered unstyled.
It now checks property by property. The one problematic rule gets dropped and
everything else is kept, so you get a small visual difference instead of a
broken block.
Nothing in your saved content changed
Worth saying plainly, because it is the question we get after every update:
this release does not touch the markup your accordions are saved as.
That matters because when a block’s saved output changes, WordPress notices
the mismatch and shows the “Attempt Block Recovery” warning on posts you
haven’t touched in months. It is alarming, and fixing it across a large site
is tedious.
Every fix above was made in the script that runs on the page and in the PHP,
not in what gets written to your database. We checked this by building the
plugin before and after the changes and comparing the compiled editor code
byte for byte. It is identical.
Two practical upshots. You will not see recovery prompts. And you do not need
to open and re-save anything: your existing accordions get all of these fixes
the moment you update, including posts published years ago.
What is in Pro 1.2.2
Pro gets the same treatment for the FAQs block: unique IDs, keyboard
navigation, the Open All fix, the search and Load More fix, print support, and
reduced motion.
The Unfold block also had a bug worth mentioning. If one Unfold block on a page
was missing part of its markup, the script threw an error and stopped, which
took out every other Unfold block further down the page. One broken block
could silently break five working ones. It now skips the broken one and
carries on.
How to update
Go to Plugins in your dashboard and update Easy Accordion Block to 1.5.2. If
you have Pro, update that to 1.2.2 as well. They work independently, so
updating one before the other is fine.
The plugin needs WordPress 6.6 or newer and PHP 7.4 or newer, unchanged from
before.
What we are looking at next
A few things on the list, in no particular order: FAQ schema for the free
accordion block, deep links so you can send someone straight to one open
question, and removing the jQuery dependency to make the front-end script
smaller.
If one of those would make a real difference to your site, tell us. We pay
attention to what people actually ask for, and this release came out of the
kind of detail that is easy to overlook until someone points at it.
Thanks for using the plugin.