Hello world! This is HTML5 Boilerplate. world! This is HTML5 Boilerplate. world! This is HTML5 Boilerplate. world! This is HTML5 Boilerplate. world! This is HTML5 Boilerplate. world! This is HTML5 Boilerplate. world! This is HTML5 Boilerplate. world! This is HTML5 Boilerplate. world! This is HTML5 Boilerplate. world! This is HTML5 Boilerplate. world! This is HTML5 Boilerplate. world! This is HTML5 Boilerplate. world! This is HTML5 Boilerplate. world! This is HTML5 Boilerplate. world! This is HTML5 Boilerplate. world! This is HTML5 Boilerplate. world! This is HTML5 Boilerplate. world! This is HTML5 Boilerplate. world! This is HTML5 Boilerplate. world! This is HTML5 Boilerplate. world! This is HTML5 Boilerplate. world! This is HTML5 Boilerplate. world! This is HTML5 Boilerplate. world! This is HTML5 Boilerplate. world! This is HTML5 Boilerplate. world! This is HTML5 Boilerplate. world! This is HTML5 Boilerplate. world! This is HTML5 Boilerplate. world! This is HTML5 Boilerplate. world! This is HTML5 Boilerplate. world! This is HTML5 Boilerplate. world! This is HTML5 Boilerplate. world! This is HTML5 Boilerplate. world! This is HTML5 Boilerplate. world! This is HTML5 Boilerplate.

Hello world! This is HTML5 Boilerplate.

Hello world! This is HTML5 Boilerplate.

Hello world! This is HTML5 Boilerplate.

  1. Eintrag
  2. Eintrag
  3. Eintrag
  4. Eintrag
  5. Eintrag
  6. Eintrag

Man sollte nicht den Eindruck erwecken, es sei wahnsinnig zeitaufwändig, zugängliche Webseiten zu erstellen. Nötig ist eigentlich vor allem ein einmaliger Lernaufwand, damit man weiß, wie es geht. Beispielsweise semantisch korrekte Auszeichnung: die Tags zur Auszeichnung einer Überschrift schreiben sich nicht langsamer als die für das Element strong. Man muss nur wissen, dass strong eben nicht für die Auszeichnung von Überschriften geeignet ist und wie es besser geht. Dasselbe gilt für die Verwendung von header, main, blockquote, usw statt div. Auch zusätzliche Angaben sind in aller Regel schnell gemacht. So soll die Hervorhebung von angetabbten Links mindestens so deutlich sein, wie die Hervorhebungen für Mausnutzer (:hover). In der Praxis bedeutet es, dass ich einen langen Selektor wie main #content article a:hover markiere, kopiere und ein zweites mal einfüge, hover durch focus ersetze und ein Komma einfüge. Ergebnis: main #content article a:focus, main #content article a:hover Dauer etwa 5-10 Sekunden. Das ist selbst bei aufwändig durchgestylten Webseiten, an denen man mehrere Tage entwickelt, selten mehr als zehn Mal nötig. Gesamtaufwand maximal also eineinhalb Minuten. Nutzt man Vorlagen wie HTML5-Boilerplate, hat man gleich jene ganze Reihe von Klassen inklusive, die auch die Entwicklung zugänglicherSeiten erleichtern, wie zum Beispiel visuallyhidden, um Texte nur für Screenreadernutzer bereit zu stellen (oder falls mal CSS nicht funktioniert). Mit einem durchdachten Workflow, klug gewählten Vorlagen und Werkzeugen und dem nötigen Wissen entsteht dafür kaum ein nennenswerter Mehraufwand. So ist es mit vielen Dingen. Berücksichtigt man gleich beim Design ausreichende Kontraste und gibt man für das Layout nicht pixelgenaue Breiten statt fluider Spalten vor (was in Zeiten des responsiven Designs ohnedies schwachsinnig ist), wie viel länger dauert das dann, wenn überhaupt? Zugegeben, der Testaufwand steigt. Aber in Zeiten responsiver Layouts ist auch das anteilmäßig nicht mehr so der große Brocken. Es ist deutlich aufwändiger in allen Browser- und (mobilen) OS-Kombinationen zu testen, als einen Test auf Zugänglichkeit zu machen (der sich größtenteils in die anderen Tests integrieren lässt). Viele Dinge, die für zugängliche Webseiten vorgeschrieben sind, sind ohnehin nach W3-Standard nötig, wie valides HTML, Verzicht auch veraltete Elemente und Attribute, alt-Texte, semantische Elemente statt div und so weiter. Aufwändig und teuer (und relativ nutzlos) sind dagegen Zusammenfassungen in Leichter Sprache und Deutscher Gebärdensprache. Entweder man “übersetzt” alle Inhalte (de facto wohl nicht zu leisten) oder man steht auch dazu und lässt es gleich ganz. Für mich sind diese Forderungen der BITV (die ohnehin nur für die wenigsten Sites, nämlich Portale verlangt werden) reine Alibi-Forderungen, um sagen zu können, dass man Gehörlose und Menschen mit kognitiven Einschränkungen auch ernst nimmt. Von daher kann ich auch ein Stück weit verstehen, dass die Vertreter der diversen Behindertenverbände behaupten, die BITV berücksichtige vor allem die Interessen von Fehlsichtigen und Blinden. Nichtsdestotrotz: viele wesentliche Verbesserungen sind schnell gemacht. Der zusätzliche Aufwand sollte (für die einmaligen technischen und gestalterischen Aspekte) 10% kaum überschreiten, selbst wenn es schon richtig gut gemacht wird. Wenn man dazu noch bedenkt, dass bei zwei bis fünf Jahren der Laufzeit einer Website der Dauerbetrieb deutlich mehr Ressourcen verbraucht, sieht man, wie gering der Zusatzaufwand während der gesamten Lebensdauer solch eines Projektes ist. Was ich aber nicht verschweigen möchte, Sind inhaltliche (nicht technische) Gesichtspunkte. Redakteure müssen einige Angaben machen, die für zugängliche Webseiten vorgeschrieben sind, die aber die Nutzbarkeit für jeden Leser erhöhen verbessern. Das sind beispielsweise saubere, tippfehlerfreie Texte, die nach den Regeln der entsprechenden Textgattung verfasst und sprachlich an die Zielgruppe angepasst sind: Zitate sollen als Zitate ausgezeichnet, Abkürzungen aufgelöst, fremdsprachige Texte übersetzt sein – alles für jeden Webseitenbesucher und -Betreiber ein Gewinn. Denn auf solche Webseiten kommt man gerne wieder. Das gilt auch für Tante Google, die man mit den Auflösungen von Abkürzungen oder Übersetzungen natürlich ebenfalls füttert und die Texte so bewertet, als wären sie gut geschrieben (wichtiges zuerst, später die Details und am Ende ein Fazit). Google ist sicher der häufigste wiederkehrende “blinde” Besucher der meisten Websites. Darum hat auch der Betreiber einer Seite etwas davon, wenn diese Kriterien der Zugänglichkeit berücksichtigt. Ganz zu schweigen davon, dass man potentiell mehr Besucher erreicht, wenn man Menschen mit Behinderungen nicht durch unüberwindbare Hürden vom Besuch der eigenen Site abhält. Und letztendlich macht es einen Auftraggeber oder Webseitenbetreiber sympathisch, wenn er Seiten für alle erstellt. So kann man soziale Kompetenz demonstrieren.

Dieser Beitrag wurde am 20. November 2013.

Texte aufklappen und verbergen mittels

und Hinterlasse eine Antwort

Gerade auf Smartphones ist Platz kostbar. Aber auch auf dem Desktop ist es mitunter sinnvoll, Inhalte nur bei Bedarf ainzublenden. HTML5 bringt mit den Elementen details und summary alles nötige mit. Beispiele mit etwas Text

Mittels details und summary kann man es dem Besucher einer Webseite die Entscheidung überlassen, Texte anzuzeigen oder zu verbergen.

Leider unterstützen derzeit weder Firefox noch InternetExplorer diese Elemente (details auf caniuse). Glücklicherweise hat ein freundlicher Belgier namens Matthias Bynens hingesetzt und ein Polyfill geschrieben, dass bei fehlender Unterstützung die korrekte Verhaltensweise emuliert. Dies stellt er als jQuery-Plugin zur Verfügung: http://mathiasbynens.be/demo/html5-details-jquery

Dieser Beitrag wurde am 10. Juni 2013.

RWD und Retina Displays: Bilder mit hoher Qualität auf Kilobyte-Diät

Ich mag PNG. Aber seit ich mich mit responsivem Webdesign auseinandersetze, greife ich doch immer häufiger auf JPEG zurück. Natürlich kann man für alles JavaScript einsetzen. Auch um auf kleinen Bildschirmen kleine Bilder auzuliefern und große Bilder auf großen Bildschirmen. Weil ich möchte, dass möglichst viel ohne JavaScript läuft, habe ich aber immer öfter mit den Kompressionsraten an großen Bildern heumgespielt und festgestellt, dass häufig erstaunlich kleine (leichte) Dateien dabei herauskommen, JPEG sei dank.

Metropolen an Flüssen
Stadt Land Fluss
Köln NRW Rhein
München Bayern Isar
© 2014