Der nachfolgende Text wurden mit KI erstellt und kann Fehler enthalten. Fehler gefunden? Bei GitHub editieren
Heute haben wir zu Gast Danny Koppenhagen und Maximilian Franzke und das Thema Web Accessibility.
Ja, Danny, Maximilian, wollt ihr euch vielleicht gerade mal vorstellen?
Danny, willst du anfangen?
Ja, sehr gerne.
Danke, Ralf.
Ja, ich bin Danny Koppenhagen.
Ich bin Mitglied in einem DevOps-Team und wir entwickeln barrierefreie Web-Anwendungen, tatsächlich auch mit dem Fokus auch auf Reisende.
Und letztendlich, ich bin auch, also mein Fokus ist Frontend-Architektur und Barrierefreiheit.
Ich habe vor ein paar Jahren mal so ein Angular-Buch auch geschrieben, wo auch im nächsten Jahr eine neue Auflage kommt.
Und da wird das Thema auch, Barrierefreiheit kommt da natürlich auch nicht zu kurz.
Und dann übergebe ich mal an Maximilian.
Genau, perfekt.
Danke dir, Danny.
Tatsächlich, wir haben ja immer so die Zusammenhänge aufgeführt.
Wir arbeiten bei derselben Arbeitgeberin, sind beide so im Kontext eben von IT-Architektur, DevOps mit unterwegs, Open-Source-Enthusiasten.
Bei mir ist nochmal so die Spezialität oder Besonderheit, vor allem, dass ich auch Prüfer im renommierten BTV-Prüferbund in Deutschland bin, der sich eben um die Etablierung von Barrierefreiheit entsprechend auch kümmert, digitaler Barrierefreiheit.
Genau.
Okay, sehr cool.
Digitale Barrierefreiheit finde ich ja ein super spannendes Thema, zumal, wenn ich es jetzt richtig in Erinnerung habe, ist das auch irgendwie in die Gesetzgebung jetzt gerade übergegangen, dass man verpflichtet ist, digital barrierefrei zu sein.
Erstmal zu dem Begriff gleich vorneweg die Frage, geht es, barrierefrei zu sein, oder ist das Ziel Barrierearmut?
Genau, magst du einsteigen, Danny?
Das ist eine sehr gute Frage auf jeden Fall.
Also, das Ziel ist natürlich immer barrierefrei zu sein.
Ob man das Ziel tatsächlich zu 100% erreichen kann und immer erreichen wird, das kann vielleicht nicht immer gelingen.
Es gibt auch Situationen, wo man auf eine bestimmte Gruppe von Personen optimiert, wo man vielleicht eine Anwendung mit einem bestimmten Nutzerfokus hat und da auch nochmal wirklich konkreter die Nutzergruppen abholen will und da wirklich auch anpasst, seine Anwendung daraufhin optimiert.
Und dann kann das aber eben auch Konsequenzen haben und das muss man immer im Blick haben, dass man dann nicht vielleicht eine andere Nutzergruppe vielleicht ein bisschen ausschließt.
Und deshalb muss man immer schauen, möglichst barrierearm zu sein.
Genau.
Okay, ich sehe schon, ihr habt ja hier Slides mitgebracht.
Ich hatte jetzt die Frage einfach mal so gestellt, ohne die Slides zu kennen und ihr habt gleich die passenden Slides hier aufgetischt.
Genau, einmal mit Profis arbeiten.
Wollt ihr ein bisschen die Einführung jetzt gerade mal geben, bevor ich dann blöde Fragen stelle?
Ich fand die Frage gut, aber wir können später auf den Punkt auch noch zurückkommen.
Wir haben es ja quasi schon eingeblendet, zeichnen ja aber einen Podcast auf.
Dementsprechend werden wir natürlich auch alles verbalisieren, was wir heute visualisieren wollen.
Das heißt in der Tat, lass erst mal einsteigen, dann können wir später nochmal auf diese Frage zurückkommen.
Danny, magst du die Arten von Einschränkungen gerade mal übernehmen?
Genau, auch zum Thema eben Barrierefreiheit.
Was sind eigentlich Barrieren?
Das muss man sich vor Augen halten, weil viele Menschen denken in erster Linie auch an Barrieren im Sinne von, ich habe jetzt vielleicht irgendwie eine blinde Person, die eine Web-Anwendung bedienen möchte.
Aber zum Thema Barrieren und Barrierefreiheit gehört eben noch viel mehr dazu.
Also oft sind es halt eben die permanenten Barrieren, die uns über den Weg laufen, die wirklich, wo wir sagen, okay, da müssen wir wirklich was tun, damit die Leute auch grundsätzlich darauf zugreifen können.
Aber es gibt eben auch sowas wie temporäre Barrieren.
Also stellen wir mal vor, ich habe mir einen Arm gebrochen und kann vielleicht irgendwie meine Tastatur entsprechend nicht richtig bedienen oder meine Maus nicht richtig bedienen.
Und ich brauche vielleicht irgendwie eine Alternative, wie ich meine Web-Anwendungen bedienen kann.
Oder ich habe vielleicht irgendwie eine Augenoperation gehabt oder irgendeine Entzündung.
Das alles sind Barrieren.
Genauso eben irgendwie auch, wenn ich mein Kind auf dem Arm habe und jetzt vielleicht nicht irgendwie auch entsprechend nur mit einer Hand mein Smartphone bedienen kann.
Oder ich habe vielleicht ältere Leute, die vielleicht Probleme haben mit der Schriftgröße, weil die ein bisschen klein ist oder der Kontrast nicht so hoch ist.
Also auch Augenprobleme zum Beispiel treten ja auch gern mal im Alter auf.
Das auch sind alles Barrieren, die eben temporär oder auch situativ sein können, wo wir alle auch davon profitieren, wenn wir als Entwicklende darauf achten, diese Barrieren sozusagen zu berücksichtigen.
Und dann haben wir eben alle sozusagen eine einfache Webseite, die wir einfacher bedienen können.
Eine schnelle Anmerkung noch, weil mir die da relativ passend ist.
Es gibt auch so einen schönen Satz, ich versuche ungefähr richtig zu zitieren, dass wir die Barrierefreiheit ja wirklich selbst auch für uns bauen, wie Dennis auch gerade schon angedeutet hat, weil ein jeder Mensch potenziell im Laufe des Lebens nur eine Zeit lang nicht von Einschränkungen betroffen sein wird.
Und dementsprechend ist es etwas, das uns wirklich alle angeht.
Das ist keine zu marginalisierende Thematik, über die wir hier reden.
Das finde ich einen super spannenden Aspekt, weil oftmals wird es ja so vom Tisch gewischt von wegen, na ja, unser Angebot, gehen wir davon aus, dass jeder es sehen kann.
Aber ich meine, ich habe es ja jetzt auch im Alter mit der Brille und merke, oh, ich habe die falsche Brille mitgenommen.
Pech gehabt, ja, für den Tag.
Diese fünf Kategorien, die ich jetzt hier auf der Slide sehe, also Steuern, Sehen, Hören, Sprechen, Denken, sind das so offizielle Kategorien, mit denen man bei der Accessibility arbeitet?
Ich würde sagen, die sind so halbwegs normiert.
Also es gibt, das basiert jetzt letztendlich auf einer ganz schönen Visualisierung, die auch von Microsoft kommt.
In den W3C findet sich das, war das dort eher eine technisch normative Beschreibung, findet sich das ein bisschen anders.
Wieder dort wird eher davon gesprochen, das ist zum Beispiel in der W3C, und auch da können wir gleich nochmal erklären, was das konkret ist, dass es dort eingeteilt ist, einzelne Kriterien, die zu testen sind, konkret in die Bereiche wahrnehmbar, bedienbar, verständlich, robust.
Und dennoch sind die natürlich ein bisschen eher technisch wiederformuliert.
Das heißt, ich mag den einen Slide auch wirklich sehr gerne, weil man da einfach sagen kann, das ist dann tatsächlich leichter auch annehmbar, da komme ich leichter rein, da komme ich leichter, kann ich auch was von entsprechend empfinden dann, von diesem Punkt, genau.
Jetzt hatte ich gerade da den Begriff WCAG gesehen.
Also wir haben es ja auch mit Standards zu tun.
Das ist jetzt aber kein deutscher Standard WCAG, oder?
Nee, genau, das ist ein Standard aus dem World Wide Web.
Wir haben das hier versucht, nochmal ein bisschen die Zusammenhänge zu verdeutlichen.
Also letztendlich gibt es das World Wide Web Konsortium, was im Prinzip über alle möglichen Standards im Web die Schirmherrschaft hat, und innerhalb des W3C gibt es dann diese Web Accessibility Initiative, und die wiederum veröffentlicht die Web Content Accessibility Guidelines, wo wir uns gerade meistens nach der Version 2.2 richten, da ist auch schon eine Version 3.0 schon in Arbeit, aber das ist eben sozusagen eigentlich ein Katalog sozusagen an Richtlinien, die wir beachten müssen, wenn es um Barrierefreiheit geht, und das Ganze, diese Guidelines, die werden dann eben auch referenziert in der europäischen Norm 301.549, und in der BITV wird das Ganze dann in Deutschland umgesetzt, und da wiederum, das Ganze ist durch das BFSG entsprechend auch geregelt und eben auch gesetzlich vorgeschrieben, dass wir verpflichtet sind, eben auch diese Regularien eben einzuhalten und uns da nachzurichten.
Gibt es eine Langform für BITV?
Barrierefreie Informationstechnikverordnung.
BGG ist das Behindertengleichstellungsgesetz, und das BFSG ist das Barrierefreiheitsstärkungsgesetz.
Danke sehr.
Stimmt, gerade in Fallen, merci.
Viele kennen vielleicht auch den Begriff noch EAA, das ist der European Accessibility Act, und das BFSG ist im Prinzip die deutsche, also die nationale Umsetzung dieses EAA.
Das hört sich alles sehr, sehr deutsch an.
Aber wo wir gerade bei Abkürzungen sind, ich lese immer ALI, also ich lese es als ALI, und es ist irgendwie A11y.
Könnt ihr das kurz nochmal auflösen?
Ja, da gibt es ja im Bereich Web recht viele so Numeronyme, nennen die sich auch I18n zum Beispiel, oder LCn, also für Internationalisierung oder Lokalisierung.
Und A11y meint einfach, bei Accessibility ist A der erste Buchstabe, dann folgen elf weitere, und am Ende kommt ein Y.
Und das ist im Prinzip was ein Numeronym ist.
Also für die Schreibfoulen, und dass man nicht wieder irgendwie eine komische Abkürzung nimmt, wo der Müller dann nachfragt, was bedeutet das eigentlich?
Okay, gut.
Ja, jetzt haben wir die Slides offen.
Was habt ihr da uns als nächstes mitgebracht?
Ja, wir können einmal mal gerade eingehen, ganz konkret dazu, und vielleicht ist es ein ganz guter Übergang auch nochmal von dem, was du vorhin schon mal gefragt hattest, Ralf.
Das war so diese Thematik, wie weit kann ich mich eigentlich dem Thema einer barrierevollen Umsetzung oder auch einer Barrierefreiheit dann am Ende des Tages auch nähren?
Ich würde vielleicht sogar tatsächlich erst mal mit dem anderen Slide einsteigen, wo du auch gefragt hast, wie ist das jetzt für eine Terminologie, Barrierefreiheit, Barrierearmut?
Tatsächlich ist es halt so, die Terminologie, der Begriff Barrierefreiheit, der ist wirklich technisch, juristisch und normativ anzusehen, ist derartig geprägt, ist auch ein binärer Begriff, entweder ist zum Beispiel ein digitales Angebot oder auch, was wir hier auch aufgeführt haben, eine DIN-Norm zum Beispiel für barrierefreies Bauen, da ist es durchaus so, entweder ein solches Angebot ist barrierefrei oder halt nicht.
Und es ist tatsächlich auch derart entsprechend anzusehen, auch derart entsprechend dann zu klassifizieren.
Davon abgetrennt geht es zu diesem Begriff der Barrierearmut, und da ist es so, dass es gerade in der Literatur oder auch in der öffentlichen Nutzung halt als Begriff auch gerade dann genutzt wird, wenn es so um Übergangslösungen geht, wenn es dann darum geht, man hat ein bisschen was verbessert auf diesem Weg, denn es ist ein Weg, gerade auch ein digitales Angebot barrierefrei zu erstellen, es ist ein Weg, der organisatorische, aber auch in der IT-Architektur bezogene Lösungen mitbedingt.
Und auf diesem Weg quasi dann zum Ausdruck zu bringen, wir sind an so einer Zwischenstation angekommen, aber wir sind halt wirklich auch noch nicht da, wir sind noch nicht bei der Barrierefreiheit, wir wissen aber entsprechend darum.
Das ist so ungefähr die Differenzierung der Terminologie.
Und eine ganz schnelle Anmerkung noch zu dem, was du vorhin schon angemerkt hast, Ralf, wie stark kann man sich so diesem Thema Barrierefreiheit dann auch widmen, wie stark kann man das erreichen?
Es ist einerseits durch diese Norm und auch durch die Gesetze vorgeschrieben, und ich fand es sehr schön, was Erik Eggert dazu auf LinkedIn geschrieben hat, ich werde es jetzt nicht komplett vorlesen, aber er sagt, so ungefähr als Quintessenz, eine Seite ist, nachdem man jetzt nach der WCAG alles entsprechend umgesetzt hat, nach diesen Kriterien das Ganze getestet hat, noch nicht unbedingt perfekt nutzbar, es sagt noch nicht unbedingt etwas darüber aus, dass es dann gut nutzbar ist, aber es ist trotzdem so, dass wir auch zum Beispiel im Verkehrsbereich entsprechende Gesetze haben, dass wir einen Führerschein machen, danach sind wir immer noch nicht ein guter Fahrer am Ende des Tages, ein guter Autofahrer, aber auf der anderen Seite ist es halt schon so, dass es unsere demokratische, unsere gesellschaftliche Basis, das, was wir ausgehandelt haben, ist, und deswegen gibt es quasi das Ganze, weil es die Basis dafür darstellt, und es gibt auch noch weitere Arbeiten, die darauf folgen.
Aber jetzt, selbst wenn meine Website barrierefrei tituliert ist, dann wird sie ja teilweise auf Geräten ausgeführt, oder was heißt teilweise?
Ich meine, die Smartphones, ich erinnere mich an die Zeit zurück, als ein Smartphone, ein Personal Digital Assistant, eine Tastatur hatte, die ich fühlen konnte, wo ich blind tippen konnte, und jetzt haben wir nur noch die Touchscreens, wo ich mir denke, ich bin froh, dass ich den Touchscreen sehen kann, dass ich weiß, was für Optionen es gibt, wo ich hinklicken kann und sonst was.
Kann ich auf so einem Device überhaupt barrierefrei arbeiten?
Danny?
Magst du?
Es gibt natürlich ja auch Technologien, die uns dabei unterstützen.
Also, wenn ich jetzt hier auch mal das Beispiel nehme, eben von blinden Personen oder sehr eingeschränkten Personen, die vielleicht eine starke Seheinschränkung haben und tatsächlich alles nicht so gut erkennen, auch auf dem Touch-Device, dann gibt es ja so Technologien wie Screen Reader, die eben sowohl für Desktop-Devices als auch für Touch-Devices vorhanden sind.
Und eben auch von den Herstellern, also bei Android hat man kannte Sachen wie Talkback, und bei iOS gibt es eben Voice-Over, die da eben auch schon mit integriert sind, mitgedacht sind, wo ich dann wirklich Unterstützung habe, dass mir das Smartphone eben ansagt, wo bin ich jetzt gerade mit meinem Finger drauf?
Auf welchem Buchstaben bin ich gerade drauf?
Und dann muss ich den halt irgendwie doppelt anklicken, damit der entsprechend ausgewählt wird.
Also, ich habe da unterstützende Maßnahmen, die mir eben helfen, dieses Haptische so ein bisschen zurückzubekommen.
Okay, das ist ja jetzt, ich meine, ich sage mal, ich als nur situativ Eingeschränkter, wenn ich das jetzt so richtig formuliert habe, kenne ja diese ganzen Features gar nicht.
Gibt es da nicht vieles, was vielleicht auch, wenn ich es kennen würde, auch mich unterstützen könnte?
Ich denke an so Sachen, dass mir zum Beispiel eine Nachricht vorgelesen wird oder sowas.
Ist da nicht zu viel irgendwo auch im Versteckten, was wir uns selbst gar nicht aktivieren, dass wir mit den Geräten besser umgehen können?
Wir hatten es ja vorhin, dass situativ sind wir alle irgendwann mal betroffen von Einschränkungen.
Und dann wäre es ja eigentlich ganz gut, wenn wir das wüssten, oder?
Ja, es ist sogar tatsächlich so, dass die Aspekte, die dort erfunden werden, in dem Lösungsraum oder eben von anderen entsprechend auch erdacht werden oder umgesetzt werden, dass die schon Einzug gehalten haben, dass du sie vielleicht gar nicht so aus diesem Kontext betrachtet hast.
Das sind beispielsweise Möglichkeiten, aus Browsers entsprechende Suggestions zu bekommen, entsprechende Vorschläge zu bekommen, die dann beispielsweise deine Adresse vorausgefüllt eingetragen, wo du es eintragen lassen kannst.
Aber selbst ein Device, wie jetzt zum Beispiel unsere Voice Control, ist jetzt gerade mal so von Amazon zum Beispiel mitgenannt.
Da geht es ja darum, dass du Menschen, die gegebenenfalls durch eine motorische Einschränkung tatsächlich jetzt nicht die Möglichkeit haben, gewisse Dinge abzurufen oder die einfach eine Erleichterung dadurch erhalten oder auch selbst Siri wird so aus diesem Kontextpotenzial kommen, die aber trotzdem so in eine breite Maße an Nutzenden auch Einzug gehalten haben.
Da kann man halt auch wirklich sagen, es wurde vielleicht aus einem Kontext für ein konkretes Problem erdacht, aber es hilft dann am Ende des Tages allen, wenn wir Barrierefreiheit allgemein umsetzen, wenn wir dort Innovationen einbringen, wenn wir das Thema voranbringen.
Das ist halt so ein bisschen dieser Übergang zwischen UX und Barrierefreiheit.
Barrierefreiheit sorgt auch an vieler Stelle für eine sehr gute User Experience.
Also auch wenn ich jetzt so an Texteingabefelder denke, wo mittlerweile mein natives Device, mein iPhone, mein Android-Smartphone mir eben die Möglichkeit bietet, dass ich eben auch meinen Text einfach per Spracheingabe dort eingeben kann, eben nicht selber tippen muss sozusagen.
Oder dass ich eben bei numerischen Eingabefeldern entsprechend auch wirklich nur eine numerische Tastatur angezeigt bekomme.
Das alles sind Sachen, wo wir auch als Entwickler irgendwie Einfluss drauf haben und im Prinzip sowohl zur besseren User Experience beitragen, als auch zur Barrierefreiheit.
Ja, Markus sagt im Chat gerade, sehr hilfreich für alle Untertitel bei Videos oder auch Livestreams.
Das ist zum Beispiel so ein Feature, was ich gerne vergesse.
Und teilweise nervt es mich auch, wenn die Untertitel gerade bei irgendwelchen Videos so fett drübergelegt sind oder so.
Und gerade eben war, ja genau, sowas wie Spracheingabe bei der Tastatur, das finde ich, ist auch noch viel zu, ja, man verwendet es nicht so alltäglich.
Und ich muss mich immer erst wieder daran erinnern, dass ich ja bei der Tastatur tatsächlich ein Voice-to-Text drin habe.
Und viele Leute benutzen ja dann doch lieber die Sprachnachricht, wo ich mich immer ärgere, Mensch, jetzt muss ich mir erst mal 10 Minuten irgendwie Smalltalk anhören, bis derjenige dann auf den Punkt kommt.
Man muss sich dran gewöhnen, man muss es richtig verwenden.
Ja, absolut, absolut.
Ich mag auch das Beispiel von Markus deswegen sehr gerne, weil es wieder so ein kleiner Mosaikstein genau in der Richtung ist.
Das wurde vielleicht mal entsprechend konzipiert und erdacht, Untertitel einzufügen für Menschen mit gewissen Einschränkungen.
Aber heutzutage hat es sich halt soweit auch in die Kultur einbezogen, dass wenn du im Zug sitzt, wenn du vielleicht eh eine laute Umgebung hast, dort vielleicht auch den Ton gar nicht anmachen willst, siehst du dort Menschen sitzen, die auf ihr Handy gucken und entsprechend sich die Sprache durch Untertitel ausgeben lassen.
Das heißt, du hast dort auch wieder so diesen Aspekt von, es zieht einfach ein in eine allgemeine Nutzung, sagen wir mal.
Und das ist so ein schönes Beispiel aus der Richtung.
Ja, Eberhard hat gerade hier im Chat richtig ergänzt.
Wir haben im Nachgang einen Transkript unserer Folgen über KI, lassen wir die Folge auch nochmal dann zusammenfassen, über normale Technologie zu erschlagen.
Und die richtige Slide ist da.
Wir sind auch alle hier vorbereitet, Ralf.
Du kreierst tatsächlich eine große Unterstützung auch, also gerade wenn es auch darum geht, irgendwie Regressionen sicherzustellen, also wirklich meine Website auch nachhaltig sozusagen abzusichern und zu prüfen, dass eben die Barrierefreiheit auch künftig eingehalten wird, auch wenn nicht neue Features im Zubau.
Da ist gerade dieses Entwickeln von Testplänen oder auch konkreten Unit-Tests oder Integrations- oder End-to-End-Tests ist auf jeden Fall ein Riesenpunkt.
Also ich kann zum Beispiel sehr gut der KI sozusagen meine Anwendung in den Kontext geben und dann eben entsprechend basieren, auf den WCAG-Kriterien mir entsprechenden Testplan aufstellen lassen, wo ich sage, hey, sag mir mal konkret, welche Kriterien treffen denn jetzt für meine Anwendung zu?
Was sollte ich denn auf jeden Fall automatisiert zum Beispiel prüfen und schreib mir doch gleich mal ein paar Tests dazu.
Das ist natürlich nicht die Lösung und man kann jetzt nicht die KI da irgendwie völlig alleine das machen lassen.
Man muss das natürlich schon noch prüfen und auch auf Sinnhaftigkeit eben überprüfen.
Aber es ist auf jeden Fall eine große Unterstützung oder auch wenn es darum geht, zum Beispiel Bildbeschreibungen zu erstellen.
Das ist so ein Klassiker, der gern vergessen wird.
Ich habe irgendwie eine Grafik, die auf meiner Seite irgendwas darstellt und es fehlt aber komplett irgendwie der Alternativ-Text dazu.
Das heißt, wir schließen damit eben im Prinzip alle Menschen, die nicht sehen können, aus.
Die können diesen Content einfach nicht wahrnehmen.
Und da ist es eben wichtig, alternative Beschreibungen, Beschriftungen für dieses Bild eben auch darzustellen und auch bei sowas kann mir eben die KI sehr gut helfen, auch da immer nochmal kontrollieren, dass da kein Quatsch drinsteht.
Die ist auf jeden Fall nicht fehlbar.
Deshalb genau da unten, da ist der Punkt Human in the Loop ganz wichtig auch hier.
Aber jetzt mit den Bildbeschriftungen, ich meine, ich muss zugeben, ich sehe die Bildbeschriftung eigentlich nie.
Deswegen, wenn ich da mal irgendwie auf die Schnelle was mache, dann vergesse ich sie meistens.
Ist das immer noch so, dass wir die Bildbeschriftung selbst machen müssen oder unterstützen da die Browser schon, dass wenn sie erkennen, oh, da fehlt eine Bildbeschriftung, da setze ich eine selbst mit KI hin.
Wir haben einen Arbeitskollegen, der tagtäglich genau mit diesem Feature kämpft, weil er halt sagt, ich kriege da zu 50 Prozent gute Ergebnisse, zu 50 Prozent wie Murks.
Da müssen wir jetzt mal mit einem KI-Experten nochmal reden, woran das liegt, Ralf.
Aber ich glaube, es ist so dieses Thema von dieses Human in the Loop.
Ich glaube, das kann man hier nicht hoch genug ansetzen.
Natürlich auch aus ökologischen und ökonomischen Gründen zu sagen, ich muss mir das nicht jedes Mal wieder entsprechend übersetzen.
Das kann ich einmal machen, das ist in den Prozess integriert.
Ich habe danach jemanden, der nochmal drüber guckt und dann wird das entsprechend auch fest hinterlegt.
Weil mein laienhaftes Verständnis, auch hier wieder, ich bin kein KI-Experte, ist aber auch an der Stelle im Endeffekt, am besten arbeite ich mit akkuraten Daten.
Das heißt, ich sollte es in meinem Prozess optimieren und nicht erst beim Nutzer.
Ich sollte nicht zwischen meiner Website und den Nutzenden eine KI stellen, sondern ich sollte einfach für akkurate, gute Datenqualität, gute Auszeichnungen sorgen.
Und das sollte so meine Maxime sein.
Davon sollte ich den Einsatz dann auch ableiten.
Ja, gerade hier ist auch ein bisschen die Gefahr.
Also wenn du eben die Daten reingibst, die die KI nimmt und du hast halt irgendwie eine große Datenquelle mit vielen Bildern und 90 Prozent der Bilder haben eine schlechte Beschriftung, dann ist natürlich der Output entsprechend auch nicht so gut.
Genau, einen richtig guten Vortrag auch noch unbedingt zu erwähnen, hat auch die Casey Krier auf dem letzten CCC im letzten Jahr mitgeliefert unter dem Titel Rettet uns die KI über die Zukunft der digitalen Inklusion.
Das auch unbedingt mal googeln oder halt später über den Handout der Folien auch nochmal zu beziehen.
Aber ich denke mit ein Problem wird hier der fehlende Kontext für die KI sein.
Wenn sie nur das Bild sieht, kann eben teilweise der Kontext fehlen, sodass sie es nicht gut beschreiben kann.
Und dann ist wieder die Gefahr.
Ja, wenn die KI uns die Bildunterschriften generiert, werden wir faul und Human in the Loop ist immer gut.
Aber wenn wir halt zu faul sind, um den Human in the Loop zu machen, dann haben wir wieder ein Problem.
Das ist auch ein super Stichwort.
Auch der Markus hat gerade nochmal im Chat dazu was geschrieben.
Dieser Kontext ist so entscheidend, weil du kannst auch, also darüber könnte man fast wahrscheinlich einen eigenen Vortrag nochmal halten, aber vielleicht schnell zusammengefasst.
Ein Produktbild, das ich in einem Webshop ausgebe, kann eine komplett andere Bedeutung in der informationstragenden Seite haben.
Es kann sein, dass es mir auf dem Webshop um die Zutaten eines Produktes geht, bei einem Lebensmittel zum Beispiel.
Was ich in einem anderen Fall beschreiben will, was ich auf diesem Bild beispielsweise sehe oder was das Ganze ausmacht.
Es kann sein, dass ich, wenn ich es kaufen will, dass es mir sehr wichtig ist, ob das jetzt eine Dose ist, die ich entsprechend im Drehfahrtsschluss habe oder ein Glas ist oder ob ich da noch ein weiteres Utensil brauche, um die zu öffnen.
Da sind so ganz viele Aspekte, die einfach aufmachen.
Den Kontext bringst du in der Regel über das, was du auf der Seite abbildest, wo du dieses Bild kontextualisiert einfügst.
Und deswegen ist es so entscheidend.
Das wird uns eine KI nicht direkt abnehmen können.
Vielleicht irgendwann mal.
Sie versteht auch den Kontext etc.
Aber da zu sagen, ich gebe das akkurat rein, wie ich das als Seitenbetreiber, wie ich das als Informationsanbieter auch gerne hätte, das ist sicherlich auch eine menschliche Leistung.
Aktuell auf jeden Fall.
Was mache ich denn, wenn ich zum Beispiel so dekorative Bilder habe?
Du hast jetzt gesagt ein Rezept und teilweise hat man ja dann einfach nur.
Ach komm, ich mache hier irgendein Bild mit Zutaten, die passt nicht zu den Zutaten, aber ich habe ein Bild.
Ich habe es optisch verschönert.
Ja, ist es dann fair, den Alttext wegzulassen oder soll ich dann reinschreiben?
Also nur ein Platzhalter.
Genau.
Also mal genau.
Man sollte das Attribut entsprechend setzen, aber dann tatsächlich mit einem mit einem leeren String.
Also das Ding ist, man muss sich halt immer überlegen, ist es für jemanden, der den nicht sehen kann, hilfreich, eine Beschreibung dieses Bildes zu bekommen?
Wenn ich jetzt zum Beispiel, ich habe einen Button und auf dem ist ein Diskettensymbol und daneben steht speichern, dann brauche ich nicht das Diskettensymbol nochmal mit speichern zu beschriften.
Das bringt sozusagen keinen Mehrwert an der Stelle.
Habe ich aber nur einen kleinen Button, wo nur ein Diskettensymbol ist und ich habe keine Information, dass das der Speichernbutton ist, dann sollte ich auf jeden Fall diesen Text mit hinterlegen.
Aber da sprichst du ja jetzt auch noch so diesen Altersbezug an.
Also wir wissen, was ein Diskettensymbol ist.
Ja, stimmt.
Das, was ja vor allem gemeint ist, man stellt sich das jetzt vielleicht mal so kurz für die Fantasie vor.
Ich habe irgendwie ein Diskettensymbol und daneben steht nochmal ein Text, der dann ja tatsächlich auch in der Internationalisierung quasi, das steht dann safe oder steht speichern oder so.
Vielleicht steht aber im Kontext auch was anderes und man hat sich tatsächlich zu diesem Symbol was anderes gedacht.
Es ist halt, und da können natürlich jetzt Danny und ich als nicht tägliche Anwendende, Screen-Widerlutzende auch nicht ungeheuer dafür sprechen.
Und die Diskussion, die ich wahrnehme, ist, es ist so diese Gemengelage von die Information wäre jetzt redundant, wenn ich jetzt die Diskette beschrifte mit speichern, salopp formuliert.
Also da bringt mir das überhaupt nichts.
Da steht ja eine Beschriftung mit speichern.
Spannend wird es im Fall von so Bildern, die nicht rein informationstragend sind, bei denen zum Beispiel jetzt nicht im Text abgebildet wird, sondern die vielleicht auch einen emotionalisierenden Charakter haben.
Ich denke mal einfach an eine Website für Reisendenbuchungen.
Da ist irgendwie ein Strand zu sehen.
Da sind lachende Menschen zu sehen, die am Strand rumlaufen.
Das kann, es ist keine normative Bildinformation, die relevant ist, aber es kann halt auf einer Reisebuchung selbst dann trotzdem etwas sein, das natürlich zu meiner User Experience dazugehört, das natürlich dazugehört zu diesem Erlebnis, eine Reise zu buchen, dass ich auch so etwas beschrieben haben will.
Und hier sind wir wieder bei Kontext.
Das ist eine Sache, die nicht in den Normen so klar vorkommt, die sicherlich immer wieder auszuhandeln ist, die auch gegensätzlich Positionen ein Stück weit ausmacht, aber die stark eben auch beim Seitenbetreiber dann liegt, das zu beurteilen.
Wo du jetzt so emotionale Bilder angesprochen hast, Emojis.
Ich hatte mal mitbekommen, dass das gar nicht so toll ist, wenn ich jetzt irgendwie in meinem Namen auf Social Media irgendwie fünf Emojis drin habe.
Ist da was dran?
Also man sollte auf keinen Fall Emojis dazu verwenden, Textinformationen zu ersetzen.
Also es gibt ja auch gerne mal so LinkedIn-Beispiele, wo Leute so komische, das sieht dann aus, als wäre das eine fancy Schriftart, aber eigentlich sind das irgendwelche Sonderzeichen, die natürlich absolut nicht barrierefrei sind und das führt dann natürlich dazu, dass mir so ein Screenreader zum Beispiel dann entsprechend Kauderwelsch vorliest.
Also ich kann dann nicht mehr sinnvoll sozusagen diesen Text irgendwie wahrnehmen.
Emojis können genutzt werden, aber zum einen irgendwie nur in Maßen und zum anderen sollten sie eben nicht Informationen ersetzen, weil man muss sich immer auch da denken, okay, ich habe jetzt so einen Screenreader, eine assistive Technologie, die geht da drüber, die liest das alles vor und wenn die dann mir irgendwie 20 Mal hintereinander vorliest, lachender Smiley und trauriger Smiley und eine Gurke oder sonst was, dann ist das natürlich total ablenkend und irritierend für Menschen, die mit solchen Technologien arbeiten.
Ich sehe jetzt hier gerade einen ganz interessanten Kommentar über die Cookie-Banner, die irgendwo in den Gesetzestexten aufgetaucht sind und dann hat jeder gedacht, bevor ich abgemahnt werde, setze ich die auch auf meine Website und dass die ja auch nicht so richtig barrierefrei sind.
Da widerspricht sich der Gesetzgeber ein bisschen, oder?
Das wäre jetzt fast ein eigener Vortrag wahrscheinlich nochmal.
Ich habe kürzlich auch gelesen, es ist halt so dieser Trade-off, du fragst und es ist jetzt nichts gegen Juristinnen und Juristen, aber du fragst drei Juristen und Juristen kriegst fünf Meinungen.
Es ist wahrscheinlich so diese Gemengelage, was bilden wir dort gerade ab im Endeffekt, wie restriktiv sind wir?
Meinem Verständnis nach, was ich kürzlich als rechtliche Bewertung mal wieder gelesen habe, ist, dass wir teilweise da so ein bisschen übers Ziel hinausschießen und für Teilbereiche, für Funktionalitäten unserer Websites, wo ich es eigentlich gar nicht bräuchte, direkt mal mit einem Cookie-Banner nochmal drauf haue.
Das heißt, das ist aber ein eigenes Thema sozusagen.
Was aber die Barrierefreiheit betrifft, ist, dass wir natürlich dadurch, dass wir eben auch immer wieder Tests durchführen, dass wir Seiten selbst auch nochmal mit analysieren, auch einfach sehen, die Anbieter, die es da draußen gibt, die großen Anbieter, ohne jetzt welche Einzelnahme zu benennen, die haben auch nach wie vor alle ihre Probleme.
Dort kannst du bei jedem dieser Anbieter nach wie vor feststellen, dass sie tatsächlich allzu oft nicht zügig sind.
Und das ist ja in dem Fall gerade sehr relevant, auch hier wieder, ich bin kein Jurist, aber meinem Verständnis nach musst du dort als Seitenbetreiber ziemlich genau informieren.
Eine bewusste Entscheidung auch treffen können und wenn du das halt nicht den Nutzenden bietest quasi, dann hast du sicherlich auch rechtlichen Problemen, aber das ist juristisch nochmal mehr zu bewerten dann.
Okay.
Jetzt sind wir ja hier bei Software-Architektur im Stream-Architektur.
Wie ist das?
Kann ich irgendwie eine bessere Grundlage legen, eine Architekturentscheidung treffen, um die Barrierefreiheit gleich von Anfang an zu unterstützen?
Auf was ist da zu achten?
Ja, tatsächlich ist das eine sehr gute Frage, weil letztendlich die Architekturentscheidungen sind ja immer die, die wir sozusagen im Nachhinein schwer ändern können.
Und da gibt es tatsächlich sehr viele.
Gerade im Frontend-Bereich ist es in der Regel so, dass ich als Grundlage für mein gesamtes Design irgendwie auf ein Framework aufsetze.
Also sind die wenigsten, die jetzt irgendwie ihr ganzes CSS-Template und so weiter alles per Hand schreiben, sondern man greift in der Regel auf Komponenten-Libraries zurück.
Man greift eben auf fertige Dinge zurück.
Und genau bei dieser Auswahl dieser Dinge, gerade wenn es wirklich komplette Komponenten-Libraries sind, die mir wirklich vom Button bis zum Eingabefeld bis hin zu irgendwelchen Modalen und so weiter alles bieten, ist es ganz wichtig, dass wir da darauf achten, sind diese Sachen, sind die grundlegenden Libraries, sind die barrierefrei?
Weil es wird für uns ganz schwierig, wenn wir sozusagen diese Foundation auf unserem UI haben, dann wird es ganz schwierig, die nachher wieder barrierefrei zu machen, wenn eben darunter sozusagen irgendwie Standards sozusagen ausgehebelt werden.
Und grundsätzlich ist es so, das Web ist barrierefrei, das ist barrierefrei gedacht.
Wir sollten möglichst viel semantisches HTML verwenden, das ist eben das gesamte Spektrum, was uns HTML bietet mittlerweile, und da gibt es halt auch solche Landmarks, die zum Beispiel auch meine Seite hier in grobe Regionen aufteilen, die helfen eben auch Screenreadernutzenden, zwischen diesen Regionen auch schon mal hin und her zu springen, damit sie auch schneller navigieren können, und es gibt eben entsprechend auch noch die ARIA-Attribute, die eben dann noch mal unterstützend dafür da sind, Dinge noch mal besser auszuzeichnen, hervorzuheben und so weiter.
Aber wichtig ist wirklich, ich brauche irgendwie eine gute Grundlage bei meiner Auswahl, bei meinem Framework, damit ich eben nicht dann in die Gefahr gerate, ich entwickle irgendwas und kann es hinterher nur ganz schwer barrierefrei machen, weil einfach die Grundlage darunter zu schlecht ist.
Die meisten UI-Libraries, sollte man mal nachschauen, die haben auch dazu irgendwo oft einen extra Abschnitt zum Thema Barrierefreiheit, wo sie auch erläutern, was sie dazu beitragen, wie sie das machen, das sollte man sich auf jeden Fall mal durchlesen.
Wenn man das nicht findet, dann ist das meistens nicht so ein gutes Zeichen, und dann sollte man auf jeden Fall evaluieren, ob entsprechende Sachen da wirklich barrierefrei sind.
Aber dann können wir ja schon mal festhalten, dass Architekturentscheidungen immer als Kriterium irgendwo die Barrierefreiheit mit berücksichtigen sollten.
Notfalls kann man ja sagen, okay, die Komponente, die verändert die Barrierefreiheit nicht, Haken, aber wir sollten es immer jetzt irgendwie in den Entscheidungen drin haben.
Mit dem ARIA-Attribut, das hatte ich jetzt noch nicht so ganz verstanden.
Was ist das für ein Attribut?
Ich bin nicht so mehr im Frontend drin.
Könnt ihr das noch mal kurz erläutern?
Genau, ja.
ARIA-Attribute jetzt im Speziellen, oder Danny hatte das, was wir jetzt auch eingebildet haben, aber das eben noch mal verbalisiert.
Wir haben einerseits zunächst mal die Möglichkeit, natürlich aus den, ich weiß es nicht ganz aus dem Kopf, 120, 150 bereits bestehenden HTML-Elementen entsprechend auszuleben, eine Seite semantisch aufzubauen und dort auch durchaus für ein Video zum Beispiel das Video-HTML-Element zu nutzen, weil ich da wie ein kleines Micro-Frontend in meinem Browser direkt integriert habe.
Das heißt, die Funktionalität ist da, ich brauche dafür kein JavaScript, also keine weiteren Technologien, die ich nochmal über die Leitung übertragen muss.
Ich habe eine gewisse Barrierefreiheit, die in der Regel dann eben auch sichergestellt wird, schon mal von den Browser-Anbietenden.
Das sind also diese Grundelemente, die jetzt schon existieren, die über eine lange Laufzeit vom W3C letztendlich am HTML-Standard aufstandsisiert wurden und für Funktionalität, die so darüber hinausgeht, wo ich einfach sage, dort habe ich noch mal eine Annotation, die ist vielleicht gar nicht für alle sichtbar, sondern die ist speziell für Hilfsmittel gedacht beispielsweise oder Thematiken auch, dass ich irgendwelche neuen UI-Elemente auch entsprechend trotzdem semantisch auszeichnen will, selbst wenn ich noch kein HTML-Element dafür habe.
Dafür sind diese sogenannten ARIA-Attribute als entsprechende Annotationen einsetzbar.
Das heißt, damit kann ich einfach Semantik mitgeben und das ist nochmal ein komplett eigener Namespace, der sich dort dann nochmal auftut.
Jetzt hast du gerade von neueren Elementen wie dem Video-Element gesprochen.
Das heißt, wenn ich jetzt irgendwie eine alte Anwendung habe, die halt auf altem HTML basiert, dann habe ich tatsächlich Probleme, die irgendwie nachträglich barrierefrei zu bekommen, oder?
Da kann ich jetzt nicht irgendwie ein Layer drüberlegen oder so und sagen, so, jetzt habe ich es, sondern dann habe ich wahrscheinlich tatsächlich das Problem, dass die ersetzt werden muss, oder?
Das kommt stark darauf an quasi, ob die damals schon barrierefrei gedacht wurde.
Ich habe kürzlich eine Seite von mir wiederentdeckt, die ist jetzt so 20 Jahre alt.
Das Faszinierende ist ja, wir haben uns immer mal zu Anfang des World Wide Web gedacht, wir bauen etwas, das dann Wissen semantisch abgelegt bekommt.
Das rufen wir später auf.
Ja, das ist noch abrufbar, aber das waren damals halt Konstrukte in, es wird so ein bisschen technischer nochmal aus dem Bereich Entwicklung, es waren damals halt Table-Konstrukte.
Damals haben wir Layouts über Table-HTML-Elemente abgebildet.
Und das Problem in diesem Fall ist, dass die halt zum Beispiel eine Visualität dann aufgemacht haben, die aber weder responsive ist, also sprich, ich kann es potenziell auf einem mobilen Endgerät nicht angucken.
Ich habe gegebenenfalls auch Menschen, die ein Gerät nur in einer gewissen Ausrichtung sich angucken, eine Website nur in einer gewissen Ausrichtung angucken können durch das Gerät in der gewissen Fixierung.
Und ich habe natürlich auch tatsächlich zum Beispiel Screenreader-Nutzende, die in dem Fall einfach eine Visualität in eigentlich einer semantischen Datenstruktur abgebildet bekommen.
Wenn man das damals schon mitgedacht hat, auf Semantik schon gesetzt hat in frühen Zeiten, auch schon auf Styling über CSS abgebildet hat, teilweise reden wir ja bei so einer Laufzeit von so einer Anwendung über fünf bis zehn Jahre, dass die durchaus schon Legacy sein kann.
Wenn das damals schon mitgedacht war, kann es auch sein, dass die wirklich schon gut umgesetzt ist und dass du noch gewisse Kniffe machen musst.
Es kann aber auch sein, dass du es wirklich tatsächlich in größerem Teil neu schreiben musst.
Okay.
Du hast jetzt ganz häufig den Screenreader erwähnt.
Und das ist so ein Ding.
Ich habe keinen Screenreader.
Also ich fände es mal ganz interessant, wenn man mal so selbst diese Erfahrung machen könnte.
Wie kommt so eine Website für jemanden rüber, der eben Hilfsmittel verwendet?
Habt ihr da irgendwelche Tipps und Tricks, was man da machen kann?
Auf jeden Fall.
Also weil du sagtest, du hast keinen Screenreader.
In der Regel hat eigentlich jeder, der irgendwie ein Smartphone hat, hat einen Screenreader mit dabei oder kann sich den nachinstallieren oder auch auf einer Desktop-Anwendung.
Da gibt es verschiedene.
Das kommt immer auf die Technologien an.
Also bei Apple hat man meistens dann eben VoiceOver, was eben der Out-of-the-Box-Screenreader ist, der wirklich von Apple für iOS und für Macintosh entsprechend mitgeliefert wird.
Und da ist es auch ganz nett, dass man eben auch einen geführten Einstieg da machen kann.
Also man kann auf seinem Gerät so einen geführten Einstieg machen.
Da wird man dann angeleitet.
Wie bediene ich diesen Screenreader?
Wie kann ich den aktivieren?
Wie navigiere ich damit?
Das sollte man auf jeden Fall sich einmal anhören.
Weil es ist nicht einfach eins zu eins sozusagen.
Ich bediene die Tastatur, sondern das Smartphone oder auch der Desktop-PC verhält sich dann schon ein bisschen anders.
Ich muss schon vielleicht ein paar mehr Interaktionen machen, ein bisschen expliziter interagieren, vielleicht andere Tastenkombinationen nutzen.
Aber das wird mir da irgendwie alles sehr schön erläutert bei diesem Tutorial, was ich da wirklich direkt machen kann.
Und für Windows gibt es, denke ich, ähnliche.
Da sind vor allem auf Desktop-Systemen NVDA.
Das ist einer der bekanntesten und meistgenutzten Screenreader, die man sich dort entsprechend installieren kann.
Und bei Android ist es TalkBack.
Genau.
Was mir auch noch dazu einfällt, ist die Thematik, wenn du dort wirklich selbst reinexplorieren willst, wenn du einfach Erfahrungen sammeln willst, ist es ja immer total spannend, jetzt nicht nur etwas zu lesen, sich ein YouTube-Video anzugucken, sondern wirklich darüber zu reden.
Da gibt es halt so zwei Gedanken, die wir dazu noch haben.
Alleine für einen Austausch in der Community gibt es zum Beispiel eine Faktensteuerungsreihe, den Accessibility-Club, gerade hier aus dem europäischen Raum eine größere Community-Veranstaltung, eine Konferenz.
Die sind wirklich damit gestartet, dass sie gesagt haben, wir haben hier zu 10 Mal einen Raum gemietet, haben uns einen Kollegen geschnappt, der tatsächlich täglich den Screenreader nutzt und haben das einfach mal mitbekommen, haben einfach mal wirklich erfahren, wie das ist.
Du bekommst halt auch einen Einblick, den du als Nicht-Screenreader-Nutzer täglich nicht bekommst.
Manche sprechen auch ganz gerne davon, dass wir diejenigen, die es nicht nutzen, auch in diesem Bereich einfach nur Touristen sind und quasi draufgucken und vielleicht auch Dinge gar nicht verstehen, auch nie verstehen werden.
Warum ist das jetzt so schnell gesprochen?
Nur um nochmal kurz ein, zwei Anekdoten mit rauszunehmen.
Das wäre ja jetzt eine total schwierige Anwendung auch, weil wenn du dann eben wirklich mit Menschen redest, die das täglich tun, sagen sie, nee, das ist etwas, das ich erlernen kann, mit dem ich durchaus erstmal natürlich reinkommen muss, aber dann kriege ich das mit.
Und da sind genau solche Community-Formate, würde ich da wirklich vorschlagen.
Vielleicht auch mal auf meetup.com vorbeigucken.
Was ist da in meinem lokalen Raum vielleicht mal eine Gruppe, die sich zusammenfindet, die über das Thema Accessibility spricht, über das Thema Barrierefreiheit spricht oder die mir vielleicht auch entsprechende Einblicke gibt.
Das wäre so meine Idee, weil dort habe ich einen direkten Anknüpfungspunkt jetzt gegenüber Literatur und YouTube oder anderen Streamingportalen beispielsweise.
Genau, das kann ich auch nochmal bekräftigen.
Also auch unser Team hat, es gibt bei uns auch einen stark seriengeschränkten Entwickler und wir haben mit dem auch mal zusammen so einen Workshop gemacht, einfach mal so einen halben Tag lang auf eine unserer Anwendungen mit ihm zusammen drauf geschaut und er hat sozusagen mit seinem Screenreader dort durchgegangen und hat das mal auf laut gestellt und man bekommt auch als Entwickler nochmal eine ganz andere Sicht auf die Dinge.
Vorher hat man so viel theoretisches Wissen, aber wenn man jemanden wirklich, der tagtäglich diese Technologien benutzt, da beobachtet, wie er es wirklich verwendet, wie navigiert wird, welche Dinge sind wirklich wichtig, welche sind vielleicht nicht ganz so wichtig.
Wo denkt man sich vielleicht, okay, hier müsste ich eigentlich noch was tun, aber vielleicht ist es gar nicht so relevant.
Also das sind alles so Themen, sowas kriegt man gut durch so ein Shadowing raus, wenn man einfach mal jemandem wirklich dabei zuschaut und das wirklich auch mal selber ausprobiert, mal selber mitmacht.
Das hilft ungemein.
Ich finde es ja so faszinierend, als die KI aufgekommen ist, Large Language Models und man auf einmal gemerkt hat, die KI kann nicht so gut mit Webseiten umgehen, weil da ist so viel störende Werbung. für den Menschen besser.
Und gerade kommt es mir so, Werbung, ist die eigentlich barrierefrei, wenn die so…
Gerade gibt es ja so Webseiten, wo sich so eine Werbung erstmal über die ganze Website schiebt, dass man sie wegklicken muss und so, ne?
Wäre es denn ein Feature oder ein Bug, dass sie zugänglich ist oder nicht zugänglich?
Wenn sie nicht zugänglich ist, kann sie einen vielleicht auch weniger nerven.
Das wäre jetzt nochmal eine andere Diskussion.
Wenn wir jetzt eher so die technische und die IT-Brille mal darauf tun oder darauf packen, ist es tatsächlich natürlich so, dass Werbung teilweise eben ja auch wirklich direkt in die Seite initiiert wird.
Dann tut sich eine ganze Menge und je mehr quasi durchaus auf einer Seite auch an beispielsweise JavaScript-Code initiiert wird, kann es auch mal dazu kommen, dass ein Stream wieder halt wirklich durch entweder textuelle Überlagerung oder halt auch einfach durch zu viel JavaScript auch tatsächlich abstürzen kann, dass sich diese Seite nicht mehr bedienen kann.
Und da sind wir schon in dieser Gemengelage natürlich auch in der grundsätzlichen architekturellen Entscheidung dabei, wie viel Code liefere ich aus, auch gerade in Bezug auf eben Werbung.
Wenn jetzt tatsächlich so eine Werbung nicht direkt zugänglich ist, hätte ich gesagt, vielleicht ist es sogar ein Feature, aber das ist vielleicht eine eigene Kapitalismus-Diskussion an dieser Stelle.
Also, dass die Werbung nicht zugänglich ist, okay, ja, aber sie sollte natürlich auch den Rest nicht stören, ne?
Es soll auch, genau, es soll ja auf der anderen Seite das, was, es soll auch gar nicht jetzt komplett weggelächelt werden, um es nur auch nochmal ernsthaft zu bewerten, das, was die Grundmaxime ist, ist natürlich trotz allem erstmal zu sagen, das, was abgebildet wird, das, was ich anhand meiner eigenen Einschränkungen wahrnehmen kann, soll auch jemand anders wahrnehmen können.
Das ist erstmal das, mit dem man auf so eine Testung auf eine Seite als Seitenbetreibender auch per se erstmal drauf blicken kann.
Werbung ist vielleicht jetzt ein spezielles Thema, aber wenn wir davon kurz wegkommen, ist so die Maxime immer zu sagen, das, was ich da abbilde, sollte für alle zugänglich sein, sowohl bei versteckten als auch sichtbaren Inhalten beispielsweise, dieselbe Experience dann zu liefern beispielsweise.
Jetzt hast du die Testung angesprochen, also wir haben ja jetzt schon so indirekt so ein bisschen gesagt, naja, wenn ich mit Frontends zu tun habe, dann sollte ich mich mal schlau machen, sollte man auf ein Meetup gehen, mir das angucken, was das alles bedeutet, wie ich eben damit umgehen kann, da ich bei Architekturentscheidungen die Accessibility mit berücksichtige.
Wie kann ich jetzt aber, wenn ich eben meine Anwendung habe, überprüfen, ob sie den Anforderungen entspricht?
Gibt es da einen Testkatalog, wo ich abhaken kann oder kann ich mir das zertifizieren lassen oder was mache ich als Entwickler, um da möglichst schnell voranzukommen?
Habt ihr da Tipps?
Also der Testkatalog ist eben im Prinzip diese WCAG-Kriterien.
Das ist quasi unser Testkatalog, wonach wir uns richten können und sollten.
Und das Schöne ist aber, dass wir da nicht irgendwie jedes Mal den Text nachlesen müssen und umsetzen.
Also wir müssen natürlich umsetzen, aber es gibt natürlich auch Tools, die uns helfen.
Und da gibt es eben Automatisierungstools, womit wir eben diese Tests schreiben können und die uns auch konkret sagen, hey, pass mal auf, du hast da irgendwie eine Verletzung gegen folgendes WCAG-Kriterium.
Und diese Tools, die können wir zum einen teilweise im Browser als Extensions nutzen.
Da gibt es sowas wie X-Accessibility-Extension, die wir im Google Chrome oder auch Edge installieren können, wo wir wirklich über unsere Seite einmal so ein Scan machen können und dann sagt der uns, hey, pass mal auf, hier fehlt ein Alt-Attribut, hier ist irgendwas, irgendwelche Elemente sind nicht richtig geschachtelt, die musst du anders verwenden und so weiter.
Es sagt uns auch konkret dann Tipps, wie wir es beheben können.
Und das Ganze können wir eben dann auch noch auf visueller Ebene mit Tools wie Pally automatisieren.
Also da können wir das in unserer CICD-Pipeline einbauen und wirklich automatische Checks dagegen fahren oder auch mit Playwright.
Da gibt es eben auch Extensions und die X-Dev-Tools, das ist so eine ganze Suite eben von Tools, sowohl als Browser-Plugin als auch für Playwright als Plugin oder für V-Test und so weiter.
Das können wir an verschiedensten Stellen nutzen, das ist so das Bekannteste.
Aber es gibt auch Plugins für Storybook oder GuidePub ist nochmal sehr speziell, das ist auch nochmal ganz interessant.
Da kann ich wirklich prüfen, wie ist sozusagen die Sprachausgabe, wenn ich jetzt einen Screenreader verwende und über einen gewissen Teil meiner Seite schaue, wie wird da wirklich der Text announced, also wie wird er mir wiedergegeben.
Und davon kann ich dann zum Beispiel auch ähnlich wie bei Screenshot-Tests, kann ich einen Snapshot machen quasi von dem gesprochenen Wort und kann den sozusagen als Regressionstest hinterlegen und kann damit eben sicherstellen, wenn ich jetzt künftig vielleicht an dem Feature entwickle, dass ich eben nicht diesen Test verletze und dass eben trotzdem irgendwie diese Stelle meiner Website immer gleich wiedergeben wird und da nicht irgendwie der Content irgendwie durcheinander gewürfelt wird.
Was du jetzt genannt hast, ist ja ein ganzer Blumenstrauß.
Muss ich die ganzen Tools kennen oder machen die eigentlich alle das Gleiche?
Wir haben so in der täglichen Arbeit tatsächlich festgestellt, dass die eine Überdeckung haben, aber dass sie tatsächlich in verschiedenen Aspekten durchaus auch unterschiedlich gut waren.
Gerade wenn ich jetzt wirklich zum Beispiel einen Screenreader emuliere, ist das eine gewisse Tätigkeit, die quasi jetzt durch so ein Tool abgebildet wird, wie es beispielsweise GuidePub.
Da gibt es jetzt eher wenige Produkte in dem Bereich jetzt zum Beispiel, was Danny schon genannt hatte mit X.
Es ist beispielsweise so, dass das so eine Toolsuite ist, die dann wiederum auch bei einem Tool wie Lighthouse, das im Browser schon mitkommt, auch genutzt wird.
Das heißt, es gibt so ein paar größere Anbieter.
Was wir aber festgestellt haben, ist, dass es sich durchaus lohnt, eine Seite auch, gerade weil wir auch im Kontext von Automatisierung sind, auch mal mit mehreren Tools zu testen.
Gar nicht so sehr, weil wir Falls Positives eventuell ausschließen würden, sondern vor allem, weil wirklich auch eine unterschiedliche Qualität jeweils in einzelnen dieser Segmente sind.
Wo sich aber die Anbieter und auch weltweit die Experten einig sind, ist die Thematik davon, dass diese Tools eher nur in der Höhe der Umsetzung oder Durchdringung sind.
Das, wo sie sich einig sind, ist, dass sie keine manuelle Vertestung ersetzen.
Sie gehen davon aus, dass – und da gibt es halt wirklich unterschiedliche Zahlen, 30 bis 50 Prozent – vielleicht kommt man irgendwann mal perspektivisch auf 70 Prozent dieser vorgenannten WCAG-Kriterien oder auch dem, was in der europäischen Norm 301549 drinnen steht, dass davon vielleicht mal bis zu 70 Prozent vertestet werden können.
Was da aber der entscheidende und ganz, ganz wichtige Aspekt ist, sie werden nicht alles vertesten können.
Sie werden vielleicht mit JavaScript-Anwendungen, vielleicht mit komplexen Konstrukten Probleme haben.
Es braucht immer, auch hier wird es ein Faktor human in the loop, Experten, Experten in the loop, die dort nochmal drüber gucken und genauso auch die gesetzlichen Verpflichtungen beispielsweise, das jetzt wirklich auch nutzende Feedback geben können.
Das braucht man auf jeden Fall und das sind auf jeden Fall die Dinge, die du dann auch etablieren solltest.
Was, ich hätte vielleicht noch, ich hätte also den Übergang, es ist ja alles nicht geskript, wir machen es ja wirklich hier ziemlich spontan.
Ich hätte tatsächlich noch einen kurzen Zusatz bei Tools und dann so zur Organisation.
Ich weiß aber nicht, also ob du jetzt weg wolltest oder direkt eine Anschlussfrage hattest.
Pardon Rolf.
Nehmen wir weiter.
Sehr gerne, weil das einfachste Tool, darauf weißt du ja auch mal ganz gerne hin, wenn du nochmal gerade teilen magst.
Wir haben jetzt viele technische Tools angesprochen, da muss ich irgendwie erst etwas integrieren, da muss ich am Ende des Tages im Zweifel einfach nur meinen Browser öffnen und dann irgendetwas ausführen auf einer konkreten Seite.
Das einfachste Tool haben wir als Seitenbetreibende direkt jeden Tag vor der Nase.
Wir haben direkt vor uns in der Regel eine Tastatur liegen, die wir selbst bedienen können und auf der du, mit der du probieren kannst, die Seite, die du verantwortest, egal aus welcher Rolle, als Produktmanager, als Projektmanager, als Tester, als Gestaltender, als Entwicklender, tatsächlich zu jeder Zeit probieren kannst, sind alle interaktiven Elemente, die ich auf der Seite habe, entsprechend anspringbar.
Ich muss mal von diesem Slide weggehen, da haben wir die Animation nicht mehr.
Sind die entsprechend alle anspringbar an dieser Stelle?
Sind sie auch alle interaktiv?
Komme ich zu demselben Ergebnis, das ich habe, wenn ich zum Beispiel über die Maus meine Seite bediene?
Auf diesem Weg kriegst du mit, sind potenziell diese Elemente semantisch korrekt ausgezeichnet, sind sie dann eben auch zugänglich für eine Spracheingabe, für eine Sprachausgabe.
Bei der Sprachausgabe kann es immer noch sein, bei dem Screenreader konkret natürlich, dass ein Element falsch beschriftet ist, aber ich habe einfach erst mal eine gewisse Möglichkeit, so einen allerersten Eindruck zu bekommen, der sehr, sehr niederschwellig bereits passiert.
Aber das heißt eigentlich auch, ich meine, ich benutze meistens keine Tastaturshortcuts oder so, weil das ist mir nicht intuitiv.
Also ja, wenn ich im Formular zwischen den Feldern springe, ist das prima, aber wie ich auf einer Website ins Menü kommen sollte oder so, das ist mir meistens verschlossen.
Gibt es da dann eigentlich so Standards für irgendwelche Shortcuts, dass, keine Ahnung, Steuerung M eigentlich immer Menü sein sollte?
In der Screenreader-Software ja.
Also in der Screenreader-Software beispielsweise hast du genau diese Standardisierung, weil dort geht es ja in der Regel darum zu sagen, du hast eine Seite, die visuell vielleicht sehr schnell wahrnehmbar ist, wo ich sehr schnell irgendwo hinspringen kann.
Dort hilft dann quasi weiter, dass eine Seite, wenn sie semantisch ausgezeichnet ist, dass ich dann beispielsweise gewisse Bereiche anspringen kann, dass ich direkt auf den Main-Bereich springen kann, dass ich über die Headlines navigieren kann, dass ich mir die Links alle ausgeben lassen kann, alle Bilder ausgeben lassen kann.
Da hast du quasi entsprechende Shortcuts.
Normierung jetzt allgemein übergreifend wäre mir nicht unmittelbar bekannt, zumindest nicht in einem großen Umfang.
Es mag so einzelne Shortcuts geben, die mir jetzt gerade entfallen sind, aber jetzt keine Thematik von ich kann alles beliebig irgendwie anspringen.
Das ist eher so, dass du dann auch nochmal als Seite beispielsweise einzelne Sprunglinks am Anfang einer Seite hinterlegen kannst.
Das ist eher so das Prozedere.
Wir haben ja noch eine Frage.
Wie verhalten sich Frontend-Frameworks, React, Angular, Vue.js bei diesem Thema?
Wahrscheinlich die modernen würden das irgendwie unterstützen, oder?
Genau, also in der Regel alle großen modernen Frontend-Frameworks unterstützen das, stellen entsprechend auch APIs bereit, dass auch wenn ich jetzt meine Komponenten, also in der Regel sind ja alle Komponenten basiert, wenn ich die entwickle, dass da eben auch solche ARIA-Attribute zum Beispiel oder auch Rollen und so weiter durchgereicht werden.
Also sie tragen zur, also sie machen die Barrierefreiheit sozusagen an der Stelle nicht schlechter.
Einige Frontend-Frameworks haben aber auch noch extra Tooling, also zum Beispiel beim Angular-Framework gibt es noch so dieses Component-Development-Kit, wo ich wirklich auch nochmal ein Toolkit habe, was mir hilft, sozusagen Headless-Komponenten, also Komponenten ohne Styles zu erstellen, die entsprechend auch gleich mit einer guten Barrierefreiheit daherkommen.
Und Ähnliches gibt es eben auch für React oder für Vue, und auch alle, also wir haben auch so ein bisschen dieses Thema, Frontend-Frameworks, meistens sind das ja Single-Page-Application-Frameworks, und da haben wir ja kein richtiges Routing mehr im Sinne von, wir haben jetzt irgendwie eine Seitennavigation, sondern wir laden eine App, und da drinnen befindet sich der Router, und all diese Router, die da verwendet werden, sei es für Angular, für Vue und so weiter, stellen uns auch Features bereit, womit ich eben auch zum Beispiel Unique-Page-Titel setzen kann, also dass mein Seitentitel, das ist ja auch eine der Anforderungen der WCAG-Kriterien, für jene meiner Unterseiten sollte ich entsprechend einen individuellen Seitentitel haben, damit der entsprechend auch vorgelesen wird, und auch das unterstützt eben diese Router-Implementierung, dass ich diese Titel dafür entsprechend auch programmatisch dann setzen kann, und das Framework setzt sie dann entsprechend auf Anwendungsebene sozusagen, auch wenn ich nur innerhalb meines Single-Page-Application-Routers bin.
Wenn du gerade vom Seitentitel sprichst, ich kenne das eigentlich immer so, dass man eigentlich gar nicht nur den Seitentitel, also der aktuellen Seite, sondern man möchte irgendwie den Produktnamen oder sonst was, und dann Doppelpunkt, macht das Sinn, dass man immer wieder, versteht ihr, was ich denke?
Nein.
Ich weiß, was du meinst.
Wenn wir jetzt auf StreamYard sind, dann würde vorne immer StreamYard stehen und auf jeder Unterseite dann irgendwie getrennt mit einem Bindestrich die einzelne Unterseite.
Das ist vor allem, wenn du das erste Mal die Seite navigierst, auf jeden Fall hilfreich, weil du dann weißt, auf welcher Seite bist du und auf welcher Unterseite.
Wenn man jetzt innerhalb der Seite navigiert, dann kann das manchmal vielleicht auch für einen jetzt nicht unbedingt hilfreich sein, aber es stört auch nicht zwingend.
Ich sollte natürlich schauen, dass ich jetzt mich im Seitentitel nicht irgendwie total verkünstle und da irgendwelche Sonderzeichen und Emojis wieder reinpacken, immer wieder dieses Thema, sondern der sollte schon entsprechend lesbar sein, mein Seitentitel, weil der entsprechend auch so vorgelesen wird dann.
Genau.
Es gibt quasi vielleicht einen ganz kurzen Exkurs.
Ich hatte es ja vorhin erwähnt.
Ich bin auch dort Prüfer in diesem BTV-Prüferbund.
Das ist quasi dann Übersetzung des Prüfkatalogs.
Das ist ein Prüfkatalog, der übersetzt ist dann aus der EN, auch nochmal angereichert mit eigenen Mengengrößen und Prüfkriterien.
Und dort existiert explizit eben auch die Anmerkung, ein Seitentitel sollte in der Regel individuell die einzelne Seite beschreiben, auch differenzierbar zu anderen Seiten, gerade zum Beispiel in einem Prozess, den ich durchführe, Warenkorb etc.
Danach aber durchaus eben auch den Seitenanbieter nennen, einfach weil auch das ein differenzierendes Merkmal ist, ein Browser, mehrere Tabs beispielsweise, oder ein Bookmark, dass man sich erstellt, dass dann auch immer der Seitenanbieter genannt wird, einfach weil auch dort wieder andere Kontexte für die Nutzung dann aufkommen können.
Okay.
Du hast jetzt gerade gesagt, es gibt Organisationen, die offiziell eine Prüfung vornehmen.
Das heißt, habe ich ein großes Unternehmen, kann ich da sagen, okay, könnt ihr mir mal das zertifizieren, dass meine Seiten barrierefrei sind.
Wenn ich jetzt hier meine kleine Open Source Website habe, muss ich damit rechnen, dass ich dann abgemahnt werde, weil ich eben doch nicht alles berücksichtigt habe?
Da sind wir halt so halbwegs in dem juristischen Umfang drin.
Das wird ein Jurist sagen können, es gibt bei dem BFSG gewisse Ausnahmekriterien, es gibt auch bei dem BGG für die öffentlichen Stellen gewisse Ausnahmen.
Ich hätte gesagt, dort sind wir halt wieder eher mal quasi aus der sozialen Betrachtung dabei.
Warum sollten wir nicht alle anstreben, möglichst viel uns anzunähern einer Barrierefreiheit, einer vollen Umsetzung und einem Ausmerzen dieser Barrieren an dieser Stelle?
Erst mal von der reinen sozialen Brille betrachtet.
Da Ausnahmen zu finden, halte ich für schwierig.
Ich würde es dann eher auf dem Zeithorizont sehen.
Ist das ein Thema, das ich verschiedentlich in meine Organisation integriere?
Und wenn ich jetzt eher mal die größeren Organisationen nehmen würde, jetzt weniger, was du schon beschrieben hast, vielleicht eine private Seite, wo ich eventuell, wie gesagt, kein juristisches Urteil aktuell gesetzlich noch nicht dazu verpflichtet wäre.
Ist es in Organisationen so, dass wir sagen, wir sprechen ganz gerne von diesem Triptychon aus drei Säulen, mit denen man das Ganze etablieren kann, einerseits wirklich Aufmerksamkeit und Wissen für das Thema dafür zu sorgen, andererseits eine automatisierte Vertestung einzuführen.
Das ist genau das, was wir gerade so aufgezeigt haben mit verschiedenen Testtools.
Und als Drittes dann auch wirklich manuelles Vertesten durch Experten.
Das sind allzu oft eben wirklich Prüfverbünde, externe Agenturen, die sich darum kümmern können, die dann auch unabhängig mal darauf schauen und auch nach wie vor das Involvieren von Nutzenden an der Stelle.
Okay.
Wie ist denn das gesetzlich?
Ich meine, ich glaube, die erste Deadline ist jetzt schon gefallen, dass man sich darum kümmern muss.
Gibt es Übergangsregelungen?
Diese sind vorbei.
Das wäre okay.
Danach werden wir auch mal wieder gefragt.
Das BEG, die öffentlichen Stellen, sind seit 2014 oder 2016, glaube ich, gesetzlich verpflichtet.
Das BFSG, das kann man, wenn man es stark zusammenfassen will, sagen, das sind die Seiten, die auf einen Vertragsabschluss abstellen.
Das sind aber auch Versicherungen, das ist auch das Transportwesen.
Da ist jetzt quasi 2015 im Juni quasi die Deadline gewesen.
Das war aber bereits das Ende der Übergangsregelung, wenn man so sagen will.
Es gibt ganz gewisse Ausnahmen, aber die sind jetzt einfach zu speziell an der Stelle.
Womit sich manche, und ich mache nur den Satz vielleicht noch ganz kurz, womit sich manche auch noch versuchen, so ein bisschen rauszureden, ist, dass es durchaus noch allgemeine Ausnahmeregelungen gibt für unverhältnismäßige Belastungen.
Die sind aber ganz, ganz eng mit gefasst.
Da haben wir auch später nochmal den Link für weitere Lektüre entsprechend in den Handouts.
Aber auch darauf wird man sich, einfach gesagt, einfach mal nicht berufen können.
Get your shit done, sage ich jetzt einfach mal sehr salopp.
Darf ich das hier sagen?
Habe ich jetzt schon gemacht, zu spät.
Es ist ein Qualitätskriterium, Barrierefreiheit.
Es gehört mit in diesen Katalog mit rein.
Und wir sollten uns einfach darum kümmern.
Das ist so quasi die saloppe Aussage.
Okay, das heißt, mein Wochenende werde ich jetzt mit meinen Open-Source-Webseiten verbringen.
Schauen wir, wie die aussehen.
Wenn du später bist, unterstützt mich nicht.
Gerade ein guter Appell an die Product-Owner und so weiter.
Das ist wirklich sehr wichtig, dass dieses Thema, wir müssen das als Entwickler in uns aufsaugen.
Wir müssen das behandeln wie Unit-Tests oder sonst was.
Wobei Unit-Tests werden leider auch nicht immer geschrieben.
Oder Tests allgemein.
Aber letztendlich, Barrierefreiheit gehört einfach zu unserem Job dazu.
Wir müssen das mit umsetzen.
Und das muss für uns selbstverständlich werden, dass wir die Aufwände, die wir dafür haben, auch in unseren Schätzungen und so weiter mit berücksichtigen.
Weil es ist deutlich, deutlich teurer, auch am Ende, auch für die Firmen eben, dann im Nachhinein irgendwie eine Seite barrierefrei zu machen, die erstmal sehr viele Barrieren hat.
Das ist oft gar nicht so einfach, weil man dann doch Dinge wieder komplett umbauen muss.
Und wenn man dann vielleicht die falsche Grundlage in der Architektur gewählt hat und irgendwie eine Library verwendet hat, die das gar nicht hergibt, dann hat man sowieso ein Problem.
Deshalb wirklich von vornherein mitdenken, darauf achten und auch immer mit einplanen, dass man eben dafür auch Aufwände vorsieht.
Genau.
Haben wir einen harten Anschlag?
Hast du nur für eine Stunde diese Software bezahlt, Ralf?
Nein, du kannst noch ausholen.
Okay, dann hole ich noch.
Du kennst mich.
Das war nicht machbar, dass wir hier in einer Stunde durch sind, wenn du mich als Teilnehmenden anfragst.
Nein, im Ernst.
Das Entscheidende ist quasi, und darauf hast du ja auch gerade aufgebaut, wie informiere ich mich eigentlich weiter?
Ich habe ja vorhin auch schon von diesem Meetups geredet.
Das ist eine extrem interessante Community, die dort unterwegs ist.
Wenn ich aber wirklich sage, ich will mich jetzt mal informieren, ich will mich einlesen, ich will vielleicht auch Rechtstexte lesen, ich will ein Handout lesen.
Dort gibt es eben wirklich Organisationen, die einerseits auch ohnehin so im Kontext auch von sogenannten Überwachungsstellen in Deutschland mandatiert sind, das Ganze zu überwachen, aber die eben andererseits auch Beratungsleistungen bieten.
Das ist so unter anderem die Bundesfachstelle Barrierefreiheit, die Überwachungsstelle des Bundes für Barrierefreiheit von Informationstechnik.
Dann gibt es nochmal die Seite barrierefreiheit-dienste-konsilium-bund.de.
Und was mir auch immer nochmal so eine Herzensangelegenheit ist, ist zum Beispiel die Seite Gehirngerecht Digital.
Das ist eine Agentur, die sich speziell eben auch dafür nochmal spezialisiert hat.
Sie hat sehr viel so in Richtung Social Media, bereitet das super auf, sehr leicht zugänglich, sehr schön visuell runtergebrochen.
Das, was durchaus ja teilweise auch vielleicht mal trocken und normativ und technisch sein kann, ist dort wirklich sehr gut zugänglich.
Und das ist so eine unbedingte Empfehlung, die ich da auch beispielsweise habe, die wirklich diesen Einstieg auch nochmal erleichtert und auch einfach begeistern kann für das Thema.
Ich sehe schon, wir haben recht viel, was wir in den Shownotes verlinken können und verlinken werden.
Herzlichen Dank für diesen Einblick.
Ich fand das jetzt einen sehr guten Start in die Thematik, auch wenn er jetzt, wie ich gerade erfahren habe, für mich viel zu spät kam.
Und ja, herzlichen Dank an alle Zuhörer.
Ihr werdet in den Shownotes diese ganzen Links bekommen.
Macht euch schlau, schaut zu, dass auch eure Arbeit barrierefrei wird, weil es bringt uns allen was.
Danke für eure Aufmerksamkeit.
Bis dann.
Vielen Dank.
Danke allen.
Schönen Tag.