Ja, zugegegeben. Die WCAG 1.0 Richtlinien und im Anschluss das BITV in ein Webprojekt umzusetzen, kann auch sehr viel Handarbeit erfordern. Es sich jedoch dadurch leichter zu machen, dass man einfach mal alle Punkte, die umstritten sind und meist auch noch zusätzliche Arbeit machen, wegzulassen, ist der falsche Ansatz.
Das Korrekturen-Papier der WCAG Samurai macht aber genau das.
Man muss sich dieses Dokument mal richtig auf der barrierefreien Zunge zergehen lassen – schon aus der Einleitung kann man die wesentliche Schlagrichtung entnehmen:
Den Ball zum Browserhersteller zurückspielen
Wenn im WCAG 1.0 der Verweis auf Browserbedingtheiten oder -unzulänglichkeiten gesetzt ist, wird immer eine Lösung angeboten, bis Browserunterstützung diese hinfällig macht. Die Samurais fordern nun, auf diese Techniken und Lösungen ganz zu verzichten, weil das Browsersache ist. Gut: auch ein Argument! Aber wie weit führt das? Seit den Zwistigkeiten um HTML 5 und den jeweiligen Interessensgruppen wissen wir, dass das nicht der Weg sein kann. Wer weiss, wann die Browserhersteller das eine oder andere Problem überhaupt als solches erkennen. Allein der weite Weg bis dato und die fehlende Unterstützung diverser HTML und CSS-Techniken sollte doch zu denken geben.
Das ist definitiv der falsche Ansatz. Damit meine ich jedoch auch, dass der Ball immer wieder zum Browserhersteller zurückzuspielen ist.
WCAG 1.0 Priorität 3 komplett vernachlässigen
Aber genau die Punkte der Priorität 3 sind heiss umkämpft und machen in der Implementierung die meiste Arbeit. Sei es der sinnvolle, wenn auch geringe Einsatz von ACCESSKEYS, der SUMMARY für die Datentabelle und mögliche Abkürzungen für die Überschriten von Datentabellen, der nicht immer leicht handhabare TABINDEX, die zusätzlichen Erweiterungen und Optimierungen von Navigationen oder die SKIPNAV-Möglichkeit – all diese Elemente sind sinnvoll und längst Standard in barrierefreien Auftritten, mal mehr und mal weniger eingesetzt. Und sie sind alle Priorität 3, im BITV Priorität 2.
Da kommen nun die Samurais und sagen, nee – brauchen wir alles nicht (mehr). Gut, auch ein Ansatz. Aber ein wirklich merkwürdiger.
Dafür sind wir an anderer Stelle härter 🙂
Ansonsten bieten die Samurais nicht viel neues unter der WCAG Sonne. Sie spitzen nur noch weiter zu, wo das WCAG 1.0, weil aus dem Jahre 1999, verständliche Spielräume offen gelassen hat.
Ja – keine Layouttabellen und keine Frames. Wissen wir schon. Deshalb auch gleich die WCAG 1.0 Priorität 2 zum Muss-Kriterium erheben. Aber auch hier sind einige Punkte umstritten wie Zitatauszeichnung und die genaue Linkzielangabe.
Aber sicherlich kann man den Samurais hier am ehesten folgen. Der verstärkte Fokus auf zugängliche PDFs und Multimedia Inhalte ist ehrenvoll und wichtig. Gerade das Transkribieren von Audioquellen wäre sicherlich immer mehr wünschenswert, aber meisthin wird das gar nicht in Erwägung gezogen.
Fazit
Ich halte aufgrund der völlig überzogenen Ansätze – sowohl positiver als auch negativer Art -, diese WCAG 1.0 Neudefinition (den Bezug auf das WCAG 2.0 Update schliessen die Samurais ja völlig aus) für nicht geeignet, um über eventuelle Aktualisierungen hinsichtlich des BITVs überhaupt nachzudenken. Dieser Versuch, das WCAG 1.0 zu aktualisieren ist heroisch – sicherlich, zeigt aber die gleichen Schwächen wie das WCAG 2.0 mit der zusätzlichen Einschränkung, dass der Wille, etwas zu renovieren, noch lange nicht hinreicht.
> Es sich jedoch dadurch leichter zu machen, dass man einfach mal alle Punkte, die umstritten sind und meist auch noch zusätzliche Arbeit machen, wegzulassen, ist der falsche Ansatz.
Ziel der WCAG Samurai ist nicht, es sich möglichst einfach zu machen, indem man möglichst viele Punkte weglässt. Zudem streicht das Errata-Dokument keine »umstrittenen« Punkte, sonder Punkte, die nach dem aktuellen Stand der Technik unumstritten überholt sind:
– Die Pflicht zur Vorbelegung von Formularfeldern ist nicht umstritten, sondern ganz einfach überholt.
– Dass Layout-Tabellen nicht mehr dem Stand der Technik im Jahre 2007 entsprechen ist doch wohl auch unumstritten. Folgerichtig braucht man auch keine Checkpunkte mehr in den Richtlinien, die sich einzig und alleine mit Layout-Tabellen befassen.
– Frames waren schon immer ekelig und werden mit zunehmendem Alter immer ekeliger. Warum braucht man also Checkpunkte in den Richtlinien, um eine Technik künstlich am Leben zu halten, die eh niemand mehr benutzt?
– Im Jahre 2007 baut niemand mehr Datentabellen aus ASCII-Art, weil noch nicht alle Browser Tabellen beherrschen (daher kommt diese Richtlinie!). Beibehalten?
– Abkürzungen, deren volle Bedeutung im Richtigen Leben niemand kennt, geschweige denn benutzt (DVD) müssen nicht mit abbr title=“…“ ausgezeichnet werden, weil das niemandem etwas nutzen würde. Zudem ist das »erste Auftreten« in der Praxis nicht definierbar. Was ist daran so schlimm, wenn dieser Punkt endlich klargestellt wird?
– bei einigen Richtlinien sagt selbst der amerikanische Gesetzgeber in der Literatur zur Section 508, dass man keine Ahnung habe, was das W3C wohl damit gemeint haben könnte – folgerichtig wurden diese Checkpunkte nicht übernommen (z.B. WCAG 6.2). Aber wir müssen sie hier weiter umsetzen?
> Die Samurais fordern nun, auf diese Techniken und Lösungen ganz zu verzichten, weil das Browsersache ist.
Stimmt. Die WCAG sind nur ein Drittel der Richtlinien. Ohne eine Umsetzung der UAAG und der ATAG kann man als Webentwickler noch so Verrenkungen machen – wenn die User Agents es nicht verstehen, oder die Autorenwerkzeuge es nicht ermöglichen, dann bekommt man am Ende auch nur ein Drittel Barrierefreiheit. Deswegen ist dieser deutliche Hinweis auf die Verantwortung Dritter vollkommen ok.
> Sei es der sinnvolle, wenn auch geringe Einsatz von ACCESSKEYS
Der Nachweis, dass Accesskeys tatsächlich geeignet sind, Barrieren für Menschen mit Behinderungen zu reduzieren, ist bisher nicht geführt worden. Ebenso fehlt der umgekehrte Beweis, dass die Abwesenheit von Accesskeys eine besondere Hürde für Menschen mit Behinderungen darstellen würde.
> der SUMMARY für die Datentabelle
Summaries in Datentabellen sind unsichtbare Daten und damit schlechte Daten. Für Screenreader-Nutzer sind sie eventuell zugänglich, für sehende Nutzer jedoch nicht, weshalb man sie zweimal hinterlegen muss. Damit hört der Screenreader-Nutzer die Daten dann zweimal. Soll man diese Richtlinie also künstlich am Leben erhalten, obwohl sie jeder menschlichen Vernunft widerspricht, nur um der Erhaltung der Richtlinien willens?
> Gerade das Transkribieren von Audioquellen wäre sicherlich immer mehr wünschenswert, aber meisthin wird das gar nicht in Erwägung gezogen.
Deswegen steht das genau so in den Errata: wenn Podcast mit Text, dann muss der Text als Text veröffentlicht werden und nicht nur als Audiodatei.
> diese WCAG 1.0 Neudefinition
Die WCAG Samurai versuchen keine Neudefinition des Themas. Es handelt sich lediglich um ein Dokument, dass die gröbsten Fehler der WCAG 1.0 behebt und die Richtlinien auf eine Linie mit 8 Jahren Weiterentwicklung im Web bringt. Nicht mehr und nichts weniger.
It is not accurate to say that summary on tables is banned because it’s in Priority 3. You may use it if your table requires it, as it is part of the HTML specification. What we are not doing is requiring it as part of Priority 3.
[quote comment=“1464″]It is not accurate to say that summary on tables is banned because it’s in Priority 3. You may use it if your table requires it, as it is part of the HTML specification. What we are not doing is requiring it as part of Priority 3.[/quote]
Joe Clark – this sounds for me a bit inconsistent. I really want to understand what WCAG samurais mean with the statement „No to Priority 3“?! Summary for tables so far as I know is priority 3 (Provide summaries for tables. [WCAG 1.0 – Priority 3]).
Of course you could leave it to everyone to find his way through WCAG 1.0, your Errata document and even WCAG 2.0.. And for myself it seems now more and more like a jungle.
For many of your arguments about the table summary, accesskeys, tabindex and so on i can understand the real concern, but not what we should do in between when for instance no browser vendor fullfills this or that feature request.
I read the the samurai document more like a manifesto. I am always interested in such. But a manifesto is mostly too pointed. 🙂
You’re required to follow HTML syntax, which may necessitate table summaries and so on. You aren’t required to use table summaries because Priority 3 says so.
I trust you understand that a feature may be required for more than one reason, and by getting rid of one of those reasons we haven’t gotten rid of all of them.
Of course I understand your argument. But should specifications or somehow ones that want to function as one try to avoid such things? I fear there will be then a backlash to other specifications as for instance HTML 5 – where also table issues are in discussion. So well …
Oh – ein deutschsprachiger Samurai – interessant. 🙂
Gut, was umstritten oder aktuell bestritten wird, läßt sich nachverfolgen. Davon sind etliche Punkte von den Samurais raugenommen worden. Und: mir fiel auf, dass die meisten Punkte der Priorität 3 des WCAG 1.0 angehören. Das mag Zufall sein oder auch nicht. Denn, soweit ich das aus meiner Webarbeit heraus beurteilen kann, sind das dann genau die Punkte, die wirklich zusätzlich zu erarbeiten sind, seien es Abkürzungen, Akronyme, Datentabellen oder Accesskeys.
Dass es sich die Samurais etwas zu einfach machen, war sicherliche eine Zuspitzung. Mir erschien es im Durchlesen des Manifestes schon so.
Die ersten Punkte, die Sie in Ihrem Kommentar anführen, würde ich nicht bestreiten bzw. die bestreitet ja auch das WCAG 1.0 schon nicht mehr völlig. 1999 ist lange her und zu der Zeit machte man noch in Tabelle und Frames. 🙂 Dass man heute noch immer auf diese Dinge hinweisen muss, ist schon fast anachronistisch.
Heute wäre von den Samurais eher auf
IFRAMESabzuheben, die ja nach wie vor sich großer Beliebtheit erfreuen, auch bei Kunden, die sich der Barrierearmut verschrieben haben.Lustig ist schon fast, dass die Sinnhaftigkeit von Abkürzungen und deren Kennzeichnung in HTML immer mit den gleichen einfachen, weil doch so geläufigen, Beispielen in Frage gestellt wird. Aber das wird doch schon in der HTML Spezifikation erkärt, dass das nur auf jene Abkürzungen zutrifft, die nicht jedem bekannt sind bzw. den Lesern nicht, die man als Publikum erwartet.
Zur Verwendung von
ACCESSKEYSbliebe anzumerken, dass die nicht nur fuer die Barrierefreiheit von Nutzen sein können, sondern für alle Nutzer, die sich gerne und häufig der Tastatur bedienen. Das gleiche gilt für denTABINDEX.Gut – man könnte hier noch weiter in Detailfragen gehen. Mir war nur wichtig anzumerken, dass die meisten der Punkte der Samurais ohnehin dem historischen Verfallsdatum des WCAG 1.0 zu verdanken sind (deswegen warten wir ja alle auf das Update des WCAGs) und etliche Punkte nicht in der Form wegzudiskutieren sind, weil sie eben nur eine Prio 3 haben und – wie Joe Clark ja weiter unten immer wieder anführt – im Ermessen des Entwicklers liegen, diese Techniken einzusetzen.
Vielleicht sollte man sich heute eher fragen, ob ein Richtlinie (Priorität 1) für alternativen Inhalt von etwa AJAX (also auch ohne AJAX die Inhalt erreichbar sein müssen) noch durchsetzbar ist oder nur in bestimmten Kontexten.
Ich möchte hier nicht missverstanden werden, ich bin die erste, die zu diesen Problemen immer nach einer alternativen Lösung ruft. Aber: wenn man ehrlich mit der Webentwicklung ist, es wird immer seltener, dass an diese Problematik gedacht wird.
Solche Fragestellung halte ich für dringlicher, als sich etwa vom
ACCESSKEYabzusetzen. 🙂 Nicht mehr und nicht weniger.