ein Blog übers Web, IT, Linux, Techiekram...

Webdesign ::: Checkliste um Webauftritte und Blogs zu testen

Wer Webseiten erstellt oder verschiedene Themes in Blogs einsetzt, sollte vor allem bei neuen Layouts, aber auch bei Änderungen testen. Es gibt die unterschiedlichsten Arten das zu tun, wir bei miradlo nutzen dazu eine Checkliste, um nichts zu vergessen. Einer der wichtigsten Punkte bereits während des Erstellens neuer Webseiten sind die regelmäßigen Prüfungen in den Validatoren, Validator-Links siehe Glossar zu Validatoren. Wir passen unsere Checkliste immer mal wieder an, der ein oder andere hat sich auch weitere eigene Punkte notiert oder diese Liste ergänzt. Unsere Liste ist aufgeteilt in Gruppen von Tests:

Benutzerfreundlich

  • nur soviel Pflichtfelder wie nötig, nicht gleich den Stammbaum, nur um Kontakt aufzunehmen
  • nicht eindeutige Linktexte mit zusätzlichem title, klar unterscheidbare verschiedene Namen für Links (nicht zehnmal "mehr" oder "weiterlesen")
  • spezielles CSS für print und handheld (klappt aus Zeitgründen grad noch nicht immer)
  • Sitemaps sobald der Auftritt eine umfangreichere Navigation hat (bei einem 10-Seiten-Auftritt ohne Unternavigation halte ich eine Sitemap für überflüssig)
  • Fehlerseiten mit vollständiger Navigation (error und forbiddeen für 404, 401 und 403)
  • favicon zur Orientierung
  • fremdsprachige Texte bekommen z.B. ein <div lang="en"></div> (allerdings bei "denglischen" Begriffen spare ich mir das)
  • Links haben verschiedene Auszeichnungen für ihre Zustände (visited, hover, focus, active sind unterscheidbar definiert, so dass sich besuchte Links unterscheiden und auch bei Tastaturnavigation erkennbar ist, bei welchem Link man grad steht)

Les- und benutzbar möglichst ohne Barrieren

  • Skiplinks für die Navigation (nehmt hier mal die Tastatur zum Navigieren, dann erscheinen die Links die entweder zur Navigation oder zum Inhalt führen)
  • entweder alt-Texte, die zumindest grob Bilder beschreiben, oder Bildtitelbeschriftungen dann meist kein weiterer alt-Text, wichtig dann jedoch das leere alt-Attribut: alt="" (sonst lesen z.B. Screenreader vor:"Alternativtext ein Leerzeichen" ;-)
  • wann immer möglich flexibles, skalierbares Layout (Sonderwünsche, Kundenwünsche, spezielle Anforderungen können Ausnahmen sein, sonst ab 800*600 ohne Scrollen und auf 1680*1050 trotzdem nicht gähnende Leere)
  • Formulare mit sinnvollen Labels, die die Eingabefelder umschließen
  • Fehlermeldungen, die man verstehen kann ("die Eingaben sind nicht korrekt" hilft dem Besucher nicht rauszufinden, was jetzt nicht korrekt war)
  • Grundlayout möglichst mit guten Farb- und Helligkeitskontrasten (online testen von Farbkontrasten einer Seite ist eine Variante, für den Firefox gibts ein Plugin, welches jedoch bei Firefox 3 noch nicht läuft. Bei Hintergrundbildern entscheide ich derzeit nach Augenmaß, da die Tools das noch nicht berücksichtigen)
  • Definitionen von Hintergrundfarben so, dass auch ohne Bilder kein weißer Text auf weißem Hintergrund steht
  • Informationen, nicht nur mittels Farben unterscheidbar

Trennung von Inhalt und Layout

  • sinnvolle Semantik: Seiten beginnen mit h1, bestehen aus Überschriften, Listen, Absätzen...
  • keine Spielereien, wie: da noch eine Überschrift, weil die grad die passende Größe und Design hat
  • Textauszeichnungen per CSS sowie Hervorhebungen mittels strong und em
  • CSS möglichst strukturiert und spezielles für den IE mit Conditional Comments, außerdem möglichst wenige Klassen, sondern eher nutzen der HTML-Elemente
  • div nur für Strukturen, nicht um alles einzupacken
  • Hintergrundbilder gibts im CSS

