Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Einbindung von Drittanbietern, Abgrenzung, und Konformitätstests #345

Open
detlevhfischer opened this issue Jun 28, 2023 · 5 comments
Open

Comments

@detlevhfischer
Copy link
Contributor

detlevhfischer commented Jun 28, 2023

Hier zur Diskussion ein Thema, das immer wieder auftaucht. Laut BITV und EU-Webrichtlinie (PDF) Erwägungsgrund 30 gehören ja eingebettete Inhalte Dritter dazu, wenn sie vom Anbieter der Site verantwortet oder finanziert werden. WCAG EM erlaubt im Principle of Website Enclosure den Test eines abgrenzbaren Untersystems (z.B. Bibliothek einer Uni), nicht aber das Ausklammern eingebundener Angebote (also kein Uni-Test ohne auch die Bibliothek zu testen).

Schwieriger wird es nun, wenn Dienstleistungen eingebunden, aber nicht technisch "eingebettet" sind. Nutzt ein Theater z.B. Eventim für den Ticketverkauf, dann bettet nicht das Theater Eventim ein, sondern Eventim das Theater. Die URL sieht dann so aus:

https://mein-theater.eventim-inhouse.de/webshop/webticket/seatmap?eventId=16655 (kein funktionierender Link)

Das Theater taucht als Subdomain von eventim-inhouse.de auf, Eventim schafft eine Art Shop für das Theater und übernimmt dessen Logo u. andere Infos in einem völlig anders strukturiertem (und augenscheinlich nicht voll barrierefreiem) Angebot, auf welches das Theater keinen Zugriff hat.

Die Frage ist, wie wir das behandeln, wenn der Kunde Theater einen repräsentativen Test will und damit die Barrierefreiheit seines Angebots zeigen will. An vielen Stellen verlässt der Kunde bei Aktivierung von "Ticket" das Angebot und kehrt ggf. nach Kauf dorthin zurück. Die Abgrenzung selbst ist über mehrere Faktoren (abweichende Gestaltung, Navigation, andere URL) usw. relativ deutlich. Die Frage bleibt aber, ob nicht die WCAG Konformitätsbedingung "vollständige Prozesse", die auch in der EN unter Clause 9.6 übernommen ist, gebietet, dass der Kauf-Prozess auf der Eventim Subdomain mitzuprüfen wäre, denn er wird ja auf der Theater-Seite getriggert und führt erst dann zu Eventim hinüber. Praktikabel wäre ein solcher Test nicht, er würde riesig und Konformität würde dann unabhängig von der Güte der Theater-Site (zurzeit) nie erreicht. Die Konsequenz ist also entweder:

  1. Einrichtungen, die Eventim-Dienste in der genannten Weise nutzen, können nie repräsentativ getestet werden, es sei denn, der gesamte Ticketkaufprozess, den der Kunde gar nicht verantwortet, würde mitgetestet;
  2. Einrichtungen, die Eventim-Dienste in der genannten Weise nutzen, können sich repräsentativ testen lassen, müssen aber bei Nutzung eines Prüfsiegels im Prüfreport und in der Erklärung zur Barrierefreiheit deutlich herausstellen, das der Ticketkaufprozess ausgeschlossen ist.

Was denkt ihr?

@MarcHaunschild
Copy link

MarcHaunschild commented Jun 28, 2023

Das ist nicht nur über EN und WCAG, sondern mMn auch und sogar ganz besonders durch das BFSG so geregelt, dass vor allem interaktive Dienste barrierefrei sein müssen wie z.B. ein Ticketverkauf oder eine Terminreservierung. Das sind immer wieder genannte Beispiele.

Mir scheint, wenn der Link wirklich wegführt von der Site des Theaters, dann ist das ein eigenständiger Webauftritt und der Ticketverkauf muss eigenständig getestet werden.

Es wären also zwei voneinander unabhängige Prüfungen nötig.

@detlevhfischer
Copy link
Contributor Author

Ich habe ein AGWG issue dazu angelegt w3c/wcag#3257

@johannesFischer84
Copy link
Contributor

Ich würde sagen, wenn z. B. auf der Theater-Seite ein Link steht, der eindeutig sagt, dass man für das Theater Tickets buchen kann, dann gehört der Prozess der Ticketbuchung zur Veranwortung des Theaters. Anderenfalls dürfte das Theater keine Online-Buchung anbieten.
Im Gegensatz dazu: Wenn es einen Link gibt, wo darauf hingewiesen wird, dass für andere externe Theater eine Online-Ticketbuchung auf einer externen Seite möglich ist, ist das Theater nicht verantwortlich, solange es für sich selbst dort keine Ticketbuchung anbietet. Meiner Meinung nach geht es darum, dass es eine Leistung für das eigene Theater ist, auf die auf der eigenen Seite hingewiesen wird.

Gesetzlich ist das allerdings eine Grauzone, da es nirgendwo klar so steht und man es nur so herausinterpretieren kann. Letztendlich müssten das am Ende Gerichte entscheiden.

@anatom5
Copy link

anatom5 commented Mar 22, 2024

Für die Öffentliche Hand (Theater gehören meist in diese Kategorie) ist das eigentlich über "elektronische Verwaltungsabläufe" abgedeckt, oder? "... und elektronische Verwaltungsabläufe sind von öffentlichen Stellen barrierefrei zu gestalten": https://www.bundesfachstelle-barrierefreiheit.de/DE/Fachwissen/Informationstechnik/EU-Webseitenrichtlinie/BGG-und-BITV-2-0/Die-neue-BITV-2-0/die-neue-bitv-2-0_node.html.

@MarcHaunschild
Copy link

Das ist spannend. Ich habe das bisher immer als Auftrag gesehen, alles was in einer Behörde ist barrierefrei zu machen, aber klar: eine Buchung ist ein Verwaltungsakt, inklusive dem speichern von Kontakt-Daten, der bezahlsbwicklung, Mahnwesen...
Der gesamte Prozess einer Bestellung ist letztlich nur ein Verwaltungsakt.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants