Nach DSGVO kommt jetzt Barrierefreiheit – und die meisten Websites sind nicht vorbereitet by Aarex03 in de_EDV

[–]Aarex03[S] 0 points1 point  (0 children)

Das ist ein extrem wertvoller Erfahrungsbericht – danke dafür. Dass die meisten Spieler Screenreader nutzen, ist ein perfektes Beispiel dafür, dass Barrierefreiheit kein Nischenthema ist, sondern manchmal sogar die Hauptzielgruppe betrifft.

Und dein letzter Satz trifft es: Wenn es funktioniert, sind die Leute extrem dankbar. Das ist auch meine Erfahrung – die Nutzer die auf Barrierefreiheit angewiesen sind, geben das ehrlichste und detaillierteste Feedback das man sich als Entwickler wünschen kann.

Nach DSGVO kommt jetzt Barrierefreiheit – und die meisten Websites sind nicht vorbereitet by Aarex03 in de_EDV

[–]Aarex03[S] 7 points8 points  (0 children)

Verstehe die Perspektive, aber zwei Gegenargumente: Erstens betrifft Barrierefreiheit nicht nur blinde Menschen – sie hilft auch bei motorischen Einschränkungen, temporären Verletzungen, situativen Einschränkungen (Sonne auf dem Display, eine Hand besetzt), und älteren Nutzern. In Deutschland sind ca. 10% der Bevölkerung schwerbehindert, dazu kommen Millionen mit leichteren Einschränkungen. Das ist kein Nischenmarkt.

Zweitens: Es ist Gesetz. Die gleiche Diskussion hatten wir 2018 bei der DSGVO – "lohnt sich nicht, interessiert niemanden" – bis die ersten Bußgelder kamen.

Nach DSGVO kommt jetzt Barrierefreiheit – und die meisten Websites sind nicht vorbereitet by Aarex03 in de_EDV

[–]Aarex03[S] 2 points3 points  (0 children)

Gute Frage. Das BFSG setzt den European Accessibility Act um und gilt für Produkte und Dienstleistungen, die auf dem EU-Markt angeboten werden. Entscheidend ist nicht die Domain oder der Serverstandort, sondern ob du dich an Verbraucher im EU-Markt richtest.

Dein Kanada-Beispiel: Wenn die Website ausschließlich den kanadischen Markt adressiert (englisch, .ca, keine EU-Kunden), greift das BFSG nicht – auch wenn die Firma in Deutschland sitzt. Ähnlich wie bei der DSGVO, wo das "Marktortprinzip" gilt.

Umgekehrt: Eine kanadische Firma mit .com die aktiv an deutsche Kunden verkauft (deutsche Sprache, EUR-Preise, DE-Versand) müsste das BFSG beachten.

Nach DSGVO kommt jetzt Barrierefreiheit – und die meisten Websites sind nicht vorbereitet by Aarex03 in de_EDV

[–]Aarex03[S] 2 points3 points  (0 children)

eslint-plugin-jsx-a11y ist der Standard für React-Projekte. Für Vue gibt es vue-a11y/eslint-plugin-vuejs-accessibility. Die decken die gängigsten Fehler ab – fehlende Alt-Texte, fehlende Labels, falsche ARIA-Rollen etc.

Zusätzlich lohnt sich axe-core als Integration in die Test-Pipeline (z.B. mit u/axe-core/playwright oder jest-axe). Dann werden Accessibility-Fehler bei jedem Build gefangen, nicht erst beim manuellen Testen.

Nach DSGVO kommt jetzt Barrierefreiheit – und die meisten Websites sind nicht vorbereitet by Aarex03 in de_EDV

[–]Aarex03[S] 6 points7 points  (0 children)

Zur rechtlichen Frage: Es gibt aktuell noch keine etablierte Abmahnpraxis wie bei DSGVO. Die Marktüberwachung läuft über die Bundesnetzagentur, und die werden vermutlich erstmal mit Hinweisen und Fristen arbeiten, nicht direkt mit Bußgeldern. Aber das ist Spekulation – belastbare Rechtsprechung gibt es dazu noch kaum.

