Semanti­cality™ Plugin für Word­Press-Guten­berg.

Warum echte Barriere­frei­heit in Word­Press so schwer ist?

Du kennst das: Ein Kunde liebt das Design seines neuen Premium-Themes, doch der von Guten­berg erzeugte HTML-Code ist ein semantisches Minenfeld. Hier kommt Semanti­cality™ ins Spiel.

Echte Barriere­frei­heit entsteht durch korrekten, semantischen HTML-Code – doch genau hier stoßen Entwickler bei Word­Press schnell an Grenzen: Es gibt kaum Möglichkeiten, den Code anzupassen, ohne das Theme komplett neu zu programmieren.

<div class="wp-block-card">
  <div class="wp-block-card__title">Mein Kartentitel</div>
  <div class="wp-block-card__content">Hier steht der Inhalt.</div>
  <div class="wp-block-card__link" onclick="location.href='/mehr'">Mehr lesen</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">Mein Kartentitel</h3>
  <p class="wp-block-card__content">Hier steht der Inhalt.</p>
  <a href="/mehr" class="wp-block-card__link" aria-label="Mehr über 'Mein Kartentitel' lesen">Mehr lesen</a>
</article>
      

Besonders im Kontext des neuen BFSG ist das unverzichtbar, um die gesetzlichen Anforderungen zu erfüllen. Semanti­cality™ eignet sich ideal, um nach einem BFSG-Audit die HTML-bezogene Maßnahmen in wenigen Stunden statt in Monaten umzusetzen*.

• Die technische Grundlage Deiner Arbeit

  Mit Semanti­cality™ arbeitest Du direkt auf der HTML-Struktur, die dem Barriere­frei­heits-Objektmodell (AOM) zugrunde liegt. Im Guten­berg Block Editor korrigierst Du den Code grafisch anhand von Regeln – diese werden während des Renders angewendet.

  Du korrigierst den fehlerhaften HTML-Code mit Semanti­cality™, bevor er in eine Knoten-Baumstruktur mit korrekten Hinweisen umgewandelt wird.

  [Heading level 2] Produktübersicht

  [Paragraph] Das ist ein zugänglicher Text...

  Nutzer können dank des korrekten AOM einfach navigieren und Inhalte vorlesen lassen.

  

• Barrierefreiheitsstandards, die Du erfüllst

  Mit Semanti­cality™ schaffst Du die technische Grundlage für zentrale Anforderungen aus WCAG 2.2 / EN 301 549 / BITV 2.0 / BFSG – dort, wo semantischer HTML-Code & ARIA gefragt sind – ganz ohne Theme-Umbau**.

  • 

    ISO 40500:2012

    Internationaler Standard zur Barriere­frei­heit

  • 

    WAI-ARIA

    Technologie zur Umsetzung von Barriere­frei­heit

  • 

    WHATWG

    HTML5-Standard

  • 

    WCAG 2.2 AA

    Internationale Richtlinien für Website Barriere­frei­heit

  • 

    ISO 40500:2012

    Internationaler Standard zur Barriere­frei­heit

  • 

    WAI-ARIA

    Technologie zur Umsetzung von Barriere­frei­heit

  • 

    WHATWG

    HTML5-Standard

  • 

    WCAG 2.2 AA

    Internationale Richtlinien für Website Barriere­frei­heit

  • 

    EAA

    Anforderungen für D2C / B2C Unternehmen in der EU

  • 

    BITV 2.0

    Anforderungen für öffentliche Stellen in Deutschland

  • 

    ADA

    Amerikanische Barriere­frei­heits­gesetz­gebung

  • 

    BFSG

    Umsetzung von EAA in Deutschland

  • 

    EAA

    Anforderungen für D2C / B2C Unternehmen in der EU

  • 

    BITV 2.0

    Anforderungen für öffentliche Stellen in Deutschland

  • 

    ADA

    Amerikanische Barriere­frei­heits­gesetz­gebung

  • 

    BFSG

    Umsetzung von EAA in Deutschland

• Ein robustes Fundament. Für jeden Nutzer.

  Passe Deine Guten­berg-Blöcke in kürzester Zeit an und optimiere Deine Website für Barriere­frei­heit** und BFSG-Compliance*** in Stunden statt in Monaten*.

  Jetzt mit Semanti­cality™ durchstarten

  

  

