Web-Accessibility-Mythen und -Fails

Web-Accessibility-Mythen und -Fails Beispiele von Websites, Herausforderungen und Lösungsansätze Manuel Matuzović, Rheinwerk Barrierefreie Webseiten, 18. Februar 25

Hallo und Guten Morgen. Vielen Dank, dass ich wieder hier zu Besuch sein und etwas erzählen darf.

Mein Name ist Manuel Matuzovic. Ich bin Frontend Developer, Berater und Auditor aus Wien und lebe aktuell in Graz. Das Thema meines Vortrags heute ist Web Accessibility Mythen und Fails. Bevor ich erkläre, was ich vorhabe, muss ich mich ganz kurz bei Manu Heim bedanken weil sie mich letztes Jahr zur Fachtagung e-Accessibility nach Bern geladen und für mich dieses Thema vorgeschlagen hat. D.h. ohne sie gäbe es das Thema nicht. Heute halte ich nicht den selben Vortrag sondern eine längere Version. Ich vermute, dass sich sehr viele von euch aktiv mit Barrierefreiheit im Web beschäftigen. Deswegen wisst ihr sicher auch, dass es sehr viele Mythen gibt und noch viel mehr Fails. Ich könnte also heute den ganzen Tag hier sitzen und mit würde das Material nicht ausgehen. Meine Zeit ist aber limitiert und deswegen habe ich mir sieben Mythen ausgesucht, die mich in der Praxis stark beschäftigen.

accessibility-cookbook.com matuzo.social htmhell.dev matuzo.at manuel@matuzo.at

Der erste Mythos ist “Solange wir alles beschriften, ist alles gut”. Wenn ich von beschriften rede meine ich die Bereitstellung von Textalternativen für Multimedia-Inhalte und die Bezeichnung von semantischen Elementen in HTML. Jetzt werden sich ein paar von euch denken “Naja, aber Beschriften ist ja grundsätzlich nicht Schlechtes.” Sowieso nicht. Wir haben vor allem auch ein massives Problem mit zu wenig Beschriftung im Web. Dazu gibt es auch Zahlen.

Die NGO WebAim veröffentlicht jährlich einen Report namens “The WebAim Million”. Sie testen die Barrierefreiheit von den Top 1 Million Websites mit dem automatisierten Testing Tool “Wave”, werten die Daten aus und machen eben den Bericht.

https://webaim.org/projects/million

In dem Bericht sagen sie uns beispielsweise, dass sie automatisch erkennbare Fehler auf 95.9% der getesteten Websites gefunden haben.

Sie listen auch die 6 häufigsten Fehler auf. - Mangelhafter Kontrast auf 81% der Seiten - Fehlende Bildbeschreibungen auf 54.5% - Fehlende Beschriftung von Formularfeldern auf 48.6% - Leere Links auf 44.6% - Leere Button auf 28.2% - Fehlende Auszeichnung der natürlichen Sprache auf 17.1% 4 von 6 Fehlern sind auf mangelhafte Beschriftung zurückzuführen. Wir haben da also wirklich Verbesserungsbedarf. Das Problem ist nur, dass es manche von uns zu gut meinen.

https://webaim.org/projects/million/#errors

Nehmen wir zum Beispiel die Schaltfläche, einen Button, in einem Suchformular. Oft kommt diese ohne sichtbaren Text, sondern besteht nur aus einem Button und einem Piktogramm auf dem eine Lupe dargestellt ist. Der Button und das Piktogramm in Kombination mit einem einzelnen Eingabefeld funktionieren für sich stehend so gut, dass die meisten Menschen wissen, was hier zu tun ist und was sie erwarten können. Der Such-Button ist ein erlerntes Muster. Für jene, die einen Screenreader verwenden, muss ich eine Alternative Text-Bezeichnung bereitstellen, zB “Suchen”. Kurz und knackig, auf den Punkt. Das passt.

<button aria-label=”Suchen”> <svg>…</svg> </button>

Manche meinen es aber leider zu gut und sind über engagiert. Oft findet man statt einfach nur “Suchen” Bezeichnungen wie “Um eine Suchanfrage abzusenden, klicken sie bitte auf diese Schaltfläche”.

<button aria-label=”Um eine Suchanfrage abzusenden, klicken Sie bitte auf diese Schaltfläche.”> <svg>…</svg> </button>

Das wäre ca. so als würde man vor einer Tür stehen, wie hier bei einem Restaurant in Graz zu sehen, und anstatt “Ziehen” steht da…

“Um die Türe zu öffnen nehmen sie die Klinke in die Hand, drücken sie hinunter und ziehen”. Mein sieht hier die selbe Tür aber mit eben diesem Satz meisterhaft von mir gephotoshoppt. Das klingt vielleicht nicht schlimm, aber wenn das gesamte Interface so ist, kann es schon sehr mühsam sein, die Website zu bedienen. Außerdem ist sowas sehr fehleranfällig, so wie man auf dem Foto sehen kann, weil es das gar keine Klinke sondern nur einen Griff gibt.

Hier ein weiteres Beispiel, das kürzlich eine blinde Entwickler-Kollegin mit mir geteilt hat. Auf der Website waren einige Links, Buttons, und Bilder zu sehen. Nichts aufregendes. Ein Link mit der Bezeichnung Produkte, einer Team, ein Button mit der Bezeichnung Login, ein Bild mit Beschreibung, etc. Ich habe einen Screenreader gestartet und erwartet, dass ich sowas wie “Produkte, Link”, “Team, Link”, “Login, Button” oder “Gruppenfoto unseres Teams, Bild” hören werde. Also das Standardverhalten bei dem immer die Bezeichnung mit der semantischen Rolle des Elements vorgelesen wird. Bekommen habe ich aber “Link, Link”, “Link, Link”, “Button, Button”, “Bild, Bild”.

<a href=”/produkte”> Produkte </a> <a href=”/team”> Team </a> <button> Login </button> <img src=”team.png” alt=”Gruppenfoto unseres Teams”>

Das Problem ist, dass die Entwickler es zu gut gemeint haben und sich dachten “Na, wie sollen die Screen Reader Nutzer:innen sonst wissen, womit sie es zu tun haben?”. Und somit haben sie jeden Link auf der Website mit Link beschriftet jeden Button mit Button, etc.

<a href=”/produkte” aria-label=”Link”> Produkte </a> <a href=”/team” aria-label=”Link”> Team </a> <button aria-label=”Button”> Login </button> <img src=”team.png” aria-label=”Bild”>

Das ist ca. so als würde man in einen Supermarkt gehen und anstatt der unterschiedlichen Marken und Bezeichnungen steht überall nur drauf, was es ist. Hier ein Foto vom Kaffee Regal in einem Supermarkt in Graz.

Also anstatt Meinl, Jacobs oder Dallmayr Kaffee bekommt man nur Kaffee. Hier dasselbe Bild aus dem Supermarkt nur dass jetzt auf jedem Kaffee einfach nur Kaffee steht

Das passiert leider öfter als man es sich wünschen würde. Ein weiteres, noch extremeres, Beispiel habe ich, zugegeben, erst einmal gesehen. Wir nehmen wieder unsere Links, den Button und das Bild von vorhin.

<a href=”/produkte”> Produkte </a> <a href=”/team”> Team </a> <button> Login </button> <img src=”team.png” alt=”Gruppenfoto unseres Teams”>

Da haben sich die Entwickler gedacht “Unsere Website ist derartig zum vergessen, dass wir den Leuten klarmachen müssen, dass sie uns am besten anrufen, wenn sie was wollen”. Und somit war dann die Bezeichnung jedes Links, jeder Schaltfläche und jedes Bildes “Wenn Sie zusätzliche Hilfe bei der Navigation oder beim Zugriff auf den Inhalt dieser Website benötigen, rufen Sie bitte unseren gebührenfreien Kundendienst unter der Nummer 1-800-666-8654309 an.”.

