Semanticality™ Plugin for WordPress Gutenberg.

Why is genuine accessibility so difficult in WordPress?

You know the feeling: A client loves the design of their new premium theme, but the HTML code generated by Gutenberg is a semantic minefield. This is where Semanticality™ comes in.

Genuine accessibility arises through correct, semantic HTML code – but this is exactly where developers quickly reach their limits with WordPress: There are hardly any possibilities to customize the code without completely reprogramming the theme.

<div class="wp-block-card">
  <div class="wp-block-card__title">My card title</div>
  <div class="wp-block-card__content">Card content is here</div>
  <div class="wp-block-card__link" onclick="location.href='/mehr'">read more</div>
</div>
      

<article class="wp-block-card" aria-labelledby="wp-block-card__title-1">
  <h3 class="wp-block-card__title" id="wp-block-card__title-1">My card title</h3>
  <p class="wp-block-card__content">Card content is here</p>
  <a href="/more" class="wp-block-card__link" aria-label="Read more about 'My card title'">read more</a>
</article>
      

Especially in the context of the new EAA (BFSG), this is indispensable to meet the legal requirements. Semanticality™ is ideal for implementing the HTML-related measures in a few hours instead of months after an EAA Audit*.

• The technical basis of your work

  With Semanticality™ you work directly on the HTML structure that underlies the Accessibility Object Model (AOM). In the Gutenberg Block Editor you correct the code graphically based on rules – these are applied during rendering.

  You correct the faulty HTML code with Semanticality™ before it is converted into a node tree structure with correct hints.

  [Heading level 2] Product Overview

  [Paragraph] This is an accessible text...

  Users can easily navigate and have content read out thanks to the correct AOM.

  

• Accessibility standards you meet

  With Semanticality™ you create the technical basis for central requirements from WCAG 2.2 / EN 301 549 / BITV 2.0 / EAA (BFSG) – where semantic HTML code & ARIA are required – completely without theme modifications**.

  • 

    ISO 40500:2012

    International standard for accessibility

  • 

    WAI-ARIA

    Technology for implementing accessibility

  • 

    WHATWG

    HTML5 standard

  • 

    WCAG 2.2 AA

    International guidelines for website accessibility

  • 

    ISO 40500:2012

    International standard for accessibility

  • 

    WAI-ARIA

    Technology for implementing accessibility

  • 

    WHATWG

    HTML5 standard

  • 

    WCAG 2.2 AA

    International guidelines for website accessibility

  • 

    EAA

    Requirements for D2C / B2C companies in the EU

  • 

    BITV 2.0

    Requirements for public bodies in Germany

  • 

    ADA

    American accessibility legislation

  • 

    BFSG

    Implementation of EAA in Germany

  • 

    EAA

    Requirements for D2C / B2C companies in the EU

  • 

    BITV 2.0

    Requirements for public bodies in Germany

  • 

    ADA

    American accessibility legislation

  • 

    BFSG

    Implementation of EAA in Germany

• A robust foundation. For every user.

  Adapt your Gutenberg blocks in the shortest time and optimize your website for accessibility** and EAA compliance*** in hours instead of months*.

  Get started with Semanticality™ now

  

  

More than just an attribute plugin. Granular control. Over every Gutenberg block.

Other plugins often only allow the addition of simple attributes to the main wrapper of a Gutenberg block.

Semanticality™ goes crucial steps further and gives you granular control over every single element within your WordPress Gutenberg blocks.

Overlay Widgets

Overlay widgets promise accessibility at the push of a button but are only a plaster. They do not change the underlying code and are usually not sufficient for genuine accessibility or compliance [1].

• No semantic correction: A div that looks like a button remains a div – unusable for screen readers and not focusable.
• Legal uncertainty: Since the actual deficiencies remain, overlays offer no guarantee of compliance with laws such as the EAA (BFSG). You risk your customers' compliance.
• Performance & Conflicts: Additional JavaScript slows down the page, causes script conflicts and degrades the user experience.

Other Plugins (e.g. Attributes for Blocks)

These plugins offer very limited customization and are not intended for accessibility. They are unsuitable for complex layouts or complete control.

• Limited customization options: Changes only possible on the main wrapper of a block.
• No adjustment of nested elements: e.g. a link in a card.
• HTML tags cannot be changed: e.g. a div cannot be converted into a button.
• No global rules or dynamic variables: e.g. no possibility to create a rule for all buttons in a block.
• No security: Static values are saved in the content and can cause unpredictable errors if deactivated.

• 1.1.1 (A) WCAG 2.2

  Have you provided meaningful text alternatives for all non-text content?

• 1.3.1 (A) WCAG 2.2

  Have you ensured that information and their relationships are programmatically discernible?

• 1.3.2 (A) WCAG 2.2

  Is the content presented in a meaningful sequence so that the meaning is maintained?