Mehr als nur ein Attribut-Plugin. Granulare Kontrolle. Über jeden Gutenberg-Block.

Andere Plugins erlauben oft nur das Hinzufügen von einfachen Attributen zum Haupt-Wrapper eines Guten­berg-Blocks.

Semanti­cality™ geht entscheidende Schritte weiter und gibt Dir granulare Kontrolle über jedes einzelne Element innerhalb Deiner Word­Press-Guten­berg-Blöcke.

Overlay-Widgets

Overlay-Widgets versprechen Barriere­frei­heit per Knopfdruck, sind aber nur ein Pflaster. Sie ändern den zugrundeliegenden Code nicht und reichen für echte Barriere­frei­heit oder Compliance in der Regel nicht aus[1].

• Keine semantische Korrektur: Ein div, das wie ein Button aussieht, bleibt ein div – für Screen­reader unbrauchbar und nicht fokussierbar.
• Rechtliche Unsicherheit: Da die eigentlichen Mängel bestehen bleiben, bieten Overlays keine Garantie für die Einhaltung von Gesetzen wie dem BFSG. Du riskierst die Compliance Deiner Kunden.
• Performance & Konflikte: Zusätzliches JavaScript verlangsamt die Seite, verursacht Skript-Konflikte und verschlechtert die Nutzererfahrung.

Andere Plugins (z. B. Attributes for Blocks)

Diese Plugins bieten nur sehr eingeschränkte Anpassungen und sind nicht für Barriere­frei­heit gedacht. Für komplexe Layouts oder vollständige Kontrolle sind sie ungeeignet.

• Begrenzte Anpassungs­möglich­keiten: Änderungen nur am Haupt-Wrapper eines Blocks möglich.
• Keine Anpassung verschachtelter Elemente: z. B. ein Link in einer Karteikarte.
• HTML-Tags lassen sich nicht ändern: z. B. ein div kann nicht in einen Button umgewandelt werden.
• Keine globalen Regeln oder dynamischen Variablen: z. B. keine Möglichkeit, eine Regel für alle Buttons in einem Block zu erstellen.
• Keine Sicherheit: Statische Werte werden im Inhalt gespeichert und können bei Deaktivierung unvorhersehbare Fehler verursachen.

• 1.1.1 (A) WCAG 2.2

  Hast Du für alle nicht‐textuellen Inhalte einen sinnvollen Textalternativtext angegeben?

• 1.3.1 (A) WCAG 2.2

  Hast Du sichergestellt, dass Informationen und ihre Beziehungen programmgesteuert erkennbar sind?

• 1.3.2 (A) WCAG 2.2

  Wird der Inhalt in einer sinnvollen Reihenfolge präsentiert, sodass der Sinn erhalten bleibt?

• 1.3.3 (A) WCAG 2.2

  Verlassen sich Anweisungen nicht ausschließlich auf sensorische Eigenschaften?

• 1.3.4 (AA) WCAG 2.2

  Wird der Inhalt nicht auf eine einzige Ausrichtung beschränkt?

• 1.3.5 (AA) WCAG 2.2

  Kann der Zweck jedes Eingabefeldes programmgesteuert bestimmt werden?

• 1.4.1 (A) WCAG 2.2

  Wird Farbe nicht als einziges Mittel zur Informationsvermittlung verwendet?

• 1.4.2 (A) WCAG 2.2

  Kannst Du automatisch abspielende Audiodateien steuern (anhalten oder stoppen)?

• 1.4.3 (AA) WCAG 2.2

  Hast Du ein ausreichendes Kontrastverhältnis zwischen Text und Hintergrund sichergestellt?

• 1.1.1 (A) WCAG 2.2

  Hast Du für alle nicht‐textuellen Inhalte einen sinnvollen Textalternativtext angegeben?

• 1.3.1 (A) WCAG 2.2

  Hast Du sichergestellt, dass Informationen und ihre Beziehungen programmgesteuert erkennbar sind?

• 1.3.2 (A) WCAG 2.2

  Wird der Inhalt in einer sinnvollen Reihenfolge präsentiert, sodass der Sinn erhalten bleibt?

• 1.3.3 (A) WCAG 2.2

  Verlassen sich Anweisungen nicht ausschließlich auf sensorische Eigenschaften?

