#053: Praktische Tipps für Barrierefreie WP Projekte | m. Nina Jameson & Tobias Roppelt

Herzlich Willkommen bei der 53. Episode der Dominik Liss Show.

Auf diesem Podcast gibt es WordPress und Business Talks, das heißt, wenn du WordPress in deinem Business verwendest, dann bist du hier genau richtig, weil in jeder Episode entpacken wir die Skills, Storys und Geheimnisse der besten Experten aus der WordPress-Branche und das Ziel des Podcasts ist dir dabei zu helfen, ein besserer Professional in der WordPress-Welt zu werden.

Und heute geht es um Barrierefreiheit.

Und zwar ist so das Ziel dieser Episode, dir dabei zu helfen, deine Kunden besser über Barrierefreiheit zu beraten, weil es gibt ja viele Begriffe jetzt im Internet, wie eben zum Teil Barrierefreiheit, Barrierearmheit, und das ist ein bisschen so, wie wenn man sich so eine Pizza bestellen würde übers Telefon, du bestellst ja auch nicht, hey, ich würde dir gerne eine Pizza bestellen, sondern ja, es wäre halt gut zu wissen, welche Pizza das ist, und das klären wir heute auf, also wir werden konkret die Begriffe definieren, Wir werden uns auf die Gesetzeslagen fokussieren, was sind die Unterschiede zwischen den Gesetzeslagen in Deutschland, Österreich und Schweiz, aber wir werden auch in die praktischen Felder antauchen und zwar in das WordPress-Setup, also welche Page-Builder jetzt in dem Fall eignen sich gut, um barrierefreie Websites zu bauen, welche ein bisschen weniger, welche haben da noch ein bisschen Aufholbedarf und das alles werden wir in dieser Episode zusammenfassen Und wir reden darüber mit dem Gründer Duo von gehirngerecht.

digital.

Also, auf der linken Seite Nina Jameson, auf der rechten Seite Tobias Roppelt.

Und deswegen ist es interessant, mit euch bei einander darüber zu sprechen, weil Nina, du kommst mehr aus der Developer-Welt und Tobias, du kommst mehr aus der Design-Welt und da decken wir eigentlich beide Welten ab.

Und könnt ihr euch bitte kurz vorstellen und mal sagen, wie ihr seid, was ihr macht und was gehirngerecht und digital eigentlich so ist und dann tauchen wir gleich in das Thema an.

Sehr gerne.

Ich würde direkt starten.

Wie du schon gesagt hast, ich bin Informatikerin, eigentlich von meiner Profession her.

Ich habe lange Zeit individuelle Software entwickelt, habe viel Frontend gemacht, ein bisschen App-Entwicklung und auch ein bisschen Backend, also schon Erfahrung im Fullstack-Bereich.

Während meiner Tätigkeit habe ich den Tobias kennengelernt.

Wir haben tatsächlich beide als Werkstätten bei derselben Firma angefangen und haben auch beide dort programmiert.

Tobias hatte aber immer die Design-Schnittstelle auch im Hintergrund, weil Tobias vom Background her.

.

.

Wie nennt man das? Interface-Designer? UI-UX-Designer.

Aber es ist weird, wenn du mich Tobias nennst.

Es ist so ungewohnt.

Jetzt habe ich den Faden verloren.

Ja, jetzt hast du den Faden verloren.

Ich mache einfach weiter.

Wir machen einfach weiter.

Also hi, ich bin der Tobi, manchmal auch Tobias genannt.

Ich mache UI-UX-Design, habe eben eine Zeit lang auf Frontend entwickelt, da habe ich die Nina kennengelernt, wie gerade gesagt.

Hatte immer so einen kleinen Bezug, eine soziale Ader sozusagen, war dann in London eine Zeit lang, habe dort in einem Startup-Inkubator gearbeitet, bin dann zurückgekommen, habe mich selbstständig gemacht und war als Webdesigner und habe viel auch mit WordPress entwickelt, oder was heißt entwickelt, mit WordPress-Buildern Sachen zusammengebaut, ehrlich gesagt, war da viel unterwegs und Stück für Stück ist es dann gewachsen und kam dann eben auch, ich hatte viel Bezug zu Amerika und so kam das ganze Thema Accessibility dann auch viel mehr in meinen Fokus und dann irgendwann war ich so groß, dass ich Hilfe gebraucht habe und dann bin ich mit Nina wieder in Kontakt gekommen und dann haben wir uns zusammengetan und gesagt, ja, wir gründen einfach unsere GmbH und haben uns dann den Fokus auch wirklich auf Accessibility gesetzt, was auch mit dem kommenden Gesetz jetzt, über das wir gleich reden werden, natürlich ein großer Punkt war, dass sich da endlich was tut in der Szene und auch in Deutschland ein bisschen mehr oder auch in Europa generell ein bisschen mehr Fokus drauf gelegt wurde.

Und jetzt seit circa zwei Jahren machen wir das Ganze zusammen.

Wir haben angefangen, barrierefreie Webseiten zu bauen haben dann gemerkt, das reicht nicht aus, einfach nur barrierefreie Webseiten irgendwem hinzustellen, weil die bleiben nicht lange barrierefrei.

Es gibt eben viel, was man beachten muss, es gibt viel, was wie schon gesagt, gerade vom Dominik, was den Designbereich angeht, was den Entwicklungsbereich angeht, aber auch was den Content-Ersteller-Bereich angeht, sind alles so Dinge, die man halt wissen muss und die man dauerhaft wissen muss.

Wir sagen auch immer, Barrierefreiheit ist so das neue responsive Design, es ist jetzt da und es wird nicht mehr weggehen, man muss sich damit auskennen.

Deswegen haben wir jetzt viel angefangen, mittlerweile größere, also Firmen im generellen, Agenturen, größere Konzerne zu schulen, hinzugehen, die Designer, die Entwickler, die Containersteller, aber auch die Product-Owner abzuholen und ihnen einfach klar zu machen, was ist Barrierefreiheit, was sind die kommenden Gesetze, auf was muss man Acht geben und so weiter.

Aber das war jetzt ein etwas langes Intro.

Über all das Das werden wir jetzt noch im Detail reden.

Na, das passt, finde ich, perfekt, weil vor allem, wie du schon angesprochen hast, kommt ja 2025 so ein neues Gesetz auf uns zu und da mag ich gleich am Anfang klarstellen, okay, das ist jetzt keine Rechtsberatung, also diese Episode ersetzt jetzt keine Rechtsberatung.

Ihr beschäftigt euch zwangsläufig dann auch im Thema Barrierefreiheit auch mit den rechtlichen Themen, weil das eine kann man von anderem dann nicht trennen, deswegen habt ihr da auch schon eine wirklich umfangreiche Expertise aufgebaut, in dem Bereich auch, was die rechtlichen Themen so ein bisschen angrenzt.

Und bevor wir dann in das ganze Thema uns reinstürzen, würde ich gerne ein Thema anfangen, was vielleicht nicht so beliebt ist oder nicht allzu interessant gesehen wird, und zwar ist es die Verantwortung.

Gleich werden wir die Begriffe definieren, was bedeutet eigentlich Barrierefrei, aber bevor wir das machen, wäre es gut zu wissen, okay, es ist jetzt an einem Webprojekt zum Beispiel Webdesigner mit dabei, es ist ein Developer mit dabei, es ist ein SEO-Mensch oder ein SEO-Experte, sorry, wenn sich da irgendwer jetzt beleidigt fühlt, wenn ich das so oberflächlich einfach nur beschreibe, die einzelnen Teilbereiche bei einem Webprojekt, und dann gibt es ja noch den Website-Betreiber, der eigentlich die Hauptverantwortung für die Webseite hat, aber das Thema Barrierefreiheit ist ja sehr übergreifend und es geht von Design bis hin zu Development und dann auch zur Contentpflege.

Und wer hat dann eigentlich da die Verantwortung, wenn es um das Thema geht, ich will einen Stempel haben und sagen können, meine Webseite ist barrierefrei, aber wer ist für welchen Teil zuständig und wie kann sich dann das theoretisch in Praxis abspielen, wenn irgendwas nicht passen sollte? Ich würde jetzt mal beispielhaft bei jemanden anfangen, der halt zum Beispiel einen Online-Shop betreibt.

Also wenn wir sagen, wir haben jetzt einen Online-Shop, wir verkaufen Schuhe online, dann sind wir erst mal mit dem neuen Gesetz dafür verantwortlich, dass unser Online-Shop barrierefrei ist.

Wenn wir jetzt sagen, wir haben den Online-Shop nicht selber entwickelt, sondern wir haben eine Agentur dafür beauftragt, die das für uns übernimmt, dann würden wir von der Agentur verlangen, in das Angebot reinzuschreiben, nach was die Software barrierefrei ist.

Und wenn jemand kommt und sagt, ich kann bei einem Online Shop keine Schuhe bestellen, da trauern Barrieren auf, dann ist die Agentur in der Pflicht, diese Barrieren zu beseitigen, weil sie hat uns ja eine barrierefreie Seite versprochen.

Grundsätzlich ist es erstmal wichtig festzuhalten, wer gesagt hat, wer was macht, weil das ist auch das, wo später dann die Inhaber von den Shops darauf zurückkommen können und sagen können, hey ihr habt gesagt, ihr macht was barrierefreies, dann muss es auch barrierefrei sein.

Wenn ich das als Inhaber oder Inhaberin aber nicht auf dem Schirm habe, dann kann es auch ganz schnell mein eigenes Problem werden, weil ich habe ja keine barrierefreie Webseite, wenn ich so will, beauftragt.

Das wird auch etwas sein, da werden sich viele Dienstleister darauf berufen, dass das von vornherein kein teiles Angebot war, weil da einfach viele neue Kriterien jetzt auf die Dienstleister zukommen, die halt umgesetzt werden müssen.

Das wird Zeit kosten am Anfang, das wird auch mehr Budget kosten, weil einfach sich das Wissen auch erstmal angeeignet werden muss.

Gegebenenfalls müssen Tools ausgetauscht werden, also es wird nicht günstig.

Und deswegen ist es ganz gut, wenn man Inhaber ist, vorher zu klären, okay, was habe ich mir eigentlich da angeschafft, kann mein Dienstleister das überhaupt, viele Agenturen können das wahrscheinlich noch gar nicht und da sich auch einfach erst mal grundsätzlich Klarheit verschaffen, was sind meine Optionen als Inhaber.

Und dann haben wir natürlich noch die Sicht von den Leuten, die es halt tatsächlich machen.

Wenn wir da auf die Verantwortungsebene gehen, ist es ganz spannend, weil dadurch, dass Barrierefreiheit einfach so ein umfassendes Thema ist, ist jede Rolle in der Pflicht, sich mit dem Thema auseinanderzusetzen.

Also Designer, Entwickler, Content-Ersteller, Product-Owner, eigentlich jeder, der damit beschäftigt ist, Inhalte für den digitalen Raum zu erstellen, muss sich mit den Kriterien der Barrierefreiheit beschäftigen.

Zu einem gewissen Grad auf jeden Fall.

Kurz ergänzend dazu gibt es in der Aussage auch besonders im Accessibility-Bereich so diese Aussage shift left.

Das bedeutet, dass man in seinem Entwicklungsprozess umso mehr man links anfängt sozusagen.

Also man startet mit den Requirements, der Definition of Done, Dann kommt der Designer.

Der Designer macht erst mal das Ganze, wie es aussehen soll.

Dann kommt der Entwickler und nimmt es und setzt es um.

Und umso früher oder umso mehr auf der linken Seite man anfängt, umso billiger wird das Ganze.

Es gibt von der Firma Decree, heißen die.

Die sind seit Ewigkeiten im Accessibility-Bereich unterwegs.

Gibt eine schöne Studie darüber, die auch zeigt, dass Designer an die 68 waren es, glaube ich, oder 70 Prozent auf jeden Fall, der Fehler, die zumindest automatisierte Tests finden, beheben können, wenn sie einfach in ihrem Design schon darauf achten, was Barrierefreiheit eigentlich bedeutet und wie man Barrierefreiheit mit integriert.

Somit umso früher man anfängt, natürlich auch wenn der Product Owner das Ganze weiß und das in diese Requirements mit aufnimmt und vielleicht auch in die Akzeptanztests oder halt in die Tests, was muss denn überhaupt schlussendlich barrierefrei sein, nach welchen Sachen, nach welchen Kriterien werden wir das Ganze testen.

dieses Feature oder diesen Task, umso einfacher ist die ganze Sache natürlich oder umso eher hat man es auf dem Schirm und umso eher haben das Designer, die Entwickler und so weiter auf dem Schirm.

Ja, weil ich stelle mir das zum Beispiel so vor, ich bin jetzt in dem Fall ein Developer und setze dann die Webseiten technisch um und wenn ich jetzt ein Design bekomme, welches einfach schnell gemacht wurde und nicht im Detail ausgearbeitet wurde, also meistens sind dann auch die verschiedenen Fokus-Stati, ist glaube ich die Mehrzahl von Status, Fokus-Stati und die Hover States und so weiter.

Und wenn das jetzt zum Beispiel nicht berücksichtigt ist und das Budget einfach gering ist und ich sage, okay, ich setze euch das einfach so schnell wie möglich um und dann bedenke ich als Developer zum Beispiel nicht die einzelnen Punkte, dass man sich mit der Tabulatur das sehr schön durchnavigieren kann, ist das dann so eine Zwiegelspalte, eine Situation ein bisschen, weil dann hat der Kunde eigentlich eine funktionierende Webseite bestellt nach den aktuellen rechtlichen Grundlagen, aber dann kommt er zurück und, hey, meine Webseite ist nicht barrierefrei.

Ich sage, hey, das Design war nicht vollständig.

Designer sagt, hey, das ist doch klar, dass man das bei der Umsetzung mit berücksichtigen sollte.

Und da finde ich, ist es dann auch wirklich ein wichtiger Punkt, das im Angebot dann auch zu ergänzen, weil zum Beispiel in einem vollständigen Angebot ist ja auch sowas, das was du auch vorher angesprochen hast am Anfang mit dem Thema responsive.

Also wenn das im Angebot drinnen steht, dann muss es auch enthalten sein.

So ist das so eine Interpretationssache, ob das wirklich beauftragt wurde oder nicht.

Und das gleiche auch mit der Browser-Kompatibilität, dass man zum Beispiel sagt, mit welchen Browsern ist dann die Website kompatibel und dass man den Internet Explorer vielleicht so auslassen kann und dazuschreiben kann, okay, den unterstütze ich vielleicht nicht.

Und da kommen wir dann auch zum Thema Barrierefreiheit, weil sollte man dann auch in dem Angebot, welches man dann an den Kunden schickt, auch so einen Absatz über Barrierefreiheit hinzufügen, wo man dann zum Beispiel dann noch klarer definiert, was man mit Barrierefreiheit überhaupt meint.

Also da meine ich jetzt die Standards, die es da so gibt, könnt ihr uns da vielleicht auch klären, was man dann berücksichtigen sollte, wenn man ein Angebot an einen Kunden schickt und welche Arten oder welche Standards gibt es überhaupt, nach denen man sich richten kann, die man dann konkret ins Angebot reinschreiben kann, damit man dann noch einen gemeinsamen Nenner hat, worüber man im Thema Barrierefreiheit auch gemeinsam miteinander reden kann.

Kurze Pause je nach einer Sache, weil es geht um die WordPress Community Gruppe, weil da sind wir schon ein paar Leute, ich glaube da sind wir schon über 70 Leute, also schon eine ganz schön große Menge, da würde ich gerne dann das Gespräch dieser Podcast-Episode in der Community-Gruppe fortsetzen, weil wenn du jetzt zum Beispiel auf YouTube bist, dann kannst du gerne deine Fragen oder Kommentare einfach in den Kommentaren stellen, aber falls du jetzt beim Audio-Podcast zuhörst, in deiner Podcast-App, dann wirst du diese Möglichkeit nicht haben.

Deswegen lade ich dich ein, einfach auf den Link in der Beschreibung zu klicken, da kommst du direkt zu der Seite, wo du der kostenlosen WordPress-Community beitreten kannst.

Wie gesagt, da werden wir die Diskussion weiterführen, zu dieser Podcast-Episode, teilweise auch mit den Gästen.

Das heißt, gelegentlich wirst du dann auch mit den Gästen schreiben können.

Teil dort bitte deine Meinungen, da würde ich alle dazu motivieren, ein bisschen was zu dem Thema beizutragen.

Falls du auch andere WordPress-Fragen hast, dann wirst du natürlich Antworten auf diese Fragen bekommen.

Wenn du vorbeischaust in der Community, dann sag bitte Hallo, kannst dich gerne vorstellen, sagen was du machst.

Falls du wirklich konkrete Fragen hast, dann können wir uns gerne auch Sprechstunden ausmachen innerhalb der Community und ja, würde mich freuen, wenn du auch dabei wärst.

Dann sehen wir uns dort und jetzt geht's weiter mit dem Video.

Also für uns in Deutschland, wenn wir hier barrierefreie Software verkaufen, dann ist für uns die EN 301549 relevant.

Das ist der technische Standard, der gilt, wenn wir darüber sprechen, wenn wir barrierefreie Software verkaufen.

Da ist dann genau gelistet, wenn wir Webseiten haben, was die einhalten müssen, wenn wir nicht Webdokumente wie zum Beispiel PDFs haben, wie die ausschauen müssen, damit sie als barrierefrei gelten.

Und dann aber auch für Apps gibt es ein Kapitel.

Je nachdem, wie komplex die Software ist, gibt es halt unterschiedliche Anforderungen und da muss man dann gucken, was gilt für mich und für mein Produkt.

Diese europäische Norm, die es eben gibt, diese technische Spezifikation, die verweist auf die Web Content Accessibility Guidelines.

Das ist der internationale Standard, wenn es um digitale Barrierefreiheit geht.

Und das ist schlussendlich auch nichts anderes als ein Kriterienkatalog, der halt wirklich sagt, okay, das muss deine Website erfüllen, wenn sie barrierefrei ist.

Die ist unterteilt in verschiedene Level, wenn man so will.

A, AA und AAA.

Die spezifizieren Ausbaustufen, die ein Produkt quasi haben kann in Bezug auf Barrierefreiheit.

Und rechtlich bindend für uns in Deutschland ist A und AA.

Das heißt, wenn wir von Barrierefreiheit sprechen, dann wollen wir immer Barrierefreiheit nach der EN 301549. Und das ist auch das, was in Angebote rein muss.

