Präsentation abgeschlossen.

Ja, ruhig hier. Genau. Das ist nochmal kurz ein bisschen was über mich.

Das hatten wir gerade alles schon. Ich war früher mal bei Freedom Scientific,

das ist der Jaws Hersteller. Jetzt bin ich bei Mozilla tätig und mit dem Thema Barrierefreiheit beschäftige ich mich schon seit Anfang der 90er Jahre.

Genau. So. Was ist der Accessibility Inspector von Firefox? Das ist ein neues Tool,

das es seit Firefox 61 gibt. Das ist die Version, die im Juli erschienen ist. Jetzt im September ist Version 62 erschienen.

Da hat es schon einige Verbesserungen gegeben. Und ab Version 63, die im Oktober erscheinen wird,

die jetzt in einer Beta-Version ist, wird der Accessibility Inspector voraussichtlich, wenn sich da nicht noch was ändert, standardmäßig eingeschaltet sein.

Man kann ihn jetzt schon von Hand einschalten über die Einstellungen der Entwicklertools in Firefox.

Und wenn das dann getan ist, dann kriegt man den wunderbar sofort zu sehen. Und ab der Version 63 oder 64, das steht noch nicht ganz fest,

jetzt in der 63er Developer Edition ist er schon eingeschaltet, dann ist er automatisch sofort verfügbar,

ähnlich wie alle anderen Entwicklertools, man muss ihn dann nicht extra einschalten.

Und dann, was macht der? Der Accessibility Inspector stellt den Accessibility Baum dar.

Das ist der Baum, eine Untermenge von Informationen zur, der Website des DOM, des Dokumentobjektmodells, auch durch JavaScript und CSS gegebenenfalls verändert.

Und stellt dann die gleichen Eigenschaften dar, die der Screenreader auch von Firefox bekommt.

So, ich weiß jetzt nicht, ob ich noch synchron bin mit den Folien, weil hier gerade der Screenreader streikt.

Okay, und jetzt kommt die Übersicht, was das eigentlich alles für Informationen sind, glaube ich.

Also, die Ernahme, das heißt das Label eines Eingabefeldes, eines Formularfeldes, die Beschriftung eines Buttons, der Alternativtext einer Grafik oder der Text einer Überschrift,

sind nur einige Beispiele, das sind so die Informationen, die der Browser eben für den Screenreader schon errechnet und ihm dann übergibt.

Und der Accessibility Inspector nutzt dieselben Informationen, um das alles zugänglich zu machen und darzustellen.

Das heißt, ihr könnt dann tatsächlich die Informationen selber überprüfen beim Programmieren und beim Entwickeln des Markups, ob das alles schon so passt,

bevor ihr überhaupt irgendeine Prüfung nach WCAG oder was auch immer durchführt.

Da könnt ihr schon sehen, okay, da kriege ich jetzt nicht gleich alles um die Ohren gehauen, weil die Formularfehler nicht richtig beschriftet sind.

Wenn ich das schon weiß, dass ich das machen muss, dann kann ich das auch gleich überprüfen.

Und da brauche ich dann nicht mal ein Screenreader zu, wenn es nicht sein muss.

Also man sollte natürlich immer auch mit dem Screenreader testen, ab einem bestimmten Punkt gerade die Interaktion mit der Tastatur und wie das alles so zusammenspielt.

Aber so um die ganzen Basics abzudecken, das kann man dann mit dem Tool machen, ohne den Screenreader nutzen zu müssen.

So, woher bekommt der das alles?

Der Browser kennt ja die Webinhalte, die er darstellt. Logisch, sonst könnte er sie ja nicht darstellen.

Und das heißt, je besser das Markup, desto besser die Zugänglichkeit.

Denn wir machen das alles ja schon diejenigen, die in den Standards mitarbeiten seit über 20 Jahren.

Unter anderem deshalb, damit der Browser aus richtig semantisch eingestellten HTML-Elementen die richtigen Informationen ableiten kann.

Und zwar egal eigentlich welcher Browser. Ob das der Firefox ist, ob das Chrome ist, ob das Microsoft Edge ist.

Das Ziel ist, dass möglichst eine konforme Umsetzung erfolgt.

Dass ein P-Element eben immer ein Absatz ist oder die Logik zum Errechnen eines Namens, einer Beschriftung für einen Input immer die gleichen Voraussetzungen hat.

Dass die Browser eben da sich alle selber, nicht jeder sein eigenes Süppchen kocht, sondern das alles wirklich ähnlich wie bei anderen Dingen ja auch,

dann die Umsetzung möglichst einheitlich erfolgt. Das heißt aber auch, und jetzt komme ich ein bisschen an eine kleine Exkursion,

je besser das Markup schon von Anfang an da ist und das Wissen um das Markup, um die Möglichkeiten da ist, desto besser ist natürlich auch das Ergebnis.

Und hier muss ich mal kurz ausholen und sagen, ich bin jetzt da auf der technischen Seite der Umsetzung hier gerade beschäftigt mit dem Accessibility Inspector.

Das Ganze fängt aber schon viel früher an und es müsste, es müsste, und da sind wir alle in der Pflicht, da nehme ich mich überhaupt nicht von aus,

sondern und jeden von euch schließe ich damit ein, noch viel früher anfangen und zwar schon während der Universitätszeit.

Wir kriegen heute immer noch viele Absolventen von Universitäten in die Firmen, die nicht wissen, was H-Elemente sind,

die nicht wissen, dass man Tabellen vernünftig auszeichnet, die kennen ganz viele JavaScript und sonst wie Tod und Teufel Geschichten und so weiter.

Genauso bei Designern, Designer haben noch nie was von Kontrastverhältnissen gehört, die man braucht um vernünftig sehen zu können.

Die wundern sich dann manchmal selbst, wenn sie sich mit dem Smartphone in die Sonne stellen, dass sie bestimmte Dinge nicht lesen können, die sie selbst designt haben.

Warum? Weil die Kontraste nicht groß genug sind. Und warum nicht? Weil es ihnen keiner beibringt auf der Uni.

Und wisst ihr was? Wir predigen seit 20 Jahren, Leute, gebt euren Grafiken Alternativtexte, wir predigen seit 20 Jahren,

beschriftet eure Formularfelder vernünftig, wir predigen seit 20 Jahren Überschriftenstrukturen. Sollen wir das in 20 Jahren immer noch tun?

Wenn das so ist wie im Moment, tun wir das in 20 Jahren noch. Ich habe vor drei Jahren einen Blogbeitrag geschrieben,

der nannte sich The Web Accessibility Basics. Haben vielleicht einige von euch in meinem Blog auch gelesen.