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: HTML
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.
HTML oder Plain Text – die Zukunft der Mail
Immer wieder einmal keimt die Debatte auf, ob man Mails als HTML oder reinen Text versenden sollte. Die Diskussion ist eigentlich müßig, HTML-Mails bieten kaum Vorteile, dafür jede Menge Nachteile.
HTML-Mails sind mit oder ohne Bilder recht groß. Die Größe wird dabei von Gestaltungs-Elementen bestimmt, die wenn im Web verwendet an der Fähigkeit des Webdesigners zweifeln ließen: Inline-CSS, Layout-Tabellen, 0-Pixel-Graphiken und so weiter. Die Vielfalt der Mailprogramme und MailClients lässt nur eine begrenzte Bandbreite an Gestaltungselementen zu. Dazu kommt noch, dass die Mailfenster selbst unterschiedlich breit sein können. Das reicht von der Miniansicht auf Smartphones bis zur Maxidarstellung auf 24-Zoll-Displays. Ein festes Design sieht deshalb fast immer lächerlich aus: zu groß für das Smartphone, zu schmal für das große Display. Ein fluides Design sieht hingegen auf einem großen Display einfach alber aus, weil die Mail dann irgendwie zu kurz geraten aussieht.
Datenschutz
Viele Anbieter möchten über Newsletter Tracking betreiben. Das geht einerseits über speziell generierte Links in den Mails und über Bilder, die über das Web nachgeladen werden. Das könnte ein Verstoß gegen den Datenschutz sein, ich kann mich zumindest nicht daran erinnern, jemals danach gefragt worden zu sein, ob ich mit der Erhebung solcher Daten einverstanden bin. Es ist auch nicht naheliegend anzunehmen, der Empfang eines Newsletters könnte für solche Zwecke verwendet werden. Deswegen wird der Benutzer auch nicht gesondert auf solche Probleme achten. Für einen Tracking-Link ist es hingegen egal, ob er in HTML oder PlainText verwendet wird.
Mobilität
Wer seine Mails mobil abruft, wird sich über Mails freuen, die 100 Kilobyte groß sind, 200 x 150 Pixel große Bilder nachladen und wegen des Tabellen-Designs sowohl horizontal als auch vertikal gescrollt werden müssen. Bestimmt.
Sicherheitsrisiken
HTML-Mails stellen ein Sicherheitsrisiko dar. Sie landen doch recht häufig im Spam (wo sie auch meistens gut aufgehoben sind). Viele Webmailer blockieren zunächst die Volldarstellung.
Dem Leser geht es um den Inhalt der Mails und nicht um bunte Logos, farbenfrohe Graphiken und flockige Bilder, weswegen er kein Interesse daran hat, sich die Volldarstellung anzusehen.
Wozu gibt es RSS und Webseiten?
Newsletter sind eine aussterbende Rarität wie Gästebücher. Viele Nutzer greifen heute auf RSS, Twitter oder Facebook zurück, um sich aktuelle Informationen zu beschaffen. Immerhin bietet das Inhaltsverzeichnis eines Newsletters – wenn es gut gemacht ist – einen schnellen Überblick über die Neuigkeiten. Das funktioniert aber nicht, wenn bunte Bilder, Disclaimer und weitere Informationen den Blick auf den Inhalt verstellen.
HTML sollte dem Web vorbehalten bleiben, wo es gut aufgehoben ist und seinen Zweck erfüllt. Es gab früher und gibt bis heute keinen Grund, seine Mitmenschen mit HTML-Mails zu belästigen. Und mal ehrlich, wann hast du das letzte Mal das tolle Design eines Newsletters bewundert?
Wirklich absurd sind Newsletter, die als PDF verschickt oder irgendwo heruntergeladen werden müssen. Die Anbieter haben wohl nicht wirklich verstanden, dass das Internet keine Litfassäule ist.
Auch wenn der Newsletter als Informationsmedium eine große Rolle spielt und ähnlich wie der RSS-Feed zumindest in absehbarer Zeit nicht aussterben wird, sollte man die Kraft des Mediums nicht überschätzen. Entscheidend ist, wie viele Leute man tatsächlich erreicht und nicht, wie viele Leute den Newsletter abonniert haben. Im Mailprogramm ist es leichter, die Löschen-Taste zu drücken als ein Abo abzubestellen. Die Anbieter werden es nicht gerne hören, aber die Zahl der echten Leser steht in keinem guten Verhältnis zur Zahl der Abonnenten. Auch das ist ein Grund, sich auf das Wesentliche zu konzentrieren und alle möglicherweise störenden Elemente zu entfernen.