Also jetzt hat nur WCAG zum Beispiel reinzuschreiben, wäre zu wenig, weil die EN mehr verlangt als die WCAG.

Die WCAG ist aber ein guter Anfang für Leute, wenn sie anfangen wollen, sich ins Thema einzuarbeiten.

Deswegen kommt auch ein bisschen darauf an, finde ich, aus welcher Perspektive man auf die Barrierefreiheit schaut.

An sich sind das aber die zwei Dokumente, die sehr, sehr wichtig sind.

Wenn wir barrierefreie Software entwickeln und uns Angebote quasi anschauen zu dem Thema, aber auch uns in das Thema einarbeiten wollen.

Ja, weil oft liest man ja nur so im Internet, okay, der WCAG-Standard, AA, der AA-Standard ist so, okay, wenn du das hast, dann ist deine Website barrierefrei.

Und das ist dann interessanter noch, das zu unterscheiden, eben, was ist die Gesetzeslage in Deutschland, Österreich und in der Schweiz? Nach was sollte man sich richten? Da kommt ja noch 2025 der European Accessibility Act und irgendwie gibt es da sehr viele Gesetze, wo man sich erst reinlesen muss, aber es gibt dann auch dieses Phänomen, fünf Experten und zehn Meinungen und man liest halt verschiedene Sachen im Internet und du meinst, dass man in dem Fall war die Gesetzeslage, die du erwähnt hast, die aus Deutschland, oder? Also es gibt eine europäische Richtlinie, die muss von jedem Mitgliedstaat der EU ratifiziert werden.

Und Deutschland war eins der Länder, die gesagt haben, ja wir finden Barrierefreiheit wichtig, wir ratifizieren das und deswegen wurde das quasi in Deutschland in internationales Recht umgegossen und wir haben daraus das Barrierefreiheitsstärkungsgesetz gemacht.

Österreich hat dafür ein anderes Gesetz und die Schweiz, die ist ja gar kein EU-Mitgliedstaat eigentlich, deswegen ist die da ein bisschen außen vor genommen, für die gelten andere Richtlinien.

Und wir haben in unseren Gesetzestexten und Verordnungen festgehalten, dass für uns Barrierefreiheit barrierefrei nach dieser EN-Norm heißt.

Das ist aber etwas, das ist deutschlandspezifisch.

Diese Norm, die ist europaweit und jedes Land, wenn es denn möchte, kann sich danach richten, muss es aber nicht.

Jetzt hat im europaweiten Vergleich ist die EN-Norm aber schon sehr fortgeschritten, was den Grad an Barrierefreiheit angeht.

Im Vergleich zu anderen ländern wenn man netz halt leute fragen würde die sehr aktiv der barrierefreiheit sind würden sie sagen da geht auf jeden fall mehr.

Das ist immer die frage wenn du fragst für rechtliche sicherheit ist das aber ausreichend und das ist auch der punkt du bist auch nicht barrierefrei wenn du konform bist mit der EN Norm du bist halt barrierefrei nach der EN Norm diese ganzen kriterien die in der WCAG verzeichnet sind die sind auch sehr wichtig für barrierefreiheit sonst gäbe die nicht in der Form.

In der WCAG sind generell wirklich nur Probleme gelistet, die, wenn sie nicht erfüllt sind, ein Problem für Menschen mit Behinderung darstellen.

Und aufgeteilt hat man es deswegen in gewissen Graden, weil du halt bei einem A-Level sagst, okay, wenn das nicht erfüllt ist, dann kann ein Mensch mit Behinderung diese Webseite nicht benutzen.

Das sind wirklich gravierende Mängel, die eine Webseite hat.

Da fällt man sofort durch.

Doppel-A ist ein bisschen weniger weit am Anfang.

Zum Beispiel, was ein Doppel-A-Kriterium ist, ist ein Minimalkontrast, die deine Webseite einhalten muss, dass du quasi sagst, deine Schrift muss sich stark genug vom Hintergrund abheben, dass man sie lesen kann.

Das wäre Doppel-A-Kriterium, ist aber trotzdem sehr, sehr wichtig.

Also du brauchst es schon, um eine barrierefreie Webseite quasi zu haben.

AAA ist dann nochmal ein bisschen extremer.

Es gibt zum Beispiel auch eine Kontrastanforderung, die ist dann noch höher.

Die würde dann unter AAA fallen.

Da sind einfach die Anforderungen stärker.

Aber da wird halt auch geschaut, okay, wie einfach ist es denn für die Leute, das umzusetzen.

Also das fließt dann auch in die Einschätzung mit rein.

Wenn du sagst, okay, du hast verschiedene Grade an Barrierefreiheit.

Wie leicht ist es für RedakteurInnen, das umzusetzen? Wie leicht ist es für einen Entwickler? Was ist ein AAA noch? Zum Beispiel, dass Überschriften wirklich hierarchisch aufgebaut werden müssen.

Das ist ein AAA-Kriterium, dass die keine Ebene überspringen dürfen.

So was zum Beispiel wäre ein fortgeschrittenes Kriterium, was, wenn wir ehrlich sind, leicht zu erfüllen ist.

Also es ist gut, das mitzunehmen, wenn man kann.

Und deswegen ist es immer besser, nach AAA zu gehen, wenn man kann, als es auszulassen, aber für die gesetzliche Konformität ist es eben nicht notwendig.

Und deswegen finde ich es immer schwierig zu sagen, was ist dann wirklich barrierefrei.

Weil wirkliche Barrierefreiheit würde ja heißen, dass niemand eine Barriere hat, wenn er versucht auf seine Website zu gehen und jetzt zum Beispiel unsere paar Schuhe zu kaufen.

Das ist ja aktuell technisch noch nicht umsetzbar, wenn man so will.

Deswegen sagen wir auch immer barrierefrei nach, weil es halt immer einen gewissen Grad gibt an Problemen, die auftreten können.

An sich sind wir aber da auf jeden Fall in dem Bereich, wo wir sagen, es geht hier nur darum, die Nutzbarkeit sicherzustellen.

Also wir machen da keine gute UI/UX, wir machen da nichts Gutes für Menschen, sondern wir stellen wirklich die Nutzbarkeit nur sicher.

Und das alles, was wir tun, diese bis 100 Prozent Barrierefreiheit, das ist quasi noch ein Riesenweg, den wir eigentlich hätten, wenn wir uns dann von dem Standard lösen und von den gesetzlichen Anforderungen, was wir noch tun könnten.

Zum Beispiel einen Dark Mode.

Ich glaube, finden alle sehr sehr hilfreich, ist keine Anforderung nach der WCAG und da gibt es eigentlich recht viele Dinge, die man noch machen kann, die halt jetzt nicht im Standard referenziert werden.

Um das vielleicht mal so zusammenzufassen, damit dann, dass sich die Leute dann auch die die Zuschauer und Zuschauerinnen gut strukturieren können, ist finde ich das, was man sich da mitnehmen kann, ist einfach jetzt was du gut gesagt hast, wenn man von Barrierefreiheit spricht, dann sollte man auch dazu sagen, nach welcher Norm das ist.

Also das ist einmal wichtig, dass das auch vor allem dann auch im Angebot drinnen steht und nicht, dass man nur so dazu schreibt, ja, die Website ist dann einfach barrierefrei.

Dann damit man das einfach konkretisiert und dann was bei mir noch so im Kopf herum schwebt, weil du hast die EN-Norm erwähnt und dann noch den AA-Standard von der WCAG, vom WCAG-Standard.

Wenn ich irgendwelche Begriffe falsch verwende, könnt ihr mich da gerne korrigieren, also macht's nur.

Aber in dem hast du auch am Anfang gesagt, dass die EN-Norm besser geeignet ist, weil die einfach mehr umfasst.

Ist das dann so, dass man sich einfach nach der richten sollte oder dann mehr nach dem AA-Standard von der WCAG? Also das ist quasi eine Verweiskette.

Also unsere Gesetze verweisen auf die EN-Norm.

Deswegen ist es wichtig, wenn wir jetzt hier in Deutschland arbeiten in dem Bereich, dass wir immer in unsere Angebote und Verträge die EN-Norm reinschreiben.

Die EN-Norm, die verweist aber selber auf die WCAG.

Das heißt, die EN-Norm sagt, barrierefrei ist das, was die WCAG sagt.

Rechtlich gesehen gilt aber trotzdem die EN-Norm.

Deswegen müssen wir die IEN-Norm immer verwenden, wenn wir darüber sprechen.

Aber eigentlich, jetzt flapsig gesehen, ist das sehr deckungsgleich.

Die EN-Norm hat halt mehrere Kapitel und die kümmert sich um die Barrierefreiheit des ganzen Produktes und wir kümmern uns ja eigentlich nur um den digitalen Bereich.

Und da gibt es zum Beispiel in der EN-Norm das Kapitel 9 und das heißt ausschließlich Web und da gibt es gewisse Punkte, die unter dem Web-Bereich fallen.

Und dieses Kapitel verweist komplett auf die WCAG AA.

Und für die meisten einfachen Webseiten oder auch etwas komplexere Webseiten reicht es vollkommen aus, sich nach diesen Standards zu halten.

Es gibt da natürlich noch andere, wenn man jetzt davon ausgeht.

Mittlerweile gibt es ja super komplexe Web-Apps.

Es gibt sowas, wer das Design-Tool Figma kennt.

