Schlagwort-Archive: CSS

Webseiten als ebook im ePub-Format aufbereiten

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.

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.

Barrierefrei glücklich – kein Pfusch beim Design

Handwerklich schlecht gemacht ist Design, wenn improvisiert wird. Nachdem wir die Grundlagen tabellenfreier Layouts betrachtet haben, fragen wir uns nun, wie man „Abstand hält“.

Schlechte Designer verwenden dazu das geschütze Leerzeichen oder nonbreaking space, also HTML-Entität &nbsp;. Oder man verwendet das break <br> als Abstandhalter für Absätze. Das ist nicht sinnvoll, früher oder später möchte man eventuell so etwas ändern und muss es dann aufwändig suchen und entfernen. Sinnvoller ist es hier, von Anfang an auf CSS zu setzen. By the way, man sollte auf Inline-CSS nach Möglichkeit vollständig verzichten.

Zum Abstandhalten werden die Eigenschaften margin und padding verwendet. Margin ist der Außenabstand, padding der Innenabstand oder Einbettung. Diese Eigenschaften können etwa für Links, Absätze, Bilder und andere Elemente verwendet werden, auch für div oder span. Werden sie nicht vergeben, wird normalerweise das browserseitige CSS eingesetzt.

Die beiden Eigenschaften lassen sich verfeinern, indem man unterschiedliche Abstände eingibt:

margin-left: 5px; margin-right:4px; margin-top:3px; margin-bottom:2px;

Typographische Abstände lassen sich wie gewohnt definieren über word-spacing oder letter-spacing. Damit kann – was sonst – die Abstände zwischen Worten und Buchstaben regulieren.

Wie baue ich ein tabellenfreies Webseiten-Layout

Die Layouttabelle war vor der Entwicklung der Layoutsprache CSS die einzige brauchbare Möglichkeit, komplexe Layouts zu entwickeln. Seitdem hat sich viel getan: Die Unterstützung für CSS ist so weit etabliert, dass Tabellenlayouts langsam aussterben (sollten). Stattdessen setzt ausgerechnet der Computerverlag Heise konsequent auf Tabellen.

Zunächst einmal muss man verstehen, wie in CSS positioniert und formatiert wird. Alle Elemente – bis auf den body – werden in Div-Containern eingefasst <div>Element</div>. Alle Elemente, die in Div-Containern stehen, lassen sich über externe Stylesheets exakt positionieren.

Die Positionierung erfolgt über die Attribute von position: left, right, top und bottom.Die Höhe und Breite können unabhängig von position mit width und height definiert werden. Das heißt natürlich, dass man nur zwei Attribute von position definieren kann, also entweder left und top oder left und bottom und so weiter. Die Dimension wird über width und height bestimmt.

Alle großen Elemente wie Spalten sollten absolut positioniert werden, sprich:

{position: absolute; left:0; top:0; width: 1000px; height: 200px}

Es gibt die Eigenschaft float, die aber der Internet Explorer nicht unterstützt.

Das könnte unsere Kopfzeile werden, in dieser Kopfzeile können sich Elemente wie Bilder befinden. Im westlichen Kulturkreis liest man von links nach rechts und guckt zuerst nach oben links. Alle großen Container sollten daher von oben links absolut definiert werden. Möchte man etwa ein Objekt unten rechts positionieren, riskiert man, dass das Objekt bei kleinen Bildschirmen außerhalb des Sichtbereiches liegt.

Ein wichtiger Hinweis: Der Screenreader von Blinden greift auf den Quelltext zu und weiß nicht, wie Elemente auf der Seite selbst definiert wurden. Das heißt: Die Elemente der Website müssen im Quellcode genau in der Reihenfolge aufgeführt werden, in der sie auch auf der Seite präsentiert werden. Das heißt in der Regel: von oben links nach unten rechts, wobei die Fußzeile das letzte Element im Quelltext ist. Anders macht es etwa Golem, so dass ein Screenreader hier zuerst die Stellenanzeigen liest, die aber auf dem Bildschirm NACH der Artikelliste angezeigt wird.

Hier meine Seite als Beispiel und hier deren CSS-Code.

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.

SEO IV – schwerer wirds immer – technische Aspekte

Laden Sie alle Beiträge zur Suchmaschinenoptimierung als PDF herunter

Der Titel „SEO leicht gemacht“, den ich bisher verwendet habe, war irreführend. SEO ist zumindest zeitaufwendig und ein Prozess, der genau genommen nie ganz abgeschlossen ist.

Die technische Ebene ist dabei die wahrscheinlich komplexeste Ebene. Hier kommt man ohne HTML-Kenntnisse nicht weit.

Die Bots und Crawler der Suchmaschinen können zwar nicht denken, sie sind aber keine totalen Authisten. Deswegen kann man ihnen auch so leicht nichts vormachen.

Sie können zum Beispiel erkennen, ob eine Seite sauber geschrieben ist. Viele der älteren WYSIWYG-Editoren wie Frontpage 2000, aber auch NVU X.X produzieren schlechten Code. Das hat sich wohl gebessert, auch beim Dreamweaver, ein weiteres Manko des WYSIWYG wird sich wohl nie beheben lassen – die Produktion von redundantem und kompliziertem  Code.

Das mag auch daran liegen, dass Stylesheets auf dieser Ebene eher schwierig zu implementieren sind.

Clean the code

