WCAG 2 total Technikwürze 162

Technikwürze einhundertzweiundsechzig heute mit Dirk Ginader aus den USA.

Hallo.

Und in der Internethauptstadt Tomas Caspers aus Köln.

Hallo.

Herzlich willkommen zu Technikwürze, eurem Design und Webstandards-Podcast.

So, wir müssen uns ein bisschen beeilen, weil wir haben gestern gemerkt, dass Köln so, wenn alle aufstehen, nicht so viel mit diesem Internet zu tun hat. Der, Thomas sitzt da an einer kleinen Leitung in Köln, würde ich sagen. Wir schauen heute uns die, WCAG zwei Web Content Accessibility Guidelines an. Dirk, du darfst mal einen kleinen Einblick geben, was das Ganze überhaupt so ist und, womit wir es da zu tun haben.

Gerne. Anno 1999, hat die Web Accessibility Group, die erste WCAG eins damals rausgebracht und das war so der allererste Versuch,, Accessibility irgendwie testbar in, in, ein Dokument, zu pressen. Und das war '99. Das heißt, das war noch natürlich ein ganz, ganz anderes Internet und, viel war damals noch sehr, sehr anders. Zum Beispiel JavaScript war damals absolut uneingeschränkt böse.

Das heißt, offiziell war alles, was damals JavaScript war, nicht accessible und das, hat sich natürlich im Laufe der Zeit sehr verändert. Es, es war... Ja, Thomas, greif mal ein.

Soweit war das ja schon, schon korrekt. Also das war damals tatsächlich so 'ne, 'ne Situation, die eigentlich so für, zum Beispiel für, für, blinde Menschen vergleichbar war mit der, mit der Einführung von, von Microsoft Windows, wo dann ihre ganzen DOS-basierten Hilfsmittel alle nicht mehr mit klarkamen. Tatsächlich im Web da auch 'ne ganze Menge. Die Leute, spielten sehr viel rum, probierten aus, benutzten Dinge für, für Sachen, für die sie eigentlich nie gedacht waren.

Und diese, diese damals schon rasante Entwicklung, die sich in den letzten Jahren ja dann noch mal etwas beschleunigt hat, hat eben dazu geführt, dass, so typische Hilfsmittel von Menschen mit Behinderungen eben mit den damals aktuellen, Webinhalten nicht mehr oder nur sehr eingeschränkt, klarkamen. Und um das, um die Entwicklung ein bisschen zu bremsen, wurde eben von der, vom W3C dann, wurden dann diese Richtlinien entwickelt, um das Ganze ein bisschen in vernünftige Bahnen zu lenken.

Und wie der, wie der Dirk schon gesagt hat, das war halt eben 1999, und man hat damals, geplant, die, die Richtlinien, die damals auch teilweise schon zum Zeitpunkt der Veröffentlichung, na ja, so fast schon ein bisschen veraltet waren, regelmäßig zu aktualisieren. Und genau das ist nicht passiert, oder ist lange Jahre nicht passiert, bis, dann die neue, Guideline, überarbeitete Guideline rauskam, über die wir dann im, im weiteren Verlauf der Sendung noch ein bisschen schnacken werden.

Hat denn die erste Version in Deutschland überhaupt 'ne, 'ne Rolle gespielt?

Ja, hat sie. Nachdem die veröffentlicht wurde, ist dann eine Zeit lang später aus dieser WCAG oder WCAG eins, die deutsche BITV, die barrierefreie Informationstechnikverordnung geworden, die quasi 'ne, na ja, nicht ganz eins-zu-eins-Kopie, oder Übersetzung mit, mit ein paar kleinen Änderungen, Umsatzierungen und auch ein paar, kleinen zusätzlichen Fehlerchen, dann, zu 'ner, zu 'ner verpflichtenden Verordnung für, wie das im Gesetz heißt, für Träger öffentlicher Gewalt des Bundes.

Also alles, was irgendwie Bundesrecht ausführt, war daran gehalten, diese, diese Verordnung und damit eben die WCAG One, WCAG eins, einzuhalten.

Genau, also das ist schon heute noch gültig, richtig?

Das, das ist das große Problem. Das W3C hat die, die Guidelines aktualisiert, überarbeitet. Das war ein ziemlich langer Prozess. Werden wir gleich noch im Detail uns angucken, wie dieser Prozess genau abgelaufen ist. Und der Bund hat bisher nicht nachgezogen.

Könnt ihr, könnt ihr, um das ein bisschen greifbarer zu machen, mal ein, zwei Beispiele, aus, aus der ersten Version nennen, die, ja, dem, dem heutigen Stand einfach komplett widersprechen?

Ja, mein Lieblingsbeispiel, mein, mein absolutes Lieblingsbeispiel: Es gibt eine Vorgabe in, den alten Guidelines, dass, Formularfelder mit Platzhaltertext vorzubelegen sind. Also wenn man irgendwo 'ne Input type gleich Text hat, muss da, nicht nur, nicht nur ein Label davor, sondern auch in, in, in dem, in dem Wert schon irgendwas drinstehen. Das basiert da drauf.

Da hat mal ein schlauer Kopf, weil das beim W3C nicht dokumentiert ist, wodrauf diese, diese Anforderung überhaupt basiert, warum es die gibt, hat mal ein bisschen nachgeforscht und die basiert tatsächlich auf einem, Bug in einem Screenreader-, der, unter ganz bestimmten Voraussetzungen, ich meine, ich muss mal grad ein bisschen im Hirn graben. Das war, Alva Outspoken, also 'ne holländische Softwarefirma, was eh schon verdächtig ist mit, Netscape vier unter Mac OS sieben.

Yes.

Ja. Der hatte einen Bug, dass der, Formularfeld, also Input Type gleich Text und Text Area nicht erkannt hat, wenn da kein Text drinstand. Dann hat er die einfach nicht vorgelesen. Und da ist dann eine, eine, eine Richtlinie draus geworden, dass man eben zum, zum Umschiffen dieses Bugs, den, den, den Platzhaltertext verwenden sollte.

Es ist aber nicht dokumentiert, warum das so ist und das ist eigentlich mittlerweile obsolet ist und dazu kommt, dass dieser Screenreader in Deutschland nie aktiv vertrieben wurde. Also es, ne, holländischer Screenreader mit Mac OS sieben und Netscape vier. Und es, es, es wird, der Nachweis wird einfach schwierig sein, in Deutschland einen User nachzuweisen, der auf diese Barriere stößt.

Das hat der Bund dann aber einfach, einfach eins zu eins übernommen und da, das so in die BITV eins null reingeschrieben, wie bis heute gilt.

Das ist natürlich großes Tennis, denn, streng genommen- Denn streng genommen ist ja eigentlich ein vorgelegtes Formularfeld eigentlich eher Worst Practice, was das Ability angeht.

Ja, natürlich. Natürlich, klar. Das war, das führte dann dann wieder zu, zu, das hat 'nen ganzen Rattenschwanz an, an, an, wo sich Webentwickler dann die Köpfe zerbrochen haben und den Mund fusselig geredet haben und diskutiert haben mit, was passiert denn, wenn man das dann, wenn man den Cursor da reinsetzt und der, der vorbelegte Text wird nicht gelöscht, kriegst du ja automatisch dann, 'ne Fehlermeldung zurück, weil das dann keine gültige E-Mail-Adresse mehr ist, ne. Und solche Geschichten.

Also musst du irgendwelche Skripte entwickeln, die dann die Vorbelegung rausnehmen, sobald das fokussiert wird und sobald, es entfokussiert wird, wirst, musst du gucken, hat der Benutzer was eingefügt, oder, wenn nicht, dann schreib ich den Default Text wieder rein und so weiter und so fort. Also, ne? Das hat einen Riesengattenschwanz an, an, an, was müssen wir denn jetzt machen, um das alles möglichst sinnvoll zu erfüllen, nach sich gezogen.

Und das, der, die eigentliche Lösung wäre gewesen: streichen. Ja. Und das ist, das ist eben, lange Jahre nicht passiert, bis, bis dann, 2008 die, die,, aktualisierte Fassung, veröffentlicht wurde.

Hat es denn die, das Quasi Verbot von JavaScript auch noch in die heutige Zeit geschafft?

Ja, das ist de facto-

Das ist offiziell drin.

Das ist offiziell so drin. Also das, das de facto Verbot, es ist nicht verboten. Es sind nur alle sinnvollen Anwendungszwecke effektiv verboten. Also schönes Beispiel: Man muss, wenn man kann, man kann richtig groben Unfug machen mit, mit JavaScript, das ist erlaubt. Aber sinnvolle Sachen darf man nicht machen, weil man für JavaScript, immer einen statischen Fallback haben muss. Also man muss irgendwie gewährleisten, dass das Ganze, auch ohne JavaScript läuft.

Schönes Beispiel: Hier bei der Planung für diese Sendung haben wir Google Docs benutzt. Wie soll ich denn da bitte einen statisch, einen statischen Fallback machen, der ohne JavaScript funktioniert?

Ja, ein großes Formularfeld. Yay.

Ein großes Formularfeld. Super. Oder? Ja, Word aufmachen, ne?

Ja, ne? Und das das immer wieder rumschicken und mit der Versionskontrolle in Word dann. Also das ist, ne, das ist 'n, 'n wunderbares Beispiel für, für was Sinnvolles, was man mit JavaScript machen kann und was vor allen Dingen ohne JavaScript prinzipienbedingt nicht funktionieren kann. Da kann ich keinen statischen Fallback für bauen. Und das ist, tatsächlich, na ja, bis heute so in der, in der, in der Bundesverordnung zumindest.

In dem BCAG ja zum Glück nicht mehr, weil die sich ja, weil die aktualisiert wurden, aber in der Bundesverordnung ist es nach wie vor so drin. Ja.

Wie, wie wirken sich diese Relikte aus vergangenen Zeiten dann auf, moderne Webentwicklungen mit CSS aus? Oder wird man zu Tabellen gezwungen?

Mhm. Mach mal nur ganz kurz zurück an ein schönes Beispiel, wodrauf sich das, im, im Bereich, Webentwicklung und JavaScript auswirkt. Ist, ich muss mal gerade eben in meinem E-Mail-Ordner, genau. Der Bund, aktualisiert oder, oder entwickelt gerade einen, einen Bürgerclient, neuen elektronischen Personalausweis und ich weiß nicht, was alles, wo ich mich als Bürger gegenüber dem Bund in einer Form identifizieren kann.

Und die Entwicklung dieses Bürgerclient basiert, auf WCAG eins Komma null im Jahr 2010.

Yay.

Ja, muss man jetzt nicht weiter erläutern, glaub ich. Ich denke, das reicht einfach mal so als Schreckensszenario, ne?

Elf Jahre in unserem Traditionshandwerk, da passiert ja nicht viel.

Ja, das--

Kann ich mich mit dran erinnern. Also es ist ja grundsätzlich jetzt so, dass es eigentlich was viel Besseres gibt, denn die, die WCAG eins ist nun offensichtlich hinter uns und ist vollkommen veraltet. Die, die BITV ist leider noch nicht so weit. Es gibt aber die WCAG zwo, die sehr, sehr viele der alten Probleme eigentlich komplett, überarbeitet hat. Wie ist der Stand der BITV dahingehend?

Keine Ahnung. Das ist ein schwarzes Loch. -

Okay, da gibt's auch, da gibt's auch gar keinen Prog, Progress, der irgendwie angezeigt wird, sondern das ist-

Nein. Nee, es gibt, es gibt, es gab mal Äußerungen von, von den beteiligten Ministerien, dass also, spätestens im Jahr 2008 oder so die, die überarbeitete BITV an den Start gehen soll.

Oder schaffen wir?

Dann gab's mal 'ne Anfrage, ja, ja, da gab's mal 'ne Anfrage, 'ne offizielle Anfrage der Behindertenverbände an den Bund, auch an die Kanzlerin. Da hat dann ein Referent geantwortet, dass, die Kanzlerin guter Dinge ist, dass die bearbeitete BitV noch vor der Bundestagswahl, an den Start gehen soll. Er hat nicht dabei gesagt, welche Bundestagswahl.

Das war unmittelbar vor der Letzten. Also kann man jetzt raten, welche er meinte. Ja und dann, und dann wurde ja nach der Bundestagswahl munter umsortiert. Der, der zuständige Minister hat dann ja gleich,, gleich zweimal hintereinander gewechselt. Der, der neue Behindertenbeauftragte des Bundes ist jetzt auch seit ein paar Wochen erst, frisch im Amt. Und irgendwo dazwischen liegt das im Augenblick. Wo und wie der Stand ist? Keine Ahnung.

Ja, das ist natürlich bitter. Denn wie wir jetzt wissen und wie wir jetzt auch noch verkünden müssen, ist die WCAG zwei ja richtig gut geworden. Auch wenn's am Anfang auf dem Weg dahin ein bisschen tragisch aussah, die WCAG zwei enthält richtig gute Sachen. Können wir mal grob darauf eingehen, was zwischen WCAG eins und WCAG zwo passiert ist?

Also die, Grundvoraussetzung, das ist, glaube ich, das Wichtigste, was als, als Ziel ausgerufen wurde für die Entwicklung der WCAG zwei null war der, der, glaube ich, wichtigste Kritikpunkt einer alten Richtlinie, dass es im Prinzip nicht testbar ist, was da drinsteht.

Das sind alles hehre Ziele, die sich toll anhören und wo alle sagen können: "Ja, stimmt, sollte man so machen." Aber, aber wie das gemacht wird und vor allen Dingen, ob das in der Praxis wirklich so machbar ist, war mit der, mit der eins null, nicht, nicht wirklich nachweisbar. Also die war nicht, nicht verlässlich testbar. Wenn man da zwei Experten gefragt hat, hat man drei Meinungen gekriegt.

