2. April 2008, von Maria Putzhuber
Adobe, ich will mein Geld zurück
Acrobat Professional, das einzige Programm am Markt mit dem man PDFs professionell barrierefrei auszeichnen kann, kostet 560 Euro, das ist nicht nichts, wenn man es nur dafür braucht.
Die Accessibility Features sind nur ein kleines Beiprodukt dieser mächtigen Software, die deshalb auch wahrscheinlich alles andere besser kann, als PDFs barrierefrei zu machen.
Jetzt reden wir nicht von simplen Textdokumenten, die Sie schon in Word mit korrekten Formatvorlagen erstellt haben. Mit einem Klick machen Sie daraus ein nahezu fehlerfrei getaggtes PDF.
Wir reden auch nicht vom anderen Ende, von komplexen Tabellen oder Formularen, wo sowohl die barrierefreie Strukturierung schwierig als auch die Unterstützung durch Assistive Technologien sehr mangelhaft ist.
Wir reden von einem PDF Normalfall, von Drucksorten – Foldern, Broschüren, Berichten, die auch ins Netz gestellt oder per E-Mail versendet, jedenfalls am Computer gelesen werden. Sie werden hier wahrscheinlich keinen Einfluss auf das – vermutlich von PrintgrafikerInnen erstellte – Ausgangsdokument haben und ein semantisch unstrukturiertes PDF nun im Acrobat für Onlinezwecke optimieren wollen.
Reden wir von der Praxis
Ich möchte Ihnen ein wenig von meinen Erfahrungen mit dem Taggen des Accessibility Logbuchs (PDF, 8,5MB) erzählen. Sie sollten vorher einen Blick hineinwerfen, damit Sie nachvollziehen können, wovon ich rede.
Ausgangspunkt war ein 172 Seiten PDF, 56 MB groß, druckfertig aus QuarkXPress generiert. Es wurde mir geraten, mit dem unkomprimierten Dokument zu arbeiten, weil man öfters zwischenspeichern muss und JPGs bei jedem Speichern an Qualität verlieren.
Sichern Sie
Machen Sie eine Kopie des Ausgangsdokument, speichern Sie oft und machen Sie eine Kopie des Zwischenstands vor neuen Arbeitsschritten.
Bei einem so großen Dokument stürzt Acrobat gern mal ab, bei meinem mehr als 2 Jahre alten Rechner eh nur 5 Mal bei 172 Seiten, häufiges Speichern ist aber jedenfalls anzuraten.
Wenn Sie nicht sehr viel Erfahrung haben, ist es von großem Vorteil, auch den Zwischenstand Ihrer Arbeit zu sichern, weil man schon einiges anstellen und sich das PDF zerstören kann.
PDF für Druck und Web
Versuchen Sie das PDF zu bekommen, bevor es druckfertig gemacht wurde.
Der Wunsch an den Printgrafiker, das komprimierte PDF mit Druckmarken lieber unkomprimiert und ohne Druckmarken zu bekommen, resultierte in einem beschnittenen PDF, in dem die Druckmarkierungen aber nach wie vor unsichtbar außerhalb vorhanden waren. Um den Grafiker nicht nochmals zu belästigen, gedachte ich nach dem vollständigen Taggen des sichtbaren Inhalts übriggebliebene Elemente mit einem Klick zu löschen: Optimismus der Unerfahrenen, übrig gebliebene Pfade und Bilder müssen Seite für Seite markiert und gelöscht oder als außertextliches Element definiert werden, um nicht 1000 Fehlermeldungen bei der Ausgabeprüfung zu behalten.
Überlegen Sie sich vorher, wie Sie es machen
Eine nicht unangenehme meditative Übung wird das, dachte ich: Hübsche Grafik, mäßig anspruchsvolle Textstruktur: Überschriften, Absätze, Listen, sehr viele Links, viele sich wiederholende Schmuckelemente wie Lesezeichenkästen und Icons (als Hinweis zum Glossar, für interne Links), viele Fremdwörter, viele freigestellte Bilder, um die der Text herumfließt.
Auf den ersten Blick tricky wirkten nur Überschriften und Bilder, die sich über 2 Seiten erstrecken und Texte, die über runde Pfade geführt wurden oder hochkant stehen.
Auf den zweiten Blick als problematisch erwiesen sich die vielen Zeilenumbrüche und Trennungsstriche und die Lesereihenfolge für die Bilder.
Auf den dritten Blick – nach dem optimistischen Vorsatz am Anfang, dieses PDF ganz vorbildhaft proper auszuzeichnen, als unzumutbar erwies sich der Plan, dieses vor Fremdwörtern und Fachbegriffen strotzende Buch auch mit Sprachauszeichnung zu versehen.
Auf den vierten Blick als generell frustrierend und unbefriedigend erwies sich das gesamte Unternehmen grafisch gestaltetes Buch als barrierefreies PDF.
Keine Furcht vor dem Touchup Leserichtungswerkzeug
Man kann Tags automatisch erstellen lassen. Das Ergebnis ist meist nicht optimal, muss womöglich Tag für Tag korrigiert werden. Man ist also womöglich schneller, wenn man gleich manuell taggt.
Das Touchup Leserichtungswerkzeug ist ein ganz praktischer Editor dafür, mit dem man Text markieren und durch Klick auf einen Button ein Strukturelement wie Absatz, Überschrift, Bild, außertextliches Element… zuweisen kann. Gleichzeitig legt man die Lesereihenfolge fest, die im Original häufig nicht stimmt.
Fieserweise ist der Editor unvollständig. Listenpunkte, Zitate, Subüberschriften ab H4 müssen zuerst als Absatz definiert und dann im Tag Navigationsfenster, das weniger komfortabel ist, korrigiert werden. Einzelne Wörter mit einem <Span> Element für Sprachauszeichnung zu versehen ist mit dieser intuitiven Oberfläche ebenso unmöglich, wie Links zu setzen.
Muss das eigentlich so sein? Wäre der Programmieraufwand wirklich zu hoch, um den BenutzerInnen der Software etwas mehr Komfort zu bieten und Mühsal zu ersparen?
Gut ist, dass man bereits gereihte und damit getaggte Elemente wieder überschreiben, also korrigieren kann.
Gehen wirs an
Über zwei Seiten reichende (also auf einer Seite unvollständige) Texte wie Orie – ntierung zeichnete ich als Bild aus, um leicht einen Alternativtext vergeben zu können. Ebenso hochkant gestellten oder über Pfade gelegten Text, der sonst vom Screen Reader nicht in der richtigen Buchstabenfolge gelesen wird.
Die Lesereihenfolge der Artikel, die grafisch nicht einheitlich ist, legte ich einheitlich so fest, dass der Lesezeichenkasten mit Autoreninfos gleich nach Überschrift und Autorenname kommt.
Die Grafiken für den Kasten waren klarerweise außertextliche Elemente (Artifacts), ebenso die Unterlegung bei den Glossarbegriffen im Text. Das Icon für Glossarbegriff beließ ich im Textfluss, es wird zwar für Screen Reader unmotiviert als 3 vorgelesen, aber im Umfließenmodus, den vermutlich mehr Leute nutzen, bleibt es damit als Icon erhalten (kann ich ja am Ende mit <Span> Tag umgeben und mit Alternativtext versehen, dachte ich anfänglich motiviert).
Acrobat wollte nicht immer so wie ich, wollte die Abschnitte wohl lieber im originalen, fehlerhaften Dokumentenfluss behalten, ich musste die Abschnitte oft mehrmals umreihen. Nach Auszeichnung aller Absätze der Seite, waren die Lesezeichenabschnitte oft wieder irgendwo zwischen den anderen Absätzen, die Bilder legten sich manchmal über den Text, wenn ich sie ans Ende der Lesereihenfolge einer Seite stellte. Die Unterlegungen der Glossarbegriffe lagen regelmäßig als Layer über den Begriffen, die damit verschwunden waren, obwohl ich sie zuerst als Hintergrundelement getaggt und sie damit doch hätten darunterbleiben sollen. Wieder war ein Verziehen der Absätze im Lesereihenfolge Navigationsfenster nötig, um die Begriffe wieder an die Oberfläche zu zaubern.
Alles ein wenig mühsam, aber machbar, weil man mit dem Werkzeug intuitiv umgehen kann und nichts passiert ist, außer einer falschen Reihenfolge, wenn Text plötzlich verschwunden ist. Die Hierarchie im Tag Baum muss aber öfters wieder korrigiert werden, wenn Textteile im Reihenfolge Fenster verschoben oder neu ausgezeichnet werden. Tags finden sich plötzlich im Root Verzeichnis, nicht im Container, in dem sie sein sollten.
Die Werkzeuge, um die Lesereihefolge festzulegen und die Tags zu bearbeiten haben keine Rückgängigmachfunktion, ansonsten eine Selbstverständlichkeit bei guter Software. Hat das einen praktischen Grund oder darf man etwas mit der Diskriminierungskeule wackeln und sich wundern, warum die tolle Software gerade hier nicht fertig geworden ist?
Es gibt ansonsten wenig Automatisierung im Accessibility Bereich von Acrobat, aber mit einem Klick kann man die gesamte Tagging-Arbeit löschen, nicht jedoch, wie man bei der seitenbasierten PDF Struktur vermuten könnte, die Arbeit der letzten Seite. Das ist bei längeren Dokumenten und nach stunden- bis tagelanger Arbeit ein etwas sadistischer Zugang.
Testen Sie den Umfließenmodus zwischendurch
Ob das Konzept passt, sehen Sie nicht nur in der Nummerierung beim Lesereihenfolgewerkzeug, sondern auch im Umfließenmodus.
Und hier sehe ich nun, dass Bilder manchmal den Text überlappen, d.h. sie müssen an den Anfang der Lesereihenfolge einer Seite.
Ich sehe, dass die Zeilenumbrüche zwar aufgehoben sind, aber damit die Wörter beim ehemaligen Zeilenumbruch aneinanderpappen.
Ich frage mich, ob Acrobat wirklich von mir verlangt, dass ich mit dem Touchup Textwerkzeug vor jedem Zeilenumbruch auf 172 Seiten ein geschützes Leerzeichen einfüge. Ich probiere es aus, und sehe, dass sich das Layout dadurch natürlich verändert und im Umfließenmodus nun zwar die Wörter Abstand haben, aber die Zeilenabstände verschoben sind, dass nun Zeilen aneinanderpappen...Und ich denke mir erleichtert, da kann man wohl nichts machen.
Ja, kann man das nicht so programmieren, auch wenn das PDF von QuarkXPress kommt, dass Zeilenumbrüche automatisch durch ein Leerzeichen ersetzt werden? Kann doch nicht kompliziert sein? So ist der Umfließenmodus doch frustrierend!
Alles, was als außertextliches Element definiert wird, ist auch im Umfließenmodus verschwunden. Das kann man wollen oder nicht.
Zahlen, wieviele Menschen mit Sehbehinderung diesen Modus wirklich nutzen, gibt es nicht. Die Schrift ist hier zwar beliebig vergrößerbar, komfortabel kommt mir der Modus nicht vor. Empfehlenswerter ist wohl eher ein großer Bildschirm und ein Zoomen der Normalansicht.
Beim Test der Kontrastansicht (z.B. schwarz mit grüner Schrift) im Normalmodus kommt zutage, dass sie bei diesem PDF nicht möglich ist, weil der grünbeige Hintergrund der Seiten – der die Papierfarbe simuliert – mit einem Bild realisiert wurde. Man muss es als außertextliches Element markieren (172 mal). Im Umfließenmodus ist es weg, aber löschen kann man es nicht, um den Kontrastmodus auch in der Normalansicht zu ermöglichen, sonst stehen alle Bilder mit grünbeigem Hintergrund auf weiß und der angenehm nicht blendende Hintergrund ist weg.
Was in so einem Fall bleibt, ist also der Umfließen Modus von Acrobat, der bei diesem handgetaggten PDF Probleme mit den Zeilenumbrüchen hat, oder professionelle Zoomsoftware. Zoomtext kostet ca. ebensoviel wie mein Acrobat.
Das Problem lässt sich ansonsten nur im Ausgangsdokument lösen. Für das Lesen am Bildschirm für gewisse User mit Sehbehinderung sind Hintergrundbilder in PDFs ungünstig.
Der Umfließen Modus hat mir übrigens auch 3x die Startseite des PDFs zerstört. Die Seitenelemente waren halb aus der Seite gerutscht und auch nach Schließen des Dokuments ohne zu speichern nicht mehr am richtigen Platz: 3x Wiedereinfügen der Seite aus der Sicherungskopie, neues Festlegen der Lesereihenfolge, neuerliches Verschieben der Tags in den richtigen Container, neuerliches Löschen der Druckpfade, neuerliches als Artifact Definieren des Hintergrundbildes und neuerliches Hinterfragen, ob ich blöd bin oder der Acrobat.
Lassen Sie sich zwischendurch mal vorlesen (z.B. mit Jaws Testversion)
Jaws erkennt die Überschriften und Links, liest Alternativtexte für Grafiken vor, liest öfters mal die Zahl 3 dazwischen (und ich sags Ihnen nun, ich habe keinen Nerv mehr, für dieses Spiral Icon bei Glossarbegriffen einen Alternativtext zu vergeben, 3 heißt also, der Begriff ist im Glossar).
Er liest ständig Bindestrich. Hätte ich noch Energie, würde ich die ganzen Trennungsstriche als außertextliche Elemente markieren. Es tut mir leid, ich habe sie nicht.
Peinlich, gerade beim Text von Herrn Hellbusch erkennt er die Links nicht, hier ist ein nicht zugehöriges Wort zum Link dazugerutscht.
Links auszuzeichnen ist Arbeit, nichts geht automatisiert. Jeder Link, der doch eigentlich für sehende UserInnen bereits funktioniert, muss mit dem Auswahl Werkzeug nochmals markiert und in die Tag Hierarchie gebracht werden, braucht jeweils den Tag <Link> und ein Verknüpfen – OBJR Objekt. Bei einigen Links nach einem Zeilenumbruch hat dieses Taggen als Link erst funktioniert, nachdem ich ihnen zuerst ein eigenes Absatz Tag zugewiesen hatte.
Ebenso peinlich, gerade beim Text von Eva Papst ist die Lesereihenfolge wieder verrutscht, dabei war sie doch ok vorher. Seltsame Dinge passieren...
Sprachauszeichnung: Was ohne sie gelesen wird, klingt teils schon komisch, Accessibility ganz ok, Uuusabilitüüü wieder sehr seltsam, so viele Fremdwörter, man sollte, ja..., aber ich schaffe es nicht mehr. Ich sage Ihnen dafür, wie es geht.
Die Anleitung stammt aus einem PDF Schulungsskriptum von Markus Erle von Wertewerk, dem unbestrittenen PDF Experten im deutschsprachigen Raum.
Und ich frage Sie, wem ist bei längeren Dokumenten eine Sprachauszeichnung zumutbar, die für jedes einzelne Fremdwort folgende Arbeitsschritte nötig macht:
- Sie markieren mit dem Auswahl Werkzeug die „Fremdwörter“ im Dokument und suchen im Navigationsfenster Tag über Optionen > Tag in Auswahl suchen den korrespondierenden Tag im Tag-Baum (Text mit „Fremdwörter“ wird im Tagbaum markiert).
- Überprüfen Sie, ob der fremdsprachige Text bereits einen eigenen Tag besitzt (das wäre z.B. bei ganzen fremdsprachigen Absätzen der Fall). Wenn nicht, müssen sie einen eigenen
<Span>-Tag dafür anlegen:- Sie markieren denjenigen Tag, der den Text mit dem „Fremdwort“ enthält
- Über das Kontextmenü neuer Tag > Typ: Bereich auswählen erstellen Sie einen leeren
<Span>-Tag. - Sie markieren den neu entstandenen
<Span>-Tag - Sie markieren mit dem Auswahl-Werkzeug das „Fremdwort“ im Dokument und weisen im Navigationsfenster: Tag über Optionen > Tag aus Auswahl erstellen den gewählten Inhalt dem neuen
<Span>-Tag zu. - Der gesamte Textabschnitt wird dabei in 2 Teile getrennt.
- Schließlich verschieben Sie den
<Span>-Tag an die Stelle zwischen die beiden Textteile.
- Sie markieren den
<Span>-Tag. Über das Kontextmenü (rechte Maustaste) Eigenschaften... öffnen Sie das Fenster: TouchUp-Eigenschaften und können im Register: Tags im Eingabefeld: Sprache die entsprechende Sprache auswählen.
Unzumutbar und sinnlos
Ja, bin ich verrückt? Habe ich 7 Leben? Kann ich mir so etwas bei einem von Fremdwörtern strotzenden 172 Seiten PDF leisten? Hat das überhaupt einen Sinn?
Die MAIN Frauen schicken mir nettes Feedback von Herrn Hellbusch, das ich mir hier erlaube auszugsweise anzuführen:
„Die PDF ist gut lesbar, aber wie gehabt ist das nicht wirklich komfortabel,
oder: zugänglich ja, aber barrierefrei nicht. Das liegt aber u.a. an JAWS,
der Absätze in PDF nicht unterstützt und auch an den zahlreichen
Bindestrichen. Der Export zu RTF war erfolgreich, aber - warum auch immer -
da geht es sehr stark zu Lasten des Arbeitsspeichers und ich muss
gelegentlich längere Sprechpausen hinnehmen. Jetzt habe ich aus der RTF eine
TXT gemacht und es ist OK.
Da habt Ihr ja eine Menge Arbeit gehabt. In Eurer Einleitung "verteidigt"
Ihr Euch ein wenig, was sicher nicht erforderlich war. Klar: Ein Buch ist
nicht das Web! Wie auch immer, das ist ein schöner Schnappschuß des
derzeitigen Stands.“
Schön, JAWS erkennt Absätze in PDFs nicht, im Jahr 2008. Ich dachte, es liegt an meinem unzulänglichen Umgang mit JAWS, dass es mir nicht gelungen ist, von Absatz zu Absatz zu springen. Aber die Frage sei erlaubt: warum zeichne ich sie dann überhaupt aus? Für wen? Wenn die JAWS Programmierer diese doch nicht so komplizierte Funktion, Absätze in PDFs zu erkennen, nicht für nötig halten, im Jahr 2008.
Ich mache u.a. auch karrierefreies Webdesign, weil ich ein Bedürfnis nach sinnstiftender Arbeit habe. Wenn es aber eh für den Hugo ist, dass ich hier meine Lebenszeit vertagge, hat das ja überhaupt gar keinen Sinn!
Blinde UserInnen wandeln sich PDFs nach wie vor lieber in RTF oder TXT um, als ein PDF, ob getaggt oder ungetaggt, zu lesen, weil das Lesen in Word mit Screen Reader komfortabler ist. Na dann liefern wir Ihnen doch gleich ein TXT File!
Probe aufs Exempel
Die Umwandlung in ein RTF funktioniert mit dem ungetaggten Original des Accessibility Logbuchs zumindestens optisch besser als mit dem getaggten barrierefreien PDF, warum auch immer. Bei der getaggten Version stehen Absätze manchmal nebeneinander, statt untereinander, überlagern sich sogar teils.
Vielleicht liegt der Fehler bei mir? Was könnte ich bloß falsch gemacht haben?
Die Umwandlung in ein TXT geht auch mit dem Original ganz gut, die Lesereihenfolge folgt dem Original Dokumentenfluss, d.h. die Autoreninfos stehen z.b. mitten im Artikeltext, der Text ist grundsätzlich aber nur manchmal sinnentstellend durcheinander. Die Bildalternativen fehlen, aber das Ergebnis ist – mit Abstrichen lesbar. Außer der korrekteren Lesereihenfolge erkenne ich keine Vorteile im TXT aus der getaggten Version. Auf die Bildalternativtexte kann man verzichten, extra Linksetzung hätte ich mir sparen können.
Die Umfließenfunktion gibt mir noch Rätsel auf. Im ungetaggten PDF funktioniert sie weit besser als im getaggten PDF, die Lesereihenfolge stimmt natürlich nicht ganz, aber die Wörter kleben nicht aneinander und der Zeilenabstand ist größer, der Kontrastmodus klappt auch.
Was könnte ich nur falsch gemacht haben? Oder hat Acrobat hier einen Bug? Oder liegt es an QuarkXPress? Oder am Grafiker? Bei diesem PDF ist es jedenfalls so, dass die Tags, die der blinden Zielgruppe nützen (wenn der Screen Reader sie denn erkennt) der größeren Zielgruppe mit Sehbehinderung neue Schwierigkeiten schaffen. Perfide ist das!
Wie taggt Acrobat hier automatisch?
Beim Versuch, das große Orignal PDF automatisch zu taggen, stürzt Acrobat auf Seite 171 ab. Beim Versuch eine komprimierte Version automatisch zu taggen, stürzt Acrobat auf Seite 171 ab. Nach Löschen der Seite 171 stürzt Acrobat auf Seite 168 ab. Beim Versuch nur mal eine 20 Seiten Kurzversion des PDFs automatisch zu taggen, taggt Acrobat brav.
Im Tag Baum sehe ich nun viele inhaltlich falsch gesetzte Tags und fehlerhafte Lesereihenfolge, aber keine gravierenden Unterschiede in der grundsätzlichen Vorgangsweise. Aber siehe da, der Umfließenmodus funktioniert plötzlich perfekt.
Was habe ich also falsch gemacht? Sachdienliche Hinweise von ExpertInnen wären sehr willkommen. Ich oute mich gerne als ahnungslos, wenn ich etwas dazulerne.
Unfertige Software, frustrierte BenutzerInnen
Bei meinen bisherigen Kämpfen mit nichtfunktionierender Technik und höchst mysteriösen, unlogischen Vorgängen im Weballtag, stellte sich allerdings meist heraus, dass gar nicht ich selber schuld gewesen bin. Vielleicht ist tatsächlich Acrobat schlecht? Seine Autoren Liste ist erstaunlich lang, viele Köche, viel mehr ProgrammiererInnen als bei Photoshop waren hier beteiligt, viele indische und asiatische Namen. Vielleicht liegts nicht nur an zu knappen Deadlines, sondern auch an der Auslagerung von Softwareproduktion in Billiglohnländer, an daraus resultierenden Kommunikations- und Koordinationsproblemen, wenn Software unfertig und fehlerhaft ist. Wahrscheinlich ist ganz einfach wieder einmal die Globalisierung an allem schuld. Genau!









