Kommentare zu dieser Meldung: 13

Bartosz Makara meinte am 19.03.2010:

Das Tool ist schon was feines und ich hatte mich schon gefreut, als ich diese Nachricht bei Twitter las, aber leider bin ich Linux-Nutzer und somit hat sich das leider für mich erledigt. :( Kennt jemand ansonsten etwas vergleichbares unter Linux?

Markus Riesch meinte am 19.03.2010:

Im Moment gibt es leider noch keine Version für Linux und Mac. Wir werden diesen Punkt aber gerne aufnehmen und abklären, ob eine Linux- und Mac-Version entwickelt werden kann.

Panthera IT meinte am 19.03.2010:

@Bartotz wieso erledigt, was ist mit Wine? Ich dachte das kennt jeder Linux User und meisten Nutzen es auch. Für das Program danke, werde man auch testen. Hatte ich gar nicht gedacht, dass bei PDF auch so um Barrieren Freiheit gehen könnte.

Petra Kubina meinte am 20.03.2010:

Hallo Markus,

es wäre klasse, wenn es das Werkzeug auch für Linux-Systeme gäbe. In Deutschland gibt es zunehmend Projekte, Linux zum Beispiel in Schulen oder Verwaltungen einzurichten. Hier ist allein schon der Zugriff durch freie PDF-Reader problematisch (aber das ist eine andere Baustelle ... ).

@PantheraIT: Die Wine-Alternative ist in diesem Rahmen ein Notbehelf - Sinn der freien Software ist ja unter anderem, dass sie durch alle motivierten Menschen weiterentwickelt werden kann und in Bezug auf barrierefreie PDF-Anwendungen gibt es hier noch echten Bremsen, die einer wirklich barriereFREIEN Software im Weg stehen.

Noch viel besser wäre also natürlich, wenn das Werkzeug echte freie Software wäre und von euch unter eine freie Lizenz gestellt würde! Seht ihr, Markus und Kollegen, dafür Möglichkeiten?

Herzliche Grüße

Marcus meinte am 22.03.2010:

Ich beschäftige mich schon seit einigen Jahren mit der Erstellung barrierefreier PDF-Dateien. Das Tool ist eher etwas für Bearbeiter, die sich in der Materie nicht so gut auskennen und evtl. auch keine Acrobat-Software besitzen. Bei uns durchlaufen alle Dokumente diese Prüfschritte in der abschließenden Qualitätssicherung. Die gängige - in Acrobat integrierte Ausgabehilfeprüfung - ist zwar alles andere als ein verlässlicher Prüfmechanismus, jedoch deckt auch sie die meisten der 12 Prüschritte recht zuverlässig ab.

Folgende Kritikpunkte habe ich:

- Prüfung der Lesereihenfolge kann niemals zuverlässig automatisch getestet werden (das Tool gibt für mich unverständliche Warhinweise aus). Eine ganz normal "links-rechts-oben-unten"-Reihenfolge wird als möglicherwweise fehlerhaft bezeichnet. Wer schon einmal Flyer oder Print-Broschüren getaggt bzw. aufbereitet hat weiß, dass hier ein kundiger Bearbeiter Hand anlegen muss, um eine logische Lesereihenfolge Reihenfolge im Umfließen zu garantieren. Woher soll ein Tool das auch wissen???!!!

- Korrekte Syntax von Tags - zunächst bietet der Adobe-Standard-Tag-Satz viele Entsprechungen zur HTML-Syntax. Hier und bei der Rollenzuordnung sollte man sich nach Möglichkeit immer daran orientieren. Das gewährleistet, dass assistive Technologien zumindest auf die wichtigsten Grundstrukturen einwandfrei zugreifen können. Die restlichen Adobe-Tags weichen schon eher grob von den derzeit interpretierbaren Grundstrukturen ab. Aber wer definiert denn, dass ich in einem TOC neben den TOCI keine Links verwenden darf, sondern z. B. Referenz? Was soll das? Und in Parts darf ich keine Anots verwenden? Recht seltsam! Woran habt ihr hier die Semantik festgemacht? Wo ist das Regelwerk, das dies definiert?

Samuel Hofer meinte am 22.03.2010:

@Marcus: Es ist richtig, dass die in Acrobat integrierte Prüfung die meisten Prüfschritte von PAC auch abdeckt. Unseren langjährigen Erfahrungen nach, tut dies Acrobat aber sehr unzuverlässig. Wir haben unzählige Dokumente, die laut Acrobat 0 Fehler haben, aber denoch ehrhebliche Mängel in der Accessibility vorweisen.

Bezüglich der Lesereihenfolge ist klar, dass PAC diese nicht fehlerfrei prüfen kann. Aus diesem Grund gibt PAC bei dieser Prüfung immer nur Warnungen aus, um auf ein "mögliches" Problem hinzuweisen. Die Lesereihenfolge manuell zu prüfen ist eine sehr mühsame Aufgabe, die durch PAC sehr erleichtert wird. Zu oft sind wir auf Probleme mit der Reihenfolge innerhalb der Tags selbst gestossen, die fast jeder Übersehen hat. Mit PAC können diese schnell identifiziert werden.

Es ist tatsächlich ein Problem die Syntax von Tags und Rollen fundiert zu prüfen, da die PDF-Spezifikation in diesem Bereich sehr viele Lücken besitzt. PAC befindet sich zurzeit noch in der BETA-Phase wir sind hier auf Feedback wie diesen angewiesen.

Die PDF-Spezifikation sagt folgendes bezüglich TOC und TOCI:

(Table of contents) A list made up of table of contents item entries (structure type TOCI) and/or other nested table of contents entries (TOC).

A TOC entry that includes only TOCI entries represents a flat hierarchy. A TOC entry that includes other nested TOC entries (and possibly TOCI entries) represents a more complex hierarchy.

Demnach darf innherhalb eines TOC-Tags nur wieder ein TOC-Tag oder ein TOCI-Tag vorkommen.

Ein Annot-Tag ist gemäss Spezifikation ein Inline-Element und diese düfen, auch gemäss Spezifikation, nur in Block-Level-Elementen vorkommen. Da der Part-Tag aber kein Block-Level-Element ist, sondern lediglich der Gruppierung von Elemeneten dient, reklamiert PAC hier.

Marcus meinte am 23.03.2010:

Moin zusammen!

@Manuel

Adobe Dokument "Erstellen von barrierefreien PDF-Dokumenten mit Acrobat 7.0", S. 112:

--------------------------------------
Elemente auf Blockebene

Behälterelemente

Behälterelemente bilden die höchste Ebene von Elementen und erlauben die hierarchische Gruppierung von weiteren Elementen auf Blockebene ...

- ....
- Teil <Part>: Eine grobe Einteilung eines Dokuments; kann kleinere Inhaltseinheiten wie Kapitel- oder Abschnittselemente enthalten.
- ....

----------------------------------------------

Frage erneut: Warum kein <Anot>?

Ebenfalls noch einmal zu <TOC> und <TOCI> - da magst du zwar Recht haben, aber was tust du, wenn dein <TOCI> einen Alternativtext benötigt. Dann musst du einen <Span> einbauen, damit dein ... <OBJR> nicht ungültig wird... parallel zu HTML gesehen ist ein <span> einfach ein Einschub, um bestimmte Attribute (bspw. Sprachwechsel) zuzuweisen. Ähnlich wie <div> lediglich ein Container ist... auch verboten?

Ich denke, wir drehen uns hier ein bisschen im Kreis und machen uns das Leben schwer. Bislang unterscheidet z. B. JAWS (welches ja bekanntlich die derzeit beste PDF-Unterstützung bietet) nicht, ob ich eine <TOC> oder eine <L> verwende. Genauso ist es JAWS recht egal, ob deine Kapitel aus <Part> oder <Sect> bestehen... und auch der Nutzer mit seinem Screenreader bekommt dort keine Unterschiede zu spüren.

Ich würde diese Diskussion hier keinesfalls als Haarspalterei bezeichnen, das muss irgendwie geregelt werden! Aber: Ein PDF ist barrierefrei/barrierearm, wenn es Strukturen aufweist, die im Wesentlichen interpretierbar sind - Überschriften, Absätze, Listen, Links und aufbereitete Tabellen, Bilder mit Alternativtext und dazu anständig umfließt. Alles Weitere befindet sich (leider) nach wie vor in einer Grauzone, in die unbedingt Licht gebracht werden muss.

Samuel Hofer meinte am 23.03.2010:

@Marcus: Wie du selbst zitiert hast, erlauben Behälterelemente wie <Part> die hierarchische Gruppierung von Elementen der "Blockebene". <Annot> Tag ist aber gemäs ISO 32000-1:2008 ein Inline-Element.

Bezüglich <TOC> und <TOCI> verstehe ich die Frage nicht ganz. Ein Alternativtext kann auf jedem Tag platziert werden, auch auf dem <TOCI>. Zudem ist <Span> gemäss ISO 32000-1:2008 ein Inline-Element (quasi ein Inline-Container) und darf somit innerhalb von <TOCI> plaziert werden.

Es ist richtig, dass JAWS vieles zulässt und notfalls etwas interpretiert. Aber dies ist doch die Aufgabe von JAWS, auch bei schlecht barrierefreien PDF-Dokumenten dem Anwender etwas bieten zu können. Als Messlatte für die Qualität der Barrierefreiheit kann JAWS meiner Meinug nach aber nicht dienen. Geht es um die Barrierefreiheit von Webseiten wird auch valides HTML verlangt. Warum soll das bei PDF nicht verlangt werden? Und ich denke, dass JAWS bei inkorrektem HTML auch nicht reklamiert und das best Mögliche daraus macht.

Die Möglichkeiten der Barrierefreiheit von PDF sind sehr umfangreich. Leider wird von diesen Möglichkeiten aber noch wenig genutzt. Auch JAWS schöpft das Potential noch lange nicht aus. Wir kommen nur weiter, wenn wir immer ein wenig mehr tun als zurzeit nötig ist. Aus diesem Grund ist die Prüfung von PAC ein wenig streng. Er soll dazu beitragen, die Qualität von barrierefreien PDF-Dokumenten generell zu verbessern.

Marcus meinte am 23.03.2010:

@Samuel (sorry für meinen Verschreiber in vorigen Beitrag)

Aber wenn ich das richtig interpretiere, dann ist <Part> ebenfalls ein Blocklevel-Element und demnach wäre <Annot> erlaubt...

zum <TOC> bzw. <TOCI>: Ich meine hier verlinkte Inhaltsverzeichnisse. Plazierst du deinen Alternativtext hier direkt in dem <TOCI>, wird das erforderliche <OBJR> der Verknüpfung (unterhalb von <TOCI>) "überschrieben". So kann ich dir auch nicht zustimmen, wenn du sagst, dass man jedem Tag einen Alternativtext zuweisen kann... sofern du einen Alternativtext in einem <Link>-Tag definierst, bekommst du einen Fehler (s. oben).

Ich bin ja auch der Meinung, dass hier ein <Span> zugelassen sein muss (weil es in diesem Falle nicht anders geht). Allerdings schriebst du ja "Demnach darf innherhalb eines TOC-Tags nur wieder ein TOC-Tag oder ein TOCI-Tag vorkommen." ;-)

Nein, natürlich ist JAWS nicht das Maß der Dinge! Nur muss man sich als Bearbeiter an irgendetwas orientieren können... also tut man das praxisnah! Im Bereich der barrierefreien PDF muss so vieles beachtet und teilweise mit Workarounds "umschifft" werden, dass vielleicht nicht immer jeder ISO-Standard berücksichtigt werden kann - hier zählt für mich (bis auf Weiteres) die Nutzbarkeit/Zugänglichkeit!

Praxisnah gedacht stelle ich mir allerdings gerade vor was passiert, wenn mein Kunde plötzlich dieses Tool in die Finger bekommt, ein wirklich gut (manuell) aufbereitetes PDF durchschickt (und ich meine hier wirklich kein halbherzig und auto-getaggtes Dokument!), und sich mit den Warnungen und Fehlermeinungen konfrontiert sieht... armer Dienstlesiter!

Aber dennoch: Dieses Thema verlangt Beachtung - kein Zweifel!

Samuel Hofer meinte am 23.03.2010:

@Marcus: Gemäss ISO 32000-1 gibt es 4 Arten von Elementen:

- Grouping Elements
- Block-Level Elements
- Inline-Elements
- Illustration Elements

<Part> gehört gemäss ISO zu den Grouping Elements und nicht zu den Block-Level Elementen.

Richtig, ein Alternativtext überschreibt jeglichen inhalt des Tags. Ich sagte nur, das ein Alternativtext auf jedem Tag möglich ist, nicht das es da sinnvoll wäre.

Ja, innerhalb eines <TOCI> Tag darf ein <Span> kommen, aber nicht direkt innerhalb von <TOC>. Das ist ein wesentlicher Unterschied. Ein Table of Contents ist im Normalfall folgenderemassen gettagt:

<TOC>
<TOCI>
<P><Reference><Link><Span>1. Kapitel 1</Span><OBJR></Link></Reference></P>
</TOCI>
<TOCI>
...
</TOCI>
</TOC>

Marcus meinte am 24.03.2010:

@Samuel: Man lernt nie aus! Ich werde mich mal eingehender mit der ISO auseinandersetzen...danke Dir!

David K. meinte am 27.03.2010:

Danke für den interessanten Artikel. Jetzt ist mir auch klar, was mit barrierefrei gemeint ist, ich konnte mir da meist nicht allzu viel drunter vorstellen. Ich werde die Seite auf jeden Fall in meinen Lesezeichen speichern und die Ratschläge künftig bei pdf-Dateien berücksichtigen, denn ich finde es schon wichtig, dass Content für möglichst viele Menschen verfügbar ist.

Marcus Hildebrandt meinte am 25.06.2010:

Der Beitrag hier ist zwar schon etwas "angestaubt", aber ich habe mich jetzt einmal eingehender mit der ISO befasst... macht alles schon Sinn!

Ich habe bereits meine Arbeit dahingehend angepasst, so dass sie ISO-konform ist. Ein Test mit dem PAC-Tool ist demnach auch ganz hilfreich :-)

Aber: Für den Screenreader macht es (derzeit) dennoch keinen Unterschied, sofern das Dokument mit "Sinn und Verstand" getaggt und aufbereitet wurde. Ob das Tag-Nesting immer ISO-konform gestaltet, tut der Zugänglichkeit keinen Abruch - noch nicht!

Kommentar abgeben?

 

Ihr Kommentar:

Tipp: HTML ist nicht zulässig; Webadressen können Sie so: [url=domain.de]Text[/url] eingeben.

Ihr Name:

Ihre E-Mail-Adresse: (wird nicht veröffentlicht)

URL: (wird bei Spamverdacht gelöscht)

Kommentar senden