accessBlog

News mit dem Tag »Design«

14 Sep 2011

Wir haben uns wieder mal die Mühe gemacht, eine ganze Reihe neuer Konferenzen und Workshops auf der Übersichtsseite bei einfach-fuer-alle.de/events einzutragen (›Mühe‹ deshalb, weil die manuelle Einpflege von Microformats nun wirklich keinen Spaß macht, aber dafür können Sie dann alle Einträge als Kalenderdatei für Outlook oder iCal herunterladen). Falls Sie also im Herbst noch nichts vorhaben – dort finden Sie sicher eine ganze Reihe interessanter Veranstaltungen im deutschsprachigen Raum, aber auch im angrenzenden Ausland.

Besonders interessant erscheinen uns die ›beyond tellerrand‹-Konferenz am 20. – 22. November in Düsseldorf, die Fronteers-Konferenz am 06. – 07. Oktober in Amsterdam sowie der Accessibility Summit, der als reine Online-Konferenz konzipiert und durchgeführt wird. Auf der Fronteers gibt es die einmalige Chance, von internationalen Accessibility-Experten wie z.B. Derek Featherstone in einem Workshop zu lernen – Teilnehmer nehmen automatisch an der Verlosung von zwei Tickets für den Accessibility Summit teil.

Wenn Sie eine Veranstaltung zum Thema Webdesign im Allgemeinen oder Barrierefreies Internet im Speziellen kennen, die dort noch nicht aufgelistet ist, würden wir uns wie üblich über eine kurze Nachricht per Kommentar oder über das Kontaktformular freuen.

14 Jul 2011

Vor allem bei großen Webprojekten und bei der Entwicklung komplexer Programme werden häufig sogenannte Personas eingesetzt. Personas sind idealtypisch entworfene Personen mit realistischer Biographie, denen bestimmte technische Fähigkeiten und Vorgehensweisen am Computer zugeschrieben werden. Jede Nutzergruppe hat besondere Erwartungen daran, wie eine Website gestaltet sein und wie sie funktionieren sollte und diese Erwartungen sollten sich in den Personas widerspiegeln.

Zusammen mit Personas werden Szenarien eingesetzt. Szenarien definieren typische Aktionen auf der Website: der Kauf eines Produktes auf einer Shopping-Seite, eine Überweisung im Online-Banking und so weiter. Eine Persona bildet zusammen mit einem Szenario die Möglichkeit, spezifische Anforderungen an die Website zu definieren, die schon im Entwurfsprozess berücksichtigt werden können.

Weiterlesen …

Personas mit Behinderung

Dieser Beitrag erschien ursprünglich im Weblog von Domingos de Oliveira und wurde für ›Einfach für Alle‹ überarbeitet.

Weiterführendes

Auch Personas mit unterschiedlichen Behinderungen lassen sich in die Planung einer Website oder Anwendung einbauen. Dabei ist wichtig, dass Hilfstechnologien und behindertenspezifische Anforderungen bei diesen Personas untergebracht werden. Idealerweise sind folgende Gruppen bei den Personas vertreten:

  • Blinde mit Screenreader und Braillezeile
  • Sehbehinderte mit Vergrößerungssoftware
  • Menschen mit motorischen Einschränkungen – Eye-Tracking oder Sprachsteuerung
  • Gehörlose und schwerhörige Menschen
  • Menschen mit Lernbehinderungen

Gehörlose und Menschen mit Lernbehinderungen benutzen normalerweise keine Hilfstechnik, dennoch haben sie besondere Anforderungen wie Texte in Leichter Sprache oder Gebärdenvideos. Bei dem Entwurf sehbehinderter Personas sollten zudem Farbfehlsichtigkeiten berücksichtigt werden.

Im Grunde müssen diese Personas nur einmal entworfen werden und das ist die meiste Arbeit. Schließlich müssen neben den Biographien auch die typischen Handlungsweisen auf Websites ermittelt werden, die durch die Behinderung und die Hilfsmittel bestimmt sind. Sind die Personas einmal erstellt, spricht nichts dagegen, sie projektübergreifend einzusetzen und gegebenenfalls anzupassen.

Sind die Personas mit ihren typischen Eigenschaften und Handlungsweisen entworfen, müssen projektbasierte Szenarien entwickelt werden. Eine Online-Banking-Anwendung erfordert andere Vorgehensweisen als eine Shopping-Plattform. Erst in Kombination mit projektspezifischen Szenarien sind Personas wirklich sinnvoll.

Beispiel: Verhaltensmuster im Shopping

Eine typische Shopping-Anwendung bietet unterschiedliche Vorgehensweisen. Viele Leute werden sich erst einmal die Sonderangebote auf der Startseite anschauen. Die nächste Gruppe sucht ein bestimmtes Produkt und benutzt dafür die vorhandenen Kategorien, um sich durch die Produktgruppen zu bewegen. Andere wiederum suchen nach einem bestimmten Produkt direkt über die Shop-Suchmaschine.

Auch beim Bezahlen gibt es ganz unterschiedliche Vorgehensweisen. Blinde werden vielleicht versuchen, sich alle Formularelemente einer Seite anzeigen zu lassen. Sie suchen nach den typischen Eingabefeldern für die Versandadresse oder nach einer Log-In-Möglichkeit. Menschen mit anderen Behinderungen suchen vielleicht eher nach bestimmten Symbolen wie Einkaufskörben oder Registrierkassen, wie sie von Shopping-Sites allgemein bekannt sind. Blinde suchen nach der Maske, wo sie ihre Adresse oder ihre Kontodaten eingeben können, während andere Gruppen vielleicht nach den typischen Kreditkarten-Symbolen Ausschau halten. So kann man den kompletten Prozess von der Auswahl der Waren bis zum Abschluss des Einkaufs für unterschiedliche Zielgruppen und Verhaltensmuster durchdeklinieren und optimieren.

Im Rahmen von Personas können auch Gründe erfasst werden, die zum Abbruch eines Kaufprozesses führen. Die einen bezahlen vielleicht lieber per Abbuchung, die anderen wollen das Geld überweisen und wiederum andere nehmen einen Payment-Dienstleister in Anspruch. Viele werden den Bestellprozess abbrechen, wenn sie die Versandbedingungen, Allgemeinen Geschäftsbedingungen oder Richtlinien zum Datenschutz nicht dort finden, wo sie diese erwarten. Gehörlose werden häufig den Einkauf abbrechen, wenn es neben einer Telefonnummer keine funktionierende Kontaktmöglichkeit per Fax oder E-Mail gibt. Blinde werden ihre Bankverbindung nicht eingeben, wenn sie nicht feststellen können, ob die Daten sicher übertragen werden.

Daneben können auch rein technische Gründe zum Abbruch des Einkaufs führen. Dazu gehören etwa die schlechte Platzierung oder Benennung von Bedienelementen oder eine mangelhafte Tastaturbedienbarkeit.

Vorteile von Personas

Ein Vorteil von Personas besteht darin, dass viele typische Probleme durch sie anschaulicher werden. Es macht emotional einen Unterschied, ob man sagt, Hans kann nicht mit CAPTCHAs umgehen, weil er blind ist als wenn man sagt, Blinde können nicht mit CAPTCHAs umgehen. Das Problem wird sehr viel greifbarer, weil man einen Namen und einen Menschen mit nachvollziehbaren Problemen vor sich hat statt einer anonymen Gruppe. Wenn über den Entwurf einer Website diskutiert wird, können die Entwickler einfach die Frage stellen: »Würde Hans damit zurecht kommen?«. Ein Problem wird wesentlich anschaulicher, wenn man es an einer konkreten Person mit einem Namen und einer Biographie festmachen kann. Es ist leichter, sich in die Rolle einer Person zu versetzen als in die Rolle einer Gruppe.

Ein weiterer Vorteil besteht darin, dass die Anforderungen der Nutzer schon sehr früh im Entwurfsprozess erfasst und berücksichtigt werden können. Eine Anwendung nachträglich barrierefrei zu machen ist sehr viel teurer und aufwendiger, als die Anforderungen von vorneherein umzusetzen.

Vorteil gegenüber Nutzertests

Personas werden vor allem bei der Definition von Anforderungen und im Entwurfsprozess verwendet. Viele Probleme, die ansonsten erst bei Nutzertests herauskommen würden, dürften so schon im Entwurfsprozess gelöst werden. Personas sind aber kein Ersatz für Tests mit echten Nutzern.

14 Jun 2011

Eintippen, Knopf drücken, fertig: Diskussionen in Foren und Kommentare in Blogs, soziale Interaktion in Communities, das Hochladen eigener Inhalte in Videoportalen, Jobangebote und -gesuche in Stellenbörsen, Fahrplanauskünfte und Tickets bei der Bahn oder Bestellungen und Bezahlung in Online-Shops, ja sogar das Einstellen von Inhalten in Redaktionssystemen und Weblogs – all das funktioniert nur mit Formularen. In Zeiten des Mitmach-Webs werden Formulare immer wichtiger. Formulare sind die technische Basis interaktiver Angebote und die Grundlage der Kommunikation zwischen Anbietern und Nutzern einer Webseite.

Weiterlesen …

Gerade bei Formularen gelten die POUR-Prinzipien der WCAG 2.0 in Reinform: Formulare müssen wahrnehmbar (im Englischen: perceivable), bedienbar (engl. operable), verständlich (understandable) und robust (robust) sein. In den Richtlinien finden sich nur wenige direkte Vorgaben zu Formularen, aber fast alle Punkte der WCAG sind anwendbar – von HTML über CSS und WAI-ARIA bis zu JavaScript und der serverseitigen Verarbeitung der eingegebenen Daten. Obwohl HTML seit Jahren viele Elemente für barrierefreie und damit bedienerfreundliche Formulare enthält, setzen Webdesigner sie zu wenig ein.

