Ausgewählter Vortrag:
Web-Entwicklung mit WCAG 2.0
-
21.11.2008, 11:50–12:35 Uhr, Raum 2
Lange haben wir auf die neue Version der W3C Web Content Accessibility Guidelines (WCAG) 2.0 gewartet. Nun ist es bald soweit und in kürze ist WCAG 2.0 ein neuer Meilenstein in Web-Barrierefreiheit. Aber was hat sich genau geändert und wie können die neuen Richtlinien in der Praxis optimal eingesetzt werden? Dieser Vortrag bietet einen Überblick auf die Erneuerungen im WCAG 2.0 und was das für ihre öffentliche Webseiten, Intranets, und Web Applikationen bedeutet.
Unterlagen
Transkription:
Shadi Abou-Zahra
Gut, na dann fangen wir an.
Guten Tag, mein Name ist Shadi Abou-Zahra. Ich arbeite für W3C, das Web, World Wide Web Konsortium, die Web Accessibility Initiative und das Thema ist heute Webentwicklung mit WCAG 2.0.
Vor ein paar Wochen wurde ich von den Organisatoren eingeladen, um über WCAG 2.0 zu berichten, aber mit der Bedingung, dass es auch was Neues gibt. [Lachen]
Also ich bin froh, heute hier sein zu dürfen und den neuesten Stand von WCAG 2.0 zu berichten. WCAG das sind die Web Content Accessibility Guidelines 2.0. Es sind viele Gesichter, neue Gesichter in dem Raum. Wer hat sich, wer hat sich schon mit WCAG 1.0 befasst? Und weiß ungefähr die, ok, gut. Gegenfrage: wer hat sich mit WCAG noch gar nicht befasst? O.K., also ein paar neue Leute für Web-Barrierefreiheit. Aber hauptsächlich geht’s hier um ein bisschen die Unterschiede zwischen WCAG 1.0 und WCAG 2.0 bzw. was ist, was sich neues ergeben hat und welche Änderungen noch hervorstehen.
Die erste Frage ist: wer entwickelt WCAG 2.0 oder WCAG generell? WCAG wird von der W3C Web Accessibility Initiative entwickelt. Das ist ein internationales Standard-Konsortium, das viele Webstandards herstellt, die ihr hoffentlich bereits alle schon kennt, HTML, XML, CSS usw. Also die Kernwebtechnologie. Und die WAI, also die Web Accessibility Initiative ist ein Teil von W3C, der sich um die Barrierefreiheit des Webs kümmert und erstellt diesen Standard.
Es ist aber ein offener Prozess. Es ist eine internationale und kooperative Überarbeitung, d.h. es gibt verschiedene Stadien, in denen es öffentliche Entwürfe gibt und, dass das verschiedene Beiträge, auch von Leuten, die nicht direkt in der Arbeitsgruppe sind, sich beteiligen können. Z.B. in diesem Raum alleine sehe ich schon ein paar Leute, die sich auch daran beteiligt haben, die z.B. Kommentare und Entwürfe geschickt haben, die z.B. Implementierungen geschickt haben, um zu zeigen, was funktioniert und was nicht funktioniert usw. Also es ist die Arbeit von wirklich unzählige Leute, die zusammenarbeiten, um WCAG zu entwickeln und heraus zu bringen.
Der Entwicklungsprozess in W3C ist ein längerer. [Lachen]
Shadi Abou-Zahra beim Vortrag, im Hintergrund die Gebärdensprach- Dolmetscherin (Bild: Philipp Naderer)
Es folgt einem formalen Ablauf, und zwar ist es so, dass es eine Reihe von öffentlichen Entwürfen gibt. Also von Zeit zu Zeit veröffentlicht die Arbeitsgruppe einen Entwurf und verlangt Kommentare. Und dann gibt es einen Zeitpunkt, wo die Arbeitsgruppe sagt, ok, wir sind, wir denken, wir sind fertig und macht einen so genannten „Last Call“-Entwurf. Das ist meistens, wenn die wirklichen Kommentare reinkommen. Das war auch der Fall im WCAG 2.0, dass wir dann noch einmal wieder zurück auf Entwurfstadium zurück mussten, weil die Kommentare, die bei „Last Call“ reingekommen sind auch sehr substantiell waren und zur Veränderung der Richtlinien geführt haben.
Dann war ein erneutes „Last Call“, also ein wirkliches „Last Call“, „last Last Call“ und dann gab es die „Candidate Recommendation“. „Candidate Recommendation“-Phase ist eigentlich eine Testphase. Da werden die Standards in der Praxis getestet, weil es keinen Sinn macht, Standards heraus zu bringen, die in der Realität eigentlich nicht umsetzbar sind. D.h. es werden da wirkliche Implementierungen gesucht, Beispiele gesucht, wo etwas umsetzbar ist, wo ist es nicht umsetzbar, was muss noch geändert werden. Das haben wir auch hinter uns. Und seit kurzem befinden wir uns in der so genannten „Proposed Recommendation“-Phase. Das ist eigentlich eine interne Absegnung von den W3C-Mitgliedern. Es ist also nicht zu erwarten, dass sich vieles ändert oder irgend was ändert eigentlich, außer vielleicht editorielle kleine Ausbesserungen, aber inhaltlich wird sich nichts mehr ändern. Wir erwarten also, dass WCAG 2.0 als endgültiges Standard, als so genanntes „Recommendation“ im Dezember 2008. Also das ist sehr bald und wir sind schon sozusagen in der Endphase und wir freuen uns sehr drauf, dass diese Richtlinien jetzt endlich heraußen sind und dass wir damit arbeiten können.
Nun, was ändert sich, ist die große Frage. Aus einer Sicht kann ich sagen, es ändert sich nichts. Die Anforderungen bleiben unverändert. Also wir haben jetzt jahrelang an Standards gearbeitet und eigentlich ändert sich nichts. Aber es ist so, weil die Anforderungen von Menschen mit Behinderungen sich ja nicht geändert haben. Wenn man sich also schon auseinander gesetzt hat, was ist eigentlich Barrierefreiheit, wie kann ich eine Lösung finden, wie kann ich zu einem Problem, das ich habe, den Design so gestalten, dass es für die möglichst alle Leute zugänglich ist, dann wird sich eigentlich nicht viel ändern. Anders betrachtet, ändert sich eigentlich alles, vom Standards-Entwicklung her, vom Standard selber.
Der Standard WCAG 2.0 geht weg vom Checklisten-Konzept, geht weg davon zu sagen, mach’ das und tu’ dies. Es geht viel mehr daran, ein benutzerorientiertes Modell zu geben, zu sagen, was sind die Anforderungen, was sind die Bedürfnisse, und verschiedene Lösungswege vorzuschlagen, verschiedene Lösungen zu dokumentieren, die diese Anforderungen gerecht werden. Es bleibt aber dem Entwickler zu entscheiden, welcher Lösungsweg in einem gegebenen Fall genommen wird und welcher nicht. Also es kommt vielleicht ein bisschen mehr Entscheidung auf den Entwickler drauf an, zu entscheiden, welchen Weg ich jetzt nehme, aber letztendlich ist das eine Auseinandersetzung, die man hätte sowieso machen müssen. Und deswegen ändert sich einerseits nichts.
WCAG 2.0 ist eigentlich ein ziemlich umfangreiches Projekt. Im Kern ist das so genannte der eigentliche Standard, der W3C selber, das sind die Kriterien, das sind die Richtlinien selber, das steht sozusagen im Mittelpunkt. Es gibt aber andere Dokumente rund herum, um den Standard, die auch zu WCAG 2.0 gehören, die es aber leichter ermöglichen, das in der Praxis umzusetzen. Und die sind für uns als Entwickler eigentlich sehr wichtig. Schauen wir uns diese Dokumente einmal an.
Links und rechts von diesem Bild von WCAG 2.0 habe ich das so genannte „Techniken“ für Entwickler. Das sind wirklich umfangreiche Lösungen. Das sind Beispiellösungen und ich werde sie demnächst ein bisschen erklären.
Dann gibt es auch das so genannte „Understanding WCAG 2.0“. Das ist mehr Information über z.B. was ein Erfolgskriterium ist, für wen ist das gedacht, welche, welche Arten von Behinderungen betrifft das überhaupt, Beispiele usw. Diese zwei Dokumente sind eigentlich nicht bedacht, dass sie von A bis Z gelesen werden sollen. Das sind sozusagen Handbücher, Anleitungen. Wenn ich etwas nicht verstehe, kann ich das nachschlagen. Wenn ich etwas Spezifisches umsetzen will, schaue ich in die Techniken. Also das sind sozusagen Dokumentationen, Information, dass ich als Handbuch bei mir habe und ich glaub’, nicht viele Leute haben vielleicht in ihre Handbücher für irgendwelche Software jetzt gelesen oder so, sondern wenn Sie ein Problem haben, schauen Sie nach auf eine bestimmte Seite und schauen, wie kann ich jetzt, wo finde ich eine Antwort zu meiner Frage.
Was aber für uns Entwickler in dem Raum, ich nehme an die meisten sind hier Entwickler, was ganz wichtig ist, ist das „How to Meet“-Dokument, auch genannt das „Quick Reference“. Das steht hier oben im Bild. Und das werde ich im nächsten ein bisschen mehr erklären. Das ist eigentlich eine Anleitung, wie ich mich im WCAG 2.0, in diese ganze Ansammlung von Information zurecht finde. Und das ist wirklich der Einstiegspunkt für Entwickler und das ist etwas, wo ihr als Erstes reinschauen solltet. Die Struktur von WCAG 2.0 und wenn Sie das lesen können, brauchen Sie keine Brille. [Lachen] Ich werde das ein bisschen vergrößern. Gut.
Also die Struktur von WCAG 2.0 besteht aus Prinzipien, dann da drunter Richtlinien, Erfolgskriterien und dann die Techniken, die ich kurz erwähnt habe. Die sind ein eigenes Dokument. Das ist so eine Art Knowledge Base. Wenn wir das vergleichen mit WCAG 1.0, gab es eigentlich nur Richtlinien und Checkpunkte. WCAG 2.0 hat sich in beiden Richtungen ausgebreitet, in die Richtung von Prinzipien, Design-Prinzipien bis hinein in Techniken, ganz detaillierte Umsetzungen dafür.
Es gibt eigentlich nur vier Prinzipien. Auf Englisch ist die Anfangsbuchstaben von „perceivable“ also wahrnehmbar, „operable“ bedienbar, „understandable“, dass verständlich ist und dass es “robust” ist. Die Anfangsbuchstaben auf Englisch bilden das Wort „pour“, also um etwas zu schütten, wie ein Wasserfall, aber nicht „pour“ wie ja, die andere Bedeutung vom Wort.
Aber wichtig ist einfach als Designer, diese vier Grundprinzipien zu verinnerlichen und zu verstehen. Egal, was ich jetzt entwickle, welchen Inhalt oder Applikation ich entwerfe. Es soll wahrnehmbar sein für alle, dass alle die Information wahrnehmen können, dass es bedienbar ist, dass es verständlich ist und dass es auch robust ist, d.h., dass es auf verschiedenen Browsern z.B. funktioniert, oder auf verschiedenen Ebenen. Das sind die vier Grundprinzipien.
Ich glaube, damit hat keiner ein Problem, oder? Dann geht’s eine einen Schritt tiefer und zwar die Ebene der Richtlinien. Und hier habe ich nur zwei Beispiele von den Richtlinien, was sie da besagen. Z.B. Richtlinie 2.1 besagt salopp übersetzt, dass alle Inhalte über das Keyboard funktionieren sollten. Das ist noch immer sehr allgemein, ist eine allgemeine Richtlinie, aber es ist natürlich schon ein bisschen spezifischer, es gibt schon eine Anleitung. Man sieht schon an der Zahl, 2, d.h., es ist schon unter „bedienbar“ und so ist es auch formuliert. Richtlinie 3.3 ist unser, das Dritte, wer kann sich erinnern, was 3 ist, „verständlich“ genau, „understandable“ verständlich. Und das diese Richtlinie an sich besagt, dass man dem Benutzer helfen sollte, Fehler zu vermeiden und Fehler zu verbessern, z.B. bei Formulareingaben. Wenn ich einfach ein Wort falsch eingegeben habe, dass das Programm nicht abstürzt oder was immer. Also das sind Richtlinien.
Shadi Abou-Zahra beim Vortrag (Bild: Markus Ladstätter)
Wenn wir zur nächsten Ebene gehen, gehen wir schon in die Erfolgskriterien, so genannte „Success Criteria“. Die sind dann noch konkreter oder noch spezifischer. Erfolgskriterium 1.1.1, das 1er ist das „Wahrnehmbar“ und das ist das sehr Bekannte für textuelle, Entschuldigung, für nicht textuelle Inhalte sollte eine äquivalente Alternative verfügbar sein. Sehr bekannt, sehr berühmt, ich glaube, kennen alle noch vom WCAG 1.0, dass z.B., wenn ich ein Bild hab’, sollte ich das mit einem Alt-Attribut versehen, wenn ich einen Button habe, sollte es auch genau so einen Wert haben, dass wenn ich diesen Button nicht sehe oder nicht dieses Bild nicht sehe, dass ich trotzdem diese Information wahrnehmen kann.
Aber das Interessante an diesem Erfolgskriterium und der Unterschied zu WCAG 1.0 ist, dass es noch immer technologieunabhängig funktioniert, äh formuliert ist. Es ist egal, ob ich das jetzt in Flash umsetze, PDF, ein Word-Dokument habe oder HTML. Ich bin noch immer unabhängig von der Technologie, wo ich das umsetze. Es gilt noch immer, es ist noch immer eine Anforderung. Das wäre ein weiteres Beispiel, das zwar Level AAA ist und für die, die vielleicht neu zu WCAG sind, sollte ich vielleicht erklären, dass WCAG in drei Stufen gegliedert ist. Es gibt die Stufen A, AA und AAA.
Ein weiteres Beispiel Erfolgskriterium 2.2.4 besagt, dass eben Unterbrechungen können vom Benutzer unterdrückt werden. Das ist natürlich ein bisschen ein komplizierteres Kriterium, es ist auch ein bisschen ein Spezifischeres und deswegen ist es Level AAA.
Also es gibt wieder, dieses Level A ist das, was ich machen muss. Wenn ich das nicht mache, bin ich ziemlich sicher, dass ich Personenkreise ausschließe. Level AA ist, dass ich, dass es eine Verbesserung ist und Level AAA ist eine noch weitere Verbesserung.
O.K., das ist eigentlich, was im Standard, im WCAG 2.0 Standard drin ist. Das sind diese Anforderungen. Es sind noch keine Techniken, wie ich das jetzt umsetze.
Ich habe zuvor erwähnt, dass die Techniken ein eigenes Dokument sind, aber die schauen wir uns jetzt an. Techniken von WCAG 2.0 werden auch verschieden gegliedert. Es gibt die so genannte „Sufficient Techniques“, also das sind Lösungen, die ausreichen, wenn ich diese Lösung einsetze, dann erfülle ich die Anforderung, erfülle ich das Kriterium. Dann gibt es noch die „Advising Techniques“. Die dokumentieren wir auch. Das sind so genannte „Best Practices“. Ja, es reicht vielleicht aus, diese Lösungen zu machen, aber besser ist diese andere Variante.
Wie gesagt, das sind umfangreiche Dokumentationen und ich als Entwickler kann mir aussuchen, welche davon ich machen will. Drittens gibt es dann noch die „Common Failures“, also häufige Fehler, Fehler, die oft vorkommen und die dokumentieren wir. Die sind Gold wert, weil man weiß, wenn das eintritt, dann habe ich was falsch gemacht. Das ist grade, wenn ich evaluiere, oder wenn ich teste oder wenn ich schauen will, ob meine Applikation oder mein Entwurf wirklich einen, dem Standard entspricht, kann ich mit diesem „Common Failures“ viele Sachen ausschließen.
WCAG 2.0 ist ziemlich flexibel gestaltet. Es ist ziemlich situational. Es gibt verschiedene Situationen. Nehmen wir z.B. heran diese äquivalente Information für nicht textuelle Inhalte. Jetzt gibt’s verschiedene Situationen. Sagen wir, es ist möglich, diesen nicht textuellen Inhalt, nehmen wir an, es ist ein Bild, kann ich jetzt mit einer Kurzbeschreibung ausreichend beschreiben, einen kurzen Text, könnte ich das ausreichend beschreiben. Das ist eine Situation. Es gibt eine andere Situation, sagen wir es ist eine Grafik, die müsste ich dann ausführlicher Beschreiben. D.h. eine kurze Beschreibung reicht nicht aus. Nehmen wir eine andere Situation. Es ist eigentlich ein CAPTCHA also es ist nicht dafür gedacht eigentlich, dass der Inhalt, also der Alternativtext dabei steht. Es ist eine Prüfung z.B. oder es ist ein Test. Da muss ich eine andere Lösung machen, wie ich diese äquivalente Information darbiete. Also es gibt verschiedene Situationen und je nach verschiedener Situation, je nach welche Situation ich mich befinde, gibt’s verschiedene Lösungen. Was ich versuche, zu sagen, ist für jede Anforderung kann es je nach dem Kontext, was ich grad versuche zu machen, verschiedene Lösungen geben. Und das ist der große Umdenken, dass man bei WCAG 2.0 machen muss. Man denkt viel mehr an den Benutzer, an die Anforderung und was kann ich erreichen, mehr als „tu dies“ oder „tu das“.
Schauen wir uns einmal die Struktur von den Techniken selber, also eine wenn ich jetzt eine Technik ausgesucht habe, ich habe jetzt gesagt, ok, es ist eigentlich ein Formular in HTML und es ist ein Formularknopf, ein Button von einem Formular. Und ich will das jetzt, ja, ich muss diese Anforderung einhalten, eine äquivalente Information zu geben. Dafür gibt es eine spezifische Technik und zwar die Technik H36. [Lachen] Natürlich weiß das jeder oder, H36 ist genau dieser Fall. Ich werd, ja, wie man zu H36 kommt, werd’ ich dann noch beschreiben. Der Titel ist „using art attributes and images used as submit buttons“. Also das sind Submit-Knöpfe bei Formulare. Eine solche Technik ist immer in Abschnitte gegliedert und zwar die „Applicability“, welchen Rahmen betrifft das jetzt, eine Beschreibung von dieser Technik, Beispiele, Ressourcen, verwandte Techniken. Diese ganze Information steht drin.
Was für uns vielleicht ganz wichtig ist, ist der letzte Punkt, diese Tests. Das ist der Testverfahren, um zu sehen, ob ich diese Technik tatsächlich eingehalten habe oder nicht. Hier ist z.B. dieses Testverfahren für H36 und zwar ist die Prozedur, steht eine ganz Testprozedur da, also ein Testverfahren für alle Input-Elemente, die den Typ Image haben, soll ich schauen, ob ein Alt-Attribut existiert oder nicht. Schritt 2 ist check, dass diese Attribute die Funktionalität des Buttons wiedergeben. Das sind zwei Prüfschritte, die ich befolgen muss, und es gibt auch ein erwartetes Resultat. Erwartet wird, dass beide, dass ich beide diese Fragen bejahen kann.
Also wir haben jetzt angefangen von ganz, ganz allgemeine Prinzipien wie z.B. wahrnehmbar oder bedienbar oder so, und sind Schritt für Schritt tiefer gegangen bis zu einer ganz, ganz bestimmten Situation, ein ganz bestimmter Implementierung von einem Button in HTML. Das ist, was in WCAG 2.0 ist. Ich hab’ zuvor erwähnt, dass eben diese verschiedenen Dokumente zusammenarbeiten, die zu WCAG 2.0 gehören. Im Kern steht der Standard selber, wo die Anforderungen, und dann gibt’s diese Techniken, dieses Techniken-Dokument, wo all diese H36 und H37 und F13 usw. alles aufgelistet sind. Das ist sozusagen eine Knowledge Base. Wird dann herausgezogen, je nachdem, welche ich brauche. Wie mache ich das? Ich habe zuvor gesagt, ganz wichtig ist, für uns als Entwickler, einzusteigen bei dem „How to Meet WCAG 2“-Dokument. Wenn man dort einsteigt, dann ist ziemlich weit oben als Ersteres ein Formular, wo ich dieses Dokument dieses „How to Meet“-Dokument, es ist einerseits ein Dokument, andererseits vielleicht eine Applikation, kann ich, was ist das deutsche Wort für customize, anpassen, danke schön. Ich kann da angeben, welche Technologien verwende ich. Verwende ich SMIL, verwende ich CSS, verwende ich WAI-ARIA, diese ganzen Sachen kann ich angeben. Ich kann das übrigens auch speichern, also ich muss das jetzt nicht jedes Mal eingeben.
Also ich geb’ an, die Grundvoraussetzungen oder die Grundstruktur meiner zu entwerfenden Applikation oder was ich evaluieren will. Ich geb’ auch ein, welchen Level ich treffen will, will ich nur Level A, will ich Level AA usw. Ich kann auch sagen, zeig’ mir auch diese „Advising Techniques“, diese „Best Practices“ oder ich sage, nein, ich will eigentlich nur das Minimum, zeig’ mir nur das Mindeste, was ich tun muss.
Also ich kann da verschiedene Sachen eingeben, um WCAG und diese Fülle an Information für meinen bestimmten, für mein bestimmtes Ziel auswählen zu lassen. Also es ist eigentlich sozusagen ein View auf diese Daten, auf diese Masse. Das können Sie wahrscheinlich auch nicht lesen, aber das ist die Antwort, was herauskommt, ein Auszug aus dieses „How to Meet“, wenn ich dieses Formular dann abschicke, wenn ich dieses Customization mache, womit ich dann ende. Das ist hier ein Beispiel von Erfolgskriterium 1.4.3, wird dann nur dieses Erfolgskriterium gelistet. Dann die Techniken darunter aufgelistet, die für mich in Frage kommen je nach meinen Auswahlen. Es gibt die „Sufficient Techniques“ mit der Situation A und Situation B. Also was das erzeugt ist eine Checkliste, aber nicht Checkliste im Sinne von, dass ich das abhake, hab ich das gemacht, habe ich das nicht, sondern eine Checkliste, was ich meinem Entwickler geben kann, oder was ich als Entwickler haben will und was ich befolgen muss für meine spezifische Applikation. Wenn ich jetzt eine andere Applikation oder eine andere Webseite entwickle, werde ich vielleicht andere Parameter haben, und werde vielleicht einen anderen View auf WCAG 2.0 haben. Also das ist einmal die Grundidee, die Prinzipien von WCAG 2.0 und wie es sich geändert hat.
Ich möchte aber auch an dieser Stelle ein paar Vorteile von WCAG 2.0 noch einmal unterstreichen. Und zwar, dass die Kriterien testbar sind. Das ist ein ganz ein wesentlicher Design-Punkt von WCAG 2.0. In WCAG 1.0 gab es z.B. das Kriterium, dass Farbenkontraste ausreichend sein müssen. Das ist ein sehr wichtiges Kriterium, weil laut Statistik ist 1 von 4 ältere Männer haben eine Farbbehinderung. Also es ist eine sehr wichtige Anforderung. Nur die Frage für uns Entwickler stellt sich, was ist ausreichend Farbkontrast. Wann habe ich das erreicht und wann habe ich das nicht erreicht? Wir wissen genau, dass wir, wenn wir schwarz-weiß machen, dass wir das eingehalten haben. Wir wissen auch as andere Extrem, wenn wir, ich weiß nicht, gelb und orange gemacht haben, dass das wahrscheinlich nicht gut ist. Aber genau geht’s in der Mitte, was ist mit blau und rot oder verschiedene Farben davon. Wann habe ich dieses Kriterium erfüllt und wann nicht. WCAG 2.0 schlägt ein bestimmtes Algorithmus vor, wie ich diese Kontraste berechnen kann und wie ich wirklich zu einem eindeutigen, ja wie ich das eindeutig feststellen kann, ob ich diese Anforderung eingehalten habe oder nicht. Das heißt jetzt nicht, dass es automatisierbar ist unbedingt.
Barrierefreiheit ist zum Großteil nicht automatisierbar. Zum Großteil müssen noch immer manuelle Evaluierungen gemacht werden, aber es ist testbarer, es ist messbarer.
Der andere Vorteil von WCAG 2.0 ist, dass es Technologie unabhängig ist. Wir haben gesehen, dass bis zu einem hohen Grad die ganzen Anforderungen Technologie unabhängig sind. Es ist egal, ob ich PDF verwende, oder Flash oder was immer. Die Techniken sind die Dokumentationen, die mir dann sagen, wie ich das in ein bestimmtes Kontext erfüllen kann. Es ist flexibel und anpassbar. Ich kann jetzt sagen, je nach was meine Situation ist, z.B. ich entwickle auf einem Intranet und ich kenn’ genau, welche Betriebssysteme da verwendet werden, welche Clients und welche assistierenden Technologien. Es ist eine ganz andere Situation als auf einer öffentlichen Webseite, wo ich nicht von Haus aus weiß, wer jetzt auf meine Webseite kommt und wer nicht. Und diese Anpassungen sind im WCAG 2.0 möglich. Und, die umfangreiche Dokumentation sehen wir eigentlich als Vorteil. Am Anfang erscheint das als, jetzt werde ich erschlagen mit 500 Seiten oder so, aber wir machen wirklich die Erfahrung, umso mehr wir dokumentieren können, umso mehr Information wir sammeln können, umso besser ist sie.
Was ich vielleicht an der Stelle erwähnen sollte ist, dass diese Techniken mit der Zeit wachsen werden. Die Techniken sind eine Knowledge Base, die dafür gedacht sind, dass sie wachsen und wachsen und wachsen und immer mehr dazukommen bzw. alte gehen weg. Und da seid ihr auch als Entwickler gefragt bzw. gebeten, eure Techniken oder eure, falls ihr Ideen habt, Lösungen habt, wie etwas umgesetzt werden kann, gibt es ein Formular, es gibt eine Möglichkeit, diese beizutragen. Also was wir machen ist, wir dokumentieren verschiedene Lösungen, es ist aber nicht gesagt, dass nur diese Lösungen die Möglichen sind.
Ich konnte mir nicht verkneifen, wer meine Vorträge kennt, zeige ich dieses Bild immer wieder und zwar die Komponenten von WCAG von Web-Barrierefreiheit. Ich konnte es mir auch bei diesem Vortrag nicht verkneifen. Es ist einfach sehr wichtig, zu verstehen, dass WCAG eine Teillösung ist. WCAG ist vielleicht ein Ziel, wie mache ich Content barrierefrei. Es gibt aber viele andere Komponenten. Auf dem Bild ist unten zu sehen die Kernspezifikationen des Web, HTML, XML, usw., auch nicht W3C-Technologien, PDF und so. Die müssen Barrierefreiheit auch drinnen haben. Die müssen Barrierefreiheit unterstützen.
Es gibt am Nachmittag einen Vortrag über WAI-ARIA z.B. Das ist ein Beispiel, wo wir in den Kerntechnologien versuchen, Barrierefreiheit um Webapplikationen zu ermöglichen, einzubauen. Es gibt dann auch den Bereich von Benutzeragenten, Browsern und assistierende Technologien. Wenn Sie Ihren Teil nicht machen, wenn Sie z.B. weiterhin das Longdesc-Attribut ignorieren, dann ist das weiterhin in der Praxis keine Lösung. Es ist nur theoretisch eine Lösung, aber sie müssen auch Ihren Teil zur Barrierefreiheit beitragen.
Und, last but not least, die Autorenwerkzeuge, ist auch extrem wichtig. WCAG sagt dir, wie die Inhalte ausschauen muss, aber wie man dort hin kommt, der Clou ist wirklich Autorenwerkzeuge, Autorenwerkzeuge und Evaluierungswerkzeuge, die dir helfen, auch diesen Status zu beinhalten, also beizubehalten. Z.B. Content-Management-Systeme, wenn Content-Management-Systeme dauernd nur einen Müll rausspucken, dann kann ich so viele Redesigns machen, wie ich will, am nächsten Tag ist alles, meine ganze Arbeit meine ganze Mühe schon wieder weg.
Ja, also das sind die Komponenten, das darf man einfach nicht vergessen, dass wir als Entwickler, oder dass die Entwickler eine Teillösung bilden, und dass andere Komponenten mitspielen müssen, und es kommt immer auf den Kontext. Was versuche ich zu machen und welche Technologien gibt’s, welche Annahmen kann ich machen? Also was kann HTML? Z.B. wenn ich ein eine Multimedia mache, einen Multimedia-Auftritt mache, ist HTML vielleicht keine gute Idee. Es gibt andere Formate, die besser sind dafür. Und ich muss einfach bedenken, was versuche ich zu machen, welche Lösungen gibt es und wie kann ich das am besten erreichen. Das ist im Wesentlichen auch was ich im WCAG 2.0 sich etabliert hat.
Ja, danke schön und [Lachen] das war’s. [Applaus]
Shadi Abou-Zahra