So ungefähr.

Ja, es gab immer diese tollen Test-Tools wie Bobby und- -Synthia und SES und so was.

Ja, ja, ja.

Das wurde auch immer gerne herangezogen als Beweis, dass es, tatsächlich zugänglich ist. Das ist natürlich total beinahe.

Ja, das ist, das ist ein etwas anderer Ansatz. Das ist diese,, ich sag's mal etwas flapsig, diese Cover-your-ass-Accessibility. Also, Ziel, Ziel der, der Accessibility-Anstrengungen in 'nem Webprojekt ist es, hinterher dann so 'n Bobby-Aufkleber auf die Seiten klatschen zu können, um dann sich entspannt zurücklehnen zu können, zu sagen: "Wir sind doch, Bobby-konform." Ne? Oder wir sind, WCAG, one double A, getestet und geprüft und so weiter.

Das Problem war aber, dass man damit maximal nachweisen können, konnte, dass man ein wie auch immer geartetes Prüfverfahren bestanden hat. Nicht, dass man tatsächlich auch zugänglich war, dass man also für Men, für Menschen mit Behinderungen, tatsächlich ein nutzbares Angebot ins Netz gestellt, sondern nur, damit war eigentlich nur nachweisbar, dass man das Prüfverfahren absolviert hat. Und das, das kann ja dann auch nicht der Sinn der Sache sein.

Es gibt sicher sehr viele, Entscheider in Unternehmen, die da sehr viel Wert drauf legen, dass hinterher das in irgendeiner Form, bestätigt und vielleicht sogar zertifiziert wird und so weiter. Aber das nützt natürlich da draußen dem Nutzer, herzlich wenig, wenn immer noch Barrieren da drin sind, wenn sich dann der Anbieter darauf zurückzieht. Warum? Wir haben doch diesen, diesen, diesen freundlichen Polizisten da auf der Seite kleben, ne. Was wollen Sie eigentlich?

Und das, das ist ein, ein, eines der größten Probleme, die man tatsächlich mit, mit der, der eins null hatte, dass die nicht, nicht wirklich verlässlich testbar war.

Und das war, um die Kurve zu der Frage zurückzukriegen, so die Grundvoraussetzung für, alles, was in der, in der zwei null drinsteht, dass das, was dort gefordert und beschrieben wird, auch tatsächlich in der Praxis umsetzbar ist und, einen, einen nachgewiesenen Nutzen für Menschen mit Behinderung und deren Hilfsmittel, sofern sie welche benutzen, hat. Und dass es, tatsächlich auch schon, schon Beispielimplementierungen dafür gibt.

Also es musste auch, alles, was da in den Guidelines drinsteht, muss, musste nachgewiesen werden, dass es irgendwer da draußen schon mal in der Form so gemacht hat, und der, der Ausgang, der Output dessen, was er da gemacht hat, ein positiver ist. Das ist der, der riesengroße Unterschied. Also alles, was da drinsteht, hat wirklich Hand und Fuß.

War die Anforderung, war die Anforderung an die zwei null, wirklich, dass es ja schon fast maschinenlesbar tech, testbar ist?

Nein.

Oder?

Das ist auch das große Missverständnis. Mit Testen, testbar heißt immer noch nicht, dass du einen Bot bauen kannst, wie damals Bobby, der deine Seite einliest und sagt ja oder nein, sondern mit testbar heißt es, es gibt einfach Regeln, mit denen du bzw. jemand anders gegen die Seite testen kann, manuell selber, ob das funktioniert, ja oder nein. Und das sind viele einzelne kleine Regeln.

Was ja auch extrem viel Sinn macht, weil dafür ist das Ganze dann doch, je nach Anwendungskontext zu individuell, um das einen Bot machen lassen zu können.

Ja, aber dafür sind, dafür sind, die, die Testanweisungen aber auch sehr gut formuliert. Also das ist das Schöne auch, das ist auch ein großer Unterschied zur eins null, dass es nämlich diese Testanweisungen gibt. Also wie, kann ich das überhaupt überprüfen, ob mein Webangebot das, was in Punkt so und so gefordert wird, überfüllt? Ist dann genau beschrieben, was ein Webangebot leisten muss, wie, welche Qualitäten es erfüllen muss und wie ich überprüfen kann, ob es diese Qualitäten erfüllt.

Das ist, das ist 'ne ganz feine Sache, sodass das im Prinzip im Idealfall, wenn man zwei menschliche Tester-, davorsetzt, müssen die zum gleichen Ergebnis kommen.

Okay. Kannst, kannst du da ein Beispiel nennen? Ein ganz einfaches? Alttexte?

No, das ist, das ist grad das schwierigste Beispiel, weil da, da wird's bei, bei Alternativtexten, also das, das reine Vorhandensein kannst du natürlich mit, mit Tools abprüfen. Also da, dafür brauchst du noch nicht mal ein spezialisiertes Accessibility Tool. Das sagt dir der HTML-Validator, ob Alt Attribut gesetzt ist oder nicht. Ob's leer ist, oder ob irgendwas drin steht, dafür brauchst du dann schon wieder spezialisierte Tools.

Ob's wirklich sinnvoller Inhalt ist, ist dann der relevante Teil.

Ob's sinnvoller, Inhalt ist und dann, jetzt fängt die Diskussion an: Was ist denn sinnvoller Inhalt? Ist es 'ne, 'ne, 'ne sehr kurze Beschreibung, die, ja wirklich nur das Wesentliche inform--,, transportiert? Oder ist es 'ne Beschreibung, die auch, wenn, wenn ich Bilder zu, zu, emotionalen Zwecken einsetze, ist der Text so, dass er auch die Emotion für den nichtsehenden Nutzer transportiert, Fragezeichen. Und da fängt dann die Diskussion an.

Und dann kommen eben mit modernen Techniken wie, wie, weiß ich nicht, WAI-ARIA und Ähnlichem, noch 'ne andere Dimension dazu. Da kann ich ja auch dann beliebige Texte mit Bildern verknüpfen und sagen: Aria described by und geb dann 'ne ID und sag, die, die zum Beispiel auf die Bildunterschrift zeigt und sagt: Da ist der Alternativtext.

Also weg von diesem klassischen Alternativattribut, versteckte Metadaten sind böse und, und vergammeln irgendwann und werden nicht so gepflegt, weil sie keiner sieht. Und deswegen eben dieses Aria described by zum Beispiel an ein Bild anhängen und das zeigt auf die Bildunterschrift, die jeder sieht. Hat für den blinden Nutzer den Vorteil, er kriegt's nicht zweimal vorgelesen, und es ist halt wirklich logisch verknüpft miteinander. Und da, da wird's dann natürlich schwierig.

Da brauchst du schon sehr hoch spezialisierte Tools oder halt den, den amtlichen Augenschein mit Blick in den Quelltext, der das versucht aufzudröseln. Oder tatsächlich, 'n, 'n, in dem Fall 'n Screenreader-Nutzer, der das testet.

Ja, das ist immer die instän-- sinnvollste Lösung. Jetzt haben wir gerade in dem Beispiel ein paar Sachen gehört, die wir noch nicht erklärt haben. Zum Beispiel WAI-ARIA und, labeled by Attribute.

Das darfst du machen.

Das darf ich machen. Okay, ich, ich glaub, wir haben trotzdem 'n paar Sachen übersprungen, die eigentlich, sinnvoll wären zum weiteren Aufbau. Zum Beispiel erst mal die, die vier Richtlinien, die eigentlich das Ganze grob umschreiben, erst mal grob erklären, um dann zu gucken: Wie können denn die Mittel, die wir gerade genannt haben, überhaupt dahingehend angewandt werden?

Die, die vier Richtlinien, die's tatsächlich überhaupt nur gibt in WCAG zwei sind: Es soll A wahrnehmbar sein, es soll B bedienbar sein, es soll-

Das sind die Prinzipien.

Sorry? Die Prinzipien?

Ja, ja, die Richtlinien kommen da drunter.

Okay, mein Fehler. Okay, die Prinzipien sind wahrnehmbar, bedienbar, verständlich und robust. Und das ist eigentlich alles, wogegen in allererster Linie mal validiert werden kann. Ist es wahrnehmbar? Ist es bedienbar? Ist es verständlich robust? Und da drunter gibt es dann jeweils detailliertere Richtlinien. Das sind die Richtlinien, richtig?

Das sind die Richtlinien, ja. Das sind dann irgendwie zwölf oder dreizehn Stück, die dann da drunter kommen, ja.

Genau, und die haben dann wiederum jeweils selbst noch mal Prüfmechanismen. Ist das auch das richtige Wording?

Techniken, mit denen man die erfüllen kann. Eigentlich.

Okay. Und, dann sind wir nämlich auch schon bei, bei so was wie, Textalternativen und bei so was wie, WAI-ARIA labeled by. Denn wie kann man dafür sorgen, dass ein Text entsprechend wahrnehmbar ist, dass er einem Bild zugeordnet ist? Und, es gibt eben diese, Technik oder diese, dieses neue Set von, von, semantischen Auszeichnungen für den Inhalt, die als WAI-ARIA bezeichnet werden können.

Das ist grundsätzlich dafür gedacht, dass Rich Internet Applications, also das IA, das RIA in, in WAI-ARIA, dass die in allererster Linie mal auch zugänglich sein können. Das ist ohne WAI-ARIA möglich, allerdings nur mit, mit, sensationellen Kunstgriffen.

Und, das, was WAI-ARIA ermöglicht, ist tatsächlich, dass interaktive Elemente auf der Seite, Elemente, die sich auf der Seite verändern, während der Nutzer dabei ist, dass diese, Informationen in Echtzeit an den Nutzer weitergeliefert werden können. Und das ist tatsächlich das, was, die, die, diese neue Technik komplett ausmacht. Und das Schöne ist, dass es tatsächlich auch schon weitestgehend implementiert ist. Noch nicht überall, aber schon ziemlich weit.

Grade 'n, klassisches Beispiel ist, ist das, Live Update, das auch immer wieder gern genutzt wird. Wenn man sich einfach nur das, Twitter-Eingabefeld vorstellt mit dem Counter, der runterzählt und dich informiert, wie viel Zeichen noch übrig sind. Das ist was, was ohne WAI-ARIA eigentlich quasi nicht handelbar ist für 'n Screenreader-Nutzer. Und, das ist genau das, was tatsächlich dem Moment, ermöglicht wird, dass, Information in 'nem Kontext weitergegeben wird.

Hast du noch ein schöneres Beispiel als das?

Nö, das ist eigentlich schon, schon ein sehr schönes. Es gibt, es gibt natürlich jede Menge andere Sachen, wo, wo WAI-ARIA versucht,, Löcher in der, in der, nach wie vor aktuellen HTML-Spezifikation zu stopfen. HTML vier, ist ja, ist ja auch so 'n bisschen mit der heißen Nadel gestrickt worden. Und es gibt sehr viele, Elemente, die mittlerweile im, im, modernen Webdesign gang und gäbe sind, die in HTML einfach gar nicht vorhanden sind.

Weil, weil niemand dran gedacht hat, man bräuchte auch mal so was wie einen Schieberegler zum Beispiel oder ähnliche Geschichten. Und das, das versucht eben WAI-ARIA zu umgehen, indem es diese Löcher stopft und über, über bestimmte, Attribute, dem, dem Screenreader noch mehr an, an Informationen, mitzugeben, die er bisher entweder gar nicht gekriegt hat, wie eben bei diesem Schieberegler oder dir, wo, wo der Nutzer gefragt war, sich das irgendwie aufzudröseln.

Also Beispiel, schönes Beispiel diese Landmark Rolls, die man, die man wirklich gefahrlos mittlerweile überall einsetzen kann, weil sie, nicht wehtun und sehr viel Gutes machen, die zum Beispiel dazu da sind.

Es, es gibt in HTML kein, kein Element, wo man nicht sagen kann: „Hallo, ich bin die Navigation.", und diese Landmark Rolls gehen halt hin und, und hängen an beliebige Elemente, ein zusätzliches Attributwerte-Paar dran mit Roll Equals Navigation, wo dann den modernen Screenreadern mit geeigneten Browsern klar wird: Aha, alles innerhalb dieses Blocks ist jetzt tatsächlich die Navigation der Seite. Bisher musste sich der Nutzer das irgendwie aufdröseln.

Wenn ich da eine Liste habe, wo ganz viele Links drinstehen, ja, das könnte die Navigation sein, also höre ich die mal durch, oder mit versteckten Überschriften und ich weiß nicht, was für komische Konstrukte es da alles gibt und so. Und das wird damit halt wesentlich vereinfacht. Und wir kommen gerade so ein bisschen von der WCAG weg, ne. Also ich meine, ARIA ist natürlich, ist natürlich schon ein geiles Thema, da kann man wirklich feine Sachen mit machen.

Und man kann und das ist das Schöne, um jetzt die Kurve wieder zu kriegen, man kann WAI-ARIA eben auch benutzen, WCAG zwei zu erfüllen. Das ist nämlich noch eine weitere Neuerung bei den, bei den, bei der zwei null, dass die im Prinzip auf der Ebene der, der Prinzipien und, und, und Guidelines komplett neutral gegenüber den verwendeten Techniken ist. Da steht nur, was der Dirk gerade eben schon gesagt hat, mit wahrnehmbar, bedienbar, verständlich, robust.

So Ding, paar grobe Ziele drin, auf die wir uns alle ohne lange Diskussion einigen können. Das muss einfach so sein. Brauchen wir auch gar nicht lang drüber diskutieren.. Und darunter die Guidelines, die da stehen, also wie zum Beispiel, weiß nicht: Stellen Sie Text in, stellen Sie Textalternativen für Nicht-Text-Inhalte zur Verfügung.