Mit sauberem und schlankem HTML-Code kann man das Herz jedes Bots gewinnen. Eine vom WYSIWYG produzierte Seite ist trotz Optimierung doppelt oder dreimal so groß wie eine Handgeschriebene. Der Grund ist ganz einfach: Obwohl z. B. alle Absätze gleich formatiert sind, schreibt der optische Editor in jeden Absatz Schriftart, Schriftyp, Schriftgröße und weitere Informationen rein. Er weiß nicht, dass wir alle Absätze gleich formatieren wollen, weil wir das nicht vroher festgelegt haben.
Ein weiterer Grund sind Layouttabellen, die aus vielerlei Gründen von Webdesignern nach wie vor verwendet werden. Der Vorteil von Tabellen liegt tatsächlich darin, dass sich Elemente recht genau platzieren lassen und dass die Seiten auch dann strukturiert sind, wenn man sie als HTML abspeichert und offline anguckt. Stylesheets werden normalerweise nicht abgespeichert, wodurch natürlich alles verloren geht, was darin festgelegt wurde.
Aber: Layouttabellen vervielfachen den Quellcode.

Pflegeleichter Quellcode

Korrigieren lässt sich das Ganze nur auf Quelltextebene, den Quelltext muss man aber lesen können. Das beste ist wohl, parallel auf beiden Ebenen zu arbeiten, wem phase5, Notepad++ oder HTML-Studio zu spartanisch erscheint.

Banalitäten wie korrekte Dokumentendeklaration, Meta-Description, keine toten Links, Sitemaps, keine Links in JavaScript-Code, Titel für Images, Validierung des Quelltextes und des Style Sheets sollten eigentlich nicht mehr erwähnt werden. Viele Webdesigner vertrauen allerdings eher auf ihre Design- als auf technische Fähigkeiten.

Das alles ist aus einem simplen Grund wichtig: der Bot kann durchaus erkenen, ob eine Seite valides HTML ist, ob Links tot sind oder ob man sich Mühe gegeben hat, sauberen Code zu erstellen. Für den Bot ist es irrelevant, er weiß dann nur, dass da ein Profi am Werk war und das sie Seite nutzerfreundlich ist.

Meta und mehr

Obwohl Meta-Tags heute an sich für die Suchmaschinenoptimierung nicht mehr die Bedeutung wie einst hatten, müssen auch sie gepflegt werden. Der Webdesigner muss sich bemühen, einen ordentlichen Eindruck auf den Bot zu machen. Google und andere beschweren sich durchaus, wenn doppelte Meta-Descriptions vorhanden sind oder wenn die Keywords nicht mit dem Inhalt des Body übereinstimmen.
Ebenso benötigt man auch dann eine robots.txt, wenn man dem Robot eigentlich nichts mitteilen will, wenn man ihm also erlauben will, alle Verzeichnisse zu durchsuchen.

Weiterführendes

SEO VI – Web 2.0 fürs Optimieren
SEO IV – die Strukturebene

SEO leicht gemacht III – Verlinkungen

SEO für alle II – die Inhaltsebene

SEO leicht gemacht – Suchmaschinenoptimierung für alle I

SEO IV – die Strukturebene

Ebenso wichtig wie die Inhaltsebene ist die Strukturebene. Die Struktur einer einzelnen Website basiert auf der Auszeichnungssprache HTML. Mit WYSIWYG-Editoren läßt sich ein solcher HTML-Code automatisch erzeugen. Von großer Relevanz sind folgende Bereiche:

1. Der Title oder Seitentitel: Er wird in den Suchergebnissen als erstes angezeigt und ist ENTSCHEIDEND dafür, dass ein User eine Seite anklickt. Er steht im Kopf einer HTML-Datei und nicht im eigentlichen Text der Seite. Sieht man ein Suchergebnis mit dem Titel „Unbenannte Seite 1“ merkt man sofort, dass da jemand geschludert hat

2. Sprechende Links: Von Content Management CMS erzeugte Seiten waren früher sehr kompliziert. Heute werten Suchmaschinen auch die Links aus, deshalb sollten sie Keywords enthalten, siehe die Adressleiste oben. WordPress kann also standardmäßig sprechende Links erzeugen.

3. Tags im Inhalt: Struktur gewinnt eine Seite wie bei normalen Dokumenten mittels Überschriften und Hervorhebungen. WYSIWYG-Editoren wie Kompozer bieten solche Formatvorlagen standardmäßig an. Dabei sollte man den üblichen Unsinn vermeiden, etwa den ganzen Text fett oder kursiv zu machen oder willkürlich Überschriften vergeben. So doof sind die Bot-Programmierer nun doch nicht.

4. Alternativtexte und Titel für Multimedia: Innerhalb eines Links oder Multimedia-Elements lassen sich Alternativtext und Titeltext vergeben. Der Titel wird angezeigt, wenn man mit der Maus darüber fährt. Es spricht nichts dagegen, dass Suchmaschinen solchen wichtigen Text auswerten, aber die Meisten vergessen schlicht, dass es solch eine Möglichkeit überhaupt gibt.

Wichtig ist, dass über CSS definierte Klassen natürlich nicht gewertet werden können. Dazu müsste der Bot verstehen, was mit der Klasse gemeint ist, das kann er natürlich nicht.

Suchmaschinen lieben RSS-Feeds. Ein Weblog-Eintrag kann so oft innerhalb von Minuten in den Suchergebnissen auftauchen. Natürlich sollten sie auch gefüttert werden, sprich, man sollte etwas Relevantes mitzuteilen haben.