Das ist ja ein wahnsinnig krass komplexes Tool.

Das ist wie Photoshop.

Photoshop gibt es mittlerweile auch im Browser.

Wenn man sich sowas anschaut und sowas benutzt, diese ganzen Funktionen, die man damit machen kann, müssten nach der EN-Norm auch komplett barrierefrei sein.

Und das ist eben, da sind noch mehrere Sachen eben gelistet, die barrierefrei sein müssen nach der EN-Norm, die eigentlich nicht auf Webseiten, normale Webseiten zutreffen.

Deswegen ist da so ein bisschen, man ist auf der sicheren Seite, wenn man die EN-Norm reinschreibt und auch referenziert und danach auch prüft.

Aber es gibt ja dann gewisse Prüfschritte, die man durchgehen kann, um die EN-Norm zu prüfen.

Und wenn man keine komplexe Seite hat, dann fallen da schon, weiß ich nicht, 20 oder 30 Prüfschritte raus, weil man die gar nicht anwenden kann bei den meisten Webseiten.

Das meiste, was man eben anwenden kann, sind die AA-Kriterien aus der WCAG.

Deswegen werden die auch ganz oft auf die verwiesen oder die in Blogs genannt oder im Internet einfach genannt, weil das Ganze, wie man ja gerade gehört hat, das Ganze komplett zu verstehen ist immer ein bisschen komplex und man bricht es am einfachsten runter, wenn man den Leuten sagt, nimm die WCAG AA, damit bist du in 95% auf der sicheren Seite, außer du machst halt wirklich komplexe Software.

Und muss man sich dann irgendwie zertifizieren lassen? Weil bei der DSGVO da gab es ja die Zertifizierung zum Datenschutzbeauftragten zum Beispiel, nachdem die DSGVO dann, oder vielleicht gab es das auch davor, das weiß ich jetzt nicht so genau, Aber auf jeden Fall gab es die Zertifizierung zum Datenschutzbeauftragten.

Gibt es da so etwas ähnliches, was dann rechtlich eine Rolle spielen könnte in Bezug auf Barrierefreiheit? Oder muss sich damit einfach jeder mal selbst beschäftigen und nach dem Standard, nach den Gesetzen dann einfach die Arbeit erledigen, die man so normalerweise gemacht hat? Es gibt keine Pflicht auf Zertifizierung, aber man kann sich zertifizieren lassen.

Die IAAP zum Beispiel, die zertifiziert sehr viel in dem Bereich.

Es gibt zertifizierte Testverfahren, für die man sich zertifizieren lassen kann.

Das ist aber auch ein Kostenpunkt, wo man sich überlegen muss.

Es ist sehr schwer, da rein zu kommen.

Deswegen würden wir den meisten dazu raten, erst mal ohne anzufangen, weil das ganze Wissen ist ja im Internet frei zugänglich.

Es ist eine gute Quelle, um zu starten, aber es ist auf jeden Fall nicht notwendig.

Ja, und rechtlich binden ist es auch nicht.

Also es gibt keine Zertifizierung momentan.

Ich weiß, die Leute arbeiten dran, aber momentan gibt es keine Möglichkeit der Zertifizierung, die rechtlich bindend ist.

Für Webseiten meinst du? Ja, genau, für Webseiten.

Somit ist man da sowieso.

Wie die Rechtsprechung dann schlussendlich, das Gesetz ist ja noch gar nicht da, deswegen gibt es halt auch super viele offene Fragen darüber, wie das schlussendlich ausgelegt wird und wie das getestet wird und wie das gemacht wird.

Es ist ja auch, wenn man wirklich auf Barrierefreiheit im Detail testen will nach der WCAG, ist das sehr sehr komplex.

Und es wird kaum bis gar nicht der Fall sein, dass da irgendjemand sich die Mühe gibt, deine ganze Webseite durchzuschauen und jegliche Funktionen zu testen, um zu gucken, ob sie barrierefrei ist.

Das meiste, was wahrscheinlich passieren wird, wie es auch bei der DSGVO war, es werden halt irgendwelche schnellen automatisierten Tests rübergelaufen gelassen und dann wird geguckt, ob Kontrastprobleme entstehen, ob deine Links nicht gut ausgezeichnet sind, sowas was automatisierte Testtools finden können und wenn da halt ein Bericht kommt von du hast 40 Fehler, dann wird dich vielleicht jemand verklagen deswegen.

Aber wenn du dich darum kümmerst und da mal eine Grundahnung davon hast und anfängst es zu machen, dann ist auch die Gefahr wahrscheinlich relativ gering, dass du besonders mit einer kleinen Webseite abgemahnt wirst.

Natürlich, umso größer du bist, umso genauer schauen die Leute hin und umso genauer wollen sie dich dann auch.

Wissen sie, da ist Geld zu holen, dann lohnt es sich auch genauer hinzuschauen sozusagen.

Aber genau deswegen, wie das aber dann im Detail aussieht, ob man sagt, du hast jetzt drei Kontrastfehler und deswegen musst du 1000 Euro zahlen oder keine Ahnung, das muss alles, das wird erst, wenn die erste Rechtsprechung oder die ersten Rechtsprechungen dafür wirklich kommen und Leute verklagt werden und so, wird es sich erst zeigen, wie das ist.

Aber nichtsdestotrotz sollte man sich auf jeden Fall vorbereiten, weil wenn dann die Rechtsprechung kommt und man sieht, dass da Probleme auftauchen und man dann erst anfängt, sich damit auseinander zu setzen, dann lebt man halt jeden Tag damit, dass man verklagt werden kann.

Das eigene Risiko, dass man da eingehen will oder muss.

Tauchen wir vielleicht mal in die Praxis ein, weil es haben viele so rechtlich-organisatorische Themen angesprochen, aber einer eurer Stärken ist ja das, so wie ich das auf gehirngerecht.

digital gesehen habe, dass ihr eigentlich alle Bereiche abdeckt von do-it-yourself mit Kursen, die man sich kaufen kann, done with you, with workshops und done for you mit der Dienstleistung, die ihr dann anbietet und ihr macht's ja eigentlich ziemlich viel auch mit WordPress.

Und wenn wir jetzt zum Beispiel in das ganze Thema, in das praktische Thema WordPress eintauchen, da wäre es super praktisch, wenn wir mal ansprechen könnten, wie kann man dann eigentlich eine WordPress-Website testen auf Barrierefreiheit, weil dann wird sich das jetzt jeder fragen so, okay, ist meine Website barrierefrei oder nicht, wie kann ich das überprüfen überhaupt und dann wäre es super, wenn man dann ein bisschen so in den WordPress Stack, würde ich das jetzt mal bezeichnen, eintauchen, weil da gibt es ja verschiedene Page Builder, mit welchen man sich eine Website zusammenbauen kann mit WordPress und welchen Prozess habt ihr euch da ausgearbeitet oder welchen Stack verwendet ihr, wo ihr sagen könnt, für den aktuellen Tag kann man mit dieser Konstellation von Plugins und Pagebuildern eine barrierefreie Webseite erstellen? Also wenn man sich fragestellt, ob meine Webseite barrierefrei ist, dann ist sie sehr wahrscheinlich nicht barrierefrei, denn aufgrund der Tools… Also man muss sehr viel dafür tun, dass eine Webseite barrierefrei ist, will ich sagen.

Barrierefreiheit kommt nicht von alleine mit.

Und gerade was du schon auch angesprochen hast, es gibt sehr, sehr viele Tools, mit denen man Webseiten bauen kann.

Alleine schon für WordPress sind es ja unzählige, wie Elementor, Divi, WP Bakery, Oxygen, BricksBuilder benutzen wir sehr viel.

Da gibt es ja wahnsinnig viele, die gern genutzt werden und bei den meisten ist es tatsächlich der Fall, dass noch kein barrierefreier Output erzeugt werden kann.

Das heißt, ich bin da auch extrem limitiert in meiner Option, dass ich damit überhaupt barrierefreie Webseiten erstellen kann.

Das ist natürlich etwas, da müssen die Tool-Hersteller auch viel nachliefern.

Weil wenn ich einfach die Option nicht habe, weil meine Komponenten von Haus aus nicht barrierefrei sind, ist das natürlich schwierig.

Wollte nur kurz dazwischen krätschen, weil mir das gerade in den Kopf gefallen ist.

Was sind dann so die Sachen, die die Page Builder noch nicht erfüllen? Weil okay, ich kann einen Alttext hinterlegen bei den Bildern, ich kann die Hierarchie der Headings und so weiter alles steuern, ich kann den Kontrast steuern.

Was sind so dann die klassischen Sachen, auf die ihr schaut bei einem Page Builder und sagt, das passt noch nicht so ganz.

Ganz klassisches Beispiel sind zum Beispiel, wenn wir so clickable cards haben und wir machen so zwei, drei, vier nebeneinander, dann muss ja die Kartenkomponente an sich barrierefrei sein.

Damit die barrierefrei ist, muss sie gewisse Anforderungen erfüllen.

Zum Beispiel muss der Link richtig platziert sein in der Karte.

Wenn ich einer Karte keinen Link gebe, weil ich sage, ich will das nur als optisches Merkmal haben, dann darf diese Karte auch keinen Link enthalten, weil es für assistive Technologien wahnsinnig wichtig ist, dass wir die Elemente korrekt auszeichnen.

