Wir kennen schon alles: #html5, #css3, #responsive webdesign, #mobile first und #flex layout. Und das alles #barrierefrei? Aber klar doch, weil mir #accessibility einfach Spass macht.
0 thoughts on “WCAG Samurai machen es sich schlicht zu einfach”
> 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 IFRAMES abzuheben, 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 ACCESSKEYS bliebe 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 den TABINDEX.
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 ACCESSKEY abzusetzen. :-) Nicht mehr und nicht weniger.
> 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.