Ist auch was, wo man nicht lange drüber diskutieren müssen, wo aber noch nicht und das ist der große Unterschied zur, zur eins null, wo noch nicht beschrieben ist, was man dann machen muss. In der eins null waren sehr viele Sachen, wo, wo das, na ja, bis, bis auf fast bis auf Code Listings sehr granular beschrieben wurde, wie HTML auszusehen hat, um die Verordnungs- oder die, die Guidelines zu erfüllen. Das ist jetzt in den, in den, zwei null überhaupt nicht drin.

Da sind die ganzen beschreibenden, die ganzen Techniken, mit denen man die Guidelines erfüllen kann, komplett ausgelagert in Techniques Documents. Das hat den enormen Vorteil, das ist eine ganz elegante Lösung, dass man, dass man da jetzt natürlich beliebige Techniken nehmen kann, um versuchen nachzuweisen, dass man jetzt eine Guideline erfüllt hat.

Und man muss, man ist nicht nur darauf angewiesen, jetzt die Guidelines, die Techniken zu benutzen, die das W3C quasi so als so vorgefertigt schon mal veröffentlicht hat, sondern man kann sich selber auch Techniken ausdenken, von denen man glaubt oder von denen man im Ernstfall den Nachweis erbringen kann, dass sie geeignet sind, um eine Richtlinie zu erfüllen.

Vor allem bekommt man, wenn ich das jetzt richtig verstanden habe, auch eine Art, ja, Wartbarkeit hin. Weil dadurch, dass die, die Guidelines selbst von den Techniken losgelöst ist, losgelöst sind, ist es ja auch möglich, dann kommende Techniken auf die bestehenden, Guidelines anzurichten.

Genau, genau deswegen meinte ich das mit, mit WAI-ARIA, die, die nirgendwo in den Guidelines erwähnt werden, die ich aber benutzen kann, um eben, bestimmte Dinge zu erfüllen. Ne? Und wenn jetzt nächste Woche irgendwer kommt und er findet was ganz Tolles, dann kann er das auch benutzen. Und das, das ging eben mit der, mit der eins null nicht. Da musste man eben sich drauf beschränken, was da dokumentiert war und die Dokumentation war wie gesagt sehr mager, und mehr ging da nicht.

Alles andere war effektiv verboten.

Und das über neun Jahre lang.

Und das über neun Jahre lang. Gut, es hat, es hat zum Glück, nicht, nicht, kaum einen gekümmert am Schluss dann mehr, weil, weil ich denke, jedem professionellen Webentwickler war klar war, damit geht es nicht weiter.

Ja, absolut. Ist die Idee von dem Techniques-Document, dass das natürlich auch weiterwächst, dass das weiter gepflegt wird? Gibt es da schon neue Dinge, die dazu kommen?

Also die werden, die werden turnusmäßig überarbeitet und, und wenn man, wenn man, also das W3C ist, ist auch eine eigene Aussage sehr dankbar dafür, dass man selber auch Techniques, entwickelt, veröffentlicht und an das W3C weiterreicht. Die werden dann, wenn sie gut sind, eventuell bei nächsten Überarbeitungsschritten mit in die Techniques Documents aufgenommen. Das ist auch ein sehr offener Prozess. Das heißt, man kann da auch mitarbeiten.

Wenn ich mir jetzt morgen irgendwas Tolles ausdenke, kann ich das, ausformulieren. Muss es natürlich ins Englische übersetzen und an das W3C weiterreichen und mal gucken, ob die das auch so klasse finden. Also eine sehr offene Geschichte.

Das ist sehr schön.

Das macht dann, dann richtig Spaß dann, ne.

Auf jeden Fall.

Ja, wollen wir mal- Wollen wir uns die einzelnen Guidelines mal anschauen?

Sehr gerne.

Wer möchte?

Ja, fang ich doch ein, fang ich doch einfach mal an mit, dem er, dem ersten, der ersten Guideline, der ersten Richtlinie, die der, die wahrnehmbar zugeordnet ist. Die erste Richtlinie dazu ist: Stellen Sie Textalternativen, gerade drüber gesprochen, für alle Nicht-Text-Inhalte zur Verfügung, sodass diese in andere vom Benutzer bevorzugte Formen geändert werden können, wie zum Beispiel Großschrift, Braille, Symbole oder einfache Sprache.

Das ist an, an sich schon so einfach formuliert, dass es eigentlich gar keine Missverständnis mehr zulässt und dennoch gibt's dazu eben auch noch die einzelnen, Techniken, die angewendet werden können. Aber es ist dahingehend schon mal ganz klar, dass, wenn irgendetwas da ist, das nicht Text ist, muss eine Alternative da sein. Was das dann ist, haben wir gerade diskutiert, ist dann natürlich wieder diskussionswürdig und wie inhaltsvoll das Ganze ist.

Und dann gibt's auch noch, die Erweiterung dazu. Das ist dann der zweite Punkt von wahrnehmbar. Das ist die: Stellen Sie Alternativen für zeitbasierte Medien zur Verfügung. Das ist schon gar nicht mehr so einfach, aber auch da habe ich jetzt schon Implementierungen gesehen, die, auf, auf, Time Codes basieren und, Videoinhalte noch mal in Textform wiedergeben.

Ich glaube, wir müssen zuerst noch mal ganz kurz, erläutern, was wirklich zeitbasiert, was alles zu den zeitbasierten Medien fällt. Also ist es, ist es nur Audio und, Video oder?

Nicht notwendigerweise. Also ich könnte mir auch so was wie eine Slideshow vorstellen. Das Slideshare macht da eine ganz, nette Implementierung mit so einem Alternativtext. Es gab früher mal diese, diese, Präsentationsmedien, ich weiß nicht, ob das heute noch eine Alternative darstellt, aber ich denke, die Formulierung zeitbasierte Medien ist deswegen so abstrakt gehalten, weil das etwas ist, was eben auch noch sich verändern kann. Da fällt wahrscheinlich auch noch so was wie Flash drunter.

Auch wenn's im Zweifelsfall, von Haus aus selbst, zugänglich sein kann, muss dafür eine Alternative da sein. Ich grüble jetzt gerade. Gibt's noch irgendwas, was offensichtlich zeitbasiert ist?

Ja, so die klassischen, die klassischen Director Shockwave, irgendwas Anwendung Multimedia CDs, der, der Neunziger Jahre und so solche Geschichten. Fallen natürlich auch dadrunter, ne. Das, das, die sind damit natürlich dann auch prüfbar. Das Schöne ist, das ist in den, in den Richtlinien auch alles erklärt.

Also das ist,, ich erinnere mich da an, an einen Spruch von, von, Shadi Abou-Zahra von der, von der, von der Way, der sagt, es kann nicht genug zu, oder es kann nicht zu viel Dokumentation geben, sagt er immer, wenn, wenn, wenn jemand den Umfang der Richtlinien kritisiert. Ich find, ich find, da hat er recht, weil, da von den, von den Richtlinien aus, wirklich jeder einzelne Punkt mit, mit erklärenden Texten, dekoriert ist und, und überall gibt's Links.

Also neben in den Guidelines selber, steht bei den Richtlinien, genau der Punkt, wo grad die Nachfrage kam, was ist denn eigentlich zeitbasierte Medien?, ist rechts noch mal so ein kleiner Link, der heißt dann einfach,, Richtlinie eins zwei verstehen.

Und da ist dann noch mal erklärt, was ist damit gemeint, also nur Video oder nur Audio oder Audio und Video oder Audio Video kombiniert mit Interaktion und so weiter, in Listenform und dadrunter noch mal in, in, in sehr viel Prosa noch mal, was alles dadrunter fallen könnte. Also ist da auf der, auf der Ebene der Richtlinien ist schon sehr viel Dokumentation und Erklärungstext vorhanden, um eben, na ja, das, das abzufangen, die Frage: Was, was ist denn zeitbasierte Medien und so weiter.

Und genauso setz, setzt sich dann fort, in den einzelnen Punkten, die den Richtlinien zugeordnet sind, also bei eins zwei eins und eins zwei zwo Untertitel und so weiter, steht dann, was, was heißt das eigentlich? Also wie kann ich das verstehen, was da mit, mit, Untertitel gemeint ist und wie kann ich das erfüllen? Gibt's auch wieder Links zu, zu, weiterführenden Dokumenten. Da wäre jetzt eigentlich, wenn mir das erlaubt ist, ein bisschen Platz für Eigenwerbung.

Ja, gerne.

Nein, das ist, das ist,, die, das ist nicht Eigenwerbung, sondern, sondern, für einen lieben Kunden von mir.

Die Aktion Mensch hat, Mitte letzten Jahres, oder eigentlich Anfang letzten Jahres, als klar war, dass der Bund irgendwie nicht in die Füße kommt mit, mit der 420 und dass Webentwickler ziemlich ins Rudern kommen und nicht wissen, wie machen sie denn jetzt bitte webbasierte Applikationen und moderne Webanwendungen zugänglich, beschlossen, dass die WCAG 2.0 doch mal dringend ins Deutsche übersetzt werden musste.

Die ist mittlerweile veröffentlicht, ist auch von den, englischen Guidelines aus gibt's oben im Kopf der Dokument, der Dokument, des Dokuments gibt's einen Link zu Translations. Von da aus ist es auch verlinkt neben sehr vielen anderen, Übersetzungen. Es gibt mittlerweile Spanisch, Italienisch, Französisch ist fertig. Brasilianisch, Portugiesisch glaube ich, ist auch fertig, Ungarisch. Also in, in, in sich, Sprachen sind die Guidelines mittlerweile übersetzt und eben auch in Deutsch.

Die Guidelines sind aber nicht, nicht, alles, bei dieser, bei dieser Übersetzungsaktion, sondern die ganzen Understanding WCAG-Dokumente werden im Augenblick auch noch übersetzt. Also alles, was ich eben erzählt hab, da ist ein Link, da wird's weiter erklärt, wird's, im Laufe dieses Jahres auch in Deutsch geben.

Oh, super.

Das ist, 'ne, 'ne wirklich 'ne großartige Ressource, wo man, wo man auch deutschen Webentwicklern das ausdrucken, auf den Tisch knallen und sagen: Da. Lesen, machen. Und da fallen dann jede Menge Ausreden weg mit: Ich versteh kein Englisch und ist alles so kompliziert.

Und das ist wirklich dann, weil es, weil es in den, in den ganzen weiterführenden Dokumenten auch nicht mehr diesen, diesen fürchterlichen normativen W3C-Sprech hat, den, den, auch englische Muttersprachler im englischen Original schon kaum verstehen, ohne dauernd irgendwie im Glossar nachgucken zu müssen. Das, das muss aber so sein. Das soll auch keine Kritik an den, an den Guidelines sein.

Das muss einfach sein, weil es ein, ein, ein wirklich stabiles, referenzierbares, normatives, Dokument sein muss-, deswegen sind eben manche Formulierungen in den Guidelines selber, etwas verschwurbelt, ums mal vorsichtig auszudrücken. Aber da diese ganzen Techniques keine normativen Dokumente sind, sondern eben nur freundliche Informationen der, der Arbeitsgruppe, sind die wesentlich lesbarer.

Und die werden natürlich dann in der deutschen Übersetzung auch noch mal wesentlich lesbarer gemacht, weil wir da nicht durch den, durch den Ding, diesen normativen Prozess durchmüssen, wo wirklich an, an, an, jedem Punkt und Komma gefeilt wird. Das soll's mit der Eigenwerbung erst mal gewesen sein. Danke.

Super.

Ich fand, das war sehr gute Eigenwerbung.

Das war sinnvolle Eigenwerbung. Muss auch mal kurz drauf hinweisen: Was wir bislang zitiert haben, war ja alles schon deutsch. Das heißt, es war alles schon basierend auf dieser Aussage und das zeigt auch wieder einen ganz großen wesentlichen Unterschied zwischen WCAG eins und WCAG zwei auf. WCAG eins gibt's nicht in Deutsch und die BITV ist-

Doch, doch, doch, gibt's, gibt's, gibt's, aber die war nicht normativ. Also es gibt, gab 'ne Übersetzung, aber die war nicht autorisiert. Und das ist der große Unterschied. Die, die Überset-- Und deswegen waren in der deutschen Übersetzung dann noch mal so ein paar kleine Fehlerchen drin. Oder der war halt, die Übersetzung war nicht in der Qualität, die ein normatives Dokument haben muss.

Die, Übersetzung, die, Aktion Mensch initiiert hat, die ist tatsächlich ein, ein gleichrangiges normatives Dokument. Das ist also wirklich 'ne, das ist die deutsche Sprachversion des englischen Originals und ist, ist durch den, durch den gleichen Prozess gelaufen wie die Guidelines selber auch mit, mit, jeder Menge interner Beta Releases, die von der Arbeitsgruppe, begutachtet wurden und 'ner öffentlichen Kommentierungsphase, wo das ins Netz gestellt wurde.

Und dann wurde die gesamte Fachöffentlichkeit gebeten, noch mal draufzugucken, Verbesserungsvorschläge zu machen. Da mussten ganz strikte Schritte eingehalten werden, um hinterher sagen zu können, das ist jetzt ein, ein Dokument, was gleichrangig zum englischen Original ist, also wirklich auch, ja, quasi ein normatives Dokument. Das eigentliche normative Dokument ist immer das Original, aber es kann eben referenziert werden, weil's stabil ist und nicht mehr verändert wird.

Ja, genau. Vielleicht kann man an der Stelle auch grad noch mal kurz drauf hinweisen. Ich weiß, du hast es grade als, als Eigenwerbung verkauft, hast dich aber da selbst nicht eingeschlossen. Auch auf dem deutschen Dokument steht ein Name und das ist deiner. Also nur mal kurz zur Info, warum du dich so gut damit auskennst. Du hast das tatsächlich gemacht. Vielleicht mal ganz kurz da ein bisschen Credits für dich. Ich weiß nicht, nur du oder deine Frau auch?