Also das heißt, wenn ich einen Link verwende, dann muss diese Komponente auch wirklich ein Link sein, im HTML semantisch.

Wenn meine Komponente keinen Link hat, dann darf dieser Link auch in der Karte nicht enthalten sein.

Und ich habe das in vielen Buildern zum Beispiel gesehen, dass das Element trotzdem auftaucht im Code, weil das für Menschen ohne Behinderung, die keine assistive Technologie verwenden, natürlich kein Problem darstellt.

Wir sehen es ja dann nicht.

Das ist aber dann ganz anders, wenn man mit Software quasi drüber geht und dann entstehen da die ersten Probleme.

Das ist ein Punkt.

Und um das lösen zu können, müsste man quasi als Tool-Nutzer wirklich reingehen können in die Komponenten und das wirklich abschalten können, dass es auftaucht.

Das ist etwas, das geht mit Bricks-Builder, weil wir da wirklich reingehen können in die Semantik und sagen können, wir wollen, dass das Element ein A, also ein Link ist.

Wir wollen, dass das eine Liste ist.

Wir wollen, dass das eine Liste des Elements ist.

Das können wir selber einstellen mit unserem Tooling.

Aber Elementor zum Beispiel lässt sowas gar nicht zu.

Dann muss man gewisse Tags setzen können im HTML wie ARIA Labels zum Beispiel.

ARIA ist ein Standard, mit dem man Sachen barrierefrei machen kann.

Also ich kann zum Beispiel Sachen komplett aus meiner DOM Struktur herausnehmen.

Ich kann etwas einen zugänglichen Namen geben, damit assistive Technologie das auch richtig ausgeben kann.

Da habe ich ganz viele Optionen, aber um das zu können, muss ich eben auch auf HTML-Ebene gehen dürfen und da die Attribute setzen können.

Und auch das lässt nicht jeder Builder dazu.

Und dann gibt es viele Builder zum Beispiel, die nehmen von vornherein Optionen raus.

Manche Builder zum Beispiel verhindern den Zoom.

Zoom ist eine Anforderung nach der WCAG.

Es muss gegeben sein, dass ich bis auf 400 Prozent in meine Anwendung reinzoomen kann.

Die darf auch nicht kaputt gehen dabei.

Dann muss ich die Orientierung ändern können.

Das heißt, wenn ich mein Gerät quasi von Portrait in Landscape umdrehe, dann muss ich die Webseite mitdrehen.

Und das sind ganz viele kleine Anforderungen, wo viele Builder schon daran scheitern, weil sie einfach Voreinstellungen haben, die das verhindern.

Und da müsste man quasi hingehen, gucken, kann ich das ändern? Wenn ja, muss ich das wirklich oft tief in den Einstellungen tun? Und das ist einfach, abgesehen davon, dass es unnötig ist, ist es halt trotzdem etwas, wo ich mich dann tief mit zum Beispiel den Divi-Builder auseinandersetzen muss und gucken muss, okay, kann ich damit überhaupt wirklich, selbst wenn ich reingehe und mir das selber manuell anpasse, barrierefreie Lösungen erschaffen.

In den meisten Fällen ist es nicht der Fall.

Also wir kennen noch niemanden, der barrierefreie Webseiten zum Beispiel mit Elementor erstellt hat.

Einfach weil Elementor das noch nicht zulässt.

Und auch ein einfaches Beispiel sind Menüs.

Menüs, meistens ist es ja eine Komponente, die nimmt man auch in Elementor und sagt, ich will jetzt hier mein Menü platzieren und dann zieht man das da einfach rein und dann taucht da das Menü auf.

Aber dieses Menü muss halt zugänglich sein.

Es muss zum Beispiel, wenn ihr ein Untermenü in dem Menü habt und mit Hover dieses Untermenü öffnet, muss es eine Möglichkeit geben, dieses Menü auch mit mit der Tastatur zu öffnen, weil Hover alleine, es kann nicht jeder Mensch mit der Maus, kann nicht jeder Mensch eine Maus bedienen und nicht jeder kann Hovern, deswegen muss es eine andere Möglichkeit geben, dieses Untermenü zu öffnen.

Und das lässt zum Beispiel Elementor nicht zu, zumindest aus meinem Wissensstand vor, sagen wir mal, drei, vier Wochen, als wir das letzte Mal das angeschaut haben, ging das eben nicht.

Und das ist eben das, was, wenn das nicht geht, wenn das Elementor nicht implementiert, dass dieses Menü barrierefrei benutzbar ist, dann kann man auch nichts dagegen tun.

Wie Nina gesagt hat, man kann da nicht selber, man müsste sich codemäßig ein eigenes Menü schreiben.

Und das ist eben nicht möglich, oder es ist schon möglich, aber man muss halt dann wesentlich mehr können.

Und die meisten Leute, die Elementor benutzen, haben dieses Wissen ja einfach auch gar nicht.

Darum benutzen sie Elementor und Bricks gibt eben, in Bricks geht es jetzt auch nicht, also wir können Tags setzen und so weiter.

Da geht es jetzt aber auch nicht, dass wir einfach sagen, wir schreiben die komplette Komponente rum, aber Bricks hat eben damit mit ganz Barrierefreiheit im Hintergrund schon seine Komponenten gebaut.

Deswegen sind sowas wie Menüs, die man sich reinzieht oder Akkordeons oder sonstiges, die sind eben schon komplett mit der Tastatur steuerbar.

Und das ist eben das, was vielen, vielen anderen Buildern heutzutage noch fehlt.

Und da kennen wir bisher auch wirklich nur Oxygen und BricksBuilder, die einem die Möglichkeit geben, das zu tun.

Es ist mir jetzt auch, während du das erzählt hast, eingefallen.

Wenn Elementor zum Beispiel das mit den Menüs noch nicht so gut hinbekommen hat und man dann sich eigentlich selbst das Menü programmieren müsste, dann entsteht dann eine neue Art von Barriere für die meisten Leute, die jetzt nicht programmieren können.

Also ist das dann so ein bisschen so eine Matrix-Sache.

Ja, aber irgendwie hängt das dann auch davon ab, wie man das Tool selbst verwendet, weil ich kann mir gut vorstellen, dass du mit Bricks einfach einen Button setzen kannst und standardmäßig ist es ein A-Tag, der eigentlich nur etwas Interaktives macht auf der Webseite, aber zu keinem neuen Website führt.

Und da könnt ihr mich auch gerne korrigieren, wenn ich das falsch verstanden habe, aber zum Beispiel, wenn man auf eine andere Webseite verlinkt, dann sollte man den Link Tag, den A-Tag von HTML verwenden, aber wenn man zum Beispiel jetzt einen Button hat, wenn dann einfach dann dynamisch dann die Kategorie ausgewählt wird und dann die Seite nicht neu geladen wird, sondern die Blogbeiträge dann anders angeordnet werden, anders gefiltert werden und so weiter, dann werden dafür auch oft Link Tags verwendet und standardmäßig kann sein, dass einfach auch wenn das zum Beispiel Bricks ist oder Oxygen oder Elementor, ist eigentlich egal, aber standardmäßig kann sein, dass diese Elemente einfach die Link Elemente verwenden im Hintergrund, dass man das dann später umstellen kann, ist mega cool, aber dann muss man auch wissen, dass man das machen sollte und wie man das macht.

Also wenn man standardmäßig einfach die erste Website erstellt, dann muss man theoretisch dann auch wissen, dass man das machen sollte und wie man das macht.

Also von Haus aus sind ja viele Sachen noch nicht so, wenn du das Element standardmäßig verwendest, ohne das dann anzupassen, erfüllt das dann ja diese Norm der Barrierefreiheit dann in vielen Fällen noch nicht, oder? An sich würde ich sagen, dass so einfache Seiten wie WordPress, die haben eigentlich selten einen Button.

Wir kennen das so, dass ein Button nur dann verwendet werden soll, wenn sich wirklich einen Zustand verändert.

Beispielsweise wenn ich ein Formular abschicke, zum Beispiel, dann habe ich eine Zustandsänderung, weil dann schicke ich ja eine Nachricht ab.

Oder wenn ich meine Accountdaten verändere und abspeichere, dann passiert da wirklich was, weil ich etwas in der Datenbank verändere.

Und Link ist immer dann gut zu nutzen, wenn wir irgendwo anders hin wollen.

So hätte ich das jetzt gesagt.

Also was du als Beispiel genommen hast, ist mit dem Filtern.

Wenn du irgendwas filterst, auf jeden Fall, dann ist das ein Button.

Aber ansonsten sollte, wenn es irgendwo anders hinliegt, auch auf On-Page, das kenne ich tatsächlich auch nur mit Links, dass man da einfach irgendwo dann auf der Page hinlinkt oder zu anderen Pages oder Zwischenpages, wie auch immer.

Dass das alles Links sein sollten, wenn man keinen Zustand verändert.

Das ist aber trotz dessen nicht gut.

Natürlich, also Barrierefreiheit ist generell eins der wichtigsten Sachen in der ganzen Barrierefreiheit ist, dass man semantisches HTML richtig benutzt.

Umso eher man HTML richtig benutzt, umso mehr sichert man, dass deine Webseite barrierefrei ist, weil HTML ist standardmäßig eigentlich barrierefrei.

Alles was ins HTML implementiert ist, ist schon mit Barrierefreiheitsfunktionen implementiert.

Nehmen wir als Beispiel, wenn wir beim Button bleiben.