Die technischen Grundfunktionen eines Formulars – erfassen, ausfüllen und abschicken – müssen mit allen möglichen Mitteln der Ein- und Ausgabe gelingen. Konkret heisst das, Anbieter von Webseiten müssen assistierende Techniken wie z.B. Screenreader, Sprachsteuerung oder Spezialtastaturen berücksichtigen. Für öffentliche Anbieter, die den Vorgaben der Barrierefreie Informationstechnik-Verordnung (BITV) unterliegen, ist der Einsatz dieser Mittel klar geregelt: die Verordnung verlangt die Verwendung der korrekten HTML-Elemente und den Einsatz von CSS für die Gestaltung, das gilt auch für Formulare. Alle anderen Anbieter profitieren ebenfalls von einer einfachen und barrierefreien Nutzbarkeit ihrer Formulare.

Die Konzeption der Formulare oder der Anwendung steht vor der technischen Umsetzung. Der Webentwickler Timo Wirth hat die Perspektive der Nutzer in einer Präsentation einmal so formuliert: »Ein Formular ist kein Datenbankprozess, es ist der Anfang eines Gesprächs«. Damit ein gelungener Dialog entsteht, gibt diese Serie Hinweise zur barrierefreien Umsetzung von Formularen.

Die Serie ist in fünf Teile gegliedert:
Im ersten Teil »Toleranz und Rücksicht« geht es um Grundlagen und Konzeption von Formularen. Der zweite Teil – »Formulardesign: der wichtige erste Eindruck« – dreht sich um die Gestaltung, Nutzerführung und Usability. Das technische Grundgerüst und damit die Markup-Grundlage von Formularen und das Layout per CSS ist Inhalt des dritten Teils »HTML & CSS für Formulare«.

Neben den für die Struktur benötigten HTML-Elementen und CSS für die Gestaltung kommt in vielen Formularen JavaScript für das Verhalten zum Einsatz. In Teil 4 geht es um »Dynamik in Formularen – JavaScript & AJAX«.

Im letzten Teil zeigen wir, wie Sie eine erste Qualitätssicherung vornehmen können und geben Tipps für Tests mit echten Nutzern: »Testen von Formularen und web-basierten Anwendungen«.

27 Sep 2010

Die neu erschienene Broschüre »Barrierefreiheit - Universelles Design« erläutert, wie Usability Professionals die Barrierefreiheit in ihren Designs berücksichtigen können, indem sie den Gestaltungsprinzipien des Universellen Designs folgen.

Barrierefreiheit – Universelles Design

Die Broschüre zeigt unter dem Motto ›Gut für Alle‹, dass sich Barrierefreiheit lohnt. Außerdem enthalten sind zahlreiche Beispiele und praktische Tipps ebenso wie eine Zusammenfassung der aktuellen Richtlinien und weiterführende Literatur.

Sie wurde von Mitgliedern und Experten des Arbeitskreises Barrierefreiheit der Usability Professionals' Association (UPA) erstellt. Der Verband ist ein Netzwerk von und für Usability-Experten, die sich der Wissensvermittlung und Meinungsbildung rund um das Thema Usability und User Experience verpflichtet fühlen.

Die Mitglieder des Arbeitskreis Barrierefreiheit vertreten innerhalb der UPA die Schnittstelle zwischen Usability und Barrierefreiheit. Neben der Öffentlichkeitsarbeit findet ein reger Wissens- und Erfahrungsaustausch statt. Neue Mitglieder sind jederzeit willkommen; nähere Informationen finden Sie auf der Webseite der German UPA.

[Update 28.10.10: Die Broschüre »Barrierefreiheit - Universelles Design« ist nun auch als barrierefreies PDF (684 kB) erhältlich.]

12 Nov 2009

An der Bauhaus-Universität Weimar beginnen heute Beratungen einer nationalen Expertenkonferenz über die Entwicklung von einfachen, verständlichen und international wettbewerbsfähigen Produkten. Es geht um das Design der Zukunft.

Industrieunternehmen, Dienstleister, Designer und Politiker haben das Problem erkannt und fordern ein Design für alle, ein ›universal design‹. Dabei ist es nicht so, dass auf diesem Feld bisher überhaupt nichts geschehen würde: Türen, die sich wie von Geisterhand öffnen, Busse, die sich dem einsteigenden Fahrgast entgegen neigen – praktisch für jedermann, für den Bücher beladenen Studenten ebenso wie für die 70-jährige Rentnerin, die junge Mutter mit Kinderwagen oder den Rollstuhlfahrer.