Meine weitaus, meine weitaus bessere Hälfte auch, weil, die, Englische oder Amerikanistik, Literaturwissenschaften in, in, studiert hat, und etwas wesentlich besser Englisch spricht als ich. Also die war eine große Hilfe. Die hat im Prinzip die ganze, wie man im Englischen sagt, Grundwork, gemacht.

Sehr schön.

Dafür noch mal danke, falls du zuhörst.

Ja, auch, auch von meiner Seite.

Ein, ein großes Dank aus großer Runde.

Auf jeden Fall.

Wollen wir uns weiter durcharbeiten?

Ja, können wir gerne machen.

Ganz gerne. Dann-

Eins drei.

Genau, die sagt: Erstellen Sie Inhalte, die auf verschiedene Arten dargestellt werden können, zum Beispiel mit einfachem Layout, ohne dass die Informationen oder Strukturen verloren gehen. Und auch das eigentlich wieder so formuliert, dass klar ist, was erreicht werden muss und dann eben die Fragen: Was ist das jeweils?

Und, das Erste, was einem in den Kopf kommt, ist natürlich einfach ein HTML-Dokument, das, mit verschiedenen Styles in unterschiedliche Darstellung gebracht werden kann, um den unterschiedlichen Anforderungen gerecht zu werden, wie zum Beispiel deutlich größere Texte, andere Farbschemata. Fällt dir noch was anderes dazu ein?

Mobile Devices zum Beispiel, ne. Oder halt, oder eben um, na ja, ein legitimes Ausgabemedium ist auch ein Lautsprecher zum Beispiel.

Stimmt.

Ja. Oder was auch immer. Das ist ein schönes, das ist-- Daran sieht man auch schön an diesem Beispiel den Unterschied zur, zur WCAG eins wieder ab, wo, wo in der, auch nach wie vor in der BITV drinsteht irgendwie, : Ja, wenn Sie, wenn Sie, Layout-Tabellen verwenden, dann stellen Sie sicher, dass diese irgendwie linearisiert noch, sinnvoll sind. Also das ist, wenn man, wenn man die Inhalte der Tabellenzellen nacheinander vorliest, dass es irgendwie noch einigermaßen sinnvoll ist, ne.

Da, da haben wir A den Punkt, da ist schon 'ne, 'ne bestimmte Technik direkt in den Guidelines genannt, was doof ist, weil nicht aktualisierbar. Und es ist eine komplett veraltete Technik genannt. Und hier bei den, bei den, bei den neuen Guidelines steht eben nur, dass man Inhalte so erstellen soll, dass der Benutzer oder der User Agent, sie in irgendeiner Form anpassen kann, ohne dass, dass ihm Informationen oder, Strukturen oder Ähnliches verloren gehen.

Also da wird auch wieder komplett neutral gegenüber der verwendeten Technik, und damit offen für alles, was man, was man, na ja, jetzt oder in Zukunft machen kann. Dass damit jetzt im Kontext Webdesign gemeint ist, nimm HTML für die Struktur und CSS fürs, für, für die Optik und, und JavaScript fürs Verhalten, ist dann, ist dann wieder in, in den Techniken beschrieben.

Das, das kommt dann, das steht nicht in den Guidelines selber, son-sondern erst dann in den, wie kann ich denn Punkt eins, Punkt drei, Punkt zwei, erfüllen? Da, da steht es dann drin. Also nimm CSS und nimm, bau sauberes HTML und so weiter und so fort.

Und auch das kann in Zukunft natürlich dann alles sich noch mal ändern. Wenn dann das ganze Internet irgendwann komplett in Flash gebaut wird, ist auch das dann irgendwann

Ja, natürlich. Ja, wobei natürlich du mit dem schnellsten Flash das Problem hast, da eine Struktur reinzukriegen, ne. Das geht bis heute nicht so wirklich.

Stell dir jetzt komische Beispiele. Das war absichtlich.

Ja gut. Okay.

Okay, ich denke, es war auf jeden Fall klar verständlich.

Mhm. Ja, auch, auch, bei dem, bei dem nächsten Punkt ist auch wieder ein, ein schöner Unterschied zur, zu alten Guidelines. Da bei den, bei den alten Guidelines, stand nur drin irgendwie: „Nehmen Sie ausreichenden Kontrast.", super. Was ist jetzt bitte ausreichender Kontrast? Stand nirgendwo, ne.

Und dann ging die Diskussion los: „Aber ich sehe das nicht und meine Oma sieht das auch nicht." Und, und das ist, in der, in der, in den neuen Guidelines, gibt es tatsächlich, Algorithmen, mit denen ich das berechnen kann. Habe ich einen ausreichenden Kontrast zwischen, Vorder- und Hintergrundfarbe oder, zwischen Vorder- und Hintergrundgeräusch zum Beispiel auch bei Audioinhalten, ne.

Was für Menschen, die, die,, nahezu gehörlos sind oder sehr extrem schwerhörig, oder bestimmte andere, Formen der Behinderung haben, schwierig wird, Hintergrund- von Vordergrundgeräuschen zu differenzieren, wenn ich eine Audioaufnahme mit, mit, mit Verkehrslärm im Hintergrund habe und so weiter. Und da wird wirklich auch in, in Dezibel muss das Hintergrundgeräusch um so viel Dezibel geringer sein als das Vordergrundgeräusch, damit ich das, auch akustisch differenzieren kann.

Also nicht nur Farbe und, und, und, Helligkeitskontrasten, sondern auch, auch, auch auf Audio bezogen.

Genau, die Formulierung macht das auch, auch wieder deutlich klarer. Die ist nämlich einfach nur: „Machen Sie es für den Benutzer leichter, Inhalte zu sehen und zu hören, einschließlich der Trennung zwischen Vordergrund und Hintergrund." Es wird nicht mehr darauf eingegangen, dass das jetzt in dem Fall ausschließlich der Kontrast sein muss, sondern es ist grundsätzlich: Mach es leichter verständlich, mach es wahrnehmbar.

Ja, und das kann, das kann ja auch letztendlich, das, das kann auch ein, weiß ich nicht, ein transparentes vierundzwanzig-Bit-Ping über einem gemusterten Hintergrund sein oder sonst irgendwas, ne. Also das ist nicht nur, nicht nur,, Link-Farbe zur Hintergrundfarbe, ausreichender Kontrast, sondern, sondern beliebige Inhalte, ne, die in irgendeiner Form wahrgenommen werden müssen und solche Geschichten.

Ganz genau. Damit kommen wir auch zu dem zweiten Punkt in der Reihe. Nach wahrnehmbar ist der zweite Punkt nämlich bedienbar. Das ist so ungefähr mein Lieblingspunkt.

Ja, oh ja, meiner auch. Ja, vor allen Dingen ist der so einfach zu testen, ne. Das ist wirklich so, so herrlich einfach. Maus aus und fertig, ne. Das ist-- Also wirklich einfach mal 'ne, 'ne Web-App laden und, und, die versuchen, nur per Tastatur zu bedienen. Und oh Gott, oh Gott, ne. Da geht meistens irgendwas schief, ne, oder man hängt dann irgendwo drin fest und kommt nicht mehr raus und, und ähnliche Geschichten, ne.

Also das, das ist eigentlich was, was, wo man, wo man keine, Accessibility-Experten braucht, um, um das, das zu testen, sondern das, das ist wirklich was, was jeder Webentwickler selber, testen kann.

Auf jeden Fall. Da braucht man auch kein Screening dafür, kannst du dir eben-

Nee, nee. Das ist was, das bringt jeder Computer, sobald ich den anschalte, bringt der die Testumgebung mit, ne. Weil Tastatur haben sie alle.

Genau. Und das ist auch nicht zwingend nur im, im, im Kontext von, Barrierefreiheit, sondern es ist einfach nur: Können meine Nutzer das bedienen? Kann ich das bedienen, wenn ich das und das mache? Und es ist wirklich einfach gesunder Menschenverstand und es ist so einfach zu testen. Zum Beispiel der Punkt, der erste Unterpunkt unter bedienbar fragt nach: Sorgen Sie dafür, dass alle Funktionalitäten von der Tastatur aus verfügbar sind. Und es ist nichts einfacher als das.

Leg die Ta--, Maus zur Seite, wie du es gesagt hast, und nutz die Tab-Taste. Und wenn das klappt und wenn es nicht nur irgendwie klappt, sondern wenn auch noch das Ganze sich sinnvoll anfühlt und du dich mit, mit gegebenem Anlass auf die richtigen Elemente im, im deiner Seite hinbewegen kannst, dann ist das eine richtig schöne Sache für jeden Nutzer, nicht nur für irgendwelche Behinderten.

Ja, also die einzige, das einzige Wissen, was man haben muss, ist, eigentlich, welche, welche Tastatur-Shortcuts brauche ich, um irgendwelche Elemente zu bedienen. Also nur Tab geht natürlich nicht, weil, damit kann ich halt eine Seite nur durchtabben, aber ich kann in einem Formular keine Elemente bedienen. Also da brauche ich dann auch, Pfeiltasten und Leerschritt und Enter und ich weiß nicht was alles. Also das muss man schon wissen, dass man eine Checkbox mit der Leertaste an- und ausmacht.

Das ist aber letztendlich die einzige Voraussetzung, die man, die man als, als Webentwickler, als Tester seiner eigenen Applikation oder anderer Applikationen, wissen muss. Ein bisschen wie: Wie funktioniert tatsächlich Tastaturbedienung? Welche, welche Shortcuts muss ich drauf haben? Ja.

Das ist richtig, aber das, das ist auch alles, kein exklusives Wissen-

Nein, nein.

-denn wenn man sein Betriebssystem bedienen kann, dann ist das sinnvollerweise genau der gleiche Vorgang.

Ja, RTFM.

Ja. Muss man das übersetzen? Ich denke-

Nein. Es hören ja auch Kinder zu. Also insofern... Ja.

Okay, der zweite Punkt zu bedienbar sagt: Geben Sie den Benutzern ausreichend Zeit, Inhalte zu lesen und zu benutzen.

Ähnlich wie Punkt eins auch wieder was, was, nicht nur auf behinderte Menschen anzuwenden ist.

Auf gar keinen Fall. Und das spielt auch wieder so ein bisschen auf die grundsätzliche Zukunftskompatibilität hin, denn- Dem Nutzer Zeit geben zu lesen spricht halt auch so ein bisschen auf Interaktivität hin. Es spricht wieder ein bisschen auf zeitbasierte Medien hin. Grundsätzlich ist es einfach sinnvoll, sich selbst tatsächlich dem Inhalt mal auszusetzen. Ich, ich kenne das immer wieder, dass der Entwickler eine Seite baut, aber eigentlich nicht wirklich liest.

Ich nehme mich da selbst nicht aus. Und wenn man sich einfach mal hinsetzt und, die Seite wirklich versucht aufzunehmen und tatsächlich zu verstehen, dann, ist genau dieser Punkt eigentlich, sinnvoll. Denn je nach Komplexität des Contents ist es durchaus relevant, sehr, sehr lange lesen zu können.

Ja, und da sind wir eben sehr schnell in dem Bereich, wo es dann nicht mehr nur was mit, mit auch ni-nicht unbedingt zwangsweise mit einer kognitiven Behinderung zu tun hat, sondern einfach auch, mangelnde Medienkompetenz oder, mangelnde, mangelnde Erfahrung mit einem Thema, in das ich mich gerade einlese, wo ich, wo ich einfach Zeit brauche, um das zu verstehen und so weiter, ne?

Also da sind wir dann sehr schnell in den, in den Bereich, wo, strikte Vorgaben für die Accessibility für Menschen mit Behinderung auch positive Auswirkungen auf, auf die Gesamtbevölkerung haben und auf sämtliche Webnutzer, ne.

Auf jeden Fall. Ich kann nur empfehlen, jeden Mal irgendwie 'ne, 'ne, 'ne Seite über spezifische Finanzdaten zu lesen. Das ist momentan mein Beruf und ich verstehe die Hälfte davon, wenn ich es im Schnelldurchfliege und die Zeit muss ich mir nehmen und das geht anderen mit anderen Themen eben ganz genauso.

Was, was da auch wieder ganz, ganz schön zu sehen ist, wie, wie, nah an der Realität die, die einzelnen Richtlinien sind. Es gibt nämlich bei diesem Punkt, dass es keine, keine zeitliche Begrenzung bei irgendwas geben sollte, nämlich auch ein paar durchaus legitime Ausnahmen, die für viele Anbieter sehr, sehr wichtig sind.

Also ich hatte das bei einem konkreten Projekt für 'ne, für 'ne große Bundesbehörde, wo der Benutzer, dann nach einer gewissen, Zeit aus, dem System wirklich zwangsweise ausgeloggt wurde, weil ansonsten, da, datenschutzrechtliche Beden-Bedenken entgegen gestanden hätte, dass zum Beispiel der Arbeitgeber des, des Nutzers hätte sehen können, was der da macht, was, was nicht gewollt war. Und da-das sind durchaus legitime Ausnahmen.

Also wenn datenschutzrechtliche Bedenken, bestehen, dass, einem Benutzer endlos Zeit ge-gegeven wird, Inhalte zu, zu lesen und zu benutzen, dann, dann, haben die, die datenschutzrechtlichen Bedenken oder, oder die, die gute Ausrede, die, die vernünftige Ausrede, die man haben kann, gegen eine solche Begrenzung auf jeden Fall Vorrang. Das ist also, also unter den, unter der Version zwei Punkt null, der Richtlinien durchaus erlaubt, weil es einfach manchmal sein muss.

Ja, das ist sinnvoll, weil auch da halt der Hinweis ausreichend durchaus wieder nachvollziehbar ist. Ich meine, bis, bis dich eine Seite ausloggt aus Sicherheitsgründen, ist schon reichlich Zeit zu vergehen, oder nicht?