Ich kann mir ja auch einfach selber einen Button bauen mit div.

Dann kann ich sagen, das ist ein Button und es hat eine Funktionalität.

Es passiert irgendwas, es verhält sich wie ein Button.

Das Problem ist, wenn ich das mache und das ist eben, was die meisten Entwickler nicht wissen und wir auch nicht wussten, bevor wir uns mit Barrierefreiheit beschäftigt haben, dass ein Button hat ja eine gewisse Funktionalität eingebaut, damit eine Tastatur bedienen kann.

Ich kann auf einen Button gehen und ich kann Enter drücken und da passiert etwas.

Aber das hat irgendwer da eingebaut.

Dieser Button hat das nicht magisch aus dem Nichts geschaffen.

Und wenn ich mir jetzt selber einen Button mit einem div baue, ein div hat keine Semantik.

Ein div und ein Span, das sind die einzigen zwei Elemente im HTML, die keine Semantik mitliefern.

Das heißt, wenn ich einen div, wenn ich auf einen div gehe und Enter drücke, dann passiert gar nichts, weil niemand irgendwas implementiert hat, was mit Enter passiert.

Und das ist eben das größte Problem, wenn man unabhängig von WordPress jetzt, aber auch in WordPress.

Klar, wenn man selber mit PHP entwickelt in WordPress und dann irgendwelche Funktionen schreiben will in seine Komponenten rein und deswegen von selber sagt man mal, man macht einen Dropdown, das man selber programmiert, weil man nicht der Standard HTML Dropdown verwenden will, sondern man baut sich selber eins und dann fängt man an mit divs rumzuschachteln.

Dann hat man eben oft das Problem, dass Leute vergessen, die Barrierefreiheits- funktionen einzubauen.

Dann muss man anfangen, wie Nina vorhin gesagt hat, man man muss gewisse ARIA-Attribute setzen, damit diese Funktionalität gegeben wird oder aber man muss eben auch sagen, wenn man jetzt einen Dropdown öffnen kann mit der Leertaste oder mit der Enter-Taste oder wie auch immer, dann muss das mit reinprogrammiert werden, sonst funktioniert das nicht und das sind alles Sachen, die dann vergessen werden.

Darum ist eher das Ding, HTML an sich ist eigentlich barrierefrei, wenn man nur HTML verwenden würde, hätte man die wenigsten Probleme tatsächlich, aber die meisten Leute wollen halt komplexere, schönere, gut designte Sachen, wie auch immer.

Und da müssen die Entwickler anfangen, das ganze Ding neu zu bauen oder von Grund auf zu bauen.

Und da passieren eigentlich die meisten Probleme.

Somit sagen wir auch meistens, wir machen eigentlich nicht das Internet barrierefrei, wir machen die Leute barrierefrei, weil das Internet ist eigentlich schon.

HTML an sich liefert eigentlich schon ziemlich viel Barrierefreiheit mit sich.

Und habt ihr euch auch Gutenberg angeschaut, weil da du sich ja ziemlich viel in der WordPress Core-Welt und da gab es ja den WordPress-Standard-Editor, diesen klassischen Editor, ja viele, viele Jahre.

Und jetzt passierte die ganze Blockifizierung von WordPress, also angefangen von dem Editor mit dem Gutenberg-Editor bis hin zu den Blockthemes jetzt, wo man auch Header, Footer und so weiter ausstehen kann.

Habt ihr euch das näher angeschaut, ob das, was die bei WordPress alles jetzt entwickeln und neu machen, ob das von Haus aus einen gewissen Barrierefreiheitsstatus hat, oder muss man da noch sehr vorsichtig sein, was das angeht? Also WordPress hat ja eine Unit, die sich um die Barrierefreiheit von WordPress kümmert, die haben da Leute, die schauen da drüber und das haben sie auch beim Block-Editor gemacht.

Grundsätzlich kann man davon ausgehen, dass WordPress selbst als Anwendung schon relativ barrierefrei ist, weil da kümmern sie sich auch drum, deswegen ist auch der Gutenberg-Editor beziehungsweise das, was dabei rauskommt, erzeugt auch recht gute Ergebnisse.

Das Thema ist mehr, dass ich natürlich als Person, die die Inhalte einstellt, sehr stark dafür verantwortlich bin, was halt auch rauskommt und mein Theme halt auch.

Und wenn mein Theme nicht barrierefrei ist, dann kann Gutenberg wenig dafür, weil das Theme ja am Ende dafür verantwortlich ist, wie das dann quasi rausgegeben wird.

Und da muss man eben gucken, okay, ist mein Theme barrierefrei und wenn ja, nach was ist es barrierefrei? Weil da muss ich dann auch gucken, wie kann ich denn meine Standards damit überhaupt erfüllen und das muss dann eben auch nochmal geprüft werden.

Ja und das sind auch solche Sachen, wie du es gerade angesprochen hast, mit der Content-Bearbeitung.

Also man kann zum Beispiel bei einem Bild einen Alttext setzen, aber auch die automatisierten Tools, die wissen nicht oder können nicht überprüfen, ob das wirklich semantisch korrekt ist, also dass das auch wirklich das Bild beschreibt.

Man kann ja irgendeinen Text reingeben, die automatisierten Tools sehen, okay, da ist ein Alttext vorhanden, aber die können das Bild nicht analysieren und nicht nachschauen, ob das wirklich ein sprechender Text ist.

Und das sind dann solche Sachen, wofür man dann in der Contentbearbeitung dann dafür verantwortlich ist oder dass man da einfach mitdenkt.

Absolut, das ist einer der Punkte, die man auf jeden Fall mit dazu nehmen muss, wenn man jetzt barrierefreie Inhalte erstellen möchte.

Ein Prüfer zum Beispiel, der würde auch jetzt über die Alttexte gehen und beurteilen, ob der Alttext wirklich eine valide Alternative ist oder nicht.

Da gibt es ja Kriterien oder so Eckpfeiler, anhand derer man sich orientieren kann, wie ein Alttext auszusehen hat.

Also grob sagt man zum Beispiel, der soll maximal ein bis zwei Sätze lang sein.

Einfach weil Alttexte, die haben ja keine Struktur und jedes Mal, wenn ich mir einen Alttext über assistive Technologie ausgeben lasse, dann muss ich mir den immer ganz anhören und ich kann nicht springen im Alttext.

Und wenn der dann 20 Sätze lang ist, dann ist das mühselig und das hat dann einfach keinen Wert.

Deswegen einfach da sollte man darauf achten, dass es zum einen kurz und knapp ist, zum anderen aber auch wirklich, dass es die Kernaussage des Bildes transportiert.

Und da ist aber eine sehr große Lücke zwischen ich habe keinen Alttext, was wir nicht haben wollen, was sehr schlecht ist, zu ich habe einen Alttext, der genau sagt, was auf dem Bild zu sehen ist und einem, der halt wirklich hilfreich ist und die Kernaussage des Bildes transportiert.

Und da kann man Stunden drüber debattieren.

Alttext, Das ist auch so eine niemals endende Geschichte.

Aber klar, das gehört auf jeden Fall dazu.

Und ich mag die Webseite optimieren.

Ich stopfe da jetzt mega viele Keywords in den Eintext rein, damit das einfach hoch rankt.

Ja, genau.

Aber das ist auch ein super Punkt.

Barrierefreie Webseiten sind auch sehr gut für SEO, weil sie einfach sehr sauber auch gebaut sind.

Die sind ja sehr schlank und echte Rennpferde.

Also wir haben einen wahnsinnigen Anstieg auf unserer Webseite.

dadurch, dass sie barrierefrei ist, ist halt super sauber.

Wenn assistive Technologien Webseiten lesen können, kannst du natürlich auch die Suchmaschine.

Da gibt es eine ganz gute Studie von SEMrush war das, glaube ich, ne? Accessibility Checker und SEMrush.

Genau, die können wir mal nachliefern im Nachgang.

Die hatten einen wahnsinnigen Anstieg, glaub bis um 50 Prozent sogar an organischen Besuchen, also krass.

Ja, da habe ich auch letztens eine Podcast-Episode aufgenommen, ihr mit Anne-Mieke, ihr habt euch glaube ich schon kennengelernt, und da hat sie ein Beispiel erzählt, eben das mit, ich glaube Tesco war das, wo sie dann einfach ein Umsatz durch Barrierefreiheit um so viel Prozent dann gesteigert haben und das sind halt Millionenbeiträge bei denen, die dann einfach mehr als Umsatz reinfließen.

Also ist natürlich die falsche Motivation jetzt wegen dem Geld die barrierefreie Website zu gestalten, aber ist natürlich auch die Gesetzeslage ist jetzt nicht der passende Motivator dazu, aber anders z.

B.

bei der DSGVO war es ja genauso.

Vor der DSGVO haben sich die wenigsten oder die Minderheit, sag ich jetzt mal, mit dem Datenschutz beschäftigt, damit das wirklich passt und plötzlich gibt es eine Gesetzeslage, die verpflichtend ist und so.

Ja, okay, machen wir.

Wir haben doch Budget dafür.

Ja, wir würden uns dann langsam dem Ende der Episode nähern.

Habt ihr dann noch vielleicht Themen, die für euch wichtig sind, die wir noch nicht so wirklich angesprochen haben? Vielleicht grundsätzlich nochmal einfach zu den Buildern.

