sprungmarker testet

Re: Ist die Barrierefreiheit tot?

Wolfgang Wiese hat eine wichtige Frage gestellt: Ist die Barrierefreiheit tot?. Ganz abgesehen davon, ob diese Frage klar beantwortet werden kann, schließt sich an, warum stellen wir zum Thema Barrierefreiheit immer wieder die gleichen Fragen.

Man könnte jetzt mit so voll- bzw. volksmundigen Antworten beginnen, wie Totgesagte leben ohnehin immer länger oder derzeit sind Zombies wieder hoch im Kurs oder waren es Vampire. 😉 Aber lassen wird das mal beiseite – beginnen wir mit dem Sezieren. Wolfgang Wiese geht das Thema von zwei Seiten an, warum es still geworden ist um das Thema Barrierefreiheit. Zum einen könnte es ein positives Ergebnis sein: Allen ist das Thema präsent und zur Routine geworden – es ist kein Extra-Thema mehr. Zum anderen könnte es sein, dass das Thema niemanden mehr interessiert, die wenigen Rührigen haben aufgegeben und sich anderen Themen zugewandt.

Barrierefreiheit ist zur Routine geworden

Durchaus lässt sich das sagen, in den Kommentaren zum Artikel wird das auch angemerkt. Seit 2004 – das ist die magische Marke, die Wiese ansetzt – hat sich tatsächlich viel verbessert. Gerade Blog- und CMS-Systeme haben die Ausgaben der Inhalte optimiert. Aber das ist ja stets so, zuerst wird ein neues Thema erschlossen und erst einige Zeit später greifen dann auch die barrierefreien Standards nach und nach. Das heißt jetzt nicht, dass alle Systeme auf grün stehen würden, aber mit und ohne Druck von Betroffenen bewegt sich immer wieder ein Stück. Ich kenne das von WordPress ganz gut, ein ewiger Prozess-Kaugummi, bis sich wieder was bewegt.

Barrierefreiheit ist zwar zur Routine geworden, was auch meint, dass etwa Entwicklern das Thema durchaus bekannt ist, aber meiner Ansicht nach gibt es eine barrierefreie Info-Schere. Man weiß etwa über WAI-ARIA etwas, wendet es aber entweder nicht an, falsch oder sieht sich den Gesamtrahmen nicht an. Das ist ein großes Problem. Durch die rasante Entwicklung der sagen wir mal letzten 2 Jahre kommen soviele neue Themen auf die Barrierefreiheit zu, dass noch weniger auf den Gesamtrahmen acht gegeben und schlicht auf Verdacht angewendet wird. Nach dem Motto: Da nehme ich mal ein wenig WAI-ARIA und dann noch ein wenig HTML5 Formularvalidierung etc. Für mich zeigt sich ein klarer Trend der Vereinfachung von Barrierefreiheit, der ohnehin schon gerne vorherrschte: Was leicht geht und schnell, das wird eingesetzt. Was kümmert schon noch eine konsistente Überschriftenhierarchie, schließlich sind ja Überschriften eingebaut. Vertiefung und Feinschliff im Thema Barrierefreiheit ist meiner Ansicht nach leider nicht zur Routine geworden. Und angesichts der rasanten Entwicklung wird das nicht besser werden.

Barrierefreiheit ist nicht zur Routine geworden

Auch das lässt sich durchaus häufig finden, Barrierefreiheit wird da immer noch nicht in den Gesamtprozess eingebunden, sondern behält ihren Extrastatus. Damit steht sie nicht alleine derzeit, das findet man auch bei grundsätzlichen Konzepten wie der mobilen Optimierung, wo das Mobile gerne dem Desktop nachgereicht wird. Zuerst machen wir alles für das Herkömmliche fertig – weil wir uns da gut auskennen und den Rest reichen wir später nach. Konzepte wie Mobile First werden noch lange brauchen, bis sie wirklich verstanden und routinemäßig umgesetzt werden. Bis dahin wird an Bestehendes geklammert.

Viele aktuelle Debatten erinnern daher sehr stark an die zur Barrierefreiheit. Im Grunde könnte man hier einhaken und argumentative Hilfslinien ziehen, damit das Thema wieder aktueller wird. Auch so ein Luxus-Problem, dass das Thema Barrierefreiheit sich eben seit 2004 massiv gewandelt hat. sollte thematisiert werden. 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.

