MasterWP is sponsored by LearnDash. Your expertise makes you money doing what you do. Now let it make you money teaching what you do. Create a course with LearnDash. (Use coupon ‘MASTERWP25’ to save $25 on your purchase!)
As Nyasha just shared last week, the new Block Pattern Directory on WordPress-dot-org is open for submissions. The directory has been around for a while, but the open call for submissions is what will put the “open” in open-source. The directory certainly is a showcase of all of the creativity in our community and the vast potential of the block editor. Unfortunately, it’s also a very clear example of the major limitations of the block editor and of crowd-sourced design in general.
After spending time examining a few patterns, I began to notice some pretty consistent pain points. These issues are not meant to call out the authors who designed these patterns as much as concerns about the moderation of the directory, and of what’s even possible in the block editor as it currently functions.
As a whole, I love the idea of an open directory for block patterns – and am excited to see it integrated into WordPress in the same way that the theme and plugin directories are. I don’t think it’s the job of unpaid volunteers to quality control the entire internet or always have to be on the front-lines of moderation. On the other hand, as an ‘official’ directory from the WordPress team, the project could use some higher standards in order to help everyone meet the basic goals of a better internet. For example, the word “accessibility” isn’t mentioned once in the guidelines for submission.
Here’s just a few things I noticed while browsing the recent submissions, along with some suggestions for improvement.
One common issue with the block editor is the general lack of semantic markup. A number of patterns seem to convey the idea of lists or list items, but there are no actual list items there. Here’s a pattern that at first blush appears to be a ordered list (
<ol>) or better yet a definition list (
<dl>), but instead is just a heavily nested series of
<div> elements and
<p> tags. Other patterns offer “quotes” without using actual an actual
<blockquote>, and “tables” without a
<table>. Patterns that do offer a decent display of semantic elements are often by necessity underwhelming in terms of design.
There’s a few reasons to rely on the correct HTML tags, none more important than accessibility. When relying on the interpretation of a screen reader, for example, elements like buttons, lists, menus, and more are treated differently and presented with more context. Beyond that, there’s the SEO implications of what your content might look like to the bots that crawl your site.
On the other hand, these types of layouts, such as splitting list items across multiple columns, are actually hard to accomplish correctly. There’s a reason many developers still use custom templates on higher-end client sites: the block editor can’t really accomplish these types of layouts without a lot of trade-offs. The “vanilla-WordPress” crowd used to criticize the page builder community for their endless piles of nested divs and inline CSS, but here we are starting to see the same thing emerge from core WordPress.
Understanding Visual Cues
When these block patterns fail to use correct HTML, they tend to fall back on arbitrary spacing and sizing to convey hierarchy and meaning. In some of the examples above, you’ll see larger font sizes that seem to suggest heading elements, but are actually just larger paragraph elements. Often, the entire block is just made of paragraph elements. Or there are cases where the pattern does utilize heading elements, but they’re mismatched or only contain what should technically be decorative text (like numbers).
So instead, what we’re left with is a large amount of visual hierarchy based solely on font sizes. Font sizes are important, but they provide nothing meaningful to a screen reader or a search engine. Is this breaking accessibility? No, not really. But it’s also not great for it.
Then there are the block patterns that suggest functionality that clearly doesn’t exist. Here’s a countdown timer pattern, but there’s no actual countdown here, unless of course you wanted to log in every 1 second and update the blocks yourself. BYOJS, apparently.
Similarly, there are multiple “question and answer” patterns that either don’t include any structure at all, or they include extra content (like the Q and A seen here) that would baffle a screen reader. And that’s not even considering the better structured data you might see in something like the Yoast FAQ block. Sure using a Yoast block is outside the scope of this example, but then, maybe so is offering a Q and A block pattern.
Finally, there are ‘patterns’ that aren’t really patterns at all. Like this ‘background’ pattern that is essentially a cover block in it’s default state. Or this inspirational quote (but not blockquote?) that sort of is also just a cover block? The guidelines seem pretty clear that overly simplistic or single block designs shouldn’t be submitted, but then why not?
Finally, we’re seeing new patterns that are a literal copy/paste of other patterns. Or patterns that clearly fail WCAG AA color contrast guidelines. In fact, copy and paste that last pattern into the block editor and it actually warns you that “This color combination may be hard for people to read.”
A lot of this begs the question: what exactly is the goal of the pattern directory? If the goal is to offer best practices for the community to follow, then unfortunately I think it’s missing the mark. If the goal is to be a showcase of the power of the block editor, then I’m afraid it’s actually just showing many of the cracks in it’s foundation. But if the goal is to be a completely unmoderated repository for arbitrary code snippets, then in that case it’s doing just fine.
To be clear – this is much more than what we could accomplish with the Classic editor. The bones are in place for something that, if we’re being honest, Elementor and Beaver Builder have been doing just fine for years. Because these problems aren’t even problems with just the pattern directory: they honestly apply to the block editor as a whole. The further the block editor moves into page builder territory, the further it moves away from clean, semantic, and accessible markup as a starting point for web development.
If the Block Pattern Directory is going to be anything, it should at least be a reliable place for users to grab code that follows industry-standard best practices.