Wenn es um eine Projektauswahl geht und man weiß, das Projekt soll perspektivisch barrierefrei sein, macht es auf jeden Fall Sinn, jetzt schon auf Tools umzusteigen, von denen man dass sie jetzt schon barrierefreie Inhalte erstellen können, weil da kann man sich einfach sicher sein.

Also an sich, was Tobi ja auch gesagt hat, Barrierefreiheit ist in den USA schon sehr viel länger Pflicht als bei uns.

Und auch jetzt Tools wie Elementor sind, meine ich, nicht auf den europäischen Markt begrenzt.

Das ist jetzt halt ein bisschen nur eine Mutmaßung, aber wenn sie es halt bis jetzt nicht geschafft haben, da irgendwie nachzuziehen, ist fraglich, ob sie das bis 2025 schaffen.

Und das ist ja der Stichtag.

Also ab Juni, ab Ende Juni fangen die Kontrollen an und ab da wird geschaut, wer hält sich dran und wer nicht.

Und deswegen macht es natürlich Sinn, sich im Vorfeld darüber zu informieren, mit was für einem Tooling kann ich das überhaupt erreichen.

Und da auch einfach mal Bricks die Chance zu geben, einzusteigen.

Ich finde das schaut am Anfang ein bisschen komplizierter aus als Elementor, weil man halt einfach mehr in den Code reingehen kann.

Aber es ist eigentlich sehr, sehr hilfreich.

Also super Tooling dafür.

Deswegen würde ich da einfach noch mal für plädieren, sich vielleicht zu überlegen, ob dann wirklich sowas wie Divi oder Elementor die richtige Wahl ist.

Ich habe zum Beispiel gehört, dass man mit Elementor Pro Attribute setzen kann, um im HTML für mehr Barrierefreiheit zu sorgen.

Und ich finde schon alleine, dass ein Tooling, das in die Premium-Variante packt und quasi diesen Gratis-Versionen diese Fähigkeit quasi vorenthält, finde ich, sagt auch viel über den Builder aus und ja, würde ich abraten davon, wenn wir barrierefreie Webseiten entwickeln einfach.

Ja und in Bezug auf Testen, weil das Thema haben wir da ein bisschen so, mit dem haben wir uns da nicht so wirklich beschäftigt, weil im Thema Testen, da gibt es ja diese automatisierten Tests, irgendwo habe ich gelesen, dass man doch, dass man mit diesen Tests nur 20 bis 30 Prozent der Barrierefreiheitsstandards erfüllt oder die können nur 20 bis 30 Prozent testen, dann gibt es noch bei dem Google PageSpeed Test dann auch eine Unterkategorie Accessibility und das testet aktuell dann noch weniger und wie kann ich überhaupt ein Tool finden, welches mir dann einen Richtwert gibt, was kann ich verbessern, was soll ich machen, weil nur nach dem logischen Verstand ist halt die Gefahr sehr groß, dass jeder so ein bisschen anders interpretiert und wenn es da so einen standardisierten Test gibt, den man durchführen kann, ist das natürlich dann noch viel hilfreicher, wenn man dann punktuelle Sachen bekommt, die man noch verbessern sollte.

Ja, also wir würden dazu raten, zuerst einmal diese automatisierten Test-Tools laufen zu lassen, weil es einfach auch ein guter Einstieg ist, zu sehen, okay, was mache ich auf jeden Fall falsch? Das sind dann Themen wie zum Beispiel Kontrast oder wenn man keine Alttexte hat für ein Bild, sowas würde auffallen.

Wenn Hierarchien nicht durchgängig sind, sowas fällt auf.

Aber wie du schon sagst, es sind sehr wenig Fehler von allen Fehlern, die man finden kann.

Deswegen muss man, wenn man barrierefreie Webseiten erstellen möchte, da führt kein Weg dran vorbei, sich mit den Standards auseinanderzusetzen.

Aktuell ist es sehr viel manueller Aufwand, betrieben werden muss, um das zu testen.

Und es würde auch auffallen, wenn man nur die automatisierten Sachen erfüllt, zum Beispiel so was wie ein Fokus-State, habe ich noch kein Tool gesehen, das das findet, wenn der fehlt.

Und der fehlt auf jeder zweiten Webseite.

Und das ist zum Beispiel etwas, finde ich, wenn man anfängt, Software zu entwickeln, die barrierefrei ist, das sind eins der ersten Sachen, die ich teste.

Und dann weißt du sofort, okay, die haben sich nicht damit auseinandergesetzt.

Und deswegen einfach da anfangen und dann Schritt für Schritt ausbauen.

Es gibt die Webseite der BIK BITV.

Die hat die Prüfschritte gelistet für den WCAG-Test, aber auch für den BIK BITV-Test, den es auch gibt in Deutschland.

Und da sind die Prüfschritte sehr schön gelistet.

Da wird geschrieben, was wird getestet, warum wird das getestet und wie kann ich das testen.

Und das ist für den Anfang ein ganz guter Prozess, um die ersten Schritte mal zu durchlaufen und zu gucken, was muss ich eigentlich alles erfüllen.

Da können wir dir den Link auch gerne nachliefern.

Ja, ich werde versuchen, alle Ressourcen, alle rechtlichen Sachen und so weiter, was wir jetzt besprochen haben, werde ich versuchen, dann in der Beschreibung zu verlinken.

Ein Punkt, der mir persönlich noch wichtig ist, was ich jetzt bei einer, wo ich dann recherchiert habe über YouTube-Videos, weil die meisten Leute werden das wahrscheinlich in Google oder in YouTube eingeben, wie kann ich meine Webseite barrierefrei gestalten.

Da gibt es sehr viele Anleitungen zum Thema WordPress-Website barrierefrei machen oder gestalten.

Installier dir einfach dieses Plugin.

Das gibt dir so ein Overlay, wo du dann einsehen kannst, wo du dann verschiedene Sachen einstehen kannst für Kontrastschriftgrößen und so weiter.

Und jetzt ganz blöd gefragt, aber würdet ihr solche Plugins empfehlen oder ist das eher so eine Gefahr, diese zu verwenden? Also diese Plugins, von denen du Sprich, das sind sogenannte Overlay-Tools und die sind schon seit Jahren sehr heiß diskutiert.

Es gibt sehr viele offizielle Aussagen dazu, dass diese Tools nicht dafür sorgen, dass deine Webseite barrierefrei wird nach den Anforderungen, die sie erfüllen muss.

Das heißt, du kannst es schon drauf machen, es bringt dir aber nichts, weil deine Webseite darunter liegend barrierefrei sein muss.

Es gibt das sogenannte Overlay-Factsheet, das stammt aus den USA.

Da haben sehr viele Menschen mit Behinderung, aber auch ExpertInnen aus der Szene darauf unterschrieben, dass diese Tools nicht nur keine Barrieren entfernen, sondern auch selber sehr viele Barrieren einfügen.

Das kann zum Beispiel sein, dass du dann irgendwelche Einstellungen vornimmst in dem Tool und plötzlich entsteht ein krasses Flackern irgendwie auf der Webseite, was dann Epilepsie auslösen kann.

Also das, was sie zum großen Teil versprechen, halten sie nicht.

Es ist auch mehr die Frage, wenn du jetzt zum Beispiel so ein Tool einbaust und du gibst über das Tool die Möglichkeit, die Schrift zu vergrößern.

Wenn ich jetzt eine starke Sehbehinderung habe, dann brauche ich die große Schrift, sobald ich meinen PC anschalte.

Das heißt, ich gehe nicht erst in meinen Browser rein und rufe deine Webseite auf, um dann dort die Schrift zu vergrößern, sondern ich brauche ja die große Schrift, wenn ich meinen PC starte und wenn ich meinen Browser öffne und wenn ich auf deiner Webseite navigiere.

Das heißt, diese Schritte, die ich durchlaufe als Mensch mit Behinderung, bis ich auf deine Webseite komme, die muss ich ja schon machen mit einer Anpassung, bevor ich überhaupt auf deine Webseite komme.

Und deswegen ist es die Frage, für wen ist dieses Tool wirklich hilfreich? Es ist gut gemeint, aber andersrum, wie viel bringt das dann das Tool? Das erinnert mich ein bisschen an die Cookie-Banner, die da sind, wo du draufklicken kannst, aber es wird trotzdem alles davor geladen und ob du draufklickst oder nicht, ist dem Cookie-Banner dann eigentlich egal.

Heckt natürlich ab, wie der Cookie-Banner dann konfiguriert wurde, weil das sind halt die Beispiele, wenn der Cookie-Banner dann falsch konfiguriert wurde, ist dann auch so eine Sache.

Irgendwie stimmst du dem zu, aber es werden schon Sachen davor geladen, bevor du zustimmst.

Und dann bringt der Cookie-Ban halt auch nicht viel.

Und ja, das war das Thema so, glaube ich, so im Großen und Ganzen.

Ich glaube, da kann man auch viele Teilbereiche noch ausdiskutieren und falls ihr dann Fragen habt, jetzt speziell dann an die Zuschauer und Zuschauerinnen gerichtet, könnt ihr die gerne in den Kommentaren stellen oder einfach Nina und Tobi direkt anschreiben.

Die Kontaktdaten sind dann unten verlinkt.

Am Ende stelle ich dann immer noch so gerne drei Bullet-Fragen.