Ja, das, das auf jeden Fall. Klar, natürlich. Sicher auch mit diesen Hinweisen, dass, dass eben, eine Beschränkung, soundsoviel mal, oder ein Ausloggen soundsoviel mal verlängerbar sein muss und so weiter.

Oh ja, das würde ich mir bei vielen Formularen wünschen.

Ja, klar.

Okay, nächster Punkt. Der dritte Punkt zur Bedienbar sagt: "Gestalten Sie Inhalte nicht auf Arten, von denen bekannt ist, dass sie zu Anfällen führen." Ein ganz bekanntes Beispiel: Es, es gab diesen berühmten japanischen Comic, der, im Fernsehen einen wilden, flackenden Hintergrund gezeigt hat, was dazu führte, dass ein Großteil der japanischen Kinder irgendwie mit Schaum vor Mund auf dem Boden zusammengebrochen ist.

Das kann man auch mit seiner Webseite machen, wenn man das möchte, ist aber nicht ratsam.

Ja, schwieriges Thema. Diese, diese Richtlinie gibt's ja schon was länger. So was Ähnliches gab's auch schon mal in der eins null. Und ich hab versucht mal nachzuvollziehen, wo das herkommt, wo's tatsächlich schon mal Fälle gab. Ich kenne dieses, dieses, dieses Beispiel, das wird immer wieder genannt, was du gerade gesagt hast mit den, mit den japanischen Kindern. Es waren allerdings, also ich will nicht sagen, dass es in, im Bereich urbaner Mythos, sagt man das im Deutschen so?

Wie sagt man das?

Ich glaube, den Begriff gibt's nicht, aber ich glaube, man beklebt das im Internet.

Ja, also wer das nicht weiß, mag jetzt mal bitte googeln mal eben, was damit gemeint ist.

Dass es, dass es da anzusiedeln ist, weil, das ist ein Punk-Punkt, mit dem ich in der, in der WCAG wirklich ein Problem habe, weil mir da der echte Nachweis fehlt, dass das tatsächlich passiert ist. Also dass, A waren, soweit ich das weiß, die Fallzahlen bei diesem Fall in Japan, lange nicht so hoch, wie das immer kolportiert wird. Dazu kommt, dass, dass, so, so einfache Dinge: W-Was wird denn da wie gemessen?

In Japan sind Wohnungen üblicherweise super klein und Kinder sitzen mit der Nase vor dem Fernseher. Und da, da krieg ich ja auch schon Schaum vor dem Mund, obwohl ich, keine Ep-Ep-Epilepsie hab. Also da, da fehlt mir so ein bisschen der Nachweis. Aber, und das ist das eigentliche Problem: Um den Nachweis, bringen zu können, muss man im Prinzip eigentlich jemanden mit Epilepsie vor ein problematisches Angebot setzen und warten, dass der umkippt.

Das will man natürlich auch nicht machen, weil eben bei bestimmten Arten von epileptischen Anfällen eben auch, na ja, Gehirnzellen absterben können. Und da, da wird man Schwierigkeiten haben, Versuchskaninchen zu finden, die sich dessen eben aussetzen wollen.

Es gibt ja, es gibt ja auch keine genormte Art und Weise von Epilepsie, mit der man sagen kann, dass eine diese Art und Weise-

Ja, gut deswegen, deswegen ist in den Techniques halt ein Frequenzbereich von bis, ein bestimmte, ein bestimmtes Flackern in bestimmten Zeiträumen,, mit, mit auch genau festgelegten Kontrasten von zu und wieder zurück, beschrieben. Also es ist, es ist, es ist ein schwieriger Punkt, wo man, wo man einfach da jetzt auf Experten, die das entwickelt haben, vertrauen muss, und das selber nicht wirklich, verlässlich testen kann. Also es geht, es geht da nicht um, um, um flackernde Werbebanner, ne?

Also so ein Werbebanner, der so einmal die Sekunde blinkt, der ist sicher unproblematisch. Der ist nervig, aber der führt sicher nicht bei einem Epileptiker zu 'nem, zu 'nem Anfall. Das sicher nicht. Es geht da um, um, um viel kürzere Frequenzen.

Ja, auf jeden Fall.

Und die macht, macht eigentlich, sowieso keiner, außer in irgendwelchen Ballerspielen, aber da weiß der Betroffene selber, dass er sich besser nicht vor einen Ballerspiel davor setzt, und da wird er nicht von überrascht, weil er davon ausgehen kann, dass da halt mal was explodiert und blitzt und tut und macht. Also schwieriger Punkt.

Ich weiß, was du meinst. Im Unterschied zu den anderen ist der auch nur mit, mit 'ner, mit einem Gegentest beweisbar, während alle anderen ist eigentlich: Kann ich das erreichen, wenn... ist in dem Fall eher umgekehrt: Wie kann ich vermeiden, dass... Und das ist natürlich viel schlechter zu testen. Dann weiß ich, was du meinst.

Wobei es natürlich auch eine Guideline ist, die nur in den wirklich seltensten Fällen, überhaupt getestet werden muss, weil, dass, dass etwas überhaupt flackert, ist ja relativ selten.

So eine moderne Kunst.

Ja, weiß ich nicht. Also ein, ein Video aus der Disse mit einem Stroboskoplitz.

Gutes Beispiel. Das ist natürlich ein gutes Argument, ja.

Dann hätten wir es schon, ne? Und das ist halt, wenn ich auf YouTube mir irgendwelche Musikvideos angucke irgendwie und dann bumm, zack, auf einmal wach-wache ich neben meinem Stuhl auf und, ja, werd nicht vorgewarnt. Also kann schon durchaus passen, ja.

Diese technische Störung wurde Ihnen präsentiert von Skype.

So, da sind wir wieder. Du kannst.

Okay. So, der vierte Punkt von mir denen war, sagt: Stellen Sie Mittel zur Verfügung, um Benutzer dabei zu unterstützen, zu navigieren, Inhalte zu finden und zu bestimmen, wo sie sich finden. Und das ist auch etwas, was sehr, sehr plastisch vorgestellt werden kann. Mittel zur Verfügung zu stellen, die bei der Navigation helfen. Da kann man sich auch diverseste Sachen vorstellen.

Ich persönlich habe gerade überhaupt keine Idee, was das sein könnte, außer großflächige Hinweise, wo der nächste Klick sich hinführt und vielleicht so was wie, ob sich ein neues Fenster öffnet. Ist das das? Liegt da richtig, Thomas?

Nee, das ist, es geht eigentlich mehr darum, also typisches Szenario:, ein Benutzer, der die Seite nicht sieht, sondern nur hört, der sich, also der klassische blinde Screenreader-Nutzer, der immer so ein schönes, schönes plastisches Beispiel ist, der sich beim Anhören einer Seite, zum einen erst mal ein mentales Modell des Seitenaufbaus irgendwie zusammenfummeln muss. Also, wo, wo bin ich überhaupt? Wie ist das Ganze aufgebaut und wie kann ich mich da drin bewegen und wie ist es strukturiert?

Das, das wird dann klarer, wenn man, wenn man, dann in die Understanding, reingeht und in die, in die Techniken. Da geht es nämlich um, um, ja ja, um strukturelles Markup. Also benutze ich Übersch-Überschriften? Sind meine Listen als Listen ausgezeichnet? Und so weiter. Habe ich irgendwelche Möglichkeiten, Inhalte, die mich jetzt gerade nicht interessieren, in irgendeiner Form zu überspringen, zum Beispiel. Und dann kommen dann die nachgeordneten Techniken, mit denen man das erfüllen kann.

Das kann eben entweder oder, die Verwendung von Überschriftenelementen sein, also um wieder zum Screenreader-Nutzer zurückzukommen, der dann einfach seinen, seinen, seinen Überschriftenknopf drückt und sich von Überschrift zu Überschrift hangelt, und damit quasi eine Seite, akustisch so scannen kann und sich darin orientieren kann, so wie wir morgens die Zeitung aufschlagen und erst mal alle Überschriften angucken, und dann gucken, welcher Artikel interessiert uns eigentlich und dann gezielt dann in den Artikel reinzugehen.

Also das ist dann eben so die Art und Weise, wie ein Screenreader-Nutzer sich auf einer Seite orientieren könnte. Oder eine andere Technik, um das auch zu erfüllen, diese berühmten Skip Links. Am Anfang von einer, von einer Seite, dass man da irgendwelche, Links hat, mit denen man Inhalte, die jetzt mit der Seite selber nichts zu tun haben, zum Beispiel, also eine immer wiederkehrende Navigation. Ne?

Ich gehe von der Startseite eines Webangebots auf eine Unterseite und kriege dann erst mal wieder die Navigation, vorgelesen, obwohl ich ja eigentlich den Inhalt der Seite lesen wollte. Also irgendein Mechanismus, um die, die, die Navigation zu überspringen. Jetzt könnte man sagen: Okay, der Artikel, um den es auf der Seite geht, ist mit der H eins eingezeichnet, ausgezeichnet.

Also kann ich dann direkt die, die wichtigste Überschrift, H eins oder H zwei oder was auch immer anspringen, aber es ist ja nicht gesagt, dass es nicht noch weitere Überschriften auch in der Navigation gibt, die ich dann alle mit anspringe. Deswegen diese Idee mit dem Skip Link, - Im Idealfall zwei oder drei zu Beginn als erstes fokussierbares Element einer Seite zu haben, die mir quasi schon so den, den, den Seitenaufbau vermittelt.

Also hier geht's zur Navigation, hier geht's zum, zum wesentlichen Inhalt der Seite und diese, diese Blöcke auch direkt anspringen an Macht. Darum geht's da.

Da gibt's ja heute auch dann WAI-ARIA, ein wunderschönes neues Tool, die, Landmark Rolls.

Das sind die Landmark Rolls. Ja, die, die, da brauche ich dann keine Skip Links mehr. Damit habe ich im Prinzip diesen Punkt auch erfüllt, obwohl die ja nicht explizit genannt sind, aber damit kann ich, in zumindest in modernen Screenreadern mit relativ modernen Browsern, also das, das fängt bei Firefox mit eins fünf an, also schon relativ antiker Firefox, wo die angefangen haben, diese, diese Aria Rolls einzubauen. Internet Explorer und so weiter.

Also, jede Menge Browser, die das, die das mittlerweile verstehen. Die kann den, die kann ich dann auch quasi, benutzen, um diesen By Class Blocks Punkt zu erfüllen, ja.

Frage aus der Praxis: Würdest du sagen, dass das heutzutage schon 'ne vollständige,, Ersetzung von Skip Links darstellen kann oder eher noch ergänzend?

Mhm. Na, wir sind noch in so einer Übergangsphase. Also, ich, ich würde noch nicht ganz drauf verzichten, aber, wie das glücklicherweise immer so ist, die Browser, die das nicht verstehen und die User Age oder User Agents im weitesten Sinne, also inklusive Screenreader und ähnlichem, die das nicht verstehen, die werden natürlich von Tag zu Tag weniger. Und die, die das verstehen, werden von Tag zu Tag mehr.

Also es ist durchaus eine Technik, die man jetzt schon dezent einsetzen kann, aber man kann sich noch nicht hundertprozentig drauf verlassen. Deswegen würde ich im Augenblick eher, noch beides machen.

Also eigentlich wie, eigentlich wie grundsätzlich alles, was WAI-ARIA ist, kann noch oben aufgesetzt werden, noch mal zusätzlich progressive enhanced werden, aber einfach noch nicht ersetzen, was vorher da war.

Ja, richtig.

Okay. Gut. Das war's auch für den Punkt bedienbar. Als Nächstes steht der Punkt verständlich auf der Liste mit seinem ersten Unterpunkt: Machen Sie Textinhalte lesbar und verständlich. Und das ist auch wieder so erschlagend einfach, dass man an sich nichts drunter vorstellen kann, außer wie ist der Text formuliert?

Ist, ist der in extrem hochgestochenem mit Latein und Englisch durchdringtem Fremdwörtern vollgespickt oder ist das eine Sprache, die in kurzen Sätzen erklären kann, was tatsächlich gemeint ist?

Na ja, das, das ist, das ist eher dann bei, hm. Ja, das ist ein schwieriger Punkt, wo es, wo es wieder, wieder so übergeht in, in allgemeine Usability, ne? Also wir haben-

Das ist interpretierbar.

Ja, ja. Da wird's, da wird's dann schwierig. Es gibt, es gibt ein paar harte Fakten. Also gleich der erste,, 'ne Sprache muss, 'ne, 'ne Seite muss in irgendeiner Form deklarieren, in welcher Sprache sie verfasst ist. Damit's, damit Tools wissen, also jetzt wieder der klassische Blinde mit 'm, mit 'm Screenreader, in welcher Sprache er was vorlesen soll. Es gibt nichts Schlimmeres, als 'n, 'n englischen Text mit deutscher Stimme vorgelesen zu kriegen, oder andersrum.

Und das betrifft eben nicht nur, nicht nur Webseiten, sondern so der, der klassische Fehler, den wirklich alle sämtliche Behörden und Unternehmen machen, ist, in PDFs zum Beispiel nicht zu sagen, dieses PDF ist auf Deutsch. Das ist einmal in, in der Acrobat, einmal in, in Dialog rein, auswählen, Sprache Deutsch, okay, speichern fertig. Also 'ne Sache von, hm, zwanzig Sekunden ungefähr, wenn nicht in der Zeit-- Zwischenzeit Acrobat abstürzt, aber, ansonsten ist es, ist es wirklich Kinderteller.

