Projekte

Projekt: Bewerbungsseite – Barrierearm-Optimierung (Baukasten)

Zeitraum: seit 02/2026 · laufend

Kontext: Umsetzung und Optimierung in einem Website-Baukasten (ohne eigenes Coding)

Projektaufbau (Hauptseite vs. barrierearm)

Die Bewerbungsseite existiert in zwei Varianten:

Hauptseite: Standard-Version im typischen Baukasten-Design
Barrierearm: eigenständige, reduzierte Version mit gleicher Grundstruktur, die schrittweise WCAG-orientiert optimiert wird

Dieses Projekt beschreibt die fortlaufende Optimierung der barrierearmen Version mit dem Ziel, die Seite so zugänglich wie möglich zu gestalten und die Grenzen des Baukastens transparent zu dokumentieren.

Ziel

Ich untersuche, wie weit sich eine typische Baukasten-Bewerbungsseite barrierearm bzw. WCAG-orientiert verbessern lässt – mit Fokus auf Lesbarkeit, Struktur, Bedienbarkeit und realistischen Systemgrenzen.

Vorgehen

Aufbau einer barrierearm optimierten Version als eigenständige Seite (gleiche Grundstruktur, reduziertes Design)
Schrittweise Optimierung in Iterationen (Änderung → Test → Dokumentation)
Manuelle Prüfung der Bedienbarkeit (v. a. Tastatur/Fokus) sowie inhaltliche Strukturprüfung

Umgesetzte Entscheidungen (Stand: 02/2026)

Typografie: SourceSans3, feste Skala (50/35/20/18) für klare Hierarchie
Farben/Kontrast: #FAFAFA + #111111 für maximale Lesbarkeit; der Textkontrast erfüllt die WCAG-Anforderungen für AA/AAA (Kontrast) deutlich
Struktur: kurze Absätze, klare Überschriftenlogik, Bulletpoints statt Textwüsten
Interaktion trotz Minimalfarben: Links/Buttons werden über Stil/Form eindeutig erkennbar gemacht (nicht nur über Farbe)

Rahmenbedingungen & Grenzen des Baukastens

Zeilenhöhe (line-height) nicht frei steuerbar: Lesbarkeit muss über Layout und Absatzstruktur kompensiert werden
Komponenten bestimmen Verhalten: Fokus- und Zustandsdarstellung hängt teilweise von vorgegebenen Bausteinen ab
Ohne HTML/CSS-Zugriff: bestimmte Feinoptimierungen sind nur eingeschränkt möglich und werden als Limitierung dokumentiert

Nächste Schritte

Fokusführung und Tastaturpfade weiter testen und verbessern
Formulare/Interaktionselemente (falls vorhanden) systematisch prüfen
Dokumentation erweitern: „Problem → Auswirkung → Lösung/Workaround“

Projekt-Update / Denkprozess (Konzeptanpassung nach der ersten Umsetzung)

Ausgangslage:

Die reduzierte Zweitversion war anfangs als „barrierearme Zusatzseite“ geplant, während die Hauptseite primär dem typischen Baukasten-Design folgen sollte.

Beobachtung nach den ersten Umsetzungen (Stand: 02/2026):

Die reduzierte Version ist im Rahmen des Baukastens bereits weitgehend barrierearm umgesetzt (Kontrast, Typografie, Struktur, erkennbare Interaktion). Offen sind aktuell vor allem Detailarbeiten wie Bildbeschriftungen/Alt-Texte sowie einzelne Feinanpassungen.
Im Projektverlauf wurde deutlich, dass „Barrierearmut als separate Zusatzseite“ in der Außenwirkung so verstanden werden kann, als wäre Accessibility ein optionales Extra.

Schlussfolgerung (Umentscheidung):

Barrierearmut soll deshalb nicht nur als Zweitversion existieren, sondern als Baseline auch für die Hauptseite gelten. Die Hauptseite wird daher ebenfalls WCAG-orientiert optimiert – so regelkonform wie möglich und so weit es ein Baukastensystem realistisch zulässt (entspricht dem typischen Mindeststandard im Unternehmenskontext).

Erweiterte Perspektive (über reine Regelkonformität hinaus):

Gleichzeitig zeigt sich, dass Regelkonformität nicht automatisch eine für alle Nutzer:innen optimale Nutzung garantiert. Insbesondere visuelle Komplexität (Bilder, Farben, visuelle Unruhe) kann Orientierung und Konzentration beeinträchtigen. Diese Aspekte werden im WCAG-Rahmen nur begrenzt „hart“ abgebildet und werden u. a. durch ergänzende W3C-Arbeiten zur Cognitive Accessibility (COGA) erweitert (Fokus auf kognitive Belastung, Verständlichkeit, Ablenkbarkeit).

Konsequenz (Rollenverteilung & Naming):

Hauptseite: barrierearm als Compliance-Baseline (so gut wie möglich im Baukasten)
Zweitversion: reizreduzierte Alternative zur kognitiven Entlastung (bessere Orientierung, weniger Ablenkung)

Da die Hauptseite ebenfalls barrierearm wird, ist die Bezeichnung „barrierearm/barrierefrei“ für die Zweitversion nicht mehr trennscharf. Die Zweitversion wird daher künftig als „Lesemodus“ geführt (Arbeitstitel), um den funktionalen Zweck präzise zu beschreiben.

Kurzfristige nächste Schritte (konkret):

Hauptseite barrierearm „baseline“ nachziehen (Kontrast, Struktur, Interaktion, Tastatur/Fokus)
Bildbeschriftungen/Alt-Texte ergänzen und vereinheitlichen (v. a. reduzierte Version)
Naming finalisieren: Lesemodus ggf. sprachlich weiter schärfen (z. B. „Reizarme Ansicht“ als Alternative)

Change Log (Projektverlauf & Konzeptanpassung)

02/2026 – Start: Konzept „Hauptseite (Standard) + barrierearm optimierte Zweitversion“ definiert.
02/2026 – Umsetzung: Zweitversion technisch/inhaltlich weitgehend barrierearm umgesetzt (Kontrast, Typografie, Struktur, erkennbare Interaktion).
Offen: Bildbeschriftungen/Alt-Texte sowie einzelne Feinanpassungen.
02/2026 – Erkenntnis: Barrierearmut nur als „Extra-Seite“ kann so wirken, als wäre Accessibility optional. Entscheidung: Barrierearmut wird Baseline für die gesamte Bewerbungsseite.
02/2026 – Anpassung: Hauptseite wird ebenfalls WCAG-orientiert optimiert (so regelkonform wie möglich innerhalb der Baukasten-Grenzen; entspricht typischem Mindeststandard im Unternehmenskontext).
02/2026 – Erweiterung: Neben Compliance wird zusätzlich Reizreduktion / kognitive Entlastung als Ziel aufgenommen (visuelle Unruhe kann Konzentration/Orientierung beeinträchtigen; WCAG bildet diese Aspekte nur begrenzt „hart“ ab, ergänzende Perspektive z. B. über COGA).
02/2026 – Konsequenz: Umbenennung der Zweitversion geplant, da „barrierearm/barrierefrei“ nicht mehr trennscharf ist. Arbeitstitel: Lesemodus (reizreduzierte Alternative).
Nächste Tage: Hauptseite baseline-konform nachziehen · Alt-Texte/Bildbeschriftungen finalisieren · Naming final entscheiden.