Eine stark alternde Gesellschaft braucht leicht bedienbare und verständliche Produkte und Dienstleistungen. An den beiden Konferenztagen kommen Vertreter des universal design zusammen, um Strategien zu finden, wie Politik und Öffentlichkeit für das Thema sensibilisiert werden können.

»Deutschland hat eine lange Tradition in der Entwicklung demographiefester Produkte, Architekturen und Dienstleistungen«, unterstreicht Wolfgang Sattler, Professor für Produkt-Design an der Bauhaus-Universität Weimar. Dabei bezieht er sich unter anderem auf die Bauhaus-Bewegung, die bereits vor 90 Jahren Universalität von Architektur und Design forderte. »Diese Potentiale in wirtschaftlich sinnvolle und ergebnisorientierte Strategien umzusetzen, ist uns aber bisher noch nicht ausreichend gelungen«, so Sattler.

Am Samstag öffnet sich die Konferenz mit einer Veranstaltung für das Publikum. In Gesprächsrunden kann sich dann jeder in das Thema einbringen, der das möchte. Wer mehr darüber erfahren möchte, findet das Programm dieses Tages auf der Internetseite der Bauhaus-Universität.
(bei kobinet abgeschrieben)

24 Jul 2009

Die CSS-Arbeitsgruppe des W3C hat eine ganze Reihe neuer Entwürfe für Module der kommenden CSS 3-Spezifikation vorgestellt. Ganz frisch am Start sind Flexible Box Layout Module und CSS Image Values Module, beide vom 23. Juli und beide erscheinen uns beim ersten Drüberlesen sehr sinnvoll zu sein. Besonders flexbox hat es uns angetan, weil es mit sehr einfachen Regeln ermöglicht, eine Menge HTML- und CSS-Hacks zu ersparen:

»In this new box model, the children of a box are laid out either horizontally or vertically, and unused space can be assigned to a particular child or distributed among the children by assignment of ›flex‹ to the children that should expand. Nesting of these boxes (horizontal inside vertical, or vertical inside horizontal) can be used to build layouts in two dimensions.«

Bereits beim Status eines Last Call angelangt ist Ende letzten Monats der Entwurf des CSS 3-Moduls Multi-column layout, das, wie der Name schon sagt, wirklich echte mehrspaltige Layouts ermöglicht. Hier bittet die Arbeitsgruppe um Kommentare bis zum 01. Oktober diesen Jahres.

Wir hatten neulich schon mal etwas mit Multi-column layout herumgespielt und siehe da: es funktioniert sogar in modernen Browsern wie Safari 4, Google Chrome 2 oder Firefox 3.5 3.0. Zum selber ausprobieren: die Liste im Kasten »mehr zum wettbewerb:« ganz unten auf einfach-fuer-alle.de/biene-2009 basiert auf einer simplen Mehrspalten-Anordnung mit reinem CSS ohne jegliche Eingriffe ins HTML.

Weiterlesen …

Einige weitere Entwürfe aus der letzten Zeit:

Die letzten vier basieren allesamt auf Vorschlägen von Apple und funktionieren teilweise schon in aktuellen Versionen der Webkit-Engine, sind aber sicher noch nicht für den Produktiveinsatz geeignet. Und sie sind auch nicht ganz unumstritten: OK, dass von Flash-Hersteller Adobe Einwände gegen zu viel Animationen in CSS kommen mussten war vorhersehbar, aber die Frage bleibt doch, wo die Präsentations-Ebene aufhört und wo die Ebene des Verhaltens von Elementen anfängt und ob man da nicht etwas vermischt, was besser getrennt bleiben sollte.

Andererseits gibt es neben fundamentalen Fehlern noch eine Menge Löcher in den CSS-Spezifikationen aller Versionsnummern, die es zu stopfen gilt. Eine ganze Reihe von Wünschen aus der Community hatten sich schon im vergangenen Jahr aus dem WaSP Community CSS3 Feedback 2008 ergeben, wie zum Beispiel die Möglichkeit, Selektoren zu gruppieren (hier die Erklärung bei Eric Meyer) oder ein wirkliches Layout-System, dass diesen Namen auch verdient.

Und das eigentliche Problem – dass sich die CSS-Arbeitsgruppe mit geradezu Gletscher-artiger Geschwindigkeit zu bewegen scheint – ist damit auch noch nicht behoben. Zum Vergleich hier eine Liste der aktuellen CSS 3-Module mit ihrem letzten Aktualisierungs-Datum: CSS3 Module Status bei CSS3.Info – da sind schon ein paar Dinge drin, die Web-Entwickler dringend bräuchten, die aber teilweise seit 2002 (!) niemand mehr angefasst hat.

Was geht?

Gut dass zumindest ein Teil der Browser-Hersteller da etwas schneller ist und Teile der Spezifikation schon fleißig implementiert. Wenn man sich von dem Mantra verabschiedet, dass Webseiten in allen Browsern 100%ig gleich aussehen müssen (müssen sie das?), dann kann man schon vieles davon verwenden, wie die folgenden Tutorials zeigen (teilweise schon was älter, aber immer noch gut):

Wenn das noch nicht reicht: hier ist eine der zurzeit ach so beliebten Top-irgendwas-Listen: »CSS3 Exciting Functions and Features: 30+ Useful Tutorials«

23 Mär 2009

Das World Wide Web Consortium (W3C) bittet um Meinungen zur neuen Website, die Ende letzter Woche als Beta-Version online gegangen ist. Das neue Site-Design ist nun weitestgehend harmonisiert, die Informationsarchitektur wurde vereinfacht, die sog. ›Technical Reports‹ (vulgo: Web-Standards) haben ein neues Aussehen; dazu gibt es neue Inhalte wie einen Kalender und aggregierte Blogs der W3C-Mitarbeiter.

Weitere Informationen zum Redesign sieht und hört man in einem 10-minütigen Screencast sowie als ausführlichen Text auf der Seite About the W3C Site Redesign, wo die Ziele, Features, Einschränkungen und die zukünftige Weiterentwicklung beschrieben werden. Falls jemand Vorschläge zur Verbesserung hat oder Fehler findet kann man diese an site-comments@w3.org schicken.

Die Mozilla Foundation sitzt ebenfalls an einem öffentlichen Relaunch der Seiten für ihre Open-Source-Anwendungen unter www.mozilla.org. Strategische Überlegungen dazu findet man im MozillaWiki unter »Mozilla.org: Big Picture«, ebenso das Design-Briefing: »Mozilla.org/Redesign/Communication Brief« und Infos zu den verschiedenen Designs bei der beauftragten Agentur: »The Mozilla.org Redesign: Round 1«.

Hier drei Entwürfe zur Auswahl:

19 Dez 2008

Wie bei den vorangegangenen Überarbeitungen dieser Seiten in den Jahren 2001, 2003, 2004 und 2006 gab es auch diesmal wieder heftige Kritik aus vielen Richtungen. Sofern diese Kritik sachlich bleibt, stellen wir uns ihr gerne – sehr gerne sogar. Auch wir lernen täglich dazu, sonst sähen diese Seiten immer noch so aus wie früher.

Ein Teil der Kritik bezog sich auf die (vermeintliche) Nicht-Validität dieser Seiten – hierzu gab es bereits eine Folge unseres Laborberichts und wir hoffen, dass damit alle Missverständnisse ausgeräumt sind. Ein anderer Aspekt, an dem sich viele Kommentare hier und in anderen Blogs gerieben haben, sind die vermeintlich zu schwachen Kontraste in der Gestaltung dieser Seiten, und um die dreht es sich in der heutigen Folge.

Weiterlesen …

Ein Plädoyer: Kontraste mit Köpfchen

Die am 11. Dezember 2008 veröffentlichten Web Content Accessibility Guidelines (WCAG 2.0, wir berichteten) setzen Mindest-Kontraste für unterschiedliche Arten von Inhalten (Text, Text in Bildern etc.) fest. Diese sind je nach WCAG-Level unterschiedlich strikt: für Level AA braucht man einen Kontrast zwischen Vorder- und Hintergrundfarbe von 4,5 zu 1; für Level AAA schon 7 zu 1. Dabei gibt es allerdings noch Abstufungen – so reicht für Level AA bei großem und / oder fettem Text auch 3 zu 1, für Level AAA auch 4,5 zu 1 (dass es keine Obergrenze für Kontraste gibt, hatten wir bereits an anderer Stelle bemängelt, dies hat aber nichts mit dem heutigen Thema zu tun).

Allerdings sind dies nicht die einzigen Ausnahmen, sondern es werden noch weitere Beispiele genannt, bei denen diese Anforderungen nicht anwendbar sind:

  • Incidental: Text or images of text that are part of an inactive user interface component, that are pure decoration, that are not visible to anyone, or that are part of a picture that contains significant other visual content, have no contrast requirement.
  • Logotypes: Text that is part of a logo or brand name has no minimum contrast requirement.

Der zweite Punkt ist eindeutig: für Text, der Teil eines Logos oder Markennamen ist, gibt es keine Minimal-Anforderungen für Kontraste. Dies trifft auf den gesamten Kopfbereich dieser Seiten zu, in dem der Name, der Claim und das Logo der Initiative ›Einfach für Alle‹ zu finden ist.

Der erste Punkt hingegen lässt, oberflächlich betrachtet, einigen Spielraum für Interpretationen zu: Was ist »pure decoration«? Nehmen wir als Beispiel unsere Seite mit der Inhaltsübersicht: in dieser findet sich eine Überschrift »Artikel« in weiss auf hellblauem Hintergrund. Wenn man nun ein Prüfwerkzeug stur nach Schema F anwendet, erhält man einen Fehlerbericht, in dem dies bemängelt wird. Nur – ist dies wirklich ein Fehler? Ist dies wirklich eine unüberwindbare Barriere?