• 1.3.4 (AA) WCAG 2.2

  Wird der Inhalt nicht auf eine einzige Ausrichtung beschränkt?

• 1.3.5 (AA) WCAG 2.2

  Kann der Zweck jedes Eingabefeldes programmgesteuert bestimmt werden?

• 1.4.1 (A) WCAG 2.2

  Wird Farbe nicht als einziges Mittel zur Informationsvermittlung verwendet?

• 1.4.2 (A) WCAG 2.2

  Kannst Du automatisch abspielende Audiodateien steuern (anhalten oder stoppen)?

• 1.4.3 (AA) WCAG 2.2

  Hast Du ein ausreichendes Kontrastverhältnis zwischen Text und Hintergrund sichergestellt?

• 1.4.4 (AA) WCAG 2.2

  Lässt sich der Text bis zu 200% vergrößern, ohne dass Inhalte verloren gehen?

• 1.4.5 (AA) WCAG 2.2

  Wird Text nicht unnötigerweise als Bild dargestellt?

• 1.4.10 (AA) WCAG 2.2

  Passt sich der Inhalt flexibel an verschiedene Bildschirmgrößen an, ohne dass Informationen verloren gehen?

• 1.4.11 (AA) WCAG 2.2

  Haben nicht‑textuelle Elemente (Icons, Schaltflächen) ein ausreichendes Kontrastverhältnis?

• 1.4.12 (AA) WCAG 2.2

  Sind die Textabstände so gewählt, dass der Text auch bei angepasster Darstellung gut lesbar bleibt?

• 1.4.13 (AA) WCAG 2.2

  Werden zusätzliche Inhalte, die bei Hover oder Fokus erscheinen, nicht ungewollt versteckt oder überdeckt?

• 2.1.1 (A) WCAG 2.2

  Kannst Du alle Funktionen Deiner Website ausschließlich mit der Tastatur bedienen?

• 2.1.2 (A) WCAG 2.2

  Kannst Du den Tastaturfokus von jedem Element wieder verlassen?

• 2.1.4 (A) WCAG 2.2

  Sind Tastenkombinationen nur aktiv, wenn das zugehörige Element fokussiert ist, oder können sie deaktiviert werden?

• 1.4.4 (AA) WCAG 2.2

  Lässt sich der Text bis zu 200% vergrößern, ohne dass Inhalte verloren gehen?

• 1.4.5 (AA) WCAG 2.2

  Wird Text nicht unnötigerweise als Bild dargestellt?

• 1.4.10 (AA) WCAG 2.2

  Passt sich der Inhalt flexibel an verschiedene Bildschirmgrößen an, ohne dass Informationen verloren gehen?

• 1.4.11 (AA) WCAG 2.2

  Haben nicht‑textuelle Elemente (Icons, Schaltflächen) ein ausreichendes Kontrastverhältnis?

• 1.4.12 (AA) WCAG 2.2

  Sind die Textabstände so gewählt, dass der Text auch bei angepasster Darstellung gut lesbar bleibt?

• 1.4.13 (AA) WCAG 2.2

  Werden zusätzliche Inhalte, die bei Hover oder Fokus erscheinen, nicht ungewollt versteckt oder überdeckt?

• 2.1.1 (A) WCAG 2.2

  Kannst Du alle Funktionen Deiner Website ausschließlich mit der Tastatur bedienen?

• 2.1.2 (A) WCAG 2.2

  Kannst Du den Tastaturfokus von jedem Element wieder verlassen?

• 2.1.4 (A) WCAG 2.2

  Sind Tastenkombinationen nur aktiv, wenn das zugehörige Element fokussiert ist, oder können sie deaktiviert werden?

Semanti­cality™ Plugin für Word­Press-Guten­berg

Mit Semanti­cality™ erhältst Du granulare Kontrolle über den HTML-Output jedes Guten­berg-Blocks – dynamisch, sicher und serverseitig. Du definierst Regeln, Semanti­cality™ setzt sie automatisch im Code um. Hier ist der vollständige Funktionsumfang:

• Element-Ansprache per CSS-Selektor.
• HTML-Tags ändern (z.B. divdiv{/code1} zu buttonbutton{/code2}).
• Attribute hinzufügen & entfernen.
• Attribute erweitern (anfügen, ändern, voranstellen, ersetzen).
• Globale Regeln für Block-Typen.
• Lokale Regeln für einzelne Blöcke.
• Die Möglichkeit bei Eltern-Blöcken die Regeln für Kinder-Blöcke zu definieren (z. B. in einer Gruppe für alle Paragraphen eine Regel erstellen).
• Kopieren und Einsetzen von Regeln zwischen Blöcken.
• Zugriff auf Word­Press-Meta-Felder.
• Zufällige IDs generieren lassen.
• Live-Vorschau von gerendertem Code direkt im Block-Editor.

Das Ergebnis: Bis zu 10x schnellere Projekt­umsetzung*, planbare Kosten und ein klarer Wett­bewerbs­vorteil für Dich und Deine Kunden.

Jetzt mit Semanti­cality™ durchstarten

Passt Semanti­cality™ eigentlich für Dein Projekt?

Alles, was über Struktur & Semantik des HTML hinausgeht, muss in Design, Inhalt oder JS gelöst werden, nicht im Markup und damit auch nicht mit Semanti­cality™.

Semanti­cality™ ist ein schweizer Taschenmesser für die Semantik Deiner Website. Es hilft Dir, viele wichtige WCAG 2.2-Kriterien zu adressieren, die auf korrektem HTML & ARIA basieren**.

Fallstudie: Aus einem div wird eine zugängliche Sektion.

In wenigen Klicks wandelst Du einen rein visuellen Container in eine semantisch korrekte Sektion mit Landmark gemäß WCAG 2.2 Techniken ARIA11 und ARIA13.

Das verbessert Orientierung für Screen­reader-Nutzer und ist ausreichend, um WCAG 2.2 Erfolgskriterien 1.3.1 "Informationen und Beziehungen" und 2.4.1 "Blöcke umgehen" zu erfüllen***.

Semanti­cality™ Rules Editor für den Block öffnen

Bevor Du beginnst, wähle die Sektion im Block-Editor aus und öffne den Semanti­cality™ Rules Editor. Die Regeln, die Du hier definierst, gelten nur für diesen Block, solange Du sie nicht als globale Regel speicherst.

1. Wähle eine Sektion im Guten­berg Block Editor aus, die Du anpassen möchtest.
2. Drücke auf den Semanti­cality™ Button in der Werkzeugleiste des Blocks.

Regel 1: div → section

Als Erstes wandelst Du den Block-Wrapper von einem div in eine section um. Rechts im Live Code Preview siehst Du die Änderung sofort.

1. Im Reiter Local Block Rules auf + Add Rule klicken. Falls Du die Regel für alle Blöcke dieses Typs auf der gesamten Website speichern möchtest, kannst Du sie auch im Reiter Global Block Rules anlegen.
2. Wähle Change Tag als Action.
3. Definiere den CSS-Selektor des Block-Wrappers (z. B. .wp-block-group mit Mode auf First).

Regel 2: Überschrift ID

Als Nächstes gibst Du der Überschrift eine stabile ID, die Du später referenzieren kannst.

1. Klicke erneut auf + Add Rule, um eine weitere Regel hinzuzufügen.
2. Als Action wähle dieses Mal Modify Attribute.
3. Definiere den CSS-Selektor der Überschrift (z. B. h2 mit Mode auf First).
4. Wähle id als Attribut im Feld Attribute Name.
5. Im Feld Insertion wähle Add / Replace.
6. Im Feld Value gibst Du die ID ein. Du kannst hier eine statische ID wie hero-title oder eine dynamische ID wie {{ id_dein_label }} verwenden.

Regel 3: aria-labelledby

Schließlich fügst Du dem Block-Wrapper das Attribut aria-labelledby hinzu, das auf die ID der Überschrift verweist.

1. Klicke erneut auf + Add Rule, um eine weitere Regel hinzuzufügen.
2. Als Action wähle dieses Mal Modify Attribute.
3. Definiere den CSS-Selektor der Sektion (z. B. section mit Mode auf First. Die unteren Regeln gehen immer davon aus, dass die oberen bereits angewendet wurden. Deswegen kannst Du hier jetzt einfach section auswählen.).
4. Wähle aria-labelledby als Attribut im Feld Attribute Name.
5. Im Feld Insertion wähle Add / Replace.
6. Im Feld Value gibst Du die ID ein, die Du der Überschrift gegeben hast.
7. Auf Save Block Local Rules klicken, um die Regeln zu speichern und auf den Block anzuwenden.
8. Seite speichern und im Frontend testen. Wenn Du die Seite nicht speicherst, werden die Regeln nach dem Verlassen des Editors verloren gehen.

Ergebnis: Screen­reader erkennen eine benannte Landmark, die Navigation ist jetzt sinnvoller, und Du erfüllst WCAG 2.2: 1.3.1, 2.4.1 auf der Markup-Ebene - ganz ohne Theme-Umbau.

Für wen ist Semanti­cality™ Plugin geeignet?

Wir haben Semanti­cality™ für uns als Barriere­frei­heits­experten entwickelt und bei zahlreichen Projekten erfolgreich eingesetzt. Jetzt möchten wir dieses Werkzeug mit anderen Entwicklern teilen.

Wähle Deinen Semanti­cality™-Plan – alle Features, gestaffelt nach Sites & Support.

Eine Investition, die sich sofort auszahlt. Vergleiche die Kosten einer Jahreslizenz mit dem Stundensatz eines Entwicklers (ca. 100 €). Schon nach 2-3 gesparten Stunden rechnet sich Semanti­cality™ für das ganze Jahr*!

Alle Lizenzen basieren auf gleichzeitigen Aktivierungen und sind jederzeit übertragbar. Schließe ein Kundenprojekt ab, deaktiviere die Lizenz mit einem Klick und setze sie für Deinen nächsten Auftrag ein. Perfekt für den Entwickler-Alltag.

Teste Semanti­cality™ 14 Tage lang 100 % risikofrei: Wenn Du nicht überzeugt bist, erhältst Du Dein Geld zurück – ohne Wenn und Aber*****. Sichere Dir jetzt noch bis zum 31. Oktober 2025 mit dem Code LAUNCH20 den Launch-Rabatt von 20 % für das erste Jahr.

Hast Du noch Fragen?

Was genau macht Semanti­cality™?

Wo kann ich sehen, wie das Plugin bedient wird?

Verlangsamt das Plugin meine Website?

Funktioniert Semanti­cality™ mit jedem Theme und allen Block-Plugins?

Ist Semanti­cality™ auch mit Kadence Blocks kompatibel?

Ist Semanti­cality™ auch mit Elementor kompatibel?

Ist Semanti­cality™ auch mit Divi kompatibel?

Was passiert, wenn ich mein Theme wechsle?

Was wenn meine eigenen Skripte Attribute dynamisch ändern?

Was passiert, wenn ich das Plugin deaktiviere?

Was gilt bei Semanti­cality™ als „Site“? Zählt Staging & Localhost mit?

Welche technischen Voraussetzungen gibt es (Word­Press/PHP)?

Verträgt sich Semanti­cality™ mit Caching- oder Minify-Plugins?

Unterstützt Semanti­cality™ mehrsprachige Websites (WPML, Polylang)?

Gibt es zu Semanti­cality™ eine Benutzerdokumentation?

Welche WCAG 2.2 Erfolgskriterien kann ich mit Semanti­cality™ erfüllen?

Macht Semanti­cality™ meine Website automatisch barrierefrei?

Was mache ich, wenn ich als Agentur mehr als 25 Websites habe?

Wie funktioniert die Lizenz bei Kundenprojekten?

Kann ich eine Lizenz auf eine andere Domain oder an einen Kunden übertragen?

Kann ich meinen Plan später upgraden oder downgraden?

Warum ist Semanti­cality™ ein Abonnement und keine Einmalzahlung?

Was beinhaltet der Support, wie schnell erhalte ich Hilfe – und gibt es Ticket-Limits?

Wie nutze ich die 14-Tage-Geld-zurück-Garantie?

Wie löse ich den Gutschein-Code LAUNCH20 ein?

Sendet das Plugin Daten an externe Server? DSGVO-Hinweis

Kann ich meine Regeln exportieren und in anderen Projekten wiederverwenden?

Wo sehe ich die Roadmap und wie reiche ich Feature-Wünsche ein?

Wie funktioniert das Lizenzmodell genau?

Was passiert, wenn meine Lizenz nach einem Jahr abläuft?

Gibt es ein Partner- oder Affiliate-Programm?

Ist das Plugin Open Source? Warum zahle ich dann?