• 1.3.3 (A) WCAG 2.2

  Do instructions not rely exclusively on sensory characteristics?

• 1.3.4 (AA) WCAG 2.2

  Is the content not restricted to a single orientation?

• 1.3.5 (AA) WCAG 2.2

  Can the purpose of each input field be programmatically determined?

• 1.4.1 (A) WCAG 2.2

  Is color not used as the sole means of conveying information?

• 1.4.2 (A) WCAG 2.2

  Can you control automatically playing audio (pause or stop)?

• 1.4.3 (AA) WCAG 2.2

  Have you ensured an adequate contrast ratio between text and background?

• 1.1.1 (A) WCAG 2.2

  Have you provided meaningful text alternatives for all non-text content?

• 1.3.1 (A) WCAG 2.2

  Have you ensured that information and their relationships are programmatically discernible?

• 1.3.2 (A) WCAG 2.2

  Is the content presented in a meaningful sequence so that the meaning is maintained?

• 1.3.3 (A) WCAG 2.2

  Do instructions not rely exclusively on sensory characteristics?

• 1.3.4 (AA) WCAG 2.2

  Is the content not restricted to a single orientation?

• 1.3.5 (AA) WCAG 2.2

  Can the purpose of each input field be programmatically determined?

• 1.4.1 (A) WCAG 2.2

  Is color not used as the sole means of conveying information?

• 1.4.2 (A) WCAG 2.2

  Can you control automatically playing audio (pause or stop)?

• 1.4.3 (AA) WCAG 2.2

  Have you ensured an adequate contrast ratio between text and background?

• 1.4.4 (AA) WCAG 2.2

  Can the text be resized up to 200% without losing content?

• 1.4.5 (AA) WCAG 2.2

  Is text not unnecessarily presented as an image?

• 1.4.10 (AA) WCAG 2.2

  Does the content adapt flexibly to different screen sizes without losing information?

• 1.4.11 (AA) WCAG 2.2

  Do non-text elements (icons, buttons) have an adequate contrast ratio?

• 1.4.12 (AA) WCAG 2.2

  Are text spacings chosen so that the text remains easily readable even with adapted presentation?

• 1.4.13 (AA) WCAG 2.2

  Are additional contents that appear on hover or focus not unintentionally hidden or covered?

• 2.1.1 (A) WCAG 2.2

  Can you operate all functions of your website exclusively with the keyboard?

• 2.1.2 (A) WCAG 2.2

  Can you leave the keyboard focus of every element again?

• 2.1.4 (A) WCAG 2.2

  Are keyboard shortcuts only active when the corresponding element is focused, or can they be disabled?

• 1.4.4 (AA) WCAG 2.2

  Can the text be resized up to 200% without losing content?

• 1.4.5 (AA) WCAG 2.2

  Is text not unnecessarily presented as an image?

• 1.4.10 (AA) WCAG 2.2

  Does the content adapt flexibly to different screen sizes without losing information?

• 1.4.11 (AA) WCAG 2.2

  Do non-text elements (icons, buttons) have an adequate contrast ratio?

• 1.4.12 (AA) WCAG 2.2

  Are text spacings chosen so that the text remains easily readable even with adapted presentation?

• 1.4.13 (AA) WCAG 2.2

  Are additional contents that appear on hover or focus not unintentionally hidden or covered?

• 2.1.1 (A) WCAG 2.2

  Can you operate all functions of your website exclusively with the keyboard?

• 2.1.2 (A) WCAG 2.2

  Can you leave the keyboard focus of every element again?

• 2.1.4 (A) WCAG 2.2

  Are keyboard shortcuts only active when the corresponding element is focused, or can they be disabled?

Semanticality™ Plugin for WordPress Gutenberg

With Semanticality™ you get granular control over the HTML output of every Gutenberg block – dynamically, securely and server-side. You define rules, Semanticality™ implements them automatically in the code. Here is the full range of functions:

• Element addressing via CSS Selector.
• Change HTML tags (e.g. div to button).
• Add & remove attributes.
• Extend attributes (append, change, prepend, replace).
• Global rules for block types.
• Local rules for individual blocks.
• The ability to define rules for child blocks within parent blocks (e.g. create a rule for all paragraphs in a group).
• Copying and inserting of rules between blocks.
• Access to WordPress meta fields.
• Random IDs generated.
• Live preview of rendered code directly in the block editor.

The Result: Up to 10x faster project implementation*, predictable costs and a clear competitive advantage for you and your customers.

Get started with Semanticality™ now

Is Semanticality™ actually suitable for your project?

Everything that goes beyond the structure & semantics of the HTML must be solved in design, content or JS, and therefore not with Semanticality™.

Semanticality™ is a Swiss Army knife for the semantics of your website. It helps you address many important WCAG 2.2 criteria that are based on correct HTML & ARIA**.

