BFSG für Fotografen: Portfolio-Webseite und Online-Shop barrierefrei

Fotografen und BFSG: Das Alt-Text-Dilemma

Als Fotograf lebst du von Bildern. Deine Webseite zeigt hunderte Fotos in Galerien, Portfolios und Shops. Und genau hier liegt die groesste BFSG-Herausforderung: Jedes einzelne Bild braucht einen beschreibenden Alt-Text – so verlangt es WCAG-Erfolgskriterium SC 1.1.1 (Nicht-Text-Inhalt).

Bei einem Portfolio mit 500 Bildern ist das ein ernsthafter Aufwand. Aber: Wenn du Bilder online verkaufst oder digitale Dienste wie Online-Galerien fuer Kunden anbietest, bist du vom BFSG betroffen. Gemaess § 1 BFSG fallen Webseiten, ueber die Produkte oder Dienstleistungen angeboten werden, unter die Barrierefreiheitspflicht – und das schliesst Fotografen-Portfolios mit Buchungsoption oder Shop ausdruecklich ein.

Konkret bedeutet das: Sobald du ueber deine Webseite Shooting-Anfragen entgegennimmst, Preise kommunizierst oder Prints verkaufst, handelt es sich um eine digitale Dienstleistung im Sinne des § 1 Abs. 2 BFSG. Die Uebergangsfrist ist seit Juni 2025 abgelaufen – die Anforderungen gelten jetzt.

Dieser Leitfaden zeigt dir Schritt fuer Schritt, wie du deine Fotografen-Webseite BFSG-konform machst – von Alt-Texten ueber Lightbox-Navigation bis hin zu Kontaktformularen und Online-Buchung. Weitere Informationen finden Sie im BFSG-Glossar.

Was auf Fotografen-Webseiten problematisch ist

Hunderte Bilder ohne Alt-Texte (oder mit generischen Texten wie 'IMG_4523'). Lightbox-Galerien die nur per Maus navigierbar sind. Slideshows ohne Pause-Button und ohne Tastatursteuerung.

Bildershop-Checkout der nicht per Tastatur funktioniert. Kundenlogin-Bereiche fuer private Galerien ohne barrierefreien Zugang. Und: Sehr visuelle Layouts die ohne Bilder keinen Sinn ergeben.

Besonders kritisch sind Portfolio-Layouts, die ausschliesslich auf CSS-Grid oder Masonry-Effekte setzen. Wenn ein Screenreader die Bilder nicht in logischer Reihenfolge vorgelesen bekommt, geht der kuenstlerische Zusammenhang verloren. WCAG SC 1.3.2 (Bedeutungsvolle Reihenfolge) verlangt, dass die DOM-Reihenfolge der visuellen Anordnung entspricht.

Ein weiteres Problemfeld: Viele Fotografen nutzen JavaScript-basierte Lazy-Loading-Bibliotheken, die Bilder erst beim Scrollen nachladen. Screenreader-Nutzer bekommen diese Inhalte moeglicherweise nie zu sehen, wenn die Bilder rein per data-src referenziert sind und kein <noscript>-Fallback existiert. WCAG SC 4.1.2 (Name, Rolle, Wert) verlangt, dass alle UI-Komponenten programmatisch ermittelbar sind – auch nachgeladene.

Alt-Texte fuer Fotografen: Praktische Strategie

Du musst nicht jedes Bild im Portfolio einzeln beschreiben. Strategie: Bilder in Kategorien einteilen (Hochzeit, Portrait, Landschaft, etc.) und pro Kategorie beschreibende Texte nutzen. Fuer Shop-Bilder: Kurze, praezise Beschreibung (Motiv, Stimmung, Format).

Fuer Portfolio-Galerien: Galerie-Titel und Kategorie-Beschreibung reichen oft aus, einzelne Highlights gezielt beschreiben. Fuer Kunden-Galerien: Event-Name und Reihenfolge als Alt-Text.