<a href=”/produkte” aria-label=”Wenn Sie zusätzliche Hilfe bei der Navigation oder beim Zugriff auf den Inhalt dieser Website benötigen, rufen Sie bitte unseren gebührenfreien Kundendienst unter der Nummer 1-800-666-8654309 an.”> Produkte </a>

Das ist ca. so als würden Sie vor einem großen Platz stehen und auf eine Tafel schauen um sich zu orientieren. Doch anstatt der Orte und Gebäude, wie hier am Grazer Hauptplatz,…

…sieht man nur die Info “Wenn Sie zusätzliche Hilfe bei der Navigation oder beim Zugriff auf Gebäude benötigen, rufen Sie bitte unseren gebührenfreien Kundendienst unter der Nummer 1-800-666-8654309 an.” Okay, jetzt aber genug von meinen Photoshop-Künsten. Ich glaube, die Message ist angekommen. Wir haben dringenden Nachholbedarf bei der Beschriftung von semantischen Elementen, aber auch beim Know-how wie das richtig funktioniert.

Technologie und AI lösen all unsere Probleme Mythos 2 Der zweite Mythos ist “Technologie und AI lösen all unsere Probleme”. Wie schon erwähnt, bin ich Auditor. Ich teste also die Barrierefreiheit von Websites. Das macht man üblicherweise in mehreren Schritten mit unterschiedlichen Werkzeugen. Einer der ersten Schritte ist oft automatisiertes Testing. Man lässt also ein Script über eine Seite laufen, um zu sehen, ob es automatisch erkennbare Fehler gibt. Das ist super, weil man so schnell offensichtliche und oft auch kritische Fehler finden kann.

Das Ding ist nur, das diese Tools, je nachdem wen man fragt, nur 30-60% der Fehler auf einer Website finden. Den Rest muss man durch manuelles Testing entdecken. Leider hören vielen schon nach dem ersten Schritt auf weil sie denken, dass 0 Fehler oder ein perfekter Score in dem Tool heißt, dass die Seite perfekt und komplett barrierefrei ist.

Dass das so nicht ist, habe ich versucht mit einem Experiment zu beweisen. Ich habe eine einfache Seite in höchstem Grade unzugänglich gemacht ohne dass sich auch nur eines der populären Testing-Tools beschwert hat. Das Experiment habe ich in einem Artikel mit dem Titel “Building the most inaccessible site possible with a perfect Lighthouse score” beschrieben. Ich habe den Artikel bereits vor fast sechs Jahren geschrieben, aber was da drin steht gilt immer noch und mein Experiment funktioniert auch immer noch.

https://matuzo.at/blog/building-the-most-inaccessible-site-possible-with-a-perfect-lighthouse-score

So sieht das aus. Links sieht man das originale Dokument, das aus einer Überschrift, Absätzen, einer Liste und einem einfachen Formular besteht. Dieses Dokument hat 0 Fehler bzw. einen Score von 100, weils einfach sauberes Standard-HTML ist. Rechts sieht man dasselbe Dokument, aber der Text ist kaum lesbar. Wenn man genau hinsieht, sieht man leichter graue Schattierungen. Das Dokument ist nicht mit dem Keyboard, mit der Maus oder dem Screen Reader nutzbar und kann nicht gezoomt werden, aber der Score ist immer noch 100. Diese Tools sind super und wichtig, aber es reicht nicht, sich nur auf die Technologie zu verlassen. Man muss auch manuell testen mit dem Keyboard, Screen Readern und anderen Werkzeugen. Ein weiteres Beispiel dafür, dass man sich nicht rein auf Technologie verlassen kann, sind Bildbeschreibungen. Viele KI-basierte Tools können Bilder sehr gut beschreiben, aber man braucht oft Kontext, den nur ein Mensch liefern kann.

https://codepen.io/matuzo/pen/joeeqy

Hier sieht man beispielsweise ein Schwarz-Weiss Photo, das in den 50-60 Jahren während des Civil Rights Movement in den USA entstanden ist. Es ist ein junger Schwarzer man zu sehen der von einem Polizisten mit einer Hand festgehalten wird. In der anderen Hand hält er eine Hundeleine. Der Hund attackiert den Mann. Daneben steht ein weiterer Mann mit Hund. Im Hintergrund sind weitere schwarze Menschen auf der Strasse zu sehen, die irritiert aussehen. Ich weiß nicht, was da passiert ist. Ich weiß nicht, ob der Polizist den Hund auf dem Mann losgelassen hat oder ob er den Hund zurück hält. Mir fehlt hier Kontext und Hintergrundwissen um ausreichend beschrieben zu können. Meine Beschreibung ist nicht perfekt, aber okay würd ich sagen. MS PowerPoint, das auch ein Bildbeschreibungstool hat, hat das Bild beschrieben mit “Ein Polizist hilft einer person mit einem Hund”. Das passt halt wirklich absolut gar nicht und kann sehr problematisch sein. Zugegeben hat ChatGPT hingegen eine ausgesprochen detaillierte Beschreibung geliefert, aber es konnte mir auch den Namen des Photographen sagen. Es kannte wohl also das Bild. Wichtig ist für uns nur, KI kann uns bei Bildbschreibungen nicht ablösen sondern nur unterstützen, wenn wir gute Beschreibungen wollen.

Ein Weiteres Beispiel für KI-basierte Tools sind sogenannte Overlays. Widgets, die man auf einer Website einbinden kann, die versprechen die Barrierefreiheit zu verbessern. Zur erkennen sind die an einem Button mit Strichmännchen. Klickt man den Button kann man Kontraste anpassen, Schriftgröße erhöhen, etc. Man kann das Tool auch Dinge automatisch verbessern lassen bzw. machen das auch sehr viele Tools schon automatisch. Ein Beispiel dafür findet man auf der Website des Österreichischen Paralympischen Committees. Diese Website ist nicht barrierefrei, was sehr überraschend war für mich. Jedenfalls kann man mit der Maus auf den Burger-Button klicken. Dann öffnet sich ein Menü. Die Menüpunkte haben Untermenüpunkte, die aufklappen. Wenn ich dasselbe versuche mit dem Keyboard zu machen, ohne dass das Tool eingebunden ist, dann komme ich nicht weit, weil der Button kein Button-Element in HTML ist sondern einfach nur ein generisches Element, ein div. Wenn man dasselbe mit dem Keyboard macht und das Tool aktiviert ist, kickt die KI rein und fügt Skip-Links hinzu, was super ist. Es macht den Button auch zugänglich mit dem Keyboard, was er vorher nicht war, aber aus irgendeinem Grund bekommen die Submenüs die selbe Hintergrundfarbe wie der Text wenn man das Keyboard verwendet.

Ein weiteres Beispiel findet man auf bushnell.org, das ist eine Konzert-Location in den Staaten. Da gibt es auf der Konzertseite eine Suche und Filter. Wenn man die Filter aufklappt, sieht man einige Checkboxen. Die sind nicht sehr groß und der Kontrast ist auch nicht ausreichend aber zumindest kann man sie klicken. Wenn man jetzt mit dem Keyboard arbeitet dann registriert das Overlay auf der Seite, dass man offensichtlich Hilfe benötigt und plötzlich verschwinden die Checkboxen und die klickbaren Labels werden zu einfachem Text und dadurch nicht mehr nutzbar. Und das war nur ein weiteres Beispiel von dem ich weiß. Ich bin mir sicher, dass es noch viel mehr davon gibt.

Es gibt viele weitere Gründe, warum Overlays keine sehr gute Lösung sind. Untere anderem die schwierige Auffindbarkeit, dass sie eben Dinge teilweise verschlimmbessern, und die Tatsache, das man auf einer Seite Einstellungsmöglichkeiten hat und auf der nächsten dann wieder nicht oder ein anderes Tool. Solche Einstellungen müssen im Browser oder im Betriebssystem gemacht werden. Wenn man mehr über das Thema erfahren möchte, kann ich einen Vortrag meiner geschätzten Kollegin Daniela Kubesch bei technica11y auf YouTube empfehlen. Nun kommen wir zum dritten Mythos.

https://youtube.com/live/Atc5v64gqdE

Der dritte Mythos ist “Ab 28.6.2025, also mit dem Inkrafttreten des European Accessibility Act, wird alles gut”. Menschen, die in der Web Barrierefreiheit tätig sind, sind tendenziell sehr emphatisch. Nicht alle, aber ich würde vermuten, die meisten. Einige Expert:innen haben auch eine Behinderung und diese beiden Faktoren machen die Arbeit zu etwas sehr Persönlichem und auch sehr Emotionalen. Deswegen beobachtet man auch leider sehr oft, dass Expert:innen in diesem Bereich sehr schnell ausbrennen, weil es nicht nur ein anstrengender Job ist, sondern einer der auch psychisch sehr belastend sein kann. Der Job ist deswegen unter anderem belastend, weil man ständig auf Barrieren stößt. Als Mensch mit Behinderung buchstäblich auf Barrieren bei der Arbeit und bei den Projekten und Produkten mit denen man zu tun hat, aber auch sinnbildlich, weil man ständig mit Ablehnung und, ja fast, Abneigung konfrontiert wird. Das, was man selber als etwas sehr Selbstverständliches und Natürliches sieht, sehen andere als eine Bürde und entgegnen einem mit Widerstand. Firmen wollen die Projekte oft nicht barrierefrei machen, weil es zu anstrengend ist oder zu teuer ist oder weil man sonstige Gründe hat. Das hat dann Resignation zufolge, oder eben tatsächlich Burn out und zumindest eine gute, tief sitzende Dosis Pessimismus und Zynismus.

Ich bin grundsätzlich ein positiver Mensch, aber was die positiven Auswirkungen des EAA betrifft bin ich eher ein bisschen verhalten. Ich glaube, dass sich ein bisschen was tun wird und dass die Situation ein bisschen besser wird, aber man darf sich jetzt nicht erwarten, dass es den großen Umbruch geben wird und jetzt plötzlich das Web so viel barrierefreier ist im Vergleich zu wie es jetzt ist. Was auf jeden Fall gut ist an der ganzen Sache ist, dass es jetzt ein neues Bewusstsein gibt vor allem bei Menschen die von Barrierefreiheit vielleicht vorher nichts wussten und jetzt das Thema zumindest auf dem Schirm haben und dann vielleicht auch etwas tun. Vielleicht bin ich auch einfach ein bisschen zu pessimistisch. Jedenfalls müssen wir beobachten, was die nächsten Jahre passiert.

Wie sich diese Bewusstseinsbildung dann tatsächlich äußert, vor allem dann wenn sich der erste große Staub, der aufgewirbelt worden ist, gelegt hat, das wird sich noch zeigen. Ich befürchte nur, dass es erste Maßnahmen geben wird und die werden mehr oder weniger gut und mehr oder weniger nachhaltig sein und im Endeffekt befolgt man halt irgendein Gesetz mehr oder weniger und der tatsächliche Nutzen für die User ist nicht wirklich gegeben.

Wie gesagt, ich glaube, dass dieser Bewusstseinsbildungs-Effekt etwas sehr positives ist, aber es gibt auch eine negative Seite, weil es jetzt plötzlich irgendwie sehr viele Expert:innen in diesem Bereich gibt, die es vorher noch nicht gab. Weil natürlich jetzt auch einige Leute den Business Case hinter der Barrierefreiheit sehen und dementsprechend auch Barrierefreiheit anbieten. Ich hatte in den letzten Wochen und Monaten, wie vermutlich die meisten meiner Kolleg:innen, sehr viele Anfragen und einige davon kamen auch von klassischen Web-Agenturen, die Workshops wollten. Manche, weil sie wirklich lernen wollen, wie man barrierefreie Websites macht, aber andere, weil sie heute lernen wollen, wie es geht um es dann morgen selber aktiv anzubieten. Und das ist halt wirklich sehr gefährlich weil dann einiges gefährliches Halbwissen im Spiel ist. Wenn hier Entscheidungsträger:innen zuschauen, dann möchte ich euch unbedingt bitten, dass ihr bei Ausschreibungen ganz genau drauf achtet, wer euch die Dienstleistung anbietet. Schaut euch an, wie lang sie das schon machen, wie lange sie vor allem in der Barrierefreiheit tätig sind, schaut euch das Team an, schaut euch an, ob sie über das Thema bloggen, auf Social Media schreiben, oder sprechen. Und wenn möglich, sucht euch jemanden, der oder die sich 1-2 Stunden die bestehenden Projekte ansehen und vielleicht einen ersten Eindruck geben kann, wie barrierefrei die Produkte, die diese Firma macht, tatsächlich sind.

Das bringt mich zum nächsten Mythos.

Je größer die Firma, desto größer das Know-how…

…und damit auch zusammenhängend “Je größer die Buzzword-Dichte, desto größer das Know-how”. Die großen Beratungsfirmen haben jetzt natürlich auch den Business Case erkannt und gründen eigene Teams, die dann für Barrierefreiheit zuständig sind. Grundsätzlich ist es eh okay, aber man muss sich dann auch genauer anschauen, was die können und was sie tun. Ich habe Erfahrung mit diesen großen Beratungsfirmen, ich nenne jetzt keinen Namen aber man kann sich vorstellen welche das sind. Meine Erfahrung ist, dass sie beim Beratungsgespräch und in den ersten Tagen die guten Leute vorschicken, die dann aber bald weg sind und dann sitzt man da mit Leuten, die kurz davor ein 8-wöchiges Web Development-Bootcamp durchgezogen haben und jetzt direkt im Anschluss dann für einen die Arbeit machen sollen.

Ich weiß eh. Da ist er wieder der Pessimismus und Zynismus, aber so läuft’s leider manchmal. Man hört sehr oft das Argument, dass diese Firmen “To Big to Fail sind”, aber das lass ich nicht gelten, weil es bei dieser Aussage meistens um das Projekt geht und nicht um das Produkt. Ein Projekt kann auf dem Papier erfolgreich abgeschlossen werden, aber das Produkt am Ende kann trotzdem Müll sein. Habe ich so auch schon mit erlebt. Die kleine zu Bude zu buchen birgt auch seine Risiken, aber oft liefern die das bessere Ergebnis für die Nutzer:innen. So oder so, wichtig ist, wurscht ob kleine oder große Firma, jemanden zu buchen, der wirklich, weiß was er tut und der das Thema auch ernst nimmt. Eine weitere Sache ist, dass in Verkaufsgesprächen sehr wild mit irgendwelchen Begriffen um sich geworfen wird. Deswegen empfehle ich, sich ein bisschen in das Thema einzulesen, um besser abwägen zu können, ob jemand tatsächlich etwas Sinnvolles sagt oder einfach nur versucht mit Buzzwords, von denen er oder sie auch absolut keine Ahnung hat, Eindruck zu schinden. Nächster Mythos “Wir haben ein Audit machen lassen und einen Workshop gebucht, wir sind jetzt barrierefrei”

Wir haben ein Audit machen lassen und einen Workshop gebucht, wir sind jetzt barrierefrei Mythos 5 Wir haben Audit machen lassen und einen Workshop gebucht wir sind jetzt barrierefrei. Wenn man das Bewusstsein entwickelt hat, ist der nächste Schritt, etwas zu unternehmen. Viele lassen dann ein Audit machen und/oder buchen einen Workshop, um nicht nur zu lernen, welche Probleme es aktuell gibt, sondern wie man die auch selber lösen kann. Das ist ein guter erster Schritt, aber, wie schon gesagt, wird sich der Staub legen und man wird das Thema nicht mehr so präsent am Schirm haben, etwas anderes wird wichtiger, es werden neue Probleme entstehen, das Testing wird weniger, und so weiter. Bei einem sehr lebendigen Produkt ist man dann nach ein bis zwei Jahren wieder dort wo man vorher war und dann kann man das ganze Prozedere von vorne starten und wer leidet ist nicht nur das Budget sondern vor allen die Nutzer:innen.

Das Ding ist nämlich, es reicht nicht nur, dass Maßnahmen nur im Design und in der Entwicklung gesetzt werden. Es fängt im oberen Management an. Die Unternehmensführung muss bereit sein, Inklusion wirklich zu verstehen. Denn Entscheidungsträger sind ausschlaggebend für Erfolg oder Misserfolg einer inklusiven Unternehmenskultur. Denn inklusives Handeln und Denken innerhalb einer Firma, dass dann im Idealfall zu Barrierefreiheit führt, ist nur möglich wenn von ganz Oben nicht nur das Okay gegeben wird, sondern nur wenn Inklusion auch vorgelebt und vorgegeben wird. Die Maßnahmen müssen dann in jeden einzelnen Entwicklungsschritt eingewoben sein. Das fängt bei der Kundenberatung an, geht weiter zur Konzeption, ins Design, in die Entwicklung, ins Testing und schließlich dann auch in die redaktionelle Arbeit und die Wartung.

Dabei spielen oft Product Owner oder Projektmanager eine große Rolle, denn sie sind meistens das Bindeglied zwischen Design und Entwicklung und dem Management. Als Product Owner muss ich mich mit dem Thema vertraut machen, dazu stehen, es nach außen tragen, es nach oben eskalieren, Wissen vermitteln, und es priorisieren und es nicht als Add-On ansehen. Und jetzt kommen wir zum vorletzten Mythos von heute: Wir haben [Manuel] konsultiert und damit alles richtig gemacht.

Und den Namen Manuel kann man hier austauschen durch den Namen jedes anderen nicht behinderten Experten. Ich bin männlich, weiß, nicht ganz jung aber auch nicht ganz alt, Mitte/Ende 30, eigentlich gesund, bis auf ein paar Kilo zu viel und ich habe noch keine Behinderung. Ich bin der Prototyp des Menschen, der absolut keine Probleme im Alltag hat und schon gar nicht im Web. Wenn ich über Barrierefreiheit spreche, kann ich nicht aus meiner eigenen Erfahrung schöpfen. Was ich sage beruht rein auf der Erfahrung anderer und auf Annahmen. Das macht jede andere Expert:in mit dem selben Skillset und einer Behinderung geeigneter für den Job als mich und deswegen sollte man im Idealfall auch bevorzugt mit jemanden arbeiten, der/die diese persönliche Praxis und Erfahrung mitbringt. Denn Menschen die regelmäßig Exklusion erleben können ihre Expertise viel besser in Lösungen umlegen.

Denn das Problem, dass die meisten Designer:innen, Entwickler:innen und Berater:innen haben, ist, dass sie ihre eigenen Fähigkeiten als Grundlage verwenden. Und wenn wir das machen, dann kreieren wir automatisch Lösungen, für Menschen mit ähnlichen Fähigkeiten und Vorlieben und in ähnlichen Umständen, und schließen damit eine viel größere Gruppe von Menschen aus. Und das betrifft auch uns, die ohnehin schon versuchen Inklusion zu leben und auch ein Bewusstsein dafür haben.

„Nihil de nobis, sine nobis” „Nichts über uns, ohne uns.”

Inklusion bedeutet nicht, dass wir etwas für Menschen sondern mit Menschen gemeinsam machen. Deswegen ist es so wichtig, dass Menschen mit Behinderung nicht nur am Ende eines Projekts beim Testing hinzugezogen werden, nicht falsch verstehen Testing ist sehr wichtig, sondern in entscheidenden Rollen Meinungsfreiheit und Entscheidungs- und Durchsetzungskraft haben. Jetzt könnte man natürlich sagen „Okay, das klingt alles super. Sollte dann nicht auch ein Mensch mit Behinderung diese Keynote halten anstatt dir? Warum hast du nicht abgesagt?”. Das ist eine absolut berechtigte Frage und die Antwort ist, dass ich mich oft in einem Zwiespalt befinde. Einerseits will ich niemanden einen Platz wegnehmen, und ich habe auch in der Vergangenheit schon Events abgesagt. Andererseits, glaube ich, dass ich, wenn ich etwas Sinnvolles zu sagen habe, und das ist heute hoffentlich der Fall, dann kann damit viele Leute erreichen und etwas bewegen kann. Ich gehöre nicht zu den großen Namen in der Web Accessibility Szene, aber ich habe mir schon ein bisschen einen Namen gemacht und ich glaube, dass heute hier auch Leute wegen mir und wegen dem was ich zu sagen habe oder zumindest unter anderem wegen mir hier sind.

Wenn man mit Barrierefreiheit im Web anfängt, wird man, insbesondere in Österreich, in der Schweiz und in Deutschland, bald draufkommen, dass die Szene, also all jene Leute, die über das Thema sprechen und schreiben, sehr überschaubar ist. Es gibt also nicht viele Leute, die sich mit diesem Thema ernsthaft und glaubwürdig auseinandersetzen, und deswegen ist Zusammenhalt und Zusammenarbeit ganz wichtig. Unterschiedliche Menschen haben unterschiedliche Fähigkeiten und können auf unterschiedliche Art und Weise zu Lösungen beitragen. Jede Expertin:in, der Barrierefreiheit und die Menschen wichtig sind, kann wirksame Arbeit leisten, aber fix ist, dass das nur funktioniert, wenn wir Inklusion leben und von Menschen mit unterschiedlichen Fähigkeiten, Herangehensweisen und Lebensrealitäten lernen. Für Unternehmen bedeutet das, dass sie auch Menschen mit Behinderung einstellen müssen, in Führungspositionen, im Design und der Entwicklung, aber auch ihre Produkte ernst nehmen und mit einer diversen Gruppe an Menschen testen und diese dann verbessern müssen.

Nur die anderen müssen barrierefreie Websites machen Mythos 7 Und der letzte Mythos ist “Nur die anderen müssen barrierefreie Websites machen”. Irgendwie gibts es diesen Irrglauben, dass nur jene, die im öffentlichen Sektor arbeiten, und jetzt auch jene, die vom EAA betroffen sind, barrierefreie Websites machen müssen. Das macht überhaupt keinen Sinn. In der Webentwicklung geht es nicht darum, Gesetze zu beachten oder Kriterien zu erfüllen, sondern darum Menschen Zugang zu geben und ihnen zur erlauben, Teil der Gesellschaft zu sein. Und das bedeutet also, dass alle Websites barrierefrei sein müssen ganz unabhängig von irgendwelchen gesetzlichen Regelungen.

Und damit verabschiede ich mich und bedanke mich und wünsche noch viel Spaß an diesem besonderen Tag. Danke schön.

accessibility-cookbook.com matuzo.social htmhell.dev matuzo.at manuel@matuzo.at