Diese Website soll für möglichst viele Menschen gut nutzbar sein.
Ich orientiere mich bei Gestaltung und technischer Umsetzung an WCAG 2.2 auf Konformitätsstufe AA. Dazu gehören klare Struktur, Tastaturbedienung, ausreichende Kontraste, verständliche Formulare und Rücksicht auf reduzierte Bewegung.
ZielZugänglich
TastaturKontrastStrukturReduced Motion
Grundsatz
Wie wird die Website zugänglich gestaltet?
Die Website wird mit dem Ziel umgesetzt, Inhalte wahrnehmbar, bedienbar, verständlich und robust bereitzustellen. Orientierung bieten WCAG 2.2 auf Konformitätsstufe AA, semantische Struktur, Tastaturbedienung, ausreichende Kontraste und reduzierte Bewegung.
So ist es vorgesehen
Barrierefreiheit wird nicht als Zusatz behandelt.
Sie gehört zu Navigation, Texten, Farben, Formularen, Bewegungen und technischen Komponenten. Die Live-Website wird deshalb nicht nur visuell, sondern auch mit Tastatur, Zoom und Hilfstechnologien geprüft.
01Bedienbar
Navigation, Links, Buttons und Formulare müssen mit Tastatur erreichbar und klar fokussierbar sein.
02Verständlich
Überschriften, Linktexte, Fehlermeldungen und Formulare sollen ohne unnötige Fachsprache funktionieren.
03Robust
Semantisches HTML und passende ARIA-Attribute unterstützen Screenreader und andere assistive Technologien.
Bewegung & Medien
Animationen bleiben dezent und abschaltbar.
Parallax- und Reveal-Effekte sind rein dekorativ. Bei aktivierter Systemeinstellung „Bewegung reduzieren“ werden sie deaktiviert. Wichtige Informationen stehen immer als Text zur Verfügung und werden nicht ausschließlich über Farbe, Animation oder Grafik vermittelt.
Barriere melden
Etwas funktioniert für dich nicht?
Hinweise zu Barrieren helfen, die Website zu verbessern. Beschreibe möglichst kurz, auf welcher Seite und bei welcher Funktion das Problem auftritt.
Hinweis zur Barrierefreiheit senden
Du kannst dafür das Kontaktformular oder E-Mail nutzen.
Die tatsächliche Konformität wird am Live-System geprüft.
Diese Vorlagenseite beschreibt den vorgesehenen Qualitätsstandard. Vor Veröffentlichung werden Inhalte, Formulare, Navigation, Kontraste, Zoom/Reflow und assistive Nutzung am realen WordPress-System geprüft. Falls für das konkrete Angebot gesetzliche Informationspflichten nach dem BFSG gelten, werden die dafür erforderlichen Angaben gesondert rechtlich geprüft und ergänzt.
Bricks Designsystem · Section-Zuordnung
Welche Klassen und Variablen werden für diese Seite verwendet?
Die Reihenfolge entspricht der sichtbaren Seite von oben nach unten. Grundregel: Section-Farbklasse + optionaler Größenmodifikator → Container-Klasse → Layout-/Komponentenklasse. Einzelwerte nur dort, wo das Layout wirklich seitenbezogen ist.
Verbindliche Hero-Komponente: `hero-layout` auf dem inneren Layout-Wrapper, `hero-inhalt` auf der linken Inhaltsspalte und `hero-grafik` auf der rechten Grafikspalte. Eyebrow: `text-eyebrow`; Lead/Subheadline: `text-subheadline`; Buttons: `button-gruppe`. Tablet Hochformat (≤991 px) bleibt zweispaltig; erst Mobile Landscape (≤767 px) wird einspaltig gestapelt; bei Mobile Portrait (≤478 px) stehen die Buttons untereinander. Vorhandene individuelle Breakpoint-Werte für Spaltenbreite oder Textausrichtung in Bricks entfernen.
Kompakter Antwortblock. Für die asymmetrische 0,72/1,28-Aufteilung das bestehende Answer-Grid als eigene Komponentenklasse beibehalten. Eyebrow: Klasse `text-eyebrow`.
Normale Inhaltssektion auf weißer Fläche. Eyebrow: Klasse `text-eyebrow`.
Nur für die Umsetzung
SEOPress, SEO & KI-Suche
Diese Angaben gehören in SEOPress bzw. in die redaktionelle/technische Umsetzung. Den gesamten grünen Arbeitsbereich auf der Live-Website nicht als sichtbaren Inhalt übernehmen.
SEO-Titel
Barrierefreiheit | Roland Thunig
Meta-Beschreibung
Informationen zur barrierearmen Nutzung der Website von Roland Thunig sowie Kontaktmöglichkeit für Hinweise zu Barrieren.
Canonical URL
https://www.roland-thunig.de/barrierefreiheit/
Fokus-Keyphrase
keine erzwungene Fokus-Keyphrase
Robots
index, follow
Suchintention
Informationen zur barrierearmen Nutzung der Website und Möglichkeit, Barrieren zu melden.
Kernfrage für KI-/Suchantworten
Wie wird die Website zugänglich gestaltet?
Zitierfähige Kernaussage
Die Website wird mit dem Ziel umgesetzt, Inhalte wahrnehmbar, bedienbar, verständlich und robust bereitzustellen. Orientierung bieten WCAG 2.2 auf Konformitätsstufe AA, semantische Struktur, Tastaturbedienung, ausreichende Kontraste und reduzierte Bewegung.
Wichtige Entitäten
Roland Thunig; Barrierefreiheit; WCAG 2.2; Tastaturbedienung; Reduced Motion
Schema / SEOPress
WebPage; keine besondere Rich-Result-Auszeichnung erforderlich
Social-Bild
Barrierefreiheit: 1200×630-Motiv mit Fokus, Tastatur, Kontrast und Struktur
XML-Sitemap
aufnehmen
Breadcrumbs
sichtbar in Bricks; BreadcrumbList über SEOPress PRO, falls eingesetzt
Global: SEOPress Knowledge Graph auf „Person“ mit echten, konsistenten Kontaktdaten und nur tatsächlich vorhandenen Profilen (sameAs) pflegen. XML-Sitemap und Open Graph aktivieren. FAQ-Inhalte sichtbar lassen, aber FAQ-Schema nicht als Rich-Result-Strategie einplanen.
KI-Suche & Crawling
Wichtige Aussagen als sichtbaren HTML-Text ausgeben; nicht nur in SVG, Canvas, Tabs oder Bildern verstecken.
OAI-SearchBot in robots.txt zulassen. Googlebot und Bingbot weder in robots.txt noch durch Firewall/Bot-Schutz unbeabsichtigt blockieren.
GPTBot ist in dieser Vorlage für potenzielles Training gesperrt; diese Entscheidung beeinflusst OAI-SearchBot für ChatGPT Search nicht.
Keine künstlichen GEO-/AEO-Seiten und kein llms.txt als Rankingmaßnahme. Stattdessen klare Nutzerfragen, eigene Fachperspektive, Referenzen und belastbare Inhalte.
Nach Livegang messen: Google Search Console (Generative AI), Bing Webmaster Tools und ChatGPT-Verweise mit utm_source=chatgpt.com.
Bricks-Umsetzung
Die Seite nativ in Bricks aufbauen. Zusätzlich zu Layout und Breakpoints gelten verbindlich die Kapitel Barrierefreiheit, Datenschutz und KI-Suche. Öffentliche Texte nennen weiterhin nur WordPress und WooCommerce, nicht den Pagebuilder.