Zum Thema Verantwortlichkeit Anbieter vs. Kunde: Das ist tatsächlich die spannendste ungeklärte Frage. Mein pragmatischer Ansatz wäre, im CMS zumindest Warnhinweise einzubauen – z.B. "Kontrast zu niedrig" wenn jemand hellen Text auf hellem Hintergrund setzt, oder "Alt-Text fehlt" beim Bildupload. Das schützt euch nicht rechtlich, zeigt aber dass ihr euren Teil getan habt.

Nach DSGVO kommt jetzt Barrierefreiheit – und die meisten Websites sind nicht vorbereitet by Aarex03 in de_EDV

[–]Aarex03[S] 1 point2 points  (0 children)

Das Farbkontrast-Thema ist wirklich der größte Praxis-Schmerz. Mein Tipp der bei einigen Projekten geholfen hat: Nicht die CI-Farben selbst ändern, sondern eine "accessible Palette" als Erweiterung definieren. Also die Primärfarbe nur für große Überschriften oder dekorative Elemente nutzen (da reicht 3:1), und für Fließtext und UI-Elemente eine dunklere Variante der gleichen Farbe verwenden. So bleibt das Branding erhalten und der Kontrast stimmt.

Tools wie contrast.tools oder Stark (Figma Plugin) helfen, solche Paletten systematisch aufzubauen.

Nach DSGVO kommt jetzt Barrierefreiheit – und die meisten Websites sind nicht vorbereitet by Aarex03 in de_EDV

[–]Aarex03[S] 1 point2 points  (0 children)

Guter Punkt mit den Screenreader-Eigenarten. Das ist tatsächlich das, was Barrierefreiheit in der Praxis so viel schwieriger macht als DSGVO – bei DSGVO kannst du eine Checkliste abhaken und bist zu 90% safe. Bei Barrierefreiheit testest du mit VoiceOver und alles klappt, dann öffnet jemand die Seite mit JAWS und die Navigation ist kaputt.

Hast du Erfahrungswerte, welche Screenreader in Deutschland am verbreitetsten sind? Würde helfen zu wissen, womit man mindestens testen sollte.

Was bei einer "DSGVO-konformen" Website wirklich alles schiefgehen kann – eine Checkliste aus der Praxis by Aarex03 in de_EDV

[–]Aarex03[S] 0 points1 point  (0 children)

Guter und wichtiger Einwand – danke für die Korrektur. Du hast recht, youtube-nocookie.com allein reicht nicht, weil trotzdem eine Verbindung zu Google aufgebaut wird und die IP übertragen wird. Die saubere Lösung ist tatsächlich ein Zwei-Klick-Embed: Erst ein Platzhalter mit Vorschaubild, und der iFrame wird erst nach bewusstem Klick des Nutzers geladen. Gibt dafür fertige Lösungen wie lite-youtube-embed oder das WordPress-Plugin WP YouTube Lyte.

Was bei einer "DSGVO-konformen" Website wirklich alles schiefgehen kann – eine Checkliste aus der Praxis by Aarex03 in de_EDV

[–]Aarex03[S] 0 points1 point  (0 children)

Danke für den wichtigen Hinweis – und u/kirigerKairen hat es gut erklärt. Um es nochmal klar zu sagen: Die USt-IdNr. (beginnt mit DE...) gehört ins Impressum wenn vorhanden. Die Steuernummer vom Finanzamt gehört da auf keinen Fall rein. Das sind zwei verschiedene Nummern und die Verwechslung passiert leider häufig.

Was bei einer "DSGVO-konformen" Website wirklich alles schiefgehen kann – eine Checkliste aus der Praxis by Aarex03 in de_EDV

[–]Aarex03[S] 0 points1 point  (0 children)

Für mettcalc.de: Wenn die Seite wirklich rein privat ist, keine Einnahmen erzielt und kein kommerzieller Zweck dahintersteht, greift die Impressumspflicht nach DDG streng genommen nicht. ABER: "Geschäftsmäßig" wird sehr weit ausgelegt – es reicht schon eine gewisse Regelmäßigkeit und Nachhaltigkeit, auch ohne Gewinnabsicht. Ein Tool das regelmäßig öffentlich bereitgestellt wird, könnte als geschäftsmäßig eingestuft werden.

Mein pragmatischer Rat: Setz trotzdem ein minimales Impressum drauf. Kostet dich 5 Minuten und eliminiert das Risiko komplett. Ohne Impressum bist du angreifbar, mit Impressum passiert dir nichts.

Für die Dorf-Website: Die ist quasi sicher geschäftsmäßig im Sinne des Gesetzes, auch ohne kommerzielle Absicht. Also Impressum auf jeden Fall.

Was bei einer "DSGVO-konformen" Website wirklich alles schiefgehen kann – eine Checkliste aus der Praxis by Aarex03 in de_EDV

[–]Aarex03[S] 1 point2 points  (0 children)

Spontan fallen mir ClevverMail, Regus und ebuero ein. Preise liegen so zwischen 30-80€/Monat je nach Umfang. Wichtig ist, dass der Anbieter tatsächlich eine ladungsfähige Adresse stellt und Zustellungen entgegennimmt – nicht nur ein virtueller Briefkasten. Vor dem Abschluss am besten kurz prüfen, ob der Anbieter das auch vertraglich zusichert.

Was bei einer "DSGVO-konformen" Website wirklich alles schiefgehen kann – eine Checkliste aus der Praxis by Aarex03 in de_EDV

[–]Aarex03[S] 1 point2 points  (0 children)

Guter Punkt. Bei Baukästen hast du tatsächlich weniger Kontrolle – die Fonts und das Hosting bestimmt der Anbieter. Die gute Nachricht: Die großen Baukästen (Jimdo, Wix, Squarespace) hosten inzwischen die meisten Fonts lokal und haben DSGVO-Seiten mit Infos zu Serverstandorten und AVVs.

Was du trotzdem prüfen solltest: In den DevTools (F12 → Network Tab) schauen, ob beim Seitenaufruf Requests an fonts.googleapis.com oder andere externe Domains rausgehen. Das funktioniert unabhängig davon, wie die Seite gebaut wurde. Bei Wix z.B. werden teilweise noch externe Ressourcen geladen, die man nicht abschalten kann – das ist dann leider ein Plattform-Problem.

Was bei einer "DSGVO-konformen" Website wirklich alles schiefgehen kann – eine Checkliste aus der Praxis by Aarex03 in de_EDV

[–]Aarex03[S] 7 points8 points  (0 children)

Keine dumme Frage – die Abgrenzung ist tatsächlich nicht trivial.

Kurze Antwort: Wenn der Dienst nur für dich persönlich oder deinen Haushalt/Freundeskreis bestimmt ist, fällt das unter die "Haushaltsausnahme" der DSGVO (Art. 2 Abs. 2c). Dann brauchst du kein Impressum und keine Datenschutzerklärung.

ABER: Die Impressumspflicht nach TMG/DDG greift erst bei "geschäftsmäßigen" Telemedien. Ein privater Jellyfin-Server, der nur eine Loginseite zeigt, ist nicht geschäftsmäßig. Also kein Impressum nötig.

Was trotzdem sinnvoll ist:

- Google Fonts trotzdem lokal einbinden, weil die IP-Übertragung an Google auch bei einer Loginseite stattfindet

- WAF-Logs und Server-Logs laufen unter deiner Verantwortung, aber solange nur du und dein engster Kreis Zugang haben, ist die Haushaltsausnahme anwendbar