Oder, oder halt eben in, im, im CMS bei der, bei der Erstellung der, der Templates für meine Seite eben im, im HTML-Element oben ein Langattribut vergeben. Lang gleich DE fertig. Und wenn ich andere Sprachversionen hab, also in der englischsprachigen Übersetzung meiner Seite, da eben lang gleich EM reinzuschreiben. Also auch wirklich, na ja, 'n Minicode-Schnipsel, was aber leider immer noch viel zu wenig benutzt wird.

Was ein bisschen aufwendiger ist, ist dann der nächste Punkt, und der, da fängt's dann auch schon wieder an, auch in der Version zwei Punkt null ein bisschen strittig zu werden, dass, dass eben auch die, die, Sprache von, von Teilen des Webinhaltes in irgendeiner Form ausgezeichnet werden muss. Also ich kann ja einmal global für das ganze Dokument sagen, ich bin deutsch.

Wenn ich dabei jetzt sehr viele, fremdsprachige, jetzt in der IT oft Englisch, Wörter drin hab, dann, dann wird's natürlich sehr schnell, sehr mühselig, die alle einzeln auszuzeichnen. Da wird's dann schwierig, zumal man das nur bis zu einem gewissen Grad automatisieren kann, weil es eben sehr viele Sachen gibt, wo man, wo der Redakteur dann noch mal manuell nacharbeiten muss. Da wird's dann schwierig. Was muss alles ausgezeichnet werden?

Das ist auch, glaube ich, noch nicht so ganz zu Ende diskutiert. Also schönes Beispiel, wo das, wo das, eher kontraproduktiv ist, wenn ich 'nem Amerikaner, das Wort Kindergarten, mit, mit der deutschen Aussprache vorlese, dann weiß der nicht, was damit gemeint ist, ne. Oder Angst oder, oder jede Menge, wie, wie nennt man die Germanizismen? Oder wie

Vermutlich. Das finde ich super.

Oder, oder,, Schadenfreude.

Das hat jetzt keiner verstanden. Schadenfreude.

Wie, wie sprechen die das aus? Schadenfreude? Freude?

Freude.

Also das ist 'n deutsches Wort. Das muss ich nach der Regel eigentlich als Deutsch kennzeichnen. Wenn ich das Deutsch kennzeichne, versteht kein Amerikaner was mit Kindergarten. Schulz. Was, was damit gemeint ist, ne? Ist dann, also etwas schwierig. Andersrum ist es, ist es genauso relativ aufwendig, für 'n Redakteur, der, der deutsche, Wo-, Texte mit, mit Anglizismen auszeichnen muss. Mein Lieblingsbeispiel ist immer Tag oder Tag.

Das kann keine Maschine unterscheiden, ist damit d-HTML Tag gemeint oder Wochentag. Da muss, da muss ein Mensch ran und muss sagen, markieren Englisch weiter, ne? Damit es als Tag ausgesprochen wird, ne? Ansonsten würde der Screenreader halt immer Tag vorlesen und der Blinde weiß jetzt nicht, ist damit jetzt der Wochentag oder der HTML Tag, genannt, gemeint.

Sehr schönes Beispiel. Hast du eigentlich mal irgendwann ein CMS gefunden, das dir die Möglichkeit gibt, als Redakteur die Sprache zu setzen?

Nö.

Nee, ich auch nicht.

Nicht, nicht dass ich wüsste, nee. Nee, deswegen wird's eben auch nicht gemacht, weil und es ist eben auch nicht maschinell leistbar, eben aus genannten Beispielen. Also einigermaßen schwierig. Das ist, das ist 'n Punkt, da wird's sicher noch einige Diskussionen geben, ob das jetzt erfüllt ist oder nicht und ob's überhaupt sinnvoll ist, das zu erfüllen.

Das ist nachvollziehbar. Bringt uns zum zweiten Punkt des, Themas Verständlich, der da sagt: "Sorgen Sie für dafür, dass Webseiten vorhersehbar aussehen und funktionieren." Und das wird wahrscheinlich viele Designer Tränen die Augen treiben, denn die wollen natürlich alle was Neues machen. Die wollen was, Überraschendes machen und das ist eigentlich genau das, wogegen diese Aussage spricht. Was, was sie aussagt, ist wirklich, die Seite sollte nicht überraschend in eine andere Richtung scrollen.

Die Seite sollte nicht überraschend plötzlich nach oben klappen statt nach unten. Es sollte so sein, dass wenn du schon mal die Seite benutzt hast, dass du im Zweifelsfall die Seite auch benutzen kannst. Ist das richtig?

Mhm. Ja, das hört sich, das, das hört sich an wie erst mal so eine Anti-Design- oder eine Anti-Innovationsrichtlinie, ne? Also wenn man das wirklich ganz strikt auslegt, könnte man ja, behaupten, dass damit ja quasi, sämtliche Innovation, auf dem Stand von, von 2008 eingefroren wird und, und es ist eigentlich keine Änderung mehr. Aber ich denk, das wird klarer, wenn man in die, in die, einzelnen Unterpunkte reingeht. Da, da ist es dann schon, schon deutlich beschrieben, was damit gemeint ist.

Also damit ist nicht gemeint, dass man keine, keine, sich keine neuen Sachen mehr ausdenken kann, weil man damit den, den, den Benutzer ganz fürchterlich überrascht und der dann ganz verwirrt ist, sondern es geht eben im, im Kontext der, der aktuellen Nutzung darum, dass man da, den Benutzer nicht mit, mit User Interfaces, überfordert, die ihn an einer aktiven Nutzung hindern. Das ist 'n ganz wichtiger Punkt.

Also gleich beim, beim ersten zum Beispiel, beim ersten Punkt, denke ich, wird das klar. Ihr kennt wahrscheinlich alle diese, diese Scripts, wo du, on, on Change in so 'ner Liste, dann die Seite wechselst.

Oh ja.

Ja? Ohne dass der Benutzer das, das, per, per Enter, ausgelöst hat, dass die Seite jetzt wechselt. Also so 'n, gibt so 'n Dropdown, Liste, aus der ich auswähle und on Change, zack, neuer URL. Das ist damit gemeint. Also dass, dass eben, durch, durch das, das Naviga-- reine Navigationsbewegungen nicht schon irgendwie Neuladen der Seite, verursachen dürfen. Solche Beispiele sind es zum Beispiel.

Das ist ein sehr schönes Beispiel. Eine Sache, die mir auch immer wieder unterkommt, sind Custom Scroll Bars. Irgendwelche Elemente auf der Seite, die sich scrollen lassen, aber nicht mit den klassischen UI-Elementen ausgestattet sind, sondern mit irgendwas selbst gebaut und die leider nie so funktionieren, wie sie gerne hätte.

Ja, und, und im Ernstfall noch nicht mal im Tab Cycle liegen, ne? Also ich komme noch nicht mal per Tastatur dran und so.

Oh ja, genau.

Solche Geschichten. Also das ist, ja.

Apple hat da jetzt gerade bisschen was verbockt. Die haben jetzt gerade neu rausgebracht ihre, die, die, die, die Zwischenlinks, die auf iTunes Store Links führen. Haben sie's richtig schön, schön gemacht. Haben sie jetzt so Zwischenseiten, die noch mal anzeigen, was dann das, das Lied oder das Spiel ausmacht, auf das man grad geklickt hat, ohne in den iTunes Store reinzukommen.

Aha.

Aber sie wollten scheinbar unbedingt die, den Horizontal Scroller aus, aus ihrem iTunes Store eins zu eins umgesetzt haben, dass es genauso aussieht und haben dann einen Scroller gebaut, der nicht mit der Maus zu bedienen ist, der nicht mit dem Scrollpad zu bedienen ist.

Ah.

Du musst ihn wirklich anklicken und ziehen. Es ist-

Au weia. Nee, das ist natürlich-- Ja.

Ist das bei der, bei diesem Produktkarussell auf der Apple Seite anders?

Ganz genau.

Okay, das ist das gleiche Spiel. Gut.

Ja, das ist natürlich bösartig. Ja.

Ich hoff, sie merken's.

Ja, und das ist, das ist halt eben für sehr viele Nutzer 'ne, 'ne so wichtige, so wichtiges Feature, dass das so was bedienbar ist, dass diese Punkte eben in der, in der WCAG 2 bei, bei Level A, also bei den absoluten Muss-Kriterien einsortiert sind, ne?

Das ist nichts, was man noch so als, als Sahnehäubchen, wenn man noch wirklich alles für Accessibility tun will, noch, noch obendrauf deckeln kann, sondern das ist wirklich,, wirklich ein, eins der absoluten das muss ein Webangebot erfüllen, ansonsten brauchen wir gar nicht weiter testen, Kriterien, ne.

Wir sind nicht ganz durch gewesen mit, mit den Punkten. Allerdings hast du gerade was angesprochen, was ich, wichtig finde, das muss ich kurz reinschieben. Du hattest die A und Double A und Triple A angesprochen. Magst du, magst du ganz kurz erklären, was das bedeutet und was vielleicht das richtige Ziel ist?

Also Ziel ist eigentlich und das sagt das W3C auch selber, Double A. Es ist nicht immer sinnvoll, tatsächlich, Triple A grundsätzlich für, für alle, Formen von Webinhalten anzustreben, weil's eben teilweise auch gar nicht geht, oder weil es einen solch enormen Aufwand-, also weiß ich nicht, Live-Untertitelung von, von, von, von Live-Video und solche Geschichten, ne. Die sind nicht bei, und solche Geschichten, da braucht man schon ein sehr gut gepolstertes Budget, um das erfüllen zu können.

Und das kann man nicht jedem aufs Auge drücken, der, weiß nicht, bei Ustream aus seinem Wohnzimmer irgendwie gerade mal, ne, was streamt. Dass es auch noch live untertitelt werden muss, wenn man, wenn man ganz alleine da sitzt, etwas schwierig. Wie, wie gestern bei, bei Boward World zum Beispiel, ne. Ein schönes Beispiel dafür. Also die, die hätten dann tatsächlich da eigentlich streng genommen jemanden hinsetzen müssen, der die Jubiläums-,, Sendung, zweihundert war's, glaube ich-

Ja, genau.

-da, live untertitelt, damit man auch, auch,, dann mitlesen kann, was Kollege Heilmann da vom Stapel lässt, ne. Hallo Herbert. Wir müssen jetzt alle-- Sollen wir gerade mal Hallo Herbert grüßen?

Hallo Herbert. Wer ist Herbert?

Das-- Chris, Chris versteht das. Also insofern, gibt's da schon 'ne, 'ne deutliche Abstufung, zwischen den, zwischen den Prioritäten, zwischen, absolutes Muss, dann Kann und, und Soll. Soll vielleicht noch irgendwann mal. Und die, die absoluten Muss-Kriterien, die, was wir ganz eingangs hatten, Alternativtexte für, für, visuelle oder für Nicht-Textinhalte, Textalternativen, ist einfach A, Stufe A, wo man auch nicht drüber diskutieren kann, sondern das muss einfach erfüllt werden. Fertig.

Ende der Diskussion. Und so sind dann in, in Double A eben Dinge, die, erfüllt werden, na ja, eigentlich mehr oder weniger auch, auch erfüllt werden sollten, aber die mit 'nem, höheren Aufwand verbunden sind und eben in Triple A Dinge, die mit 'nem teilweise sehr hohen Aufwand und auch teilweise nicht für sämtliche, Arten von Webinhalten anwendbar sind. So ist das sortiert.

Kannst du für jeden ein Beispiel bringen?

Ja, A hatten wir, ne, also die, die Alternativtexte. Das ist einfach so 'n, so 'n, so 'n sine qua non. Also da wird nicht drüber diskutiert. Das, das muss einfach erfüllt bleiben, werden und, fertig. Und dann am anderen Ende der, der Fahnenstange eben diese, Live-Untertitelung zum Beispiel, als, kann man auch noch machen. Ich versuch grad, ich guck grad mal, ich hab jetzt auch nicht alle im Kopf, was, wo was mit, mit AA ist, was schön passt.

Deswegen frage ich nämlich eigentlich, weil so, so 'n, so 'n klassisches AA, ist eigentlich das, was man mit 'n bisschen Aufwand, ich glaub, der, der klassische ambitionierte Technikbezieher- -, hat da Interesse an den.

Ja, sichtbarer Fokus, das ist 'n, das ist 'n schönes Beispiel. Das ist,, bei AA, einsortiert. Warum das jetzt an der Stufe ist, entzieht sich meiner Kenntnis, aber es ist halt so 'n, so 'n leidiges Thema, was in sehr viele andere Bereiche reinspielt, Tastaturbedienbarkeit, Sehbehinderung und so weiter, dass beim, beim, beim Durchtabben durch 'ne Seite oder auch beim Drübermausen, immer klar sein muss, wo befinde ich mich grade.

Das, haben sehr viele Webseiten eben nicht und teilweise eben auch sogar ausdrücklich abgeschaltet. Also mir fällt da ein im deutschen Raum sehr verbreitetes Open-Source-CMS ein, was, in der, in der Standardinstallation eben diesen Fokus automatisch, sobald man linkfokussiert, wieder wegnimmt. Ja, und man kriegt es da nicht raus. Also man, man kann es ausbauen, aber wer macht das schon?

Sodass man beim Durchtabben eigentlich nie weiß, wo bin ich denn jetzt eigentlich gerade, außer dass die Seite mal nach unten scrollt und, aber ich sehe nie, auf welchem Element ist mein Fokus grade, weil er mir immer vom Skript wieder weggenommen wird. Und das ist natürlich eigentlich 'ne relativ einfache Vorgabe. Was aber schon 'n bisschen komplizierter ist, ist natürlich den Fokus auch garantiert so zu kennzeichnen, dass er, in, in allen Browsern, wirklich deutlich sichtbar ist.

Das Problem dabei ist, dass sehr viele Browser, grad unter Windows, immer nur so diese, diese kleinen,, gepunktete Outline um, um Links drum rum haben, was je nach Farbschema, was ich auf der Seite drauf hab, einfach nicht ausreicht, um, um sofort sehen zu können: Ach, da bin ich jetzt eigentlich. Jetzt gibt's natürlich für moderne Browser die Möglichkeit, mit, mit Outline zu arbeiten, was der bis heute marktführende Browser, nach wie vor nicht versteht.

Oder der Achter kann mittlerweile Outline? Weiß ich jetzt gar nicht.

Ich glaub nicht, dass er's kann.

Nee, ich glaub nicht, ne. Also und da kann ich nicht mit, mit Border arbeiten, weil dann fliegt mir, fliegen mir die Boxen um die Ohren, weil die dann da drauf gerechnet werden. Und dann, dann springt's auch dauernd. Also für moderne Browser könnte ich theoretisch die Hintergrundfarbe wechseln und noch 'ne Outline geben, weil eben die, die, die Standard, der, der Standard-Fokusmarkierung nicht, nicht ausreichend ist. Das wäre ein schönes Beispiel für 'n, für 'n Double A.

Das ist wirklich ein schönes Beispiel. Da hat mir damals auch die Fußnägel hochgerollt, als ich gesehen hab, dass, Eric Meyer in seinem, in seiner zweiten Ausgabe von seinem Stylesheets-

Oh ja.

-Reset genau das ausgeschaltet hat.

Super.

Er hat ja noch 'n Hinweis gegeben, dass es sehr, sehr wichtig ist, das wieder zu setzen. Hab ich gelesen. Ich kenne vielleicht fünf Prozent- -der Webdesigner, die, das auch wirklich tun, ja.

Ja. Und dabei ist es eigentlich so herrlich einfach. Das ist wirklich mit, mit, das ist eine CSS-Regel, die, die keinen weh tut..

Ja eben, der Witz, der Witz ist ja auch, die meisten Kunden wollen ja lustige Hover-Effekte, wenn du irgendwo über einen Link drüber gehst. Das ist genau die gleiche Regel. Machst du einfach noch auf Fokus drauf und du bist dabei.

Ja, ja. Ja, und das ist wirklich kein, kein, kein Aufwand. Auch das, das lässt sich ja, auch an, in, in vorhandenen Webseiten super einfach nachrüsten. Das, was du gerade sagtest. Also ich muss ja nur einmal in, in meinen Style Sheets einmal nach, nach Hover suchen und, und mit Fokus ergänzen. Ne? Das ist wirklich eine Sache von, bei egal wie komplex das Style Sheet ist, von zehn Minuten oder so und dann habe ich wirklich diesen Punkt auch erfüllt. Das ist ein ganz, ganz einfacher Punkt.

Absolut. Double A draufziehen.

Ja, das ist, das ist was, wo das W3C sagt, das sind die Dinge, die, die realistisch erfüllbar sind. Deswegen sollten, Webangebote, wenn sie das, das Maximum an, an, an Accessibility rausholen wollen, sich als Ziel Double A setzen. Nicht- Nicht Triple A. Also Triple A kann man immer noch als, als Bonus obendrauf machen, aber um Triple A zu erfüllen, muss man erst mal Double A erfüllt haben. Also das sind dann die, die eigentlich wichtigen Sachen.

Genau. Als dritter und letzter Punkt von, Verständlich kommt eine Aussage daher, die heißt: Helfen Sie den Benutzern dabei, Fehler zu vermeiden und zu korrigieren. Das muss ich zugeben, ich habe keine Ahnung, was ich darunter verstehen soll.

Ja, das sind, die klassischen, Formularvalidierungen, zum Beispiel, dass, dass wenn ich, wenn ich meine E-Mail-Adresse in ein, in ein Muster eingebe, was keine gültige E-Mail-Adresse sein kann, dass ich drauf hingewiesen werde und, mir das erklärt wird, wie es auszusehen hat und,, dass es auch eine Möglichkeit gibt, es, zu korrigieren und diese, diese Korrektur von der, von der Fehlermeldung aus oder diese Korrekturmöglichkeit von der Fehlermeldung aus auch direkt anspringbar ist und solche Geschichten.

Ah, okay. Also das, das ist absolut nachvollziehbar.

Das ist so als ein Beispiel.

Okay, nee, das macht absolut Sinn. Ist da noch ein anderes Beispiel, außer bei Formularen, die jetzt in der Benutzerführung vielleicht Fehler vermeiden könnten? Oder habe ich da was falsch-- Das habe ich mir ursprünglich vorgestellt, aber nicht irgendwie anwenden können.

Es geht eigentlich größtenteils um, um Eingaben und da sind wir ja automatisch im Bereich Formulare.

Mhm. Ja.

Das ist, das ist eigentlich ein Block, der sich, der sich fast ausschließlich um, um Formulare, wendet.

Natürlich so ein bisschen auch über die Abläufe in, in längeren Transaktionen und so weiter, dass ich, also dieser drei drei vier zum Beispiel, dass wenn, wenn, eine Transaktion in irgendeiner Form rechtliche oder finanzielle Auswirkungen hat, dass das, dem Benutzer, gesagt wird, dass, dass, Daten, noch mal, noch mal vom Benutzer irgendwie kontrolliert werden können, bevor sie tatsächlich dann endgültig abgeschickt werden, dass, dass der Anbieter auch oder das System selber auch, auf, auf Plausibilität überprüft und so weiter.

Also wirklich, ja gute Usability in Formularprozessen eigentlich.

Okay, nee, das ist nachvollziehbar. Das hat halt auch, glaube ich, den gleichen Punkt wie viele andere. Wenn's einfach eine gute Usability ist, dann ist es schon relativ nah an der Accessibility dran.

Ja. Ja, kann man so sagen.

Bringt uns zum vierten und allerletzten Punkt in dieser schönen Reihe. Und zwar ist das der Punkt robust.

Kann ich ganz kurz noch mal zu dem, zu dem Punkt zurück, weil das ist nämlich, das ist eigentlich ein Punkt, der, in, in den, den WCAG zwei null, also noch zur Richtlinie drei eine große Lücke ist, ist dieser, dieser große Bereich, Usability für allgemeine Nutzer. Klar, keine Frage, da gibt's große Überlappungen, aber wir, wir reden ja von einer, Barrierefreiheitsrichtlinie, deren, deren Begünstigte in Anführungsstrichen ja erst mal Menschen mit Behinderungen sind.

Und das sind natürlich auch sehr oft, und vor allen Dingen von den, von den Fallzahlen wesentlich höher als, Menschen mit, Sehbehinderung oder Hörbehinderung oder ähnlichem, sind Menschen mit kognitiver Behinderung. Die sind natürlich von diesem Block drei, ganz besonders betroffen, weil es da eben auch um, Verständnis von, von Inhalten und von Abläufen und von bestimmten Prozessen auf Webseiten oder in Webapplikationen geht.

Und da hat die, die WCAG zwei Punkt null das gleiche Problem wie die WCAG eins Punkt null, dass es einfach zu wenige Erkenntnisse in diesem Bereich gibt. Also es gibt, keine oder so sehr wenige Forschungsergebnisse aus dem Bereich kognitive Behinderung, die sich in irgendeiner Form in, in, in Webentwickler kompatible Richtlinien umformulieren lassen.

Also wo man einem Konzepter oder Designer oder, oder Coder sagen kann, mach das und das und dann wird, deine Webseite von Menschen im Intelligenzspektrum unter hundert oder so besser verstanden. Das liegt unter anderem daran, dass, dass dieser, dieser Zustand des Verstandenhabens nicht eindeutig definierbar ist. Also es gibt keine, keine Grenze wie jetzt bei Gehörlosen, hört was, hört nichts, also muss ich bestimmte Dinge machen. Oder bei Blinden, sieht was, sieht nichts, sind binäre Zustände.

Versteht oder versteht nichts ist aber ein fließender Übergang. Sodass ich da und das ist, das ist eben, wo uns die, die Vorgabe, dass alles testbar sein muss, was wir am Anfang erwähnt haben, da so ein bisschen ins Knie schießt, weil das eben nicht mehr testbar ist. Ab wann ist was verstanden worden oder nicht? Und kann der Benutzer da, was mitnehmen und beim nächsten Mal wieder anwenden?

Da sind wir nämlich sehr schnell in dem Bereich, der, der Definition von kognitiver Behinderung, dass eben bei bestimmten kognitiven Behinderungen der Nutzer nicht in der Lage ist, Sachen zu lernen und beim nächsten Mal wieder gleich anzuwenden. Und das ist, das ist eine riesengroße Lücke, wo aber, wesentlich mehr Menschen, von betroffen sind, als, als von, von, sensorischen oder motorischen Behinderungen oder irgendwie so was, ne?

Das ist ein riesengroßer Bereich von, von Menschen, die, aufgrund von einer, kognitiven Behinderung eben Sachen, bestimmte Sachen einfach nicht verstehen werden. Da, da hakt's halt noch.

Das schlägt von dieser, auch so ein bisschen die gleiche Kerbe wie, die Geschichte mit den,, na, die Leute mit dem Schaum vor dem Mund. Und es ist einfach etwas, das, nicht scharf abgetrennt werden kann. Es ist einfach ganz klar. Man weiß nicht, zu welchem Zeitpunkt das verstanden wird. Man weiß nicht, zu welchem Zeitpunkt bei dieser jeweiligen Person das genau jetzt zutrifft und deswegen ist es einfach nicht hundertprozentig testbar.

Man kann versuchen, die, die Einstiegshürde so gering wie, so tief wie möglich zu legen.

Mhm. Ja, und das ist, das ist eben dieses, dieses, diese Testbarkeit, das ist, das ist das große Problem dabei. Das ist auch nichts, was jetzt ein, ein Webentwickler, testen könnte. Sich mal, ein bisschen salopp gesagt doof anzustellen. Das ist, das, das geht nicht. Das ist,, hat vielleicht auch ich hab da, ich hab da so eine Theorie, dass das, in der gerade in der Webentwicklerszene sehr viele Leute mit, mit Asperger, rumhängen.

Überhaupt in der ganzen IT. Nun haben, nun haben Menschen mit Asperger-Syndrom, üblicherweise auch 'n, 'ne überdurchschnittliche Intelligenz. Das heißt, man ist dann sehr schnell in einem Intelligenzspektrum von, von hundertdreißig, hundertvierzig oder sonstiges.

Und wenn derjenige sich dann, dann mal doof anstellt, dann ist er höchstens auf dem Bundesdurchschnitt, und, und, und kann damit also auch nicht testen, wie jemand mit 'ner, mit 'ner, mit 'ner echten Lernbehinderung, mit, mit so einer Seite umgeht. Ne? Also das ist, 'ne ganz schwierige Kiste. Und einer der Gründe, warum zu diesem Thema in der WCAG 2.0 so gut wie gar nichts gesagt wird.

Weil es einfach entweder nichts gibt, in der Hoffnung, dass es vielleicht irgendwann mal was gibt oder es einfach nichts geben kann, was man in Form einer Richtlinie für, für diesen, für diese große Nutzergruppe noch, noch machen könnte.

Mhm. Tragischerweise ist es halt auch ganz häufig nicht in der Hand des Entwicklers, denn es ist ja in der Regel der, der Inhalt, der diese Hürde darstellt. Dementsprechend kann man allerhöchstens, seinem, seinem Kunden anraten, die, die Verständnich--, die Verständlichkeit des Textes doch auf ein entsprechendes Level zu heben, bzw. zu senken, sodass, die Zielgruppe das entsprechend auch wirklich verstehen kann.

Mhm. Also es gibt natürlich ein paar einfache Regeln, irgendwie, also Anglizismen, wenn sie nicht sein müssen, möglichst zu vermeiden. Es gibt, es gibt für sehr, sehr viele Fremdwörter, die in bestimmten Szenen immer und immer wieder verwendet werden, auch durchaus deutsche allgemeinverständliche Entsprechungen, und solche Geschichten. Es sind, es sind auch ein paar Dinge, die, in den Bereich gutes Design gehen.

Also eine gute Lesetypografie hilft auch, Menschen mit einer Lese-Rechtschreib-Schwäche. Das sind so einfache Dinge wie, ausreichenden Zeilenabstand, was auch in der, in der, in der WCAG 2.0 explizit genannt wird, dass, dass man für ausreichende Zeilenabstände und wie man sie misst, zu sorgen ist. Und das sind, das sind, also gute Lesetypografie hilft da und, aber viel mehr wird man da auch nicht machen können.

Mhm. Okay, das bringt uns aber nun wirklich zu unserem letzten Punkt in der Reihe und der heißt robust und hat nur einen einzigen Unterpunkt und der heißt: Maximieren Sie die Kompatibilität mit aktuellen und zukünftigen Benutzeragenten einschließlich assistierender Techniken. Und das ist, eine sehr interessante Geschichte, denn es wird darauf hingewiesen, dass man auf aktuelle und zukünftige Benutzeragenten aka Browser eingehen soll. Es wird nicht wirklich auf vergangene hingewiesen.

Das finde ich einen sehr wichtigen Gesichtspunkt. Das ist in dem Fall nicht absichtlich, aber ich finde es dennoch sehr wichtig zu sagen, es ist nicht zwingend immer hilfreich, alles nach abwärtskompatibel zu versuchen. Denn das kann durchaus selbst auch eine Barriere darstellen.

Mhm. Ja, das ist, um das mit einem praktischen Beispiel zu belegen, verbreitete Screenreader, halten sich selber auch nicht an Standards, und, die, die WCAG sind streng genommen eigentlich nur ein Drittel der, der Barrierefreiheitsrichtlinien der, des W3C. Es gibt auch noch die, die UAAG, also die User Agent Accessibility Guidelines.

