Oft kommt es vor, dass ein Buch als Webseite aufbereitet wurde. Die Inhalte verteilen sich auf viele, manchmal hunderte einzelne Seiten. Wer wie ich klickfaul ist, findet das gar nicht gut. Das zweite Problem ist, dass auf eBook-Readern das Surfen im netz langsam und unübersichtlich ist. Deswegen möchte man die Webseite vielleicht als ePub aufbereiten. Und so geht man dabei vor, natürlich alles auf eigene Gefahr, respektiere das Urheberrecht!
Das Vorgehen erfordert das kostenlose Programm WinHTTrack, den kostenlosen HTML-Editor phase5, ruhig auch eine ältere Version sowie den freien eBook-Konverter Calibre. Außerdem sollte man sich ein wenig in HTML auskennen.
Mit WinHTTrack laden wir die entsprechende Webseite runter. HTTrack erstellt einen lokalen Ordner aus der Webseite.
Mit Phase5 öffnen wir eine der HTML-Seiten des Buches und schauen uns den Code an. Wir erkennen solche Elemente wie den Kopf, die Navigation, den Inhalt und die rechte Sidebar. Wir wollen alles raus haben bis auf den Inhalt. Dabei gehen wir Schritt für Schritt vor. Zunächst entfernen wir alle Elemente aus dem Head, die wir nicht brauchen, dazu gehören JavaScript-Anweisungen und –Verweise, Meta-Informationen und eventuell auch das CSS. Wir Markieren den entsprechenden Code-Abschnitt und kopieren ihn in die Zwischenablage.
Phase5 hat die schöne Funktion „Dateiübergreifendes Suchen und Ersetzen“, eigentlich der einzige Grund, warum man das Programm einsetzt. Wir rufen diese Funktion auf und kopieren den Markierten Abschnitt in das obere Feld. Links suchen wir noch unseren Unterordner, wo alle HTML-Dateien liegen, die wir vorher runtergeladen haben. Dann klicken wir auf OK und schon geht es los. Je nach der Menge der Dateien kann das einige Sekunden dauern. Ach ja, du solltest vorsichtig sein, der Schritt lässt sich nicht rückgängig machen. Wir wiederholen diesen Schritt, bis wir alle Elemente entfernt haben, die uns gestört haben. Achte dabei darauf, dass du die Struktur nicht zerstörst, schon das Weglassen von Klammern oder die unvollständige Entfernung von Tags kann die Datei für die Konvertierung unbrauchbar machen.
Im Browser kontrollierst du nach, ob das Layout der Seite nun okay ist. Im Idealfall hast du nur noch den reinen Text und die Bilder, das Layout fällt überwiegend weg, weil wir die CSS-Anweisungen gelöscht haben. Achte darauf, dass Elemente wie Zierleisten, Fußleisten oder Navigationen vollständig entfernt wurden.
Anschließend starten wir Calibre. Dort ziehen wir den Webseiten-Ordner in das ‚Bearbeitungsfeld. Achte darauf, dass die Seiten in der richtigen Reihenfolge vorliegen. Hier ist es natürlich ärgerlich, wenn du das händisch nachkontrollieren musst, aber normalerweise solltest du am Dateinamen erkennen, ob die Reihenfolge korrekt ist.
Jetzt nur noch das eBook im gewünschten Format erzeugen, das wars.
Solltest du Leerzeilen oder unerwünschte Umbrüche im Dokument haben, musst du ein wenig herumexperimentieren. Es kann zum Beispiel sein, dass der Seitenersteller Gestaltungsanweisungen direkt in die HTML-Datei geschrieben hat, die nachträglich wieder gelöscht werden müssen. Außerdem stellt Calibre einige Filter bereit, die bei der Nachbereitung helfen können.
Schlagwort-Archive: CSS
Was bringen automatische Testtools für die Barrierefreiheit – die Validierung
Mittlerweile dürfte sich jede Webagentur damit schmücken, barrierefreie Websites zu bauen. Sie machen das sozusagen im Vorbeigehen, ohne Experten zu engagieren, ohne Praxistests mit Betroffenen und ohne großartig Ahnung von BIT-V oder WCAG zu haben – behaupte ich mal, denn viele Websites ob uralt oder nagelneu erfüllen nicht einmal die minimalen Basics, zum Beispiel die Verwendung von HTML-Elementen. Vielleicht greifen einige dieser Agenturen auf mehr oder weniger automatische Testtools zurück – was besser ist als gar nichts zu tun. Grund genug, sich einiger dieser Tools anzugucken und sie hier in lockerer Folge einmal vorzustellen.Ich beginne dort, wo jeder Code-Schreiber anfangen sollte, bei der Validation.
Validatoren
Dirk Jesse hat in seinem Beitrag Alles valide oder was? schon einiges zu dem Thema Validierung gesagt, dem ich nicht viel hinzufügen kann. Dennoch möchte ich das Thema vom Blickwinkel der Barrierefreiheit betrachten.
Im ersten Schritt sollte immer überprüft werden, ob die Seiten validen Code enthalten. Das hilft vor allem dabei, fehlerhafte Tags, Attribute und Werte zu finden,was zu Fehlern in der Darstellung führt.
Valide oder nicht valide – das ist nicht mehr die Frage
Kurioserweise glauben viele Leute, valider Code sei schon barrierefrei. Ergo, nicht valider Code ist eine Barriere. Die letztere Ansicht stimmt heute nicht mehr: Dank HTML5 und WAI ARIA haben sich die Möglichkeiten für barrierefreie Websites entscheidend verbessert. Beide Standards sind allerdings noch nicht verabschiedet und validieren dementsprechend zumindest beim W3C nicht. Es gibt allerdings einen experimentellen HTML5-Validator, der explizit bei der Doctype ausgewählt werden muss, wenn man nicht den neuen Doctype von HTML5 verwendet.
Jeder Code-Leser dürfte aber in der Lage sein, ARIA oder HTML5-Fehlermeldungen von echten Fehlern unterscheiden zu können. Bei CSS3 sieht es ähnlich aus. Ich plädiere stark dafür, stabile Elemente schon heute zu verwenden, weil sie die Benutzerfreundlichkeit und Zugänglichkeit erhöhen. Außerdem wird so Druck auf die Programmierer von Browsern und das W3C ausgeübt, diese Elemente auch zeitnah einzuführen.
Nutzen
Der HTML-Validator stellt zum Beispiel sicher, dass in XHTML alle Bilder einen Alternativ-Text haben. Er kann allerdings nicht beurteilen, ob dieser Text sinnvoll ist oder nicht. Er kann auch nicht sehen, ob jemand HTML für Überschriften verwendet oder sie per CSS gestaltet. div id=“h1″ ist ebenso valide wie „h1″. Die Validierung verhindert allerdings grobe Fehler wie falsche Tag-Attribut-Paare, was kein Browser der Welt korrigieren oder interpretieren kann. Er prüft auch nicht die Trennung von Layout und Struktur, die dank CSS eigentlich Standard sein sollte. Kein Validator der Welt verhindert, dass jemand mit “ “ seine Abstände einstellt oder Absätze über „br“ statt über „p“ erzeugt, das sind typische Artefakte von WYSIWYG-Editoren.
Fazit
Basis barrierefreier Websites ist fehlerfreier Code. Wer seinen Code nicht prüft, riskiert fehlerhafte Darstellung im Browser, was normalerweise einen Rattenschwanz weiterer Probleme nach sich zieht. Der Validator ist allerdings nur der Anfang und nicht das Ende der Testphase. Er schwächelt dort, wo es um semantisch sinnvolle Auszeichnungen geht und hier kommt es auf das Können des Code-Schreibers an.
Einen recht interessanten Artikel dazu gibt es bei Wait till I come. Chris und Remy Sharp diskutieren über die Bedeutung des Validierens, Chris vertritt als Protagonist der Barrierefreiheit im wesentlichen unseren Standpunkt.
Link – die Kunst der richtigen Verbindung
Auch Links wollen richtig gesetzt werden. Es ist zwar nett, am Ende eines elektroischen Textes alle Links zu erhalten, auf die im Text verwiesen wurde, aber dieses Verfahren stammt noch aud Zeiten des Papiers. Wir erinnern uns mit Schaudern an ellenlange Listen mit Fuß- und Endnoten und Anmerkungen, die zwar kleingedruckt aber dennoch um so umfangreicher sind.
Womit wir mitten im Thema sind: Eine Fußnote innerhalb eines elektronischen Textes muss prinzipiell anklickbar sein. Dabei öffnet sich entweder ein kleines neues Fenster, in dem der Text der Fußnote angezeigt wird oder das Dokument springt zur Fußnote. In letzterem Falle ist es unbedingt notwendig, eine Möglichkeit zu schaffen, damit der Leser genau dort hin zurück kommt, wo er herkam.
Häufiger tritt aber der Fall auf, dass man auf ein Dokument verweisen möchte: vielleicht als Beispiel, als Quellenverweis oder als weiter gehende Informationsquelle. In diesem Falle wird der Link direkt im Text gesetzt.
Möchte ich auf eine Pressemitteilung der Messe München verweisen, dann schreibe ich etwa: „Die Messe München sagt“, wobei der ganze Text ein Link ist, daraus schließt der Leser, dass hier auf die quelle der Aussage zurückverwiesen wird.
Dabei müssen Links deutlich erkennbar sein, etwa farblich oder unterstrichen. Dabei verwendet man am besten die klassischen Linkfarben des Web: blau für nicht-besuchte Links, lila für besuchte Seiten. Auf jeden Fall sollte man darauf verzichten, den User durch verschieden farbige Texte zu verwenden. Farben sollten immer eine bestimmte Bedeutung haben, die sich möglichst schnell erschließt.
Wenig hilfreich sind nackte Links, ob sie anklickbar sind oder nicht. Wenn sie „sprechend“ sind, also im Linktext etwas aussagekräftiges drin steht, ist das schon besser, dennoch nicht unbedingt zielführend: http://www.oliveira-online.net/wordpress/wp-admin/post.php?action=edit&post=246
Betreibt man eine professionelle Site mit vielen externen und internen Links sollte man sich überlegen, ob man ein neues Fenster öffnen will oder ob der Link im gleichen Fenster geöffnet werden soll. Wird der Link im gleichen Fenster geöffnet, ist es aufwendiger, zum ursprünglichen Artikel zurückzukehren, sofern man das möchte. Öffnet man den Link in einem neuen Fenster, ärgert sich der User gegebenenfalls darüber. Folgende Regel halte ich für einen sinnvollen Kompromiß: Siteinterne Links werden im gleichen Fenster geöffnet, externe Links in neuem Fenster. Man kann auch im Title-Tag des Ankers hierauf hinweisen.
Wohin der Online-Journalismus steuert und wie man Links nicht verwendet, erfährt man in diesem Telepolis-Artikel.