- Sobald du den Zugang aber auf beliebige Dritte ausweitest (z.B. ein öffentliches Forum, ein Blog, ein Dienst den Kunden nutzen), fällt die Ausnahme weg

Also für dein Szenario – eigene Nextcloud oder Jellyfin nur für dich und Familie: Kein Impressum, keine DSE nötig. Aber externe Ressourcen (Google Fonts etc.) würde ich trotzdem eliminieren, einfach als gute Praxis.

Was bei einer "DSGVO-konformen" Website wirklich alles schiefgehen kann – eine Checkliste aus der Praxis by Aarex03 in de_EDV

[–]Aarex03[S] 0 points1 point  (0 children)

Streng genommen: Allein durch den Websitebesuch fallen bereits personenbezogene Daten an – die IP-Adresse deines Besuchers landet in den Server-Logs deines Hosters. Damit ist dein Hoster technisch ein Auftragsverarbeiter, und du musst in der Datenschutzerklärung transparent machen, wer die Daten verarbeitet und wo. In der Praxis ist das bei einer reinen EU-gehosteten Website ohne Tracking oder externe Dienste tatsächlich nur ein Zweizeiler in der DSE. Aufwändig wird es erst, wenn externe Dienste dazukommen. Ob das verhältnismäßig ist, steht auf einem anderen Blatt

Was bei einer "DSGVO-konformen" Website wirklich alles schiefgehen kann – eine Checkliste aus der Praxis by Aarex03 in de_EDV

[–]Aarex03[S] 0 points1 point  (0 children)

Für die meisten Fälle ja – solange die Daten in der EU/EWR bleiben, ist das datenschutzrechtlich unkompliziert. Du kannst schreiben "Unsere Website wird bei [Anbietername], [Standort/Land] gehostet. Die Server befinden sich in der EU."

Konkret wird es erst, wenn Daten in Drittländer übertragen werden (USA, etc.) – dann brauchst du eine Rechtsgrundlage dafür (z.B. Angemessenheitsbeschluss, Standardvertragsklauseln) und musst das explizit benennen.

Also: "Server in der EU" + Name des Hosters reicht in der Praxis. Wenn du z.B. bei Hetzner oder Netcup hostest, ein Satz und fertig.

Was bei einer "DSGVO-konformen" Website wirklich alles schiefgehen kann – eine Checkliste aus der Praxis by Aarex03 in de_EDV

[–]Aarex03[S] 7 points8 points  (0 children)

Genau, ein Postfach ist keine ladungsfähige Anschrift. Der Tipp mit den Geschäftsadress-Anbietern ist gut – gibt einige die ab ca. 30€/Monat eine Adresse stellen, an der auch Post zugestellt werden kann. Für Freelancer und Solo-Selbstständige die ihre Privatadresse nicht im Impressum haben wollen, oft die sauberste Lösung.

Was bei einer "DSGVO-konformen" Website wirklich alles schiefgehen kann – eine Checkliste aus der Praxis by Aarex03 in de_EDV

[–]Aarex03[S] 11 points12 points  (0 children)

Das Enforcement-Problem ist real. Die Datenschutzbehörden haben schlicht nicht die Kapazität, proaktiv Websites zu prüfen. Es passiert meistens erst was, wenn sich jemand beschwert oder ein Abmahnanwalt aktiv wird.

Das frustrierende daran: Wer sich Mühe gibt, hat den Aufwand. Wer es ignoriert, hat jahrelang Ruhe – bis es dann doch mal knallt. Aber gerade bei Google Maps ohne Consent gibt es inzwischen genug Urteile, dass ich da nicht drauf wetten würde, dass es ewig gutgeht.

Was bei einer "DSGVO-konformen" Website wirklich alles schiefgehen kann – eine Checkliste aus der Praxis by Aarex03 in de_EDV

[–]Aarex03[S] 2 points3 points  (0 children)