Die regeln, wie, sind Inhalte in von einem Benutzeragenten, also Browserhilfsmittel und so weiter zu verarbeiten und dem Nutzer zu präsentieren, damit möglichst viele Leute damit klarkommen. Und es gibt die ATAG, die Authoring Tools, Accessibility Guidelines, die regeln die Autorenwerkzeuge, also ein CMS oder Dreamweaver oder was auch immer. Wie unterstützen die die, die Webautoren da drin, barrierefreie Inhalte zu erstellen.

Und erst wenn alle drei funktionieren, kann hinterher ein vernünftiges Produkt bei rauskommen. Also man kann nicht, wie das bei der eins null noch war, die gesamte Verantwortung bei dem Webentwickler abladen und sagen: „Du, mach mal und du bist jetzt verantwortlich dafür, dass da draußen alles funktioniert." Dann haben wir nämlich diese, diese Abwärtskompatibilität bis, bis DOS drei elf oder irgendwie so was, die, die da eingefordert wird, sondern es ist genau der umgekehrte Weg, ne?

Es müssen alle Beteiligten was für das Thema tun und erst dann kann ein vernünftiges Produkt hinten bei rauskommen.

Ja, sehr schönes Beispiel. Nichtsdestotrotz muss man natürlich darauf achten, was wir grad vorhin auch gesagt haben, dass wir gerade in so einer Übergangszeit sind, was, die Techniken angeht, die man heutzutage nutzen kann, um Webseiten zugänglich darzustellen.

Das heißt, vielleicht zu dem Sinn von irgendwie zwei Blicke nach vorne, einer zurück, dass man immer noch schauen kann, dass man eben nicht ausschließlich die neuesten Techniken wie zum Beispiel WAI-ARIA nutzt, um, sich darauf zu verlassen, dass irgendwas, zugänglich wird, sondern dass es erst mal von Grund auf, zugänglich sein soll und dann noch zusätzlich, weiter angereichert werden kann mit neuen Techniken.

Ja, aber es gibt einfach auch bestimmte Dinge, wo man, wo man dann als Webentwickler beruhigt sagen kann: „So da, sorry, jetzt ist Schluss mit lustig. Ich mach das jetzt einfach, auch wenn verbreitete Hilfsmittel das bis heute nicht verstehen." Also mein, mein Lieblingshassbeispiel, der, der in Deutschland marktführende Screenreader versteht auch im Jahr 2010 in der allerneuesten Version, nicht Strong und EM. Und er versteht bis heute nicht INS und DEL.

Sachen, die seit-- Wann ist HTML4 rausgekommen? 97? Round about, ne. So seit dreizehn Jahren mindestens in, in HTML spezifiziert sind, liest, man kann's ruhig sagen, JAWS, bis heute, ein mit, mit, mit Hervorhebung oder starker Hervorhebung, also IM oder Strong, ausgezeichnetes Element nicht anders vor als, irgendwas, was mit B oder I oder gar nicht gekennzeichnet ist. Oder, INS und DEL, also für inserted und deleted Text, was ich, was ich benutzen kann, um eine Änderungsverfolgung zu machen.

Da ist jetzt Text gelöscht und neu hinzugefügt worden. Keine Chance. Macht er nicht, versteht er nicht. Und das sind Sachen, die, die teilweise seit dreizehn Jahren in der, in HTML-Specs drinstehen. Wenn die die bis heute nicht verstehen, kann ich nicht-- Es gibt, es gibt keine abwärtskompat, keinen abwärtskompatiblen Workaround dafür, dass, dass dieses Hilfsmittel sich selber nicht an die Standards hält.

Und da sind dann irgendwann auch mal die, die Hersteller der Hilfsmittel gefordert, sich selber bitte schön auch, an die Standards zu halten, weil nur so kann es funktionieren.

Mhm. Und schön ist, dass da durchaus, Alternativen existieren zu JAWS, die dann wiederum, in solchen Fällen durchaus einen Schritt voran sind, auch wenn sie deutlich jünger sind.

Ja klar. Gut, aber das ist, das ist, dann 'ne ganz gefährliche Diskussion, wo man schnell in die, in die verschiedenen Geschäftsmodelle von Screenreadern auf unterschiedlichen Plattformen, kommt. Also ich, ich hab das sowieso nie verstanden, wie man, wie man ein, ein marktführendes Betriebssystem auf den Markt bringen kann, ohne dass ein Screenreader da eingebaut ist. Also ein Screen, ein Screenreader ist ja quasi die akustische GUI des blinden Nutzers zum Betriebssystem.

Und genauso wie ein sehender Nutzer halt 'ne, 'ne grafische Oberfläche mit seinem Computer mitgeliefert kriegt, kriegt der, der blinde Nutzer auf zwei von drei Plattformen auch eine akustische GUI im Karton mitgeliefert. Und es soll ja Betriebssysteme geben, die, wenn ich den Karton aufmache, den Rechner das erste Mal anschalte und mich fragen: „ hör mal, willst du 'n Screenreader benutzen?", und dann-

Drücke ich die Wählscheibe.

Ja, ja. Und dann drücke ich den Knopf und dann, dann läuft Voice-over und, und, und ich hab mit nichts mehr Probleme. Also da ist dann der Screenreader quasi ganz tief unten im System hardwareverratet drin und nicht wie auf anderen oder auf einer anderen Plattform als, als Add-on für teures Geld, hinten drangetackert.

Und das, das, das kann eigentlich nach meinem technischen Laienverständnis nur schlechter funktionieren, wenn ich was nachträglich drantacker, als wenn's gleich, in, in der Basis ganz tief unten im System, mit drin ist, einfach als, als, natürlicher Bestandteil des Systems, dass das System auch auf Nachfrage mit mir spricht.

Ich glaub, du darfst die Plattform auch mal beim Namen nennen. Wir haben jetzt so schön drumrum geredet und-

Er mag das Wort gar nicht in den Mund nehmen, glaube ich.

Nein, nein, das ist, nein, es ist, es ist klar, dass wir, dass wir hier über Windows und macOS und Linux reden. Das ist...

Ja, ich, ich denke auch, dass es bekannt ist. Und vielleicht auch mal ganz kurz als Hinweis, du hast grad vorhin beiläufig gesagt, für teuer Geld. Ich glaube, den wenigsten Leuten ist bewusst, wie teuer JAWS eigentlich ist. Kannst du mal ganz kurz 'ne Zahl nennen?

Zweieinhalb tausend Euro.

Ja, das muss man der Verzug mal zergehen lassen. Das, das ist-

Ja, es ist, es ist, da krieg ich, da krieg ich vier Mac Minis für. Ja, und dann hab ich, dann hab ich vier Mac Minis mit vorinstalliertem Screenreader, der, der einfach ab Werk schon läuft, wo ich nur einen Knopf drauf drücken muss und, und fertig. Dass es funktioniert, demonstriert der Marco Zehe Tag für Tag, der, der mit dem iPhone und mit dem MacBook unterwegs ist.

Und, er kommt gut, gut damit zurecht und kann es wunderbar nutzen und, und, und, twittert wie doof damit und, und macht seine ganze Arbeit damit und ich weiß nicht, was alles, ja.

Mhm. Das ist verblüffend. Also, gerade iPhone als, als, als Beispiel, das eben auch VoiceOver direkt mit eingebaut hat. Na-- Eigentlich glaube ich, drei von von vier Blinden in meiner direkten Umgebung haben inzwischen ein iPhone. Das muss man sich einfach auch mal vorstellen. Das ist, das ist ein Gerät, das hat nur ein großes Display und eine Taste. Nichtsdestotrotz ist das das bevorzugte Gerät von Blinden.

Mhm. Ja, wo, wo alle immer gesagt haben, irgendwie Blinde brauchen taktiles Feedback. Ja, die brauchen also in irgendeiner Form irgendwas, was wo sie mit dem Finger drauf rumfahren können, eine Braillezeile-Tastatur mit irgendwelchen Erhebungen und so weiter, wo sie, wo sie sich dann eben taktil orientieren können und so. Und das iPhone beweist genau gerade das Gegenteil, ne.

Das, das, und das, das finde ich eigentlich eine ganz spannende Entwicklung, dass, dass bisher Accessibility für bestimmte Benutzergruppen immer an bestimmte, Techniken und Hilfsmittel gekoppelt war und wir jetzt und das deck-, ist so schön deckungsgleich auch mit, mit diesem neuen Ansatz der WCAG 2.0, dass wir Accessibility losgelöst von bestimmten Techniken betrachten, sondern und, und nur messen, was muss beim Nutzer ankommen, ne?

Und wenn der, wenn der, jetzt Marco oder, oder Arthur oder irgendwer einen Ohr-Ohrstöpsel drin haben, und, mit dem Finger über eine glatte Oberfläche fahren, wo sie kein taktiles Feedback kriegen, aber sie kriegen über den Ohrstöpsel gesagt, über welchem Icon ihr Finger gerade ist. Und dann können sie es drücken und die, die App dann nutzen, erfüllt ja genau das, was, was in der, in der, in der WCAG gefordert ist.

Egal wie du das umsetzt, es muss halt der, der, der, der, der, der Output beim Nutzer muss so und so sein und das ist er damit ja, ne. Wie das umgesetzt wird, ist ja erst mal egal. Hauptsache, es funktioniert hinterher.

Absolut. Das ist auch ein sehr schönes Schlusswort eigentlich. Marcel, wollen wir das Ganze mal so von hinten aufrollen?

Von hinten aufrollen. Also ich habe auf jeden Fall mitgenommen, dass man die, zwei Nuller-Richtlinien, grundsätzlich jedem Webdesigner vor die Nase legen müsste,, und vor allem das Ganze nicht nur, einem Menschen mit Behinderung zugutekommt, sondern einfach, ja, in, in vielen Teilen einfach Bestandteil vernünftigen Webdesigns sein sollte.

Ja. Ich glaube, ich glaube, ein großer Unterschied ist auch, ich glaube, viele, viele Webentwickler haben, haben Angst, sich solche, W3C-Dokumente durchzulesen, weil sie höllisch kompliziert sind. Das ist keins davon. Das ist tatsächlich, 'ne Wonne zu lesen und zu verstehen. Und es ist richtig viel Info drin, die man im, im täglichen Gebrauch auch tatsächlich anwenden kann.

Vor allem man kann sich, man kann sich nach einem Projekt einfach oder während eines, Projektes einfach mal die, die Richtlinien nehmen, sich einfach nur mal die, die, die, Überschriften durchlesen und, bekommt da schon wunderbare Anreize, wo man vielleicht noch mal, ziemlich schmerzfrei und das finde ich vor allem so genial. Man braucht halt nicht so unglaublich tiefes Expertenwissen.

Man kann vieles echt so einfach umsetzen und ich glaube, das ist eine super gute, ein super gutes DIN-A4-Blatt, was einem da, schon mal Anreize gibt.

Ja, das ist ja-

Alles-

Entschuldigung?

Nee, ich habe nur gezuckt.

Es ist ja, es ist ja, was ihr gerade sagtet. Es ist, natürlich extrem viel Material. Also wenn ich das wirklich alles durchlese, alles ausdrucke, sind es wirklich,, Hunderte von Seiten. Aber es gibt halt auch eine ganze Menge Tools. Also mir fällt da spontan dieses, dieses How to Meet WCAG 2.0, vom W3C ein. Das ist so eine, so eine,, Schnellreferenz, die, die anpassbar ist. Da gibt es, das ist unter, der W3.org/WAI, also W-A-I, Seite auch verlinkt. How to Meet WCAG 2.0.

Da, da ist so eine, so eine Batterie an Checkboxen, wo ich sagen kann: „Zeig mir jetzt nur HTML-Techniken oder zeig mir nur CSS-Techniken oder zeig mir nur, Client-Side-Scripting, oder zeig mir CSS und Client-Side-Scripting und so weiter.

Und wenn man dann den Scrollbalken beobachtet, sieht man, wie der schrumpft, also wie die, wie die Seite insgesamt auch kürzer wird, sodass ich ganz gezielt als Webentwickler, der jetzt heute CSS auf dem Programm hat, oder ich muss mich einlesen in das, was muss ich mit CSS eigentlich machen, sich seine, seine Schnellreferenz selber zusammenklicken kann. Da kriege ich also dann ganz reduziert nur die, die Punkte aus dem WCAG, die, Cascading Style Sheets betreffen und sonst nichts.

Alles andere ist dann ausgeblendet. Und das ist eine, das ist eine ganz feine Sache. Das ist dann also, damit zählt dann diese Ausrede nicht mehr: „Ach, ist ja so viel und ist ja kaum zu bewältigen“, mehr. Nein, das ist wirklich, ich kann das, das für alles, was ich in meinem Job mache, mir meine Infos ganz reduziert, ganz schnell zusammensuchen. Eine tolle Sache. Das wird übrigens auch übersetzt. Ist gerade in der Pipeline. Sind wir so halb durch ungefähr mit dem, mit dem Dokument.

Ja, krass.

Perfekt. Ich glaube, das ist ein Thema, das kann man besonders aus praktischer Sicht noch, fünf weitere Stunden durchziehen. Wir nähern uns jetzt so langsam der zweiten. Ja, an dieser Stelle vielen Dank euch beiden.

Gerne.

Sehr gerne.

Wenn ihr an der St-- Es, es war sehr schön, sich mal ein bisschen zurückzulehnen und euch zu lauschen..

Apropos lauschen: Pünktlich zum Ende geht deine Leitung wieder den Bach runter.

Gut.

Okay, gut.

In diesem Sinne: Bis nächste Woche.

Ja, danke schön.

Tschüss.

Gute Nacht.

Mehr Qualität im Webdesign durch Webstandards. Tipps und Tricks zur Umsetzung findet ihr bei den Webkrauts auf Webkrauts.de. Für ein besseres Web.

Weitere Informationen und die Links zur Sendung auf Technikwürze.de