Größere Ansicht: Screenshot des Inhaltsverzeichnisses im Test mit Colour Contrast Analyser 2.2

Der Nutzer erreicht diese Seite ausschließlich über Links, die eindeutig das Wort »Artikel« oder »Inhaltsverzeichnis« enthalten. Diese Links sind bei Maus- und Tastaturbedienung schwarz oder dunkeldunkelgrau auf weiss, haben aber bereits in ihrem Urzustand ohne Interaktion ausreichende Kontraste. Auf der Seite selbst findet sich dann (den Browser-Chrome mitgerechnet) sechsmal das Wort »Artikel« in ausreichenden Kontrasten (im verlinkten Screenshot mit einer durchgehenden grünen Linie gekennzeichnet) und genau einmal mit nicht ausreichenden Kontrasten (im Screenshot mit einer gestrichelten roten Linie gekennzeichnet).

Ein grundsätzliches Problem bei der Forderung nach maximalen Kontrasten für Alles und Jedes: Wenn alles hervorgehoben ist, dann ist nichts hervorgehoben und man kann es auch gleich sein lassen und unformatierte Seiten ins Netz stellen. Abstufungen im Kontrast sind also bewusste Design-Entscheidungen, um den Fokus auf Elemente zu lenken oder fernzuhalten und genau dafür setzen wir diese Abstufungen ein.

Ja, aber …

