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.
Ja, danke für die Zuspitzung auf den BIENE-Wettbewerb – er trägt ja seit Jahren zur Identifikation mit dem Thema Barrierefreiheit bei. Ein permanentes Fehlen wird sich langfristig schon bemerkbar machen. Aber auch die fast völlige Absenz von Konferenzen zum Thema ist problematisch.
Ich denke, dass nach wie vor ein Tiefenwissen fehlt und zwar – das klang auch bereits in der Diskussion bei Wolfgang durch – einzelne Sachen angewendet werden, aber mangels dieses Tiefenverständnisses dennoch die von Dir beschriebene Info-Schere ziemlich offen ist. Dennoch wurde einiges erreicht und ich denke (oder besser hoffe), dass es gerade nur so ruhig ist, um besser Anlauf zu nehmen. Schaut man sich europäische Entwicklungen an, so könnte 2014 durch die dann voraussichtlich veröffentlichten Dokumente innerhalb des Mandats 376 ein wichtiges Jahr werden – auch wenn ich jetzt nicht davon ausgehe, dass dann ein Ruck durch Deutschland gehen wird.
“Selbst WCAG 2 und BITV 2 wirken mittlerweile veraltet angesichts der rasanten Entwicklung. Die WCAG 2 haben dabei den entschiedenen Vorteil, dass sich ihre Techniken nach und nach aktualisieren lassen.”
Dass die WCAG 2 veraltet wirken kann ich nicht nachvollziehen. Ich denke generell, dass die Bedeutung des Technikendokuments völlig überschätzt wird und die Techniken zu oft als quasi-normativ angesehen werden, obwohl sie nur Optionen sind und man nicht eine einzige verwenden müsste, um konform zu sein. Inzwischen ist einer meiner wesentlichen Kritikpunkte an den WCAG 2, dass die Techniken überhaupt ein Teildokument der WCAG 2 sind.
Das mit der Info-Schere zieht sich ja durch viele neue Themen – wenngleich Barrierefreiheit vergleichsweise ein “altes” ist. Irgendwie macht man ein wenig HTML5, packt da ein zwei Elemente rein, legt ein wenig das drüber oder drunter – egal. Ich vermisse in der Breite einfach das Nachdenken darüber, wie man all das nachhaltiger einsetzt. Bei Barrierefreiheit nehme ich das oft noch krasser war nach dem Motto – ach – Hauptsache wir setzen das überhaupt um.
Ich werde das gleich im Artikel genauer formulieren – ich beziehe mich bei BITV 2 und WCAG 2 natürlich auf die Techniken. Wenngleich ich denke, dass Techniken auch immer in Wechselwirkung stehen. Auch wenn WCAG 2 und BITV 2 technikneutral formulieren, implizieren sie immer auch gewisse Lösungen (Techniken). Was ich meine ist, dass die Entwicklung sehr rasch derzeit fortschreitet und viele der Lösungen schlicht schon wieder veraltet sind. Klar, kann man das alles noch so umsetzen, aber die neueren Lösungen fehlen noch. Ich denke, es wäre interessant, den Techniken so etwas wie ein Coming-Up nachzureihen – das gibt es ja schon im Ansatz unter den Lösungen, die zukünftig greifen können.
Ich verstehe Deinen Kritikpunkt, dass die Techniken ausgegliedert werden sollten. Dennoch finde ich als Entwicklerin es sehr gut bedienbar, zu konkreten Bedingungen auch immer gleich mögliche Lösungen zu erhalten. Wie denkst Du Dir die Ausgliederung? Wie sollten dann die Techniken erreichbar sein?
Ich denke, dass dieser Aspekt des “Verstehens” noch zu kurz kommt, also dieses “Warum” macht man etwas und was ist das eigentlich Wichtige daran. Weil: hat man das verstanden, dann kann man das auf jede Technologie übertragen.
Auch an dieser Stelle finde ich es immer weniger eine gute Idee, dass die Techniken Teil der WCAG sind. Hat man die Erfolgskriterien verstanden, dann kann man auch selber Techniken entwickeln und anwenden. Hier greift dann eben auch die Infoschere.
Es wird aber auf jeden Fall ein Technikenupdate kommen, der Zeitpunkt ist aber noch nicht klar. Ein Teil der aktuellen Diskussion kann über die Public Comments verfolgt werden und ein anderer Teil anhand des GL-Wiki auf http://www.w3.org/WAI/GL/wiki/Techniques.
Zu dem Technikenproblem. Das Wording “How to meet” finde ich mehr als unglücklich und ist geneigt, Leute auf die falsche Fährte zu schicken. Hier denke ich aber, dass man das schlicht nicht hat ahnen können. Es nutzt auch oft wenig, dass am Anfang des Dokument steht: Das ist alles nur optional usw. Ich denke für eine komplett neue Fassung – sofern die irgendwann mal kommen wird – wäre es gut, wenn es keinen direkten Link mehr von den Erfolgskriterien zu den Techniken geben würde und die Techniken als Dokument eben einfach von der WAI-Website aus erreichbar wären.
Eigentlich sollte es ja ein Vorteil sein, dass alles in einem Dokument ist. Ich hab nur den Eindruck, dass das eher nach hinten los gegangen ist, z.B. wenn sich in der deutschen BITV 2 ein Passus findet, der besagt, dass das Technikendokument die “anzuwendenden Techniken” für WCAG2 und entsprechend BITV 2 enthalten würde. Das führt dann quasi zu der kuriosen Situation, dass kombiniert man BITV2 mit aktueller Webentwicklung es wirklich veraltet wäre, obwohl das aus WCAG2-Sicht nicht der Fall ist. Und – abhängig davon wie sehr man sich nach der Begründung richten will – dazu, dass nach BITV2 HTML5 usw. nicht erlaubt wäre, da die Techniken (noch) nicht im Technikendokument sind und nach WCAG 2 es sehr wohl möglich ist, weil die Techniken ja nur Optionen sind.
Nun ja. Aber das sind vielleicht auch Aspekte, die viele nicht interessieren. Insgesamt denke ich ja immer mal: wir meckern zuviel an Websites herum und loben zu wenig.
Der Aspekt, ob zuviel an Websites kritisiert wird, liegt im Auge des Betrachters. :) Und macht eine andere inhaltliche Ecke auf. Ich finde, fundierte Kritik ist wichtig. Das mit dem Loben ist halt so eine Sache. Wenn die Webseite barrierefrei angelegt ist, dann kann man das lobend erwähnen. Ich halte das aber schon für selbstverständlich. Ist ein Relaunch es nicht oder nur teilweise, dann sollte man das sehr wohl anmerken.
Es gibt einfach wichtige Infobereiche, wo es wirklich nicht nötig ist, dass ein Relaunch barrierefrei ist – wie etwa im Zeitungsbereich. Dass komplett auf Überschriften verzichtet wird etc., ist ein Unding.
Der Hinweis mit dem lobenden Finger kenn ich zu gut aus anderen Bereichen, wo gerne damit Kritik unterdrückt wird. Deswegen bin ich da sehr hellhörig. :)
Danke für den Hinweis auf das WCAG 2 Technik WIKI – interessant, wenngleich zu HTML 5 etwa nur Stichwörter stehen.
Ich denke nach wie vor, dass es wichtig ist, für den Entwickler eine direkte Verbindung zu den Techniken zu setzen. Ich gehe da von der konkreten Arbeit aus, wenn man mal was schnell nachsehen will, wie der aktuelle Stand der Umsetzung ist, und dann erst mal kramen muss, dann hat die Barrierefreiheit schon verloren. Aber ganz richtig, man müsste sich mal Gedanken machen, wie man das anders zusammenführen kann.
Irgendwie hatte ich auch noch in Erinnerung, dass da bei den hinreichenden Techniken so was stand wie “1 oder mehrere Techniken müssen erfüllt sein” … Das scheint aber inzwischen rausgenommen worden zu sein. Interessant.
Ich habe mit WCAG2 (und in der Folge BITV2) ein paar Probleme - ich finde, dass beide selbst eine erhebliche Verständnishürde darstellen, ohne vorhandenes Vorwissen in Sachen Accessibility steigt man da einfach nicht durch - von Technikunabhängigkieit kann nirgends die Rede sein; Beispiel 1: wer sagt, dass es immer ein Keybard gibt? (vgl. mobile devices) Beispiel 2: warum heisst WCAG wohl so (W – web)? Beispiel 3: was an den Success Criteria ist überhaupt technologie-unabhängig – das ganze riecht 99% nach einer HTML-basierten Webseite…?
Mich ärgert das, weil mir das Thema am Herzen liegt, aber hier nicht ergebnisorientiert gedacht und gearbeitet wird. Es genügt nicht, dass sowas wie WCAG2 oder BITV2 (sachlich/politisch/ethisch/…) “richtig” ist, es muss auch praktikabel sein. An letzterem fehlt es halt leider noch erheblich, und es ist nicht erkennbar, wer sich aktiv dafür engagiert das zu ändern. Und das zu einem Zeitpunkt, wo ich glaube, dass viele, die es angeht, für dieses Thema an sich sehr offen sind, aber letztlich an der Barriere WCAG2/BITV2 scheitern.
Ich finde es wichtig, dass zur BITV 2 und WCAG 2 Rückmeldungen von Entwicklern kommen. Ich stimme da in einigem zu, anderem nicht. :)
Klar, das ist auch mein Argument, jemand der ins barrierefreie Thema rein will, dem ist WCAG 2 und BITV 2 einfach zu wenig klar und einladend. Das liegt aber vor allem daran, dass es eben möglichst neutral formuliert ist. Die genaueren Beschreibungen und die möglichen Lösungen müssten dann aber jedem Entwickler vertraut sein. Ich finde, dass da sehr viel Information drin steckt. Freilich kann ich heute auch schwer beurteilen, wie sich das liest, wenn man noch neu im Thema ist. Was mir eher Kopfschmerzen macht ist, dass die Techniken halt auch sich gegenseitig bedingen und ausschliessen können. Realisiert jetzt jemand nach Punkte- und Beuteschema das, können auch Probleme auftreten.
Ja, das mit der Technikunabhängigkeit sehe ich genauso. Man müsste Tastatur halt auch variabel formulieren. Wie sieht das auf mobilen Endgeräten aus. Wie auf TV-Ausgaben. Und ja – zu einem großen Prozentsatz geht auch die WCAG 2 davon aus, dass es sich noch um eine Webseite handelt. Andererseits gibt es etwa auch das ganze Paket für PDF-Dokumente. Ich denke, wir können auch eines für Mobile demnächst erwarten. Das wäre der nächste wichtige Schritt.
Ich habe jetzt nicht so den Einblick, ob und wie Anwenderfragen in die WCAG 2 einfliessen – die BITV 2 wird davon eher unberührt bleiben, sie ist ja eher statisch angelegt. Dazu kann Kerstin Probiesch vielleicht mehr sagen. Aber – da stimme ich zu – ganz praktikabel ist das alles vom Konzept her noch nicht. Vor allem nicht für Neueinsteiger.
Ich werde auch noch einen Artikel schreiben, wie sich der Workflow für den barrierefreien Entwickler jetzt zusätzlich mit BITV 2 verändert hat, leider nicht zum Guten.
Ich schreibe meine Einsichten aus mehreren Perspektiven: - als Entwickler (für Software für die barrierearme Erstellung von [vor allem PDF-] Dokumenten) - als Entwickler, der den künftigen Nutzern seiner Software rüberbringen möchte, was sie mit der Software machen können - dabei muss ich ihnen im Kontext barrierearmer PDF-Dokumente auch erläutern, warum man da überhaupt tun sollte, was die wichtigsten Aspekte dabei sind, wie man da am besten rangeht usw. usf. - ich muss auch Dienstleistern (die entsprechende Leistungen, hoffentlich dann auch mit Hilfe meiner Software, erbringen) und Einkäufern solcher Dienstleistungen plausibel machen, um was es hier geht - in ähnlicher Form muss ich Führungskräften (die z.B. Budget-Entscheidungen treffen) klar machen, warum sie vorhandene Mittel eher für bessere (barrierearme) Dokumente ausgeben sollen und nicht für anderes, und ich muss ihnen auch plausibe machen können, dass eine entsprechende Budget-Entscheidung einen wahrnehmbaren (und nicht nur einen homöopathischen) sowie einen nachhaltigen Effekt hat - ich muss sowohl Anwendern (z.B. Dienstleistern oder auch ganz normalen Dokument-Produzenten) eine klare und unmissverständliche Information geben können, wann sie “fertig sind”, also wann sie genug Aufwand investiert haben, um ihr Dokument mit Fug und Recht als ausreichend barrierefrei bezeichnen zu können (sowohl aus vertraglichen oder rechtlichen Gründen, ganz wesentlich aber auch aus sehr persönlichen Gründen, im Sinne von Anspruch an sich selbst, Motivation, Zufriedenheit, … – wer Freude an seiner Arbeit hat und ihren Sinn erkennt, arbeitet viel besser und effektiver) als auch Entscheidern einen klaren Orientierungspunkt dahin gehend, wann sie ihren selbst gewählten oder von außen (z.B. rechtlich) diktierten Anfoderungen ausreichend gut gerecht geworden sind.
In fast keiner der o.g. Hinsichten ist eine Weiterbildungsmaßnahme “WCAG und ich/mein Unternehmen” auch nur näherungsweise darstellbar. Außer einem lustigen ‘wie mache ich einen alternativen Text richtig’ kommt da nix bei raus (nicht das irgendjemand zweifelsfrei wüsste, wie man einen alternativen Text richtig macht).
Aus meiner Sicht hat sich daher auch in den vergangenen 10 Jahren eine Szene von Barrierefreiheits-Spezialisten entwickelt, die die einzigen sind, die WCAG kapieren und wenigstens halbwegs im Griff haben.
Stößt man von außen in diese Welt, wirkt sie sehr hermetisch. Fragt man zudem zwei dieser Experten zum selben Thema, hört man sehr oft zwei Antworten, die praktisch nicht miteinander verträglich sind.
Ein weiteres riesengroßes Problem ist, dass der Kenntnisstand der Mehrzahl der Agierenden in diesem Umfeld von dem geprägt ist, was bisher machbar ist – z.B. machbar mit oftmals älteren Versionen von assistierender Technologie oder Betriebssystemen, oder mit älteren Versionen von Basisprogrammen wie z.B. Adobe Acrobat. Ich als Sofwtareenwtickler (und auch als Multiplikator von Inahkten, die ich für wichtig halte), muss stark nach vorne in die Zukunft denken. Ich stelle mir immer die Frage: wie ich kann ich meine Resorucen einsetzen, damit es “morgen” besser wird (das meine ich jetzt ganz allgemein, nicht spezifisch im Kontext Barrierefreiheit), und welche Weichen müssen gestellt werden, damit das passierern ann (deshalb bin ich z.B., seit über 12 Jahren in der ISO-Normung aktiv).
Ich weiss dabei, dass Auswirkungen, die auf Software beruhen, immer und ausnahmslos zwei Jahre bis fünf Jahre benötigen, bis sie sich breit machen. Das gilt sogar für sehr große Softwarefirmen, auf jeden Fall aber für kleine wie meine eigene. Damit wird es piepegal, wie limitiert heute allgemein eingesetzte Software sein mag, weil in fünf Jahren sowieso alle (etwas) neuere Versionen einsetzen. Statt also vor allem herauszufinden, wie ich mit einem Programm zurecht kommen kann, das eigentlich schon ein bisschen zu sehr abgehangen ist, wäre es wichtiger, den Hersteller des Programms zu bedrängen, dass er endlich einen guten Job macht.
Deswegen sind z.B. aus meiner Sicht die PDF-Techniques totaler Blödsinn. Um es mal ganz doll auf die Spitze zu treiben: das Ansinnen, möglichst alle Leute – und nicht nur spzeialisierte Dienstleister – sollten ernsthaft Acrobat einsetzen, um ein PDF barrierefrei zu machen, ist mit “extreme Zumutung” noch sehr höflich umschrieben. Solange ich solche Zumutungen betreibe, werden gute barrrierefreie Dokumente die Ausnahme bleiben.
Wünschenswert wäre aber, dass möglichst viele Dokumente und Inhalte barrierearm werden.
Sie schreiben “Deswegen sind z.B. aus meiner Sicht die PDF-Techniques totaler Blödsinn.”. Ich denke, dass es sich hier um ein Missverständnis bezüglich des Charakters der Techniken handelt.
Nach WCAG 2.0 sind alle Techniken optional: man kann sie verwenden, man muss sie jedoch nicht verwenden. Es steht jedem frei, eigene/andere Techniken zu verwenden und wenn damit die Erfolgskriterien der jeweiligen Konformitätsstufe erfüllt sind, dann ist das Webdokument konform zu dieser Stufe. Es steht außerdem jedem frei, seine/andere Techniken über die Public Comments zu melden.
Obgleich mit “totaler Blödsinn” natürlich eine absichtlich zugespitzte Formulierung gewählt wurde – im Kern stehe ich zu meiner Aussage. Mir ist schon klar, dass es keine WCAG-Polizei gibt, die den Einsatz von PDF Techniques erzwingt. Aber sie wird von WCAG-Anhängern zu oft in den Status des faktisch unausweichlichen gehoben.
Schaue ich mir zum Beispiel “Example 4: Checking the reading order using Reflow in Adobe Acrobat 9 Pro” an, wird mir ganz anders. Reflow ist das am wenigsten sinnvolle Instrument in puncto Barrierefreiheit und PDF, das ich kenne. Reflow kümmert sich überhaupt nicht um die eigens definierte Lesereihenfolge, sondern stellt alle Seitenbestandteile einer Seite in der Reihenfolge dar, wie sie zufällig in der Seitenbeschreibung kodiert sind. Wozu der ganze Aufwand mit der Logischen Struktur, wenn ein solches Kontrollinstrument empfohlen wird, das die Logische Struktur ignoriert? Außerdem ist Reflow so verkorkst, dass es bei allen nicht-trivialen Layouts auf die Nase fällt, und womöglich garnichts mehr zu erkennen ist.
Genauso ungeeignet ist denn auch “Example 6: Repairing the reading order using the Order panel in Adobe Acrobat 9 Pro”. Als könnte man mit einer Rohrzange eine Taschenuhr reparieren. Außer bei trivialen Layouts ist dieses Werkzeug tödlich für die Integrität der betreffenden Seite.
Dessen ungeachtet taucht auf BITV-getriebenen Aufträgen und Ausschreibungen das Kriterium auf “Muss PDF Techniques vollständig erfüllen”.
Vom ganzen Ansatz her sind die PDF Techniques ziemlich “Hardcore”, und es wäre an der Zeit, dass leichter verdauliche und praktisch umsetzbare Konzeipte erarbeitet werden, und ggf. den Herstellern auf die Füße getreten wird, um entsprechende Sofwtare-Unterstützung einzufordern. Für die Zeit nach der Reflow-Steinzeit.
Olaf
@ Olaf Drümmer
“Mir ist schon klar, dass es keine WCAG-Polizei gibt, die den Einsatz von PDF Techniques erzwingt. Aber sie wird von WCAG-Anhängern zu oft in den Status des faktisch unausweichlichen gehoben.”
Es geht nicht um erzwingen oder nicht oder (k)eine Polizei. In den WCAG 2.0 steht explizit drin, dass diese nur optional sind, z.B. in der Einleitung zum Technikendokument. Diejenigen, die die Umsetzung nach WCAG 2.0 betonen sowie die WCAG Arbeitsgruppe selber wird nicht müde, das auch immer wieder zu betonen und zu wiederholen.
“Dessen ungeachtet taucht auf BITV-getriebenen Aufträgen und Ausschreibungen das Kriterium auf “Muss PDF Techniques vollständig erfüllen”.”
Dies ist nun ein ganz anderer Fall. Leider steht in der BITV 2.0, dass es sich bei den Techniken um “anzuwendende Techniken” handeln würde. Nach WCAG 2.0 ist dies wie oben schon dargestellt wurde, jedoch nicht so. Dies hat dann jedoch nichts mit den WCAG 2.0 zu tun, sondern mit der deutschen Rezeption. In diesem Fall wäre es sinnvoller auf die BITV 2.0 hinzuwirken.
@Olaf Drümmer: Da kann ich leider nichts Kluges zu sagen. Nur, dass die Begründung durchaus ‘Kriterien’ für eine Überprüfung der BITV 2 enthält und sie damit nicht “in Stein gemeißelt’ ist.
Wegen BIENE. Die Aktion Mensch ist ja auf Tauchstation daher muss man fragen: “Wie tot ist die BIENE?” http://www.bizeps.or.at/news.php?nr=13234
Ja, danke für die Zuspitzung auf den BIENE-Wettbewerb – er trägt ja seit Jahren zur Identifikation mit dem Thema Barrierefreiheit bei. Ein permanentes Fehlen wird sich langfristig schon bemerkbar machen. Aber auch die fast völlige Absenz von Konferenzen zum Thema ist problematisch.
Ich denke, dass nach wie vor ein Tiefenwissen fehlt und zwar – das klang auch bereits in der Diskussion bei Wolfgang durch – einzelne Sachen angewendet werden, aber mangels dieses Tiefenverständnisses dennoch die von Dir beschriebene Info-Schere ziemlich offen ist. Dennoch wurde einiges erreicht und ich denke (oder besser hoffe), dass es gerade nur so ruhig ist, um besser Anlauf zu nehmen. Schaut man sich europäische Entwicklungen an, so könnte 2014 durch die dann voraussichtlich veröffentlichten Dokumente innerhalb des Mandats 376 ein wichtiges Jahr werden – auch wenn ich jetzt nicht davon ausgehe, dass dann ein Ruck durch Deutschland gehen wird.
“Selbst WCAG 2 und BITV 2 wirken mittlerweile veraltet angesichts der rasanten Entwicklung. Die WCAG 2 haben dabei den entschiedenen Vorteil, dass sich ihre Techniken nach und nach aktualisieren lassen.”
Dass die WCAG 2 veraltet wirken kann ich nicht nachvollziehen. Ich denke generell, dass die Bedeutung des Technikendokuments völlig überschätzt wird und die Techniken zu oft als quasi-normativ angesehen werden, obwohl sie nur Optionen sind und man nicht eine einzige verwenden müsste, um konform zu sein. Inzwischen ist einer meiner wesentlichen Kritikpunkte an den WCAG 2, dass die Techniken überhaupt ein Teildokument der WCAG 2 sind.
Das mit der Info-Schere zieht sich ja durch viele neue Themen – wenngleich Barrierefreiheit vergleichsweise ein “altes” ist. Irgendwie macht man ein wenig HTML5, packt da ein zwei Elemente rein, legt ein wenig das drüber oder drunter – egal. Ich vermisse in der Breite einfach das Nachdenken darüber, wie man all das nachhaltiger einsetzt. Bei Barrierefreiheit nehme ich das oft noch krasser war nach dem Motto – ach – Hauptsache wir setzen das überhaupt um.
Ich werde das gleich im Artikel genauer formulieren – ich beziehe mich bei BITV 2 und WCAG 2 natürlich auf die Techniken. Wenngleich ich denke, dass Techniken auch immer in Wechselwirkung stehen. Auch wenn WCAG 2 und BITV 2 technikneutral formulieren, implizieren sie immer auch gewisse Lösungen (Techniken). Was ich meine ist, dass die Entwicklung sehr rasch derzeit fortschreitet und viele der Lösungen schlicht schon wieder veraltet sind. Klar, kann man das alles noch so umsetzen, aber die neueren Lösungen fehlen noch. Ich denke, es wäre interessant, den Techniken so etwas wie ein Coming-Up nachzureihen – das gibt es ja schon im Ansatz unter den Lösungen, die zukünftig greifen können.
Ich verstehe Deinen Kritikpunkt, dass die Techniken ausgegliedert werden sollten. Dennoch finde ich als Entwicklerin es sehr gut bedienbar, zu konkreten Bedingungen auch immer gleich mögliche Lösungen zu erhalten. Wie denkst Du Dir die Ausgliederung? Wie sollten dann die Techniken erreichbar sein?
Ich denke, dass dieser Aspekt des “Verstehens” noch zu kurz kommt, also dieses “Warum” macht man etwas und was ist das eigentlich Wichtige daran. Weil: hat man das verstanden, dann kann man das auf jede Technologie übertragen.
Auch an dieser Stelle finde ich es immer weniger eine gute Idee, dass die Techniken Teil der WCAG sind. Hat man die Erfolgskriterien verstanden, dann kann man auch selber Techniken entwickeln und anwenden. Hier greift dann eben auch die Infoschere.
Es wird aber auf jeden Fall ein Technikenupdate kommen, der Zeitpunkt ist aber noch nicht klar. Ein Teil der aktuellen Diskussion kann über die Public Comments verfolgt werden und ein anderer Teil anhand des GL-Wiki auf http://www.w3.org/WAI/GL/wiki/Techniques.
Zu dem Technikenproblem. Das Wording “How to meet” finde ich mehr als unglücklich und ist geneigt, Leute auf die falsche Fährte zu schicken. Hier denke ich aber, dass man das schlicht nicht hat ahnen können. Es nutzt auch oft wenig, dass am Anfang des Dokument steht: Das ist alles nur optional usw. Ich denke für eine komplett neue Fassung – sofern die irgendwann mal kommen wird – wäre es gut, wenn es keinen direkten Link mehr von den Erfolgskriterien zu den Techniken geben würde und die Techniken als Dokument eben einfach von der WAI-Website aus erreichbar wären.
Eigentlich sollte es ja ein Vorteil sein, dass alles in einem Dokument ist. Ich hab nur den Eindruck, dass das eher nach hinten los gegangen ist, z.B. wenn sich in der deutschen BITV 2 ein Passus findet, der besagt, dass das Technikendokument die “anzuwendenden Techniken” für WCAG2 und entsprechend BITV 2 enthalten würde. Das führt dann quasi zu der kuriosen Situation, dass kombiniert man BITV2 mit aktueller Webentwicklung es wirklich veraltet wäre, obwohl das aus WCAG2-Sicht nicht der Fall ist. Und – abhängig davon wie sehr man sich nach der Begründung richten will – dazu, dass nach BITV2 HTML5 usw. nicht erlaubt wäre, da die Techniken (noch) nicht im Technikendokument sind und nach WCAG 2 es sehr wohl möglich ist, weil die Techniken ja nur Optionen sind.
Nun ja. Aber das sind vielleicht auch Aspekte, die viele nicht interessieren. Insgesamt denke ich ja immer mal: wir meckern zuviel an Websites herum und loben zu wenig.
Der Aspekt, ob zuviel an Websites kritisiert wird, liegt im Auge des Betrachters. :) Und macht eine andere inhaltliche Ecke auf. Ich finde, fundierte Kritik ist wichtig. Das mit dem Loben ist halt so eine Sache. Wenn die Webseite barrierefrei angelegt ist, dann kann man das lobend erwähnen. Ich halte das aber schon für selbstverständlich. Ist ein Relaunch es nicht oder nur teilweise, dann sollte man das sehr wohl anmerken.
Es gibt einfach wichtige Infobereiche, wo es wirklich nicht nötig ist, dass ein Relaunch barrierefrei ist – wie etwa im Zeitungsbereich. Dass komplett auf Überschriften verzichtet wird etc., ist ein Unding.
Der Hinweis mit dem lobenden Finger kenn ich zu gut aus anderen Bereichen, wo gerne damit Kritik unterdrückt wird. Deswegen bin ich da sehr hellhörig. :)
Danke für den Hinweis auf das WCAG 2 Technik WIKI – interessant, wenngleich zu HTML 5 etwa nur Stichwörter stehen.
Ich denke nach wie vor, dass es wichtig ist, für den Entwickler eine direkte Verbindung zu den Techniken zu setzen. Ich gehe da von der konkreten Arbeit aus, wenn man mal was schnell nachsehen will, wie der aktuelle Stand der Umsetzung ist, und dann erst mal kramen muss, dann hat die Barrierefreiheit schon verloren. Aber ganz richtig, man müsste sich mal Gedanken machen, wie man das anders zusammenführen kann.
Irgendwie hatte ich auch noch in Erinnerung, dass da bei den hinreichenden Techniken so was stand wie “1 oder mehrere Techniken müssen erfüllt sein” … Das scheint aber inzwischen rausgenommen worden zu sein. Interessant.
Ich habe mit WCAG2 (und in der Folge BITV2) ein paar Probleme
- ich finde, dass beide selbst eine erhebliche Verständnishürde darstellen, ohne vorhandenes Vorwissen in Sachen Accessibility steigt man da einfach nicht durch
- von Technikunabhängigkieit kann nirgends die Rede sein; Beispiel 1: wer sagt, dass es immer ein Keybard gibt? (vgl. mobile devices) Beispiel 2: warum heisst WCAG wohl so (W – web)? Beispiel 3: was an den Success Criteria ist überhaupt technologie-unabhängig – das ganze riecht 99% nach einer HTML-basierten Webseite…?
Mich ärgert das, weil mir das Thema am Herzen liegt, aber hier nicht ergebnisorientiert gedacht und gearbeitet wird. Es genügt nicht, dass sowas wie WCAG2 oder BITV2 (sachlich/politisch/ethisch/…) “richtig” ist, es muss auch praktikabel sein. An letzterem fehlt es halt leider noch erheblich, und es ist nicht erkennbar, wer sich aktiv dafür engagiert das zu ändern. Und das zu einem Zeitpunkt, wo ich glaube, dass viele, die es angeht, für dieses Thema an sich sehr offen sind, aber letztlich an der Barriere WCAG2/BITV2 scheitern.
Olaf
Ich finde es wichtig, dass zur BITV 2 und WCAG 2 Rückmeldungen von Entwicklern kommen. Ich stimme da in einigem zu, anderem nicht. :)
Klar, das ist auch mein Argument, jemand der ins barrierefreie Thema rein will, dem ist WCAG 2 und BITV 2 einfach zu wenig klar und einladend. Das liegt aber vor allem daran, dass es eben möglichst neutral formuliert ist.
Die genaueren Beschreibungen und die möglichen Lösungen müssten dann aber jedem Entwickler vertraut sein. Ich finde, dass da sehr viel Information drin steckt. Freilich kann ich heute auch schwer beurteilen, wie sich das liest, wenn man noch neu im Thema ist. Was mir eher Kopfschmerzen macht ist, dass die Techniken halt auch sich gegenseitig bedingen und ausschliessen können. Realisiert jetzt jemand nach Punkte- und Beuteschema das, können auch Probleme auftreten.
Ja, das mit der Technikunabhängigkeit sehe ich genauso. Man müsste Tastatur halt auch variabel formulieren. Wie sieht das auf mobilen Endgeräten aus. Wie auf TV-Ausgaben. Und ja – zu einem großen Prozentsatz geht auch die WCAG 2 davon aus, dass es sich noch um eine Webseite handelt.
Andererseits gibt es etwa auch das ganze Paket für PDF-Dokumente. Ich denke, wir können auch eines für Mobile demnächst erwarten. Das wäre der nächste wichtige Schritt.
Ich habe jetzt nicht so den Einblick, ob und wie Anwenderfragen in die WCAG 2 einfliessen – die BITV 2 wird davon eher unberührt bleiben, sie ist ja eher statisch angelegt. Dazu kann Kerstin Probiesch vielleicht mehr sagen. Aber – da stimme ich zu – ganz praktikabel ist das alles vom Konzept her noch nicht. Vor allem nicht für Neueinsteiger.
Ich werde auch noch einen Artikel schreiben, wie sich der Workflow für den barrierefreien Entwickler jetzt zusätzlich mit BITV 2 verändert hat, leider nicht zum Guten.
Ich schreibe meine Einsichten aus mehreren Perspektiven:
- als Entwickler (für Software für die barrierearme Erstellung von [vor allem PDF-] Dokumenten)
- als Entwickler, der den künftigen Nutzern seiner Software rüberbringen möchte, was sie mit der Software machen können
- dabei muss ich ihnen im Kontext barrierearmer PDF-Dokumente auch erläutern, warum man da überhaupt tun sollte, was die wichtigsten Aspekte dabei sind, wie man da am besten rangeht usw. usf.
- ich muss auch Dienstleistern (die entsprechende Leistungen, hoffentlich dann auch mit Hilfe meiner Software, erbringen) und Einkäufern solcher Dienstleistungen plausibel machen, um was es hier geht
- in ähnlicher Form muss ich Führungskräften (die z.B. Budget-Entscheidungen treffen) klar machen, warum sie vorhandene Mittel eher für bessere (barrierearme) Dokumente ausgeben sollen und nicht für anderes, und ich muss ihnen auch plausibe machen können, dass eine entsprechende Budget-Entscheidung einen wahrnehmbaren (und nicht nur einen homöopathischen) sowie einen nachhaltigen Effekt hat
- ich muss sowohl Anwendern (z.B. Dienstleistern oder auch ganz normalen Dokument-Produzenten) eine klare und unmissverständliche Information geben können, wann sie “fertig sind”, also wann sie genug Aufwand investiert haben, um ihr Dokument mit Fug und Recht als ausreichend barrierefrei bezeichnen zu können (sowohl aus vertraglichen oder rechtlichen Gründen, ganz wesentlich aber auch aus sehr persönlichen Gründen, im Sinne von Anspruch an sich selbst, Motivation, Zufriedenheit, … – wer Freude an seiner Arbeit hat und ihren Sinn erkennt, arbeitet viel besser und effektiver) als auch Entscheidern einen klaren Orientierungspunkt dahin gehend, wann sie ihren selbst gewählten oder von außen (z.B. rechtlich) diktierten Anfoderungen ausreichend gut gerecht geworden sind.
In fast keiner der o.g. Hinsichten ist eine Weiterbildungsmaßnahme “WCAG und ich/mein Unternehmen” auch nur näherungsweise darstellbar. Außer einem lustigen ‘wie mache ich einen alternativen Text richtig’ kommt da nix bei raus (nicht das irgendjemand zweifelsfrei wüsste, wie man einen alternativen Text richtig macht).
Aus meiner Sicht hat sich daher auch in den vergangenen 10 Jahren eine Szene von Barrierefreiheits-Spezialisten entwickelt, die die einzigen sind, die WCAG kapieren und wenigstens halbwegs im Griff haben.
Stößt man von außen in diese Welt, wirkt sie sehr hermetisch. Fragt man zudem zwei dieser Experten zum selben Thema, hört man sehr oft zwei Antworten, die praktisch nicht miteinander verträglich sind.
Ein weiteres riesengroßes Problem ist, dass der Kenntnisstand der Mehrzahl der Agierenden in diesem Umfeld von dem geprägt ist, was bisher machbar ist – z.B. machbar mit oftmals älteren Versionen von assistierender Technologie oder Betriebssystemen, oder mit älteren Versionen von Basisprogrammen wie z.B. Adobe Acrobat. Ich als Sofwtareenwtickler (und auch als Multiplikator von Inahkten, die ich für wichtig halte), muss stark nach vorne in die Zukunft denken. Ich stelle mir immer die Frage: wie ich kann ich meine Resorucen einsetzen, damit es “morgen” besser wird (das meine ich jetzt ganz allgemein, nicht spezifisch im Kontext Barrierefreiheit), und welche Weichen müssen gestellt werden, damit das passierern ann (deshalb bin ich z.B., seit über 12 Jahren in der ISO-Normung aktiv).
Ich weiss dabei, dass Auswirkungen, die auf Software beruhen, immer und ausnahmslos zwei Jahre bis fünf Jahre benötigen, bis sie sich breit machen. Das gilt sogar für sehr große Softwarefirmen, auf jeden Fall aber für kleine wie meine eigene. Damit wird es piepegal, wie limitiert heute allgemein eingesetzte Software sein mag, weil in fünf Jahren sowieso alle (etwas) neuere Versionen einsetzen. Statt also vor allem herauszufinden, wie ich mit einem Programm zurecht kommen kann, das eigentlich schon ein bisschen zu sehr abgehangen ist, wäre es wichtiger, den Hersteller des Programms zu bedrängen, dass er endlich einen guten Job macht.
Deswegen sind z.B. aus meiner Sicht die PDF-Techniques totaler Blödsinn. Um es mal ganz doll auf die Spitze zu treiben: das Ansinnen, möglichst alle Leute – und nicht nur spzeialisierte Dienstleister – sollten ernsthaft Acrobat einsetzen, um ein PDF barrierefrei zu machen, ist mit “extreme Zumutung” noch sehr höflich umschrieben. Solange ich solche Zumutungen betreibe, werden gute barrrierefreie Dokumente die Ausnahme bleiben.
Wünschenswert wäre aber, dass möglichst viele Dokumente und Inhalte barrierearm werden.
Olaf
@ Olaf Drümmer
Sie schreiben “Deswegen sind z.B. aus meiner Sicht die PDF-Techniques totaler Blödsinn.”. Ich denke, dass es sich hier um ein Missverständnis bezüglich des Charakters der Techniken handelt.
Nach WCAG 2.0 sind alle Techniken optional: man kann sie verwenden, man muss sie jedoch nicht verwenden. Es steht jedem frei, eigene/andere Techniken zu verwenden und wenn damit die Erfolgskriterien der jeweiligen Konformitätsstufe erfüllt sind, dann ist das Webdokument konform zu dieser Stufe. Es steht außerdem jedem frei, seine/andere Techniken über die Public Comments zu melden.
@Kerstin Probiesch
Obgleich mit “totaler Blödsinn” natürlich eine absichtlich zugespitzte Formulierung gewählt wurde – im Kern stehe ich zu meiner Aussage. Mir ist schon klar, dass es keine WCAG-Polizei gibt, die den Einsatz von PDF Techniques erzwingt. Aber sie wird von WCAG-Anhängern zu oft in den Status des faktisch unausweichlichen gehoben.
Schaue ich mir zum Beispiel “Example 4: Checking the reading order using Reflow in Adobe Acrobat 9 Pro” an, wird mir ganz anders. Reflow ist das am wenigsten sinnvolle Instrument in puncto Barrierefreiheit und PDF, das ich kenne. Reflow kümmert sich überhaupt nicht um die eigens definierte Lesereihenfolge, sondern stellt alle Seitenbestandteile einer Seite in der Reihenfolge dar, wie sie zufällig in der Seitenbeschreibung kodiert sind. Wozu der ganze Aufwand mit der Logischen Struktur, wenn ein solches Kontrollinstrument empfohlen wird, das die Logische Struktur ignoriert? Außerdem ist Reflow so verkorkst, dass es bei allen nicht-trivialen Layouts auf die Nase fällt, und womöglich garnichts mehr zu erkennen ist.
Genauso ungeeignet ist denn auch “Example 6: Repairing the reading order using the Order panel in Adobe Acrobat 9 Pro”. Als könnte man mit einer Rohrzange eine Taschenuhr reparieren. Außer bei trivialen Layouts ist dieses Werkzeug tödlich für die Integrität der betreffenden Seite.
Dessen ungeachtet taucht auf BITV-getriebenen Aufträgen und Ausschreibungen das Kriterium auf “Muss PDF Techniques vollständig erfüllen”.
Vom ganzen Ansatz her sind die PDF Techniques ziemlich “Hardcore”, und es wäre an der Zeit, dass leichter verdauliche und praktisch umsetzbare Konzeipte erarbeitet werden, und ggf. den Herstellern auf die Füße getreten wird, um entsprechende Sofwtare-Unterstützung einzufordern. Für die Zeit nach der Reflow-Steinzeit.
Olaf
@ Olaf Drümmer
“Mir ist schon klar, dass es keine WCAG-Polizei gibt, die den Einsatz von PDF Techniques erzwingt. Aber sie wird von WCAG-Anhängern zu oft in den Status des faktisch unausweichlichen gehoben.”
Es geht nicht um erzwingen oder nicht oder (k)eine Polizei. In den WCAG 2.0 steht explizit drin, dass diese nur optional sind, z.B. in der Einleitung zum Technikendokument. Diejenigen, die die Umsetzung nach WCAG 2.0 betonen sowie die WCAG Arbeitsgruppe selber wird nicht müde, das auch immer wieder zu betonen und zu wiederholen.
“Dessen ungeachtet taucht auf BITV-getriebenen Aufträgen und Ausschreibungen das Kriterium auf “Muss PDF Techniques vollständig erfüllen”.”
Dies ist nun ein ganz anderer Fall. Leider steht in der BITV 2.0, dass es sich bei den Techniken um “anzuwendende Techniken” handeln würde. Nach WCAG 2.0 ist dies wie oben schon dargestellt wurde, jedoch nicht so. Dies hat dann jedoch nichts mit den WCAG 2.0 zu tun, sondern mit der deutschen Rezeption. In diesem Fall wäre es sinnvoller auf die BITV 2.0 hinzuwirken.
@Kerstin Probiesch:
“In diesem Fall wäre es sinnvoller auf die BITV 2.0 hinzuwirken.”
… und was wäre der beste Weg, dies zu tun?
Olaf
@Olaf Drümmer: Da kann ich leider nichts Kluges zu sagen. Nur, dass die Begründung durchaus ‘Kriterien’ für eine Überprüfung der BITV 2 enthält und sie damit nicht “in Stein gemeißelt’ ist.