Technisches

  • Seiten, die mit lesezeichentauglichen URLs zu finden sind (nicht .../unterordner/?seitekr5679-grr...)
  • alle Grundfunktionen sind ohne JavaScript erreichbar
  • Seiten werden vom Server mit dem passenden Zeichensatz ausgeliefert (siehe z.B. die Webdeveloper-Toolbar /Informationen/Seitenheader da sollte der Zeichensatz stehen)
  • "cool URIs don't change" zumindest nicht ohne passende Weiterleitung (das bedeutet bei Änderungen werden sinnvolle RedirectPermanent Verweise in der .htaccess gesetzt)
  • regelmäßige Kontrollen aller Links (unter Linux mit dem Link Checker, der im Quanta integriert ist, online für ganze Webauftritte, z.B: bei Link Valet)
  • Test aller Layouts auf mindestens: IE 5 bis 7, sowie Firefox, Mozilla, Opera, Konqueror, Safari und Links (aktuelle Version von Lynx unter Linux) in aktuellen Versionen (z.B. im Moment auf Firefox 2 und 3) (allerdings teste ich nicht alle Browser bei jeder Änderung an einer Seite nochmal)
  • Startseite nicht unter verschiedenen Adressen erreichbar (mit und ohne www oder mit und ohne index.dateiendung, auch dafür die .htaccess anpassen, warum nicht siehe double content)

Browser und Auflösungen

Hier geht es noch um Tipps, wie sich bereits beim Entwickeln eines Layouts möglichst viel testen lässt ohne dass der Aufwand ins Unendliche geht. Diese Tipps gehen von einer Linuxumgebung mit einigen installierten Browsern aus. Für Abschlusstests ist eine Windows-Umgebung und möglichst auch ein Mac nötig.
  • von 800*600 bis 1680*1050 zumindest auf bedienbar prüfen
  • in einem Standard-Entwicklungsbrowser, meist der Firefox, entwickeln
  • Seamonkey hier bieten sich spezielle Einstellungen an, da gleiche Engine wie Firefox
  • Opera
  • Konqueror nur wenige Sondereinstellungen, da als Safariersatz genutzt
  • Internet Explorer mindestens IE 6 und IE7
  • einen Browser immer mit anderer Hintergrundfarbe einstellen (vergessene Farbdefinitionen fallen dann auf, denn meist ist weiß Hintergrundfarbe des Browsers, wenn da eine Definition fehlt, sieht man das nur bei anderer Farbe)
  • einen Browser immer mit größerer Schriftgröße einstellen (Formularelemente haben da die Tendenz plötzlich unbenutzbar zu werden, das muss nicht sein)
  • mindestens einen echten Safaritest auf Optik, z.B. mit browsershots.org

Inhaltliche Tests

  • auf Inhalt, alles verständlich, keine nicht erklärten Fachwörter
  • Grammatik und Rechtschreibung, Tippfehler (Rechtschreibung einheitlich, nur alte, nur neue, nur deutsche, nur schweizer Version... Es ist egal welche Variante, aber sie sollte durchgängig sein)
  • durchgängige Ansprache, z.B. siezen wir auf miradlo.com und .de, aber hier auf miradlo.net duzen wir durchgehend auf allen Seiten. Manche Seiten ziehen durchgängig eine Ansprache ohne direkte Anrede vor.
  • Navigationspunkte vorhanden?
  • Brotkrümel ok?
  • Metadaten korrekt? (verschiedene zur Seite passende Titel, Keywords, Description)
  • korrekte Seiten selektiert? (gerade wenn PHP-Navigationen genutzt werden, kann es passieren, dass da was nicht stimmt)
  • Mailadressen ok? (wir kodieren Mailadressen mit &irgendwas, damit lässt sich mancher Spam verhindern, im Code sind sie dann jedoch nicht so gut lesbar, deshalb schleicht sich leichter ein Fehler ein)
  • etwaige Weiterleitungen ok?
  • Funktioniert der Bildwechsler? Textwechsler? Kontaktformular? (etwaige andere spezielle Effekte, die erscheinen sollten sieht man im Quellcode oder bei Blogs anhand genutzter Widgets und Plugins. Falls Tester und Entwickler nicht dieselbe Person sind, sollte vom Entwickler eine Liste der gewünschten Funktionen gemacht werden. ) Beim Testen von Funktionen mit Besuchereingaben, nicht nur mit korrekten Eingaben testen, sondern gerade auch mit falschen Eingaben, um zu sehen, ob korrekte Fehlermeldungen kommen.
  • wenn print.css vorhanden: Druckvorschau testen
  • wenn vorhanden: handheld-CSS testen