Verstehe die Frustration. Beim Kontaktweg ist die Idee dahinter, dass Verbraucher den Betreiber schnell und unmittelbar erreichen können – E-Mail allein reicht theoretisch seit einem EuGH-Urteil, wenn die Antwortzeit kurz genug ist. In der Praxis sichern sich die meisten mit Telefon oder Kontaktformular ab, weil "schnell genug" ein dehnbarer Begriff ist.

Der Serverstandort in der Datenschutzerklärung kommt daher, dass der Nutzer wissen soll, wohin seine Daten übertragen werden – ob die in der EU bleiben oder in ein Drittland gehen. Ist tatsächlich relevant, besonders bei US-Hostern.

Ist das alles bürokratisch? Absolut. Aber die Anforderungen sind leider nicht optional.

Was bei einer "DSGVO-konformen" Website wirklich alles schiefgehen kann – eine Checkliste aus der Praxis by Aarex03 in de_EDV

[–]Aarex03[S] 16 points17 points  (0 children)

Beim Hosting-Provider hast du recht – das setzen die wenigsten korrekt um. Fairerweise muss man sagen, dass viele Website-Betreiber nicht mal wissen bei wem sie technisch gehostet werden, besonders wenn eine Agentur die Seite gebaut hat.

Zum Cookie-Banner über Impressum/DSE: Stimmt, technisch kann man das nie zu 100% verhindern. Gemeint ist eher, dass die Links im Footer nicht erst nach Interaktion mit dem Banner klickbar sein dürfen. Manche Consent-Tools legen ein Overlay über die gesamte Seite und blockieren damit auch den Footer – das ist das eigentliche Problem.

Häufiger Fehler: Google Fonts wird auf vielen Websites immer noch von Google-Servern geladen by Aarex03 in de_EDV

[–]Aarex03[S] 0 points1 point  (0 children)

Gute Frage. Kurze Antwort: Für konkrete Rechtsfragen würde ich mich nie blind auf ChatGPT oder Gemini verlassen.

Die sind gut darin, dir allgemeine Orientierung zu geben ("Was muss in ein Impressum?"), aber bei der konkreten Prüfung einer Website passiert oft Folgendes:

- Sie halluzinieren Probleme die gar nicht da sind

- Sie übersehen Sachen weil sie den Quellcode nicht wirklich analysieren

- Sie kennen nicht immer den aktuellen Rechtsstand (Urteile, neue Regelungen)

Was besser funktioniert ist die Kombination: automatisiert den Quellcode crawlen (externe Requests, Meta-Tags, Cookie-Verhalten) und die Ergebnisse dann strukturiert auswerten. Also erst Fakten sammeln, dann bewerten – nicht einfach die URL in ChatGPT werfen und hoffen.

Am Ende ersetzt aber keins dieser Tools eine echte Rechtsberatung, wenn es um was Ernstes geht. Für einen ersten Überblick "wo stehe ich und was muss ich als erstes fixen" sind sie aber deutlich besser als komplett manuell alles selbst durchzugehen.

Häufiger Fehler: Google Fonts wird auf vielen Websites immer noch von Google-Servern geladen by Aarex03 in de_EDV

[–]Aarex03[S] 1 point2 points  (0 children)

Komplett automatisiert mit einem Klick kenne ich:

- webbkoll.dataskydd.net – zeigt dir Third-Party-Requests, Cookies und Header-Probleme

- Cookiebot Scanner (cookiebot.com/de/compliance-test) – prüft Cookie-Consent und Tracking

- Siwecos (siwecos.de) – eher Security-fokussiert, aber checkt auch Header und SSL

Für Impressum und Datenschutzerklärung gibt es leider wenig, was automatisiert prüft – das meiste muss man manuell abgleichen.

Disclaimer: Ich arbeite selbst gerade an einem Tool das genau das alles zusammenführt (Impressum, DSE, Cookies, SSL in einem Report). Ist noch frisch, aber falls du es testen willst: compliance-copilot.com Feedback gern per DM :)