Diese ›Ausrede‹ zieht natürlich nur, wenn die wesentlichen und relevanten Inhalte der Seite über ausreichende Kontraste verfügen, und genau darauf haben wir beim letzten Relaunch geachtet. Die WCAG 2.0 begründet den für Level AA geforderten Wert von 4,5:1 mit der wissenschaftlich nachgewiesenen Fähigkeit von ca. 80-jährigen Nutzern, bestimmte Kontraste noch zu differenzieren. Der Text, den Sie gerade lesen (der wesentliche Bestandteil dieser Seite), verfügt über einen Kontrast zwischen Vorder- und Hintergrundfarbe von 14,0:1 (#222 auf #f3f1e1) – damit sollten wir wohl auf der sicheren Seite sein.

Aber das schützt nicht vor weiteren Tests: So wie Toningenieure beim Abmischen einer Symphonie Autoradios berücksichtigen, so sollte man ein Design nicht nur auf nagelneuen LED-Monitoren bewerten, sondern zusätzlich noch auf einer 10 Jahre alten 17"-Röhre. Einen gewissen Einfluss auf die wahrgenommenen Kontraste hat auch die Frage, ob der Nutzer mit oder ohne Schriftglättung unterwegs ist, daher gehört das Abschalten derselben zu einem vollständigen Test.

Mehr zum Thema:

03 Dez 2008

Widgets ade

Fast täglich erreichen uns in der EfA-Redaktion Mails mit der Frage nach dem Verbleib des EfA-Fontsize-Skriptes, das den letzten Relaunch nicht überlebt hat. Die kurze Antwort: es war weg, ist weg und wird auch weg bleiben. Die lange Version der Antwort wollen wir unseren Lesern aber auch nicht vorenthalten:

Eine fiktive aber durchaus realistische Diskussion zwischen einem Frontend-Entwickler (im folgenden F. genannt) und einem Projektmanager (im folgenden P. genannt; eventuelle Ähnlichkeiten mit tatsächlichen Personen sind rein zufällig und unbeabsichtigt).

Projektmanager (P.): »Die Website muss ganz dringend barrierefrei sein. Deswegen brauchen wir da noch unbedingt so ein Ding, womit man die Schriftgröße ändern kann.«

Entwickler (F.): »Aber warum? Wir haben doch ganz andere Probleme mit der Website!«

P.: »Egal, wir brauchen so ein Ding, damit endlich diese Mails und Anrufe aufhören, wo sich Besucher über die Unzugänglichkeit der Website beschweren.«

F.: »Das wäre aber doch nur an den Symptomen rumgedoktert und würde nicht die Ursachen kurieren. Und ausserdem kann das doch jeder Browser…«

P.: »Aber unsere Statistiken sagen, dass immer noch 20% aller Besucher den IE6 benutzen. Und ich habe gehört dass der keine Schriften vergrößern kann.«

F.: »Kann er wohl…«

P.: »Egal, der Kunde will das so und basta…«

An dieser Stelle endet unsere Aufzeichnung des Gesprächs, weil F. mit dem Kopf auf die Tischplatte aufgeschlagen ist.

Weiterlesen …

Der Häufigkeit nach zu urteilen, mit der man diese »Widgets« zur Schriftskalierung oder Kontrastverstärkung auf Web-Seiten findet, muss es solche Gespräche in der ein oder anderen Form wohl häufig gegeben haben.

Zugegeben, wir sind daran nicht ganz unschuldig, denn viele davon basieren auf einem Skript, dass wir in den Anfangstagen von ›Einfach für Alle‹ veröffentlicht und auf diesen Seiten eingesetzt haben. Nun ist es aber weg und unsere Redaktion erreichen fast täglich Mails und Anrufe, wo denn das Skript geblieben sei. Es ist weg, und es wird auch nicht wiederkommen.

Warum war das Skript früher mal gut und jetzt auf einmal nicht mehr?

Machen wir einen kleinen Ausflug in die Zeit, in der das Skript entstanden ist. Damals, d.h. so um die Jahrtausendwende, waren Web-Standards nur eine nette Idee, die sich aber in den Browsern der vierten Generation nur von Spezialisten in mühsamer Handarbeit umsetzen liessen (und auch das nur höchst lückenhaft). Modernere Browser wie Firefox, Opera, Safari & Co. waren teils noch gar nicht auf dem Markt oder ausgesprochene Exoten; Microsoft hatte gerade die Weiterentwicklung des marktführenden IE 6 effektiv eingestellt. Ein »Page Zoom« war noch nicht erfunden, und damalige CSS-Layouts waren noch relativ instabil und gingen bei der kleinsten Änderung kaputt.

Menüeintrag im IE6 zur Schriftskalierung Dazu kam, dass (ausser dem IE/Mac) kein Browser in der Werkseinstellung über Knöpfe verfügte, mit denen Benutzer die Schriftgröße mit einem Klick verändern konnte. In den meisten Browsern waren die entsprechenden Optionen sehr gut vor dem Nutzer versteckt – so gut versteckt dass sich der Mythos festsetzen konnte, der IE könne keine in px bemaßten Schriften skalieren. Und damals wie heute galt, dass man es bei der Wahl der Schriftgröße nicht immer allen Recht machen kann: Für manche Nutzer ist die gewählte Schrift zu klein, für manche zu groß. Wie Sie sehen hatte das Skript also zur damaligen Zeit durchaus seine Berechtigung.

Allerdings bieten mittlerweile sämtliche aktuellen Browser die Möglichkeit, Seiten komplett zu skalieren, d.h. das gesamte Layout zoomt und bleibt intakt (und der kommende IE 8 korrigiert hierbei einige Fehler der Vorgängerversion und zieht so mit Firefox, Opera, Safari & Co. gleich). Mittlerweile sind moderne Browser wie der Firefox 3 sogar in der Lage, sich die vom Nutzer eingestellten Schriftgrade für jede Website einzeln zu merken. Zudem lässt sich in vielen Browsern eine Mindestschriftgröße angeben, die vom Ersteller der Seiten durch nichts überschreiben werden kann.

Solange Microsoft den Vista-Nachfolger nicht wieder mit dem IE 6 oder IE 7 ausliefert, wird die Zahl der Nutzer der problematischen Browser weiterhin stetig abnehmen; die Zahl der Nutzer mit moderneren Browsern nimmt jedoch täglich zu (relativ und absolut) – warum also Ressourcen für ein vermeintliches Problem aufwenden, wenn sich das Problem mittelfristig in Luft auflöst?

Ähnlich sieht dies übrigens auch das W3C, dass in den User Agent Accessibility Guidelines (UAAG 1.0 Checkpoint 4.1) die Verantwortung für solche Funktionalitäten eindeutig den Browser-Herstellern zuschiebt. Von den Erstellern einer Seite kann man lediglich verlangen, dass der Web-Inhalt weiterhin benutzbar bleibt, wenn der Nutzer eine entsprechende Funktion betätigt – mehr nicht.

Traditionelle Textskalierung ist damit also eindeutig ein Ding der Vergangenheit.

Ok, aber was ist mit den Nutzern?

Ganz einfach:

  • Bei blinden Nutzern ist der gewählte Schriftgrad egal. Per gesetzlicher Definition verfügt ein blinder Nutzer höchstens über einen Sehrest, der nicht wirklich nutzbar ist. Die Frage nach der richtigen Größe für Schrift stellt sich hier also erst garnicht.
  • Bei stark sehbehinderten Nutzern kann man in der Regel davon ausgehen, dass der Computer an die individuellen Bedürfnisse angepasst ist und Hilfsmittel benutzt werden, mit denen diese Diskussion ebenso irrelevant wird.
  • Dann wäre da die große Grauzone von Nutzern, die zwar die ein oder andere Form der Behinderung haben, jedoch (noch) keine speziellen Hilfsmittel benutzen. Dies sind nicht nur leicht sehbehinderte Nutzer, sondern auch Menschen mit Lernbehinderungen oder anderen kognitiven Behinderungen, die unter Umständen von größerer Schrift profitieren würden. Aber auch bei dieser Gruppe stellt sich die Frage, ob solch ein Schriftskalierungs-Widget irgendwem wirklich nachhaltig hilft – und das nicht nur weil es letztendlich nur eine Funktionalität dupliziert, die der verwendete Browser bereits von sich aus anbietet. Diese Benutzer werden immer und immer wieder auf das gleiche Problem stoßen und über kurz oder lang mehr Zeit mit der Nachjustierung von Schrift verbringen als mit der Aufnahme von Informationen.
  • Bleibt noch die den unerfahrenen Nutzern nachgesagte Angst vor dem Computer und davor »etwas kaputtzumachen«. Nutzer, die oftmals nicht wissen welchen Browser sie benutzen, geschweige denn was ein Browser ist. Ob ausgerechnet diese Nutzer auf (fremden) Webseiten auf einmal alle möglichen Knöpfe drücken, wenn sie schon Angst haben auf Ihrem (eigenen) Computer irgendwelche Knöpfe zu betätigen? Daran wird man wohl zweifeln dürfen. Sind dies die Nutzer, die einen 20"-Monitor auf 800×600 stellen weil dann die Schrift so schön groß ist? Und was ist wenn die Sehkraft weiter nachlässt? Stellen die Nutzer den Monitor dann auf 640×480? Wenn die Nutzer Probleme mit zu kleinen Schriften haben – wie sind sie dann auf die Seiten gekommen? Wie kommen sie mit dem Rest des Computers zurecht?

Sie sehen: solche Widgets lösen das Problem nur temporär, denn spätestens auf der nächsten Web-Seite steht der Benutzer wieder vor dem selben Problem. Die Widgets helfen also nicht bei der Lösung des Problems, sondern führen den Nutzer effektiv weiter von einer echten Problemlösung fort, indem sie an den Symptomen herumdoktern, statt die Ursachen zu beheben. Streng genommen erweist man seinen Benutzern sogar einen Bärendienst, da man eine Erwartungshaltung schürt, die nur von den wenigsten Websites erfüllt wird.

Wesentlich sinnvoller und von nachhaltigerem Effekt sind hier Ansätze wie bei der BBC-Seite »My Web My Way - Making text larger in Internet Explorer«, wo Nutzern erklärt wird wie sie das Problem dauerhaft beheben können. Wenn man also schon Ressourcen in diese Thematik steckt, dann doch wohl besser so, dass dem Nutzer wirklich geholfen wird.

Darüber hinaus stellt sich an diesem Punkt auch eine philosophische Frage: können wir einerseits verlangen, dass Webdesigner möglichst viel Kontrolle über das Erscheinungsbild aufgeben und dann wiederum das genau Gegenteil fordern? Standard-konforme Webdesigner machen nur Vorschläge - das C in CSS steht für die Kaskade (engl.: Cascading), und die endet beim Nutzer – dieser hat das letzte Wort über die Größe der Schrift.

Merke: wenn Browser oder Hilfsmittel in der Lage sind, ein Accessibility-Problem zu lösen, dann müssen Sie als Anbieter einer Seite dies nicht mehr machen. Und deswegen ist das fontsize-Skript weg.

27 Jun 2008

Gesammelte Werke mit CSS:

30 Mai 2008

In Klein-Bloggersdorf tobt gerade mal wieder die Aus­einander­setzung pro und contra Grid Layouts (nicht zu verwechseln mit Layout Grids!). Aber lesen Sie selber (und auch die zahllosen Kommentare):

Weitere lesenswerte Ressourcen zum Thema Gestaltungsraster:

Nachtrag: »Flexible Layouts – die Herausforderung der Zukunft«

28 Mai 2008

Grundlegende konzeptionelle & gestalterische Erwägungen, um dies hier zu verhindern:

20 Mai 2008

Was mit CSS:

16 Mai 2008

Heute mal was mit Usability und wie man auf dem Nutzer auf die Spur kommt:

15 Mai 2008

Heute zur Abwechselung mal was mit Typographie:

18 Apr 2008

Dem Schönen, Wahren, Guten: ganz viel CSS.

Und die wöchentlichen Wiedergänger zum Endlosthema »Reset oder nicht?« dürfen natürlich auch nicht fehlen:

16 Apr 2008

Eine Liste mit ganz vielen Listen, die Listen zum Thema CSS beinhalten:

Auch gut:

»The Highly Extensible CSS Interface ~ The Series« von Cameron Moll:

12 Mär 2008

designfragen.de richtet sich an Unternehmen und Personen, die bisher noch keine Erfahrung mit Design haben und nun ein Logo, eine Webseite oder ähnliche Designarbeiten in Auftrag geben möchten. Diese Seite beantwortet die gängigsten Einsteigerfragen, und einfache Erklärungen finden wir immer gut: designfragen.de.

07 Mär 2008

Mal wieder was mit Design und wie man's hinbekommt: