Jun 26
Mit »Design made in Germany« ist ein neues Designmagazin auf dem deutschen Markt erschienen – vielleicht auch eins, das ich länger als drei Ausgaben lese. Denn bisher fand ich noch kein Magazin interessant genug oder konnte mich sogar damit anfreunden. Mit »Design made in Germany« könnte sich das jedoch bald ändern, denn es erscheint zumindest in meinem bevorzugtem Medium – dem Internet. Angeboten wird eine PDF-Version die ansprechend gelayoutet ist und eine HTML-Version, welche ein optimiertes Layout aufweist. Als Goodie wird jeder Artikel auch als einzelne PDF-Datei angeboten.

Über das Themenspektrum lässt sich meist bei der ersten Ausgabe nicht viel sagen. In der ersten Ausgabe sind sie jedoch recht interessant. Wie sich das weiterentwickelt wird sich zeigen. Das Querlesen in der S-Bahn hat jedoch heute schon viel Spaß gemacht. Im Gegensatz zur PAGE, finde ich die Themen jedoch handfester und nicht so künstlerisch abgehoben.
Okt 30
Hinweis: Dieser Artikel erscheint im Rahmen der Accessibility Blog Parade 2007. Bitte beachten Sie auch die weiteren Artikel, die im Rahmen dieser Parade entstanden sind.
Viele Artikel über die Umsetzung von Barrierefreiheit auf Websites gehen von dem Idealzustand – eine noch nicht erstellte Website – aus. Doch nur selten steht ein Webdesigner vor diesem Idealzustand. Viel eher ist die Aufgabenstellung, eine bestehende und meistens barrierereiche Website barriereärmer zu gestalten. Zudem ist es nur in den wenigsten Fällen möglich, im Hintergrund an einer neuen Version der Website zu arbeiten, sondern die Änderungen müssen »Live« durchgeführt werden. In diesem Beitrag möchte ich in fünf Schritten zeigen, wie die Realisierung einer barrierearmen Website in der Praxis organisiert und realisiert werden kann.
Schritt 1: Nicht alles auf einmal
Bei einem ersten prüfendem Blick einer Website, zeigen sich in den meisten Fällen relativ schnell die ersten Barrieren und man merkt, wie viel doch eigentlich an dieser Website zu tun ist. Hier ist es wichtig denn Überblick zu behalten und nicht alles auf einmal erledigen zu wollen. Anstatt die Accessibility-Problematik nach dem Motto: »Ein paar Alternativtexte hier und ein paar Label hier« anzugehen, empfiehlt es sich, die Änderungen im Vorfeld genauestens zu planen und zu koordinieren.
Definieren Sie zu Beginn Ihrer Arbeit die Ziele, die Sie mit der Umstrukturierung in Bezug auf die Barrierefreiheit erreichen wollen. Einige mögliche Punkte hierfür könnten sein:
- Alle Bilder und eingebundenen Elemente besitzen einen Alternativ-Text (beispielsweise in Form von
-Attributen)
- Der Inhalt ist entscheidend und nicht das Design oder die Fenstergröße des Browsers
- Valider und Standardisierter Quellcode
- Keine Link-Bezeichnungen die sich wiederholen (beispielsweise mehrfache »mehr…«-Links)
- Alle Formularelemente sind mit dem
-Attribut ausgezeichnet
Schritt 2: Entwickeln Sie einen Schritt-für-Schritt-Plan
Nachdem Sie sich nun entschlossen haben was Sie erreichen möchten, ist der nächste Schritt zu entscheiden, wo Sie als erstes mit der Arbeit beginnen und in welcher Reihenfolge Sie die Punkte erledigen möchten. Ein möglicher Plan dafür könnte wie folgt aussehen:
Seitennavigation
Die Navigation ist für die meisten Benutzer der Ausgangspunkt für ihre Recherche auf einer Website. Daher sollte mit der Optimierung auch an dieser Stelle begonnen werden. Zudem sind die Änderungen an der Navigation meistens recht einfach durchzuführen und können zeitgleich sehr effektiv sein. Stellen Sie sich bei der Beurteilung der Navigation die Fragen: Verwendet meine Navigation Grafiken? Bleibt die Navigation auch noch benutzbar, wenn die Anzeige von Grafiken deaktiviert ist? Sind die Menüpunkte auch noch aus weiter Ferne eindeutig erkenn- und unterscheidbar (z.B. für Menschen die schlecht sehen können)?
Populäre Seiten
Als nächstes sind die Populären Seiten an der Reihe. Welche das sind, können Sie leicht über ein Statistik-Programm herausfinden. Ziel ist es bei dieser Optimierung, mit wenigen Änderungen an den entscheidenden Stellen das größtmögliche Publikum zu erreichen.
Inhaltsseiten
Weit wichtiger als die Startseite, sind die Inhaltsseiten einer Website. Denn die wenigsten Besucher betreten eine Website über die Startseite, sondern landen viel wahrscheinlicher durch Suchmaschinen mitten in Ihrem Angebot. Daher sollte als nächstes die Priorität der Accessibility-Optimierung bei den Inhaltsseiten liegen.
Sonstige Seiten
Nachdem wir die Arbeiten an allen vorrangigeren Bereichen abgeschlossen haben, können wir uns nun um die restlichen Seiten im Ihrem Webangebot kümmern. Hier ist es egal in welcher Reihenfolge Sie vorgehen. Sie können dies in thematischen Bereichen gegliedert oder in alphabetischer Reihenfolge tun. Wichtig ist nur, dass Sie dokumentieren, welche Bereiche noch eine Überarbeitung benötigen und welche Sie schon abgearbeitet haben.
Schritt 3: Benutzertests
Sobald Sie mit der Arbeit oder einem Teil fertig sind, führen Sie ausreichend Benutzertests durch. Programme zur Validierung des Quellcodes reichen dabei bei weitem nicht aus. Eine Website die gegen XHTML 1.0 Strict und CSS zu 100 Prozent validiert, muss noch lange keine perfekte Website im Sinne der Barrierefreiheit sein. Daher verzichten Sie nicht auf Tests mit echten Benutzern. Dies können Freunde, Ihre Familie oder aber auch die »normalen« Besucher Ihrer Website sein. Mehr dazu im folgenden Schritt.
Schritt 4: Sagen Sie Ihren Besuchern was Sie tun
Bei der Überarbeitung Ihrer Website haben Sie zwei Möglichkeiten: Sie können die überarbeitete Website mit einmal oder aber in Teilschritten veröffentlichen. Die zweite Möglichkeit hat dabei eindeutig Vorteile: Sie müssen nicht erst eine Mammut-Aufgabe bewältigen, sondern können sie in Teilschritten abarbeiten und erhalten schneller vorzeigbare Ergebnisse und Rückmelden seitens der Besucher. Die Rückmeldungen die Sie dabei erhalten sind sehr wertvoll und können Sie bei der weiteren Arbeit sehr unterstützen, sowie einen Teil der Benutzertests darstellen. Schließlich sind es die Benutzer, die mit Ihrer Website später »arbeiten« müssen. Aus diesem Grund sollten Sie noch vor den geplanten Optimierungsarbeiten die Benutzer Ihrer Website über die geplanten Arbeiten informieren. Zudem bringen Ihre Besucher dadurch sicherlich mehr Verständnis auf, wenn es – bedingt durch die Arbeiten – zu zeitweisen Ausfällen der Website kommt.
Schritt 5: Zeigen Sie Fortschritte
Sofern Sie die Website in einzelnen Teilschritten barrierefreier gestalten, sollten Sie Ihre Besucher darüber aufklären, was Sie schon getan haben und warum. Ihre Besucher werden dadurch erkennen, dass es wirkliche Fortschritte gibt und Ihre Ankündigung von Schritt 4 nicht nur als Lippenbekenntnis aufzufassen ist.
Okt 18
Hinweis: Dieser Artikel erscheint im Rahmen der Accessibility Blog Parade 2007. Bitte beachten Sie auch die weiteren Artikel, die im Rahmen dieser Parade entstanden sind.
Um die Gleichstellung von Menschen mit einer Behinderung auch im Internet zu gewährleisten, wurde vom Gesetzgeber im Juli 2002 ein Gesetz verabschiedet: Die »Barrierefreie Informations-Technik-Verordnung«, kurz BITV. Sie ist die wohl wichtigste Grundlage für Webdesigner, um eine Website barrierearm zu gestalten. Leider ist die BITV sehr umfangreich und nicht sehr verständlich geschrieben. Daher ich in diesem Beitrag die einzelnen Punkte kurz und kompakt wiedergeben.
- Für Multimedia-Elementen wie Bilder, Sound und Videos müssen Alternativen bereitgestellt werden, die auch ohne Hilfsmittel (z.B. Plugins) verstanden werden können. Dies kann beispielsweise durch Alternativtexte geschehen.
- Auch ohne Farben müssen Bider, Grafiken und Texte deutlich zu erkennen und zu unterscheiden sein (z.B. für Fehlsichtige).
- Die Struktur und der Inhalt müssen vom Design getrennt sein. Bei HTML und CSS sind die jeweiligen Spezifikationen einzuhalten.
- Besonderheiten in der Sprache wie Abkürzungen und Sprachwechsel müssen ausgezeichnet werden.
- Tabellen sind nicht grundsätzlich verpönt, sondern sind auch weiterhin für die Darstellung von tabellarischen Daten zu verwenden, nicht jedoch zum Layouten von Webseiten.
- Websites müssen auch ohne Plugins, JavaScript und Applets benutzbar bleiben.
- Der Benutzer muss »zeitgesteuerte« Inhalte kontrollieren können: Dazu zählen unter anderem automatische Aktualisierungen und Weiterleitungen.
- Der Zugriff auf Benutzerschnittstellen (wie Scripts, Applets, Flash, etc.) müssen genauso zugänglich sein wie statische Objekte (Texte, Grafiken, …).
- Unabhängig vom Ein- oder Ausgabegerät muss ein Webauftritt benutzbar bleiben. Beispielsweise indem ausschließlich mit der Maus statt mit der Tastatur gearbeitet wird.
- Auch in älteren Technologien und Browsern ist die Verwendbarkeit der Website sicherzustellen. Allerdings auch nur dann, wenn der Aufwand dafür noch verhältnismäßig ist.
- Alle verwendeten Technologien sollten öffentlich zugänglich und vollständig dokumentiert sein.
- Informationen zur Orientierung und zum Kontext müssen dem Nutzer zur Verfügung gestellt werden.
- Alle Navigations-Instrumente müssen übersichtlich und nachvollziehbar sein, z.B. durch die Angabe von Hyperlink-Zielen, Sitemaps. Außerdem sollte jeder Link eindeutig bezeichnet werden und nur einmal auf einer Seite vorkommen.
- Der Inhalt muss leicht zu verstehen sein, beispielsweise durch eine einfache und klare Sprache.
Viele Bedingungen lassen sich recht einfach erfüllen. In den meisten Fällen allein schon durch einen sauberen Code nach etablierten Standards. Bei anderen Punkten gibt es einen gewissen Spielraum, wodurch sie sich nicht einfach nur nach technischen Kriterien abhacken lassen. Daher sollte bei der Arbeit immer der Mensch im Hinterkopf behalten werden.
Jun 15
Unter den Webworkern ist modernes und standardkonformes Webdesign noch immer ein heißdiskutiertes Thema. Ganz oben steht in dieser Diskussion immer die Trennung von Inhalt und Design. Schließlich ist modernes Webdesign unter Einhaltung der Webstandards zukunftssicher, oder etwa doch nicht?
Unter zukunftssicherem Webdesign stelle ich mir eine Website vor, die auch noch in fünf Jahren und länger funktionstüchtig ist. Doch ist dies mit den heutigen Mitteln ohne Layout-Tabellen überhaupt zu erreichen? Derzeit stehen verschiedenen Möglichkeiten zur Realisierung von Websites zur Verfügung: Da gibt es HTML 4.0 und XHTML 1.0, sowie CSS 1.0, CSS 2.0 und demnächst CSS 3.0.
Meiner Meinung nach können nur Websites als zukunftssicher bezeichnet werden, wenn sie auf abgeschlossenen Standards basieren, an denen nicht mehr gearbeitet wird und die von den Browsern zufriedenstellend umgesetzt werden können. Dies ist bei HTML 4.0 und CSS 1.0 der Fall. Dürfen nun also auch Websites als zukunftssicher bezeichnet werden, die auf das moderne XHTML 1.0 und CSS 2.0 setzen?
An XHTML wird noch gearbeitet und die Unterstützung von CSS 2.0 ist in einigen Browsern noch als sehr mangelhaft zu bezeichnen. Daher kann es hier immer wieder zu Veränderungen bei der Unterstützung bzw. Interpretation des Quellcodes geben. Von daher würde ich modernes Webdesign mit XHTML und CSS 2.0 (zumindest derzeit) nicht als zukunftssicher bezeichnen, sondern eher als Alternative, die es einem in einigen Jahren leichter machen wird, die Website zukunftssicher zu realisieren.
Der Internet Explorer hat laut aktuellen Statistiken derzeit eine Verbreitung von 70-80%. Die Versionen 5.xx und 6.xx machen davon noch ca. 50 Prozent aus. Das Schlimme daran: Beide Versionen sind am weitesten verbreitet und beherrschen kaum CSS 2.0. Besonders schlampen tun sie ausgerechnet am stärksten bei dem Teil von CSS, welcher die »Layout-Tabellen« ersetzen soll.
Die nächste schlechte Nachricht ist: An dieser Situation wird sich leider so schnell nichts gravierendes ändern. Der überwiegendste Teil der Anwender sind nun einmal kein Webdesigner oder Informatiker, sondern einfacher Benutzer, der sich nicht mit der Materie beschäftigen möchte und daher lieber seine bisher eingesetzte Software weiterverwendet. Neue Anwendungen bzw. Versionen halten erst mit einem neuen Computer Einzug in die Wohnzimmer. Schließlich sind die Computer schon bei der Auslieferung Softwaremäßig heutzutage recht komplett ausgerüstet.
CSS-Hacks
Um jetzt doch Websites mit XHTML und CSS 2.0 entwickeln zu können – die auch im Internet Explorer einigermaßen korrekt angezeigt werden – werden meistens so genannte CSS-Hacks benötigt. Das sind kleine Codeschnipsel, die von bestimmten Browsern interpretiert und von den restlichen ignoriert werden. Dadurch ist es möglich, einzelnen Browsern unterschiedliche Anweisungen »untergeschummeln«. Die meisten Hacks gibt es für den Internet Explorer.
Diese Hacks funktionieren jedoch meist nur in einer Browser-Version. Soweit nicht sonderlich schlimm. Doch was passiert jetzt, wenn eine neue Version des Browsers veröffentlicht wird? Der Internet Explorer 7 kann beispielsweise CSS 2.0 schon etwas besser interpretieren und viele Hacks die unter dem IE 6 noch benötigt wurden, bewirken nun im IE 7 das glatte Gegenteil. Was geschieht dann? Die Hacks müssen wieder entfernt bzw. angepasst werden. Ist das zukunftssicheres Webdesign? Wohl eher nicht. Hinzukommt das bei Websites im Auftrag von Kunden durch die Mehrarbeit zusätzliche Kosten entstehen. Aber wer soll diese Kosten tragen? Der Webdesigner? Der Kunde? Microsoft jedenfalls sicherlich nicht.
Derzeit können Websites die standardkonform und ohne Layout-Tabellen realisiert sind wohl noch nicht als zukunftstauglich bezeichnet werden. Sie sind aber eine gute Grundlage für eine Zukunft, die vielleicht in fünf Jahren anfängt.
Jun 07
Im heutigen Zeitalter der digitalen Kameras und Fotohandys werden auf den Festplatten immer mehr Bilder angehäuft. Schon nach kurzer Zeit stehen die meisten Anwender vor dem Problem, den Überblick zu verlieren. Daher sollte man sich schon von Anfang an Gedanken über die Archivierung der Fotos machen. Eine Möglichkeit ist die Verschlagwortung der Bilder mit Metadaten wie Titel, Beschreibung und Keywords. Hierfür hat das standardisierte IPTC durchgesetzt.
Mit Hilfe von IPTC können Textinformationen in Bildern hinterlegt werden. Gespeichert werden die Daten in dem so genannten Header einer Datei. Sprich sie werden nicht direkt im Bild angezeigt sondern dafür wird ein extra Programm, welches die Anzeige der Daten unterstützt, benötigt. Derzeit unterstützen nur die beiden Dateiformate JPEG, TIFF und das »Digital Negative«-Format DNG von Adobe das Hinterlegen von Textinformationen.
Entwickelt wurde der Standard von der »International Press Telecommunications Council« (kurz IPTC) in Zusammenarbeit mit der NAA (Newspaper Addociation of America. Durch IPTC können leicht Titel, Autor, Copyright-Hinweise und Stichwörter in der Bilddatei gespeichert werden. Wer seine Bilder nach diesem Standard ordentlich beschriftet, hat eine bessere Übersicht über seine Aufnahmen und findet sie schneller.
Einige Angaben die im IPTC-Standard vorgesehen sind (Quelle: Wikipedia):
- Caption (Beschreibung des Bildinhalts)
- Keywords (Stichwörter)
- Credit (Credit-Zeile, z.B. Name des Fotografen oder der Agentur)
- Copyright (Copyright-Vermerk)
- Object Name (Kurzbezeichnung des Fotos, kann Dateiname sein)
- Created Date (Aufnahmedatum)
- City (Aufnahmeort: Stadt)
- Province State (Bundesland, Kanton)
- Country (Staat)
- Special Instructions (Sonstige Hinweise)
- Byline (Autoren-/Fotografenangaben)
- Category (Kategorie nach NAARTNDA)
- Headline (Titel)
- Source (Quelle)

Da die Daten nicht direkt im Bild angezeigt und damit editiert werden können, wird ein spezielles Programm benötigt. Unter Windows unterstützen unter anderem Adobe Photoshop (Datei -> Informationen) bzw. Adobe Bridge und IrfanView die IPTC-Daten. Eine vollständigere Liste für Windows gibt es bei der Wikipedia.
Unter Mac OS X kann ich neben Photoshop vor allem das Programm GraphicConverter (Apfel + I) empfehlen. Mit diesem Programm können Daten auch in mehreren Bildern gleichzeitig hinterlegt werden.
Grundsätzlich sollte man so viele Informationen wie möglich in einem Bild speichern. Und noch ein Tipp: Am besten hinterlegt man die Textinformationen in den Original-Dateien und Veränderungen werden in einer anderen Datei gespeichert. Denn einige Grafikprogramme vergessen leider die eingegebenen Textinformationen.
Anwender von dem Betriebssystem Mac OS X 10.4 alias Tiger haben einen besonderen Vorteil wenn es um das Wiederauffinden von Fotos geht. Die Desktop-Suche »Spotlight« durchsucht nämlich in Fotos auch den IPTC-Header und nimmt gefundene Informationen in den Index auf. Anwender von Windows können zum Beispiel Cumulus oder ThumbsPlus für die Archivierung ihrer Bilder verwenden. Beide Programme greifen ebenfalls auf die IPTC-Daten zurück.
Dieses Beitrag wurde schon einmal in meinem alten Weblog iBlogging veröffentlicht.
Nov 02
In unserem schönen Mediengestalter-Klassen-Forum (Seite ist leider passwortgeschützt. Daher kein Link) hat jemand die Frage aufgeworfen, warum man nicht einfach eine Grafik auf die einzelnen Pixel aufsplittet und diese anschließend wieder in einer Tabelle zusammenbaut. Eine ganze Website würde man ja schließlich auch in einzelne Grafikelemente auseinander schneiden und im Editor quasi wieder zusammensetzen.
Wie wäre es wenn man die Grafiken in 1px große quadrate sliced, und dan statt dem Bild was geladen werden muss, von jedem Pixel den HEX, RGB oder sonstewas Farbwert nimmt und den dann als Hintergrundfarbe im jeweiligen pixel-feld der Tabelle angibt.
Das dies eine ungeheure große Menge an Code gibt im Gegensatz zu einer Grafik gibt, brauche ich wohl nicht zu erwähnen. Doch wie groß ist diese Unterschied genau? (Achtung jetzt folgt viel Theorie und Mathematik!)
In einer stink normalen RGB-Grafik werden die einzelnen Farben mittels drei Werten (Rot, Grün und Blau) angegeben. Also, beispielsweise: 255|255|255 für weiß. Danach kommt der nächste Pixel und so weiter.
Meine Beispielgrafik (ein zwinkerndes Smiley) hat eine Größe von 15×15 Pixel und besteht somit aus 225 unterschiedlichen Pixeln. Jeder Pixel wird dabei mit 24 Bit angegeben. Bei einem unterkomprimierten Bild kommen wir damit auf 5400 Bit. Umgerechnet sind dies ungefähr 0,66 KByte.
Würde ich jetzt diese Grafik rein in einer Tabelle darstellen wollen, hätte ich erst einmal folgenden “Grundcode” pro Pixel.
<td bgcolor="" height="1px" width="1px"></td>
Eine Bildzeile würde praktisch so aussehen:
<tr><br />
<td bgcolor="" height="1px" width="1px"></td><br />
<td bgcolor="" height="1px" width="1px"></td><br />
<td bgcolor="" height="1px" width="1px"></td><br />
<td bgcolor="" height="1px" width="1px"></td><br />
<td bgcolor="" height="1px" width="1px"></td><br />
<td bgcolor="" height="1px" width="1px"></td><br />
<td bgcolor="" height="1px" width="1px"></td><br />
<td bgcolor="" height="1px" width="1px"></td><br />
<td bgcolor="" height="1px" width="1px"></td><br />
<td bgcolor="" height="1px" width="1px"></td><br />
<td bgcolor="" height="1px" width="1px"></td><br />
<td bgcolor="" height="1px" width="1px"></td><br />
<td bgcolor="" height="1px" width="1px"></td><br />
<td bgcolor="" height="1px" width="1px"></td><br />
<td bgcolor="" height="1px" width="1px"></td><br />
</tr>
Da ich jetzt keine Lust habe, 255 Tabellenzellen anzulegen und mit dem passenden Farbwerten zu belegen, machen wir die Berechnung des Speicherplatzes einmal theoretisch.
Bei einer ASCII-Codierung benötigen wir pro Zeichen 7 Bit. Pro Pixel benötigen wir 50 Textzeichen was einen ungefähren Speicherplatzbedarf von 43,75 Byte pro Pixel ausmacht. Eine Bildzeile benötigt somit 656,25 Byte. Das wiederum x 15 Bildzeilen ergibt einen Speicherplatzverbrauch von 9843,75 Byte (9,61 KByte.)
Also statt 0,66 KByte für die Grafik benötigen wir 9,61 KByte für die Tabelle (sollte ich mich nicht verrechnet haben ;-)). Das ist ein Unterschied von sage und schreibe ca. 1456 Prozent. In Ladezeiten ausgedrückt, würde es wie folgt aussehen: Die Grafik benötigt bei einem 56K-Modem ca. 0 Sekunden und die “Tabellen-Grafik” braucht ca. 2 Sekunden.
Da die meisten Websites recht viele Grafiken einsetzen, würde dies noch eine deutlich höhere Codemenge ausmachen. Und selbe wenn, die Tabellenmethode vom Speicherplatz und den Ladezeiten geringer ausfallen würde, würde eine Zugänglichkeit bei einem solchen Tabellengerüst absolut nicht mehr gewährleistet sein.
Im Moment fällt mir nur ein Vorteil ein, der durch eine solche Darstellung entsteht: Eine Grafik lässt sich nicht mehr so einfach über “Speichern unter…” auf die eigene Festplatte kopieren. Die Erfindung des Screenshots macht diesen Vorteil aber gleich wieder wett.
Fazit: Es gibt also absolut keinen Grund eine Grafik als Tabelle darzustellen.
Aug 01
Die meisten ambitionierten Fotografen kennen das Problem der unscharfen und verwackelten Fotos. Ein Hauptgrund für verwackelte Fotos sind unzureichende Lichtverhältnisse während der Aufnahme. Dem Fotografen standen bisher verschiedene Möglichkeiten zur Verfügung, den Effekt zu verhindern. Oft haben die einzelnen Methoden jedoch auch wieder ihre Nachteile. Hier muss der Fotograf je nach Situation die Vor- und Nachteile gegeneinander abwegen.
Den ganzen Beitrag lesen »