Bevor wir das machen, würde ich euch gerne noch den Spotlight geben, falls ihr kurz erwähnen wollt, wie können euch Leute erreichen, was bietet sie an und wie könnt ihr dann den Leuten helfen, Barrierefreiheit-Websites zu gestalten? Super gern.

Also uns erreichen kann man natürlich auf der gehirngerecht.

digital-Seite.

Auch auf LinkedIn sind wir sehr vertreten.

Da sind wir beide sehr, sehr aktiv und posten sehr regelmäßig über die Themen, versuchen eben alles, was die Barrierefreiheit angeht.

Wie ihr vielleicht jetzt auch schon gemerkt habt, ist es manchmal etwas komplex und es kann etwas Kopfweh machen, sich damit auseinanderzusetzen.

Deswegen versuchen wir, die Themen sehr, sehr leicht runterzubrechen und dann leichten Einstieg zu geben, auch was die WCAG angeht, könnt ihr da gerne mal bei uns auf der Webseite schauen.

Da haben wir alle Kriterien, die relativ wichtig sind, haben wir runtergebrochen.

Hinter uns, ich weiß nicht, ob man uns sieht, aber falls man uns sieht, hinter uns hängt auch unser Poster von der WCAG.

Da haben wir alle Kriterien einfach so einen guten, leichten Einstieg zu kriegen mit auch einem Beispiel einfach mal aufgelistet, damit man sich, es soll auch ein bisschen unterhaltsam sein, damit man es nicht so trocken sich das ganze reinziehen muss.

Dann haben wir auch speziell jetzt erst einen neuen Kurs zum Thema WordPress und Barrierefreiheit.

Da werden wir Webseiten direkt mit WordPress bauen und kann man dann, wir haben so einen 8-Stunden-Kurs, kann man zusammen in dem Workshop dann wirklich sich hinsetzen und anfangen seine erste barrierefreie Webseite mit uns zu bauen.

Man braucht nur eine Lizenz für den BrikcsBuilder eben, um mitmachen zu können und irgendwie eine Instanz, die irgendwo ist von der WordPress-Seite, aber ansonsten kann man da leicht anfangen.

Und auch wenn wir beim Thema Testen sind, einer unserer beliebtesten Workshops ist Easy Checks nach Barrierefreiheit, da lernt man auch, wie man seine Webseite eben testet, welche Tools man verwenden kann, sogenannte Bookmarklets gibt es da, die man nutzen kann oder eben auch automatisierte Testtools, um einfach zu verstehen, wie kann ich selber feststellen und herausfinden, ob meine Webseite barrierefrei ist und an was ich arbeiten muss.

Das Plakat ist super für das eigene Schlafzimmer, damit du vor dem Schlafen gehen dann auch ein bisschen so wiederholen kannst und nachschauen kannst, was sagt die WCAG eigentlich aus.

Jetzt zu den Bullet Fragen.

Sagts einfach das Erste, was euch in den Kopf schießt und ihr könnt dann gerne entscheiden, wer welche Frage übernimmt.

Es sind insgesamt drei Fragen.

Wenn es Thema WordPress und Barrierefreiheit nicht gäbe, was wäre dein Alternativberuf? Ich würde super viel Branding machen.

Ich mache so, so gerne Branding und gehe leider ein bisschen in den Hintergrund.

Ich komme gar nicht so viel dazu, wie ich es machen wollen würde, aber Branding ist auf jeden Fall noch eine Leidenschaft von mir, die ich gerne mehr machen würde.

Nina, dann kannst du einfach die zweite Frage übernehmen.

Was ist das nervigste WordPress-Feature? Die Kunden, weil ich ehrlich bin.

Gute Frage.

Wir sind so glücklich mit unserem Stack eigentlich.

Das nervigste WordPress-Feature? Die Antwort haben wir noch nie gehabt.

Muss ich ja leider recht geben.

Nein, das darf man gar nicht so öffentlich sagen wahrscheinlich, aber das nervigste wird tatsächlich seitdem wir, ich weiß nicht, ob ihr das Tool kennt, aber Automatic CSS benutzen und sind wir so happy, auch was unsere CSS-Einstellungen angeht, zusammen mit BricksBuilder, es gibt so viele hilfreiche Variablen, ja, es ist eigentlich, weiß ich gar nicht, was ist das nervigste? Ich würde mir wünschen, dass WordPress von sich aus ohne Plugin was für Mehrsprachigkeit mitliefert.

Das wäre cool.

Ja.

Das kommt.

Das ist, glaube ich, Phase 4 oder so.

Also es gibt ja diese Phasen von, ich weiß nicht, ob ihr da so drinnen seid, so im Thema, in welcher Richtung sich WordPress entwickelt, weil wo das Gutenberg-Projekt begonnen hat, das wurde, glaube ich, in vier Phasen unterteilt.

Also das erste, das war der Editor, der dann ausgetauscht wurde mit dem Block-Editor.

Ich mag das jetzt nicht durcheinander bringen, aber danach kommen die Block-Themes.

Jetzt ist, glaube ich, Collaboration, also da wird das ganze Admin-Interface neu gemacht und, glaube ich, ist dann auch so in diesen Gutenberg-Stil wieder eingepasst.

Und ich glaube, Phase 4 ist dann Mehrsprachigkeit, damit das Nativ unterstützt wird.

Also es ist schon so am Horizont.

Und genau, die dritte Frage, die letzte Frage, was war euer letzter Aha-Moment mit WordPress? Wo ihr überrascht wart, dass WordPress das auch kann? Ich glaube, mein letzter Aha-Moment war gar nicht mit WordPress, sondern mit CSS.

Aber mit WordPress an sich weiß ich gar nicht.

Wir migrieren gerade in der sehr, sehr alte Seite, in der sehr viel höheren WordPress-Version.

Und das ist mein erstes wirkliches Migrationsprojekt, das ich mache von WordPress.

Und da war ich tatsächlich erstaunt, wie schön das funktioniert hat, die Daten umzuziehen mit nur WordPress.

Das fand ich sehr cool, wie das gelöst war.

Auch, dass es alle Alttexte mitgenommen hat zum Beispiel.

Das fand ich echt cool.

Das ist wahrscheinlich mehr so eine Newbie-Geschichte, wenn jemand das öfter macht.

Das ist wahrscheinlich so Standard, aber ich fand das toll, wie gut das funktioniert hat.

Das Umziehen war schon echt stark.

Das Umziehen ist halt immer auch so eine Sache.

Also je nachdem, welches System eingebaut ist, in welches System das umgezogen werden soll, ist es immer halt so sehr individuell.

Aber find ich cool.

Das ist, glaube ich, auch ein Teil von Phase 3 oder Phase 4, aber das ist eher damit dann verbunden, dass man einfach eine WordPress-Website besser umziehen kann auf ein anderes Hosting, aber jetzt nicht das, was du gemeint hast von, ich glaube, du meintest die Migration von Content in eine neue Version, oder? Was ich so beeindruckend an WordPress finde, ist, das ist ja alles open source.

Anfang des Jahres war ich auf dem Cloud Hackathon und habe da ganz viele Leute kennengelernt, die eben für WordPress mitentwickeln.

Das ist total spannend, was für engagierte und tolle Menschen sich da einbringen, um Open Source etwas zu entwickeln, das von so vielen Firmen, Agenturen und Freelancern benutzt wird, um Geld zu verdienen.

Das finde ich abgefahren.

Auch wie viel Motivation und Leidenschaft die eigenen Leute mitbringen, um das so zu treiben.

Da habe ich viele aus dem Accessibility-Bereich tatsächlich kennengelernt und das war ein ganz, ganz toller Moment auch, um da mal eins zu steigen und zu gucken, okay, wie funktioniert das eigentlich und wie beeindruckend ist es, dass so was Großes wirklich komplett freiwillig in der Open Source funktioniert.

Das ist abgefahren.

Wart ihr mal auf einem WordCamp? Noch nicht, nein.

Weil, kann ich euch nur empfehlen, weil wir organisieren jedes Jahr in Wien ein WordCamp, da mal eine kurze Werbespot und das haben wir dann im April dieses Jahr organisiert, also immer das Wochenende nach Ostern.

Das ist immer auch voll cool, dann einfach die Leute zusammen zu bekommen.

Da kommen auch viele Leute aus Deutschland und aus der Schweiz auch einige und viele aus Österreich.

Und es gibt halt Vorträge, Networking und all das.

Und da gibt es dann jetzt im Juni WordCamp Europe in Turin.

Das wird dann so das größte WordPress Event in Europa sein, glaube ich.

Ja, also kann ich euch nur empfehlen.

Cool, habt ihr noch eine finale Message, die ihr an die Zuschauer und Zuschauerinnen weitergeben möchtet? Kümmert euch früh genug um die Barrierefreiheit, dann macht ihr euch alles, alles wesentlich leichter als erst nächstes Jahr damit anzufangen.

Sehr cool.

Ja, wie gesagt, alles wird unten verlinkt sein, falls ihr Nina und Tobi kontaktieren wollt.

Das findet ihr alles in der Beschreibung.

Und Und dann vielen Dank, dass ihr heute da warst und vielen Dank, dass wir die Podcast-Episode aufgenommen haben.

Wir haben, glaube ich, sehr coole und sehr hilfreiche Themen angesprochen und dann sehen wir uns in der nächsten Episode.

Danke dir.

Danke dir, Dominik.

.