Über dieses Blog
Am 2. April 2008 um 14:44 Uhr
Ja, Adobe-Software ist schon ein teures Grauen, aber es gibt ja nicht wirklich alternativen zu Photoshop und Acrobat.
Zum Thema JAWS und Absätze: Wenn sie niemand implementiert, dann brauch JAWS sie ja auch nicht zu unterstützen und umgekehrt
Ein klassisches Henne-Ei-Problem.
Die Accessibility-Optionen sind eben eine noch relativ neue Funktion, hoffen wir, dass sich die Handhabung noch deutlich verbessert.
Am 4. April 2008 um 13:58 Uhr
Ich habe bei jedem Absatz einmal laut “Jawohl!” gerufen und mich fast schon gefreut, dass ich nicht der einzige Nutzer unter der Sonne bin, der mit Acrobat auf Kriegsfuß steht. Der Grund, warum wir auf InDesign umgestiegen sind, liegt schlicht darin, dass man das Tagging aus Print-Dokumenten hier deutlich besser hinbekommt – schon im Ursprungs-Dokument. Das macht die Sache zwar einfacher, aber halt eben nicht einfach.
Am 4. April 2008 um 23:12 Uhr
Ausgezeichneter Artikel! Mir scheint, die ganze Diskussion kippt langsam wieder in Richtung alternatives doc/rtf (oder sogar txt – aber wo bleibt denn da das markup, ist das doch nicht so wichtig?!).
Und unterhaltsam auch noch: “karrierefreies Webdesign”, “Leben vertaggen”, gratuliere!
Am 13. April 2008 um 20:12 Uhr
Eine genaue Analyse, was Screenreader in PDFs interpretieren können, gibts bei INCOBS
Am 1. Mai 2008 um 13:38 Uhr
Der Artikel ist wirklich gut auf dem Punkt gebracht:
“karrierefreies Webdesign” und “Leben vertaggen”!
Ein weiteres Beispiel, was macht zum Beispiel ein gehörloser Webentwickler, wenn er barrierefreie PDF mit einem Umfang wie das Logbuch Accessibility gut umsetzen will?
Da gibt es eine weitere Hürde: Beim Testen ist man auf Screenreader (SR) angewiesen. Doch bis dato ist mir noch keine brauchbare Testumgebung zu Augen gekommen, das visuell nachvollziehbar macht, was der SR ausgibt und wirklich praktisch ist. Es wäre sogar alle Webentwickler, die eine starke visuelle Wahrnehmung haben ein Vorteil. Bei Flash ist es ähnlich, wenn barrierefreies Flash testen will (ich habe es schon mit ein Tool ausprobiert, aber wirklich praktisch ist es auch wieder nicht).
Bestes Beispiel im Vergleich mit CSS: die Firefox-Extension
Firebug. Ein Segen für einen visuell orientierten Webdeveloper.
Kürzlich habe ich das einem Gehörlosen gezeigt und der war
so glücklich, dass ich ihm diesen Tipp gegeben habe und es im
demonstriert habe.
Barrierefreiheit darf nicht nicht mit Fürsorgedenken verwechselt werden. Es ist eine Goldgrube, die Stärken der verschiedenen Wahrnehmungswelten zu verbinden. Ich bin mir sicher, dass es dann wirklich gute Entwicklerwerkzeuge geben würde, wenn man da auf Augenhöhe mit Menschen mit besonderer Wahrnehmungsfähigkeiten zusammenarbeitet. Das wäre echte Gleichstellung in der Webdeveloper-Branche!
Am 12. Mai 2008 um 01:23 Uhr
Ich habe mich einige Wochen in die Erstellung möglichst barrierearmer PDF-Dokumente eingearbeitet und konnte anschließend durchaus halbwegs brauchbare Ergebnisse erzielen. Die Umwandlung der Dokumente ins PDF-Format nimmt dennoch oft deutlich mehr Zeit in Anspruch als deren Erstellung. Eine echte Barriere. Für Webautoren.
Am 16. Mai 2008 um 17:20 Uhr
Hallo Maria,
wie in Gelsenkirchen persönlich gesagt, es tat in der Seele weh, diesen zwar unterhaltsamen, aber gleichzeitig frustrierenden Artikel zu lesen. Wie versprochen, hier der Link zu meinem Auswurf:
http://www.barrierekompass.de/weblog/index.php?itemid=519
Der Artikel heißt “BIK und Adobe unter einer Decke?”
Am 16. Mai 2008 um 17:34 Uhr
Da PDF-Dokumente nur mit sehr großem Aufwand für alle zugänglich zu machen sind entscheiden sich immer mehr Kommunen dazu die Dokumente nur noch im Papierform anzubieten. Was für ein Fortschritt!
Am 12. Juni 2008 um 19:00 Uhr
Ich komme gerade von einem Einführungsseminar zu barrierefreien PDFs. Nunmehr ziehe ich noch mehr den Hut vor Leistung des taggens des Logbuchs. Adobe macht es einem noch dazu wirklich nicht einfach… wobei es doch mit einigen wenigen Zusatzfunkionen schon viel besser wäre. Kann man da auf die nächste Version hoffen?