Gute Alt-Texte fuer Fotografen folgen einem einfachen Schema: Motiv + Umgebung + Technik. Beispiel: „Brautpaar vor Sonnenuntergang am Strand, Gegenlicht-Aufnahme“ statt „Hochzeitsfoto Nr. 23“. Laut WCAG SC 1.1.1 muss der Alt-Text eine aequivalente Textalternative bieten – er muss also vermitteln, was das Bild zeigt.

Tipp: Nutze dein bestehendes Metadaten-System. Viele Fotografen pflegen ohnehin IPTC-Daten in Lightroom oder Capture One. Diese Beschreibungen lassen sich oft als Grundlage fuer Alt-Texte exportieren. Mehr dazu in unserem Ratgeber Alt-Texte richtig schreiben.

Barrierefreie Bildergalerien: Technische Tipps

Lightbox muss per Tastatur (Escape zum Schliessen, Pfeiltasten zum Blaettern) bedienbar sein. Das ist eine Kernforderung von WCAG SC 2.1.1 (Tastatur). Slideshow braucht einen Pause-Button (SC 2.2.2). Alle Bilder muessen auch ohne CSS erkennbar sein (kein reines CSS-Background-Image fuer Content-Bilder).

Lazy-Loading darf die Zugaenglichkeit nicht beeintraechtigen. Und: Bild-Download- oder Bestell-Buttons muessen mit dem jeweiligen Bild verknuepft sein (aria-label).

Pruefe deine Galerie mit der Tab-Taste: Kannst du jedes Bild fokussieren, die Lightbox oeffnen, darin navigieren und sie wieder schliessen – alles ohne Maus? Falls nicht, findest du in unserem Artikel Tastatur-Bedienbarkeit testen eine vollstaendige Checkliste.

Lightbox-Navigation: So wird sie barrierefrei

Die meisten Lightbox-Bibliotheken (Fancybox, Lightbox2, PhotoSwipe) liefern von Haus aus keine vollstaendige Tastatursteuerung. Folgende Punkte musst du sicherstellen:

Focus-Trapping: Sobald die Lightbox geoeffnet ist, muss der Tastaturfokus innerhalb der Lightbox bleiben. Der Nutzer darf nicht versehentlich hinter die Lightbox tabben. Nach dem Schliessen muss der Fokus auf das Element zurueckkehren, das die Lightbox geoeffnet hat.

Tastatur-Events: Pfeiltaste links/rechts fuer Vor/Zurueck, Escape zum Schliessen, Tab fuer Navigation zwischen Schliessen-Button und Bild-Beschreibung. WCAG SC 2.1.1 verlangt, dass alle Funktionen per Tastatur erreichbar sind.

ARIA-Attribute: Die Lightbox braucht role="dialog" und aria-modal="true". Der Schliessen-Button braucht aria-label="Lightbox schliessen". Das aktuelle Bild sollte per aria-live="polite" verkuendet werden, damit Screenreader den Bildwechsel mitbekommen (SC 4.1.2).

Kontaktformulare und Online-Buchung

Die meisten Fotografen bieten ein Kontaktformular fuer Anfragen oder ein Buchungssystem fuer Shootings an. Auch diese muessen barrierefrei sein – das betrifft insbesondere WCAG SC 1.3.1 (Info und Beziehungen) und SC 3.3.2 (Beschriftungen oder Anweisungen).

Jedes Formularfeld braucht ein sichtbares <label>. Pflichtfelder muessen per aria-required="true" gekennzeichnet sein. Fehlermeldungen muessen den Nutzer klar informieren, welches Feld betroffen ist und was erwartet wird (SC 3.3.1). Fuer Datumsfelder – etwa bei der Terminauswahl fuer ein Shooting – muss ein barrierefreier Datepicker vorhanden sein, der auch per Tastatur navigierbar ist (SC 2.1.1).

Wenn du ein Buchungstool wie Calendly oder SimplyBook einbindest, bist du fuer dessen Barrierefreiheit auf deiner Seite verantwortlich. Teste das Widget per Tastatur und Screenreader. Haeufiges Problem: iFrame-Einbettungen ohne aussagekraeftigen title-Attribut. Der iFrame braucht z. B. title="Terminbuchung fuer Fotoshooting", damit Screenreader den Inhalt ankuendigen koennen. Unser Ratgeber Formulare barrierefrei gestalten erklaert die Details.

Online-Buchung: Der komplette Ablauf

Wenn du Shooting-Termine direkt ueber deine Webseite buchbar machst, muss der gesamte Ablauf barrierefrei sein – von der Paketauswahl ueber den Kalender bis zur Bestaetigung. WCAG SC 3.3.4 (Fehlervermeidung bei rechtlichen Verpflichtungen) verlangt, dass Nutzer ihre Eingaben vor dem Absenden pruefen und korrigieren koennen.

Zeige vor dem finalen Absenden eine Zusammenfassung: Gewaehltes Paket, Datum, Uhrzeit, Preis. Der Nutzer muss die Moeglichkeit haben, zurueckzugehen und Aenderungen vorzunehmen. Vermeide mehrstufige Prozesse ohne sichtbare Fortschrittsanzeige – nutze aria-current="step" fuer den aktiven Schritt.

Preislisten und Pakete barrierefrei darstellen

Viele Fotografen zeigen Preise in visuell aufwaendigen Karten oder Tabellen. Achte darauf, dass Preistabellen mit korrektem HTML (<table>, <th>, <td>) ausgezeichnet sind – nicht als div-basiertes Layout. WCAG SC 1.3.1 (Info und Beziehungen) verlangt, dass tabellarische Daten auch programmatisch als Tabelle erkennbar sind.

Preis-Karten im Grid-Layout muessen eine logische Lesereihenfolge haben. Jede Karte braucht eine klare Ueberschrift (Paketname) und der zugehoerige „Buchen“-Button muss eindeutig zugeordnet sein, z. B. per aria-label="Paket Premium buchen".

Achte darauf, dass Preise nicht ausschliesslich als Bild dargestellt werden. Text-basierte Preisangaben sind fuer Screenreader lesbar und lassen sich vergroessern, ohne unscharf zu werden – ein Vorteil fuer Nutzer mit Sehbehinderung (SC 1.4.4, Textgroessenanpassung).

Schritt-fuer-Schritt: Portfolio-Webseite BFSG-konform machen

Schritt 1: Bestandsaufnahme. Pruefe deine Webseite mit dem bf-check Scanner. So erkennst du die groessten Barrieren auf einen Blick.

Schritt 2: Alt-Texte priorisieren. Beginne mit Shop-Bildern und Startseiten-Galerien. Nutze IPTC-Daten als Grundlage und ergaenze manuell. Rein dekorative Elemente (Trennlinien, Hintergrundmuster) bekommen alt="".

Schritt 3: Lightbox tauschen oder nachrüsten. Ersetze nicht-barrierefreie Lightboxen durch GLightbox oder a11y-dialog. Teste Escape, Pfeiltasten und Tab-Navigation.

Schritt 4: Formulare und Buchung prüfen. Label-Zuordnungen, Fehlermeldungen, Pflichtfeld-Kennzeichnung. Teste den gesamten Buchungsablauf per Tastatur.

Schritt 5: Screenreader-Test. Lass dir deine Startseite und eine Galerie von NVDA oder VoiceOver vorlesen. Ergibt der Inhalt ohne visuelle Informationen Sinn?

Schritt 6: Preise und Buchung pruefen. Sind Preistabellen korrekt ausgezeichnet? Kann der gesamte Buchungsprozess per Tastatur abgeschlossen werden? Teste auch eingebettete Drittanbieter-Widgets.

Schritt 7: Dokumentation. Erstelle eine Erklaerung zur Barrierefreiheit (Accessibility Statement) und verlinke sie im Footer. Beschreibe darin, welche Standards du erfuellst und wie Nutzer Barrieren melden koennen.

Häufig gestellte Fragen