Und wenn wir ganz ehrlich sind, die BITV 2 hat es uns nicht leichter gemacht. Nun sind wir als Entwickler ohnehin schon mit einer gewissen Schallgeschwindigkeit unterwegs und müssen uns auch noch mit teilweise völlig diffusen Abweichungen zwischen Empfehlung und Gesetzgebung abquälen. Dabei dachten wir, mit den WCAG 2 sei es ja nun eindeutiger und klarer geworden, einen Auftritt barrierefrei zu erstellen. Man kann einer aktuellen Debatte zustimmen, die WCAG 2 richten sich schon in großen Teilen an den avancierten Entwickler. Auch hier haben wir wieder die barrierefreie Info-Schere. Kann man den Gesamtrahmen nicht erfassen und weiß man nicht, wie Techniken sich untereinander bedingen und auch ausschließen können, landet man schnell wieder im alten Punkte-Abarbeiten. Dann setzt man gerne das um, was man eh kennt und den Rest lässt man dann außen vor, auch wenn es für den konkreten Anwendungsfall wichtiger gewesen wäre.

Barrierefreiheit ohne Szene geht das überhaupt?

Auch da hat Wiese vollkommen recht, es ist still geworden in der deutschsprachigen Szene. Das hat viele Gründe – einige werden genannt, andere in den Kommentaren zum Artikel wieder abgearbeitet. Ich mag dazu nicht mehr viel sagen. Klar finde ich es schade, dass es so ist, wie es ist. Nehme aber durchaus auch wahr, dass an einigen Strängen trotzdem weiter gearbeitet wird etwa PDF und Barrierefreiheit – da wird wirklich wichtige Arbeit gemacht (axesPDF oder der PDF Accessibility Checker) oder an einem barrierefreien Testverfahren, sei es nun der BITV-Test oder ein noch kommendes Verfahren. Und wie Marco Zehe im Kommentar zum Artikel ganz richtig sagt, die Orientierung des barrierefreien Entwicklers geht aktuell schlicht in den englischsprachigen Raum. Dort bewegt sich mehr und lässt sich aufgrund von offenbar größeren Ressourcen mehr bewegen. Klar, es fehlen die Events, die früher das Thema fokussiert haben.

Freilich ganz so still und ohne entsprechenden gegenseitigen Resonanzboden ist es weit schwerer, immer am Thema dran zu bleiben. Dazu kommt die rasante Entwicklung, die einen dazu auffordert, beständig das Thema Barrierefreiheit mitzudenken und mitzunehmen. Ich mache das immer noch, aber präsentiere weniger meine Ergebnisse dazu. Das liegt zum einen daran, dass ich wirklich viel lerne, Kurse mache und mir Neues erarbeite. Und zum anderen, dass Energien halt auch begrenzt sind und ich mir überlege, wo ich sie noch hin packe. Und ach ja, ganz vergessen, einem neuen Job trete ich auch demnächst an und auch das wird meine Energien neu bündeln. 🙂

Aber bei mir ist der Wink mit dem argumentativen Zaunpfahl von Wolfgang Wiese durchaus angekommen, ich werde mal sehen, was ich abzwacken kann zum Thema.

Update

Auf eine Frage von Kerstin Probiesch hin präzisiere ich den Hinweis, dass WCAG 2 und BITV 2 schon veraltet wirken. Damit meinte ich die angeschlossenen Techniken. WCAG 2 und BITV 2 sind ja technikneutral formuliert und unterliegen damit einer gewissen permanenten Aktualität. Obwohl ich glaube, dass man gar nicht so technikneutral formulieren kann, dass es nicht doch letztlich an gewisse technische Rahmenbedingungen gebunden bleibt.

14 Antworten auf “Re: Ist die Barrierefreiheit tot?”

    1. 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.

  1. 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.

    1. 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?

      1. 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.

        1. 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.

  2. 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

    1. 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.

      1. 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

        1. @ 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.

          1. @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

  3. @ 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.

  4. @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

    1. @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.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert