Erklärung zur Barrierefreiheit
Zuletzt aktualisiert: 23. August 2026
Diese Übersetzung dient nur der Orientierung. Maßgeblich ist die englische Fassung dieser Seite.
1. Meine Verpflichtung
Diese Website soll für alle nutzbar sein — auch für Menschen, die mit Tastatur, Screenreader, Vergrößerung oder mit einer Einstellung für reduzierte Bewegung oder erhöhten Kontrast surfen. Barrierefreiheit wird hier als Teil der Entwicklung behandelt, nicht als Kontrolle am Ende: Mehrere der unten genannten Maßnahmen werden durch automatisierte Tests abgesichert, die den Build scheitern lassen, sobald sie zurückfallen.
2. Konformitätsstatus
Diese Website strebt die Konformität mit den Web Content Accessibility Guidelines (WCAG) 2.2 auf Stufe AA an. Nach meiner Einschätzung ist sie weitgehend konform, das heißt: Sie erfüllt die Erfolgskriterien der Stufe AA nach bestem Wissen und Prüfstand.
Ich beanspruche bewusst keine vollständige Konformität. Es wurde keine unabhängige Prüfung durch Dritte durchgeführt, und für diese Website existiert kein formaler WCAG-EM-Prüfbericht. Das ist eine Einschränkung der Belege hinter der Aussage, kein bekannter Mangel — wo ich einen Mangel finde, wird er in Abschnitt 5 aufgeführt.
3. Was umgesetzt ist
Tastatur und Fokus
- Ein Sprunglink ist das erste fokussierbare Element auf jeder Seite mit Website-Navigation, und er bewegt den Fokus zum Hauptinhalt, statt nur dorthin zu scrollen.
- Jedes interaktive Element zeigt eine sichtbare Fokusanzeige. Die Regel, die sie zeichnet, kann durch keine Utility-Klasse abgeschaltet werden; das sichert ein Test ab.
- Das mobile Menü ist eine Fokusfalle: Beim Öffnen wandert der Fokus hinein, kreist mit Tab darin, schließt mit Escape und kehrt zu der Schaltfläche zurück, die es geöffnet hat.
-
Kein Element erhält einen positiven
tabindex, sodass die Tabulatorreihenfolge der Seite folgt.
Struktur und Screenreader
-
Genau ein
main-Landmark je Seite und — überall dort, wo Kopf- und Fußbereich der Website vorhanden sind — einbannerund eincontentinfo, dazu benannte Navigations-Landmarks. -
Genau ein
h1je Seite, mit darunter in der richtigen Reihenfolge verschachtelten Überschriften und ohne übersprungene Ebenen. - Jedes Bild trägt einen Alternativtext, und dekorative Grafiken werden vor assistiven Technologien verborgen, statt Füllbeschreibungen zu erhalten.
- Wo ein Symbol die Bedeutung eines Bedienelements trägt, hat dieses einen Textnamen — die sichtbare Beschriftung beginnt stets diesen Namen, sodass Spracheingabe das Element über das ansprechen kann, was daraufsteht.
- Die Seitensprache ist deklariert, und jede Seite hat einen eindeutigen, aussagekräftigen Titel.
Farbe, Kontrast und Schrift
- Text- und Oberflächenfarben werden zur Buildzeit abgeleitet und gegen ihre eigenen Hintergründe geprüft: Fließtext muss mindestens 4,5:1 erreichen, primärer Text 7:1, und jede deckende Schaltflächenfüllung wird so weit abgedunkelt, bis ihre Beschriftung 4,5:1 überschreitet.
- Kein Text auf der Website wird unter 12 px dargestellt. Das ist eine Untergrenze, abgesichert durch einen Test.
-
Farbe ist nie der einzige Träger einer Information: Ausgewählte Zustände tragen zusätzlich
eine Beschriftung, eine Form oder einen
aria-current-Wert. - Es stehen ein helles und ein dunkles Design zur Verfügung. Die Website startet dunkel, statt Ihre Systemeinstellung zu übernehmen, und merkt sich die Auswahl, die Sie mit dem Umschalter im Kopfbereich treffen.
Bewegung, Zoom und Zeigegeräte
- Reduzierte Bewegung wird respektiert. Wenn Ihr System sie anfordert, werden Einblendanimationen, Scroll-Effekte und Ansichtsübergänge unterdrückt.
- Erhöhter Kontrast und der Windows-Kontrastmodus werden berücksichtigt: Verlaufstext fällt auf eine Volltonfarbe zurück, und Zustände, die nur durch eine Füllung angezeigt werden, erhalten einen Rahmen in Systemfarbe.
- Zoom wird nicht blockiert. Die Seite lässt sich auf 500 % vergrößern, und bei der Breite von 320 px, die WCAG 1.4.10 „Reflow“ vorgibt, wird sie einspaltig ohne horizontales Scrollen dargestellt. Geprüft wird jede Breite zwischen 320 px und 1920 px, nicht nur die benannten Breakpoints.
- Interaktive Bedienelemente bieten eine Zielfläche von mindestens 44 × 44 px und überschreiten damit das WCAG-2.2-Minimum von 24 × 24 px. Wird ein Element kleiner gezeichnet, wird seine klickbare Fläche dahinter vergrößert, statt klein zu bleiben. Die einzige Ausnahme ist ein Link innerhalb eines Satzes, der die Inline-Ausnahme nach WCAG 2.5.8 in Anspruch nimmt — eine feste Höhe würde dort den Zeilenabstand des umgebenden Absatzes zerstören.
Formulare
-
Jedes Feld hat einen programmatisch verknüpften Namen. Wo ein Formular mehr als ein Feld hat —
das Kontaktformular und das Fenster für Cookie-Einstellungen —, ist dieser Name ein sichtbares
<label>. Die einfeldrigen Bedienelemente (Newsletter-Anmeldung, Suche in Übersichten, Kommentarfeld, E-Mail-Anmeldung) beziehen ihren Namen stattdessen aus einemaria-label, wobei die Überschrift, das Symbol oder die Schaltfläche daneben auf dem Bildschirm dieselbe Bedeutung trägt. - Fehler werden als Text neben dem zugehörigen Feld beschrieben, nicht allein durch Farbe, und sind mit ihm verknüpft, sodass ein Screenreader die Meldung vorliest, sobald das Feld den Fokus erhält.
- Wird ein Formular mit einem ungültigen Feld abgeschickt, wandert der Fokus zu diesem Feld — das Problem findet Sie, nicht umgekehrt.
- Textfelder werden auf Touch-Geräten mit 16 px dargestellt, sodass das Fokussieren keinen iOS-Zoom auslöst, den Sie nicht rückgängig machen können.
4. Wie das geprüft wurde
Durch Selbstbewertung, mit einer Kombination aus automatisierten und manuellen Prüfungen:
- Automatisierte Tests in der projekteigenen Testsuite, die den Build scheitern lassen, sobald Fokusanzeigen, Mindestschriftgröße, Zielflächengröße, Landmark-Struktur, Alternativtexte von Bildern oder die Überschriftenreihenfolge zurückfallen.
- Kontrastmessung anhand gerenderter Pixel, wobei durchscheinende Ebenen überlagert werden, statt deklarierte Farben abzulesen.
- Ein Viewport-Durchlauf von 320 px bis 1920 px, der bei jedem Schritt dazwischen auf horizontales Überlaufen, überlappende Elemente und abgeschnittenen Text prüft — nicht nur an den benannten Breakpoints.
- Manuelle Tastaturdurchläufe sowie Prüfungen in mehreren Engines: Chromium, Firefox und WebKit.
5. Bekannte Einschränkungen
- Keine unabhängige Prüfung. Alles Vorstehende ist selbst bewertet. Eine Prüfung durch jemanden außer dem Autor wäre eine belastbarere Grundlage für die Konformitätsaussage in Abschnitt 2.
- Begrenzte Tests mit assistiven Technologien. Struktur und Verhalten sind gegen den Accessibility-Tree und per Tastatur geprüft, aber die Website wurde nicht durchgängig mit allen gängigen Screenreadern getestet.
- Inhalte Dritter. Die Terminvereinbarung übernimmt ein externer Buchungsdienst auf seiner eigenen Domain. Auf dessen Barrierefreiheit habe ich keinen Einfluss. Falls das für Sie eine Barriere ist, nutzen Sie bitte einen der Kontaktwege aus Abschnitt 6 — ein Gespräch lässt sich immer per E-Mail vereinbaren.
- Eingebettete Medien. Auf dieser Website ist derzeit kein Video veröffentlicht. Das Vorstellungsvideo, das die Seite „Über mich“ ankündigt, ist noch nicht aufgezeichnet; sobald es das ist, verlangen WCAG 1.2.2 und 1.2.3 Untertitel und ein Transkript für die oben beanspruchte Konformitätsstufe.
6. Rückmeldung und Kontakt
Wenn Sie auf dieser Website auf eine Barriere stoßen, sagen Sie es mir bitte — das ist der schnellste Weg, sie zu beheben, und Hinweise sind auch dann willkommen, wenn Sie nicht sicher sind, ob das Problem auf meiner Seite liegt.
- E-Mail an contact@mhsaeed.com — schreiben Sie „Barrierefreiheit“ in die Betreffzeile, wenn es vorrangig behandelt werden soll.
- Oder nutzen Sie das Kontaktformular.
Ich antworte innerhalb von 24 Stunden — dieselbe Zusage, die auch die Kontaktseite macht. Bitte beschreiben Sie die Seite, was Sie tun wollten, und den Browser oder die assistive Technologie, die Sie verwendet haben, sofern Sie das teilen möchten — das macht das Problem deutlich schneller nachvollziehbar.