Case Study: A div becomes an accessible section.

In a few clicks you convert a purely visual container into a semantically correct section with landmark according to WCAG 2.2 techniques ARIA11 and ARIA13.

This improves orientation for screen reader users and is sufficient to meet WCAG 2.2 success criteria 1.3.1 "Info and Relationships" and 2.4.1 "Bypass Blocks"***.

Open Semanticality™ Rules Editor for the block

Before you start, select the section in the Block Editor and open the Semanticality™ Rules Editor. The rules you define here only apply to this block, unless you save them as a global rule.

1. Select a section in the Gutenberg Block Editor that you want to customize.
2. Press the Semanticality™ Button in the block's toolbar.

Rule 1: div → section

First, you convert the block wrapper from a div to a section. On the right in the Live Code Preview you can see the change immediately.

1. Click on Local Block Rules in the tab + Add Rule. If you want to save the rule for all blocks of this type on the entire website, you can also create it in the tab Global Block Rules.
2. Select Change Tag as the Action.
3. Define the CSS selector of the block wrapper (e.g. .wp-block-group with Mode on First).

Rule 2: Heading ID

Next, you give the heading a stable ID that you can reference later.

1. Click on + Add Rule again to add another rule.
2. For Action, this time select Modify Attribute.
3. Define the CSS selector of the heading (e.g. h2 with Mode on First).
4. Select id as the attribute in the Attribute Name field.
5. In the Insertion field, select Add / Replace.
6. In the {code} field, enter the ID. You can use a static ID like hero-title or a dynamic ID like {{ id_dein_label }} here.

Rule 3: aria-labelledby

Finally, you add the aria-labelledby attribute to the block wrapper, which refers to the ID of the heading.

1. Click on + Add Rule again to add another rule.
2. For Action, this time select Modify Attribute.
3. Define the CSS selector of the section (e.g. section with Mode on First. The lower rules always assume that the upper ones have already been applied. That's why you can now simply select section here).
4. Select aria-labelledby as the attribute in the Attribute Name field.
5. In the Insertion field, select Add / Replace.
6. In the Value field, enter the ID you gave the heading.
7. Click on Save Block Local Rules to save the rules and apply them to the block.
8. Save the page and test in the frontend. If you do not save the page, the rules will be lost after leaving the editor.

Result: Screen readers recognize a named landmark, navigation is now more meaningful, and you meet WCAG 2.2: 1.3.1, 2.4.1 at the markup level - completely without theme modification.

Who is the Semanticality™ Plugin suitable for?

We developed Semanticality™ for ourselves as accessibility experts and have successfully used it in numerous projects. Now we want to share this tool with other developers.

Choose Your Semanticality™ Plan – all features, tiered by sites & support.

An investment that pays off immediately. Compare the cost of an annual license with a developer's hourly rate (approx. €100). After just 2-3 hours saved Semanticality™ pays for itself for the entire year*!

All licenses are based on simultaneous activations and are transferable at any time. Finish a client project, deactivate the license with one click, and use it for your next job. Perfect for a developer's daily work.

Test Semanticality™ for 14 days 100% risk-free: If you are not convinced, you will get your money back – no questions asked*****. Secure your 20% Launch Discount for the first year with the code LAUNCH20 until November 30, 2025.

Do you still have questions?

What exactly does Semanticality™ do?

Where can I see how the plugin is operated?

Does the plugin slow down my website?

Does Semanticality™ work with every theme and all block plugins?

Is Semanticality™ also compatible with Kadence Blocks?

Is Semanticality™ also compatible with Elementor?

Is Semanticality™ also compatible with Divi?

What happens if I change my theme?

What if my own scripts dynamically change attributes?

What happens if I deactivate the plugin?

What counts as a "Site" for Semanticality™? Does staging & localhost count?

What are the technical requirements (WordPress/PHP)?

Is Semanticality™ compatible with caching or minify plugins?

Does Semanticality™ support multilingual websites (WPML, Polylang)?

Is there user documentation for Semanticality™?

Which WCAG 2.2 success criteria can I meet with Semanticality™?

Does Semanticality™ automatically make my website accessible?

What do I do if I have more than 25 websites as an agency?

How does the license work with client projects?

Can I transfer a license to another domain or to a client?

Can I upgrade or downgrade my plan later?

Why is Semanticality™ a subscription and not a one-time payment?

What is included in the support, how quickly do I receive help – and are there ticket limits?

How do I use the 14-day money-back guarantee?

How do I redeem the voucher code LAUNCH20?

Does the plugin send data to external servers? GDPR note

Can I export my rules and reuse them in other projects?

Where do I see the roadmap and how do I submit feature requests?

How exactly does the license model work?

What happens if my license expires after one year?

Is there a partner or affiliate program?

Is the plugin Open Source? Why do I pay then?