Unterm Strich

Beachtet man die obigen Punkte, dann sind Webseiten noch immer nicht zu 100% barrierefrei, aber sie sind für viele leichter zu nutzen. Über manchen Punkt kann man diskutieren, diese Liste stammt von mir, sie enthält im Zweifel meine Sichtweise. Bei miradlo gilt, dass sich alle an diese Liste halten müssen, wenn ein Punkt nicht passt, dann diskutieren wir den und ändern ihn entweder oder machen auch mal eine Ausnahme je nach Auftritt. Wichtig ist, dass man beim Testen weiß, woran man sich orientieren kann, was soll man überhaupt prüfen... Bei Blogs sollte man bei Updates noch manches andere berücksichtigen.

Tipp für Tests nach Checkliste

Sinnvoll ist es sich eine eigene Testliste zu erstellen, als Grundlage, kann z.B. diese Liste dienen. Die eigene Liste, z.B. fürs eigene Blog oder die eigene Website sollte spezielle Eigenschaften berücksichtigen, weglassen kann man, was man sowieso bei Änderungen bereits automatisch testet. Unsere Liste geht davon aus, dass meist die Webautoren ihre Seite nicht selbst testen, das ist sinnvoll, wenn es möglich ist, denn manche Fehler sieht man selbst nicht. Wer jedoch selbst entwickelt und testet sollte die persönliche Checkliste dementsprechend anpassen.

Noch keine Kommentare

  • Dieter
    Dieter  
    Jetzt weiß ich, warum ich immer relativ lange für das Erstellen eines Webauftritts oder Blogs brauche. ;-) Deine Checkliste ist super und macht mir deutlich, was ich selbst alles so überprüfe. Da kann ich die Checkliste fast direkt übernehmen. :-) Lediglich mit dem Punkt Hintergrundbilder mit CSS habe ich manchmal so meine Probleme, denn derzeit sind diese noch nicht skalier-/zoombar. Und da ich Windows XP als Betriebssystem habe kommen bei mir teilweise andere Programme zum Einsatz. So beispielsweise Xenu für das Überprüfen externer Links.
  • Mark
    Mark  
    mich will er gar nicht validieren :-(
  • ute
    ute  
    @Mark Dein Server liefert: ##################### Date: Thu, 18 Dec 2008 19:29:22 GMT Server: Apache Content-Type: text/html; charset=none Transfer-Encoding: chunked Connection: Keep-Alive 200 OK ############# Wenn vom Server kein Zeichensatz ausgeliefert wird, klappt das Ganze nicht. Meist kannst du darauf per .htaccess Einfluß nehmen... Wie das geht findest du bei Google, sollte das nicht klappen, musst du mit deinem Hoster klären, was sich tun lässt.

Kommentar schreiben

Gravatar, Twitter, Favatar Autoren-Bilder werden unterstützt.
Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
Um einen Kommentar hinterlassen zu können, erhalten Sie nach dem Kommentieren eine E-Mail mit Aktivierungslink an ihre angegebene Adresse.
BBCode-Formatierung erlaubt
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.