Webstandards
Kommentare 14

Die Evaluierung von Webseitenzugänglichkeit Teil 2, Grundlegende Prüfschritte

Dieser Artikel ist eine Übersetzung des Artikels “Evaluating Website Accessibility Part 2, Basic Checkpoints” von Roger Johansson. Alle Rechte am Artikel bleiben beim Autoren. Für weitere Informationen und Artikel zum Thema Webstandards besuchen Sie seine Seite 456 Berea Street.

Dies ist der zweite Artikel von einer dreiteiligen Artikelserie, die erklärt wie man die Zugänglichkeit einer Website evaluiert. Für ein wenig Hintergrundwissen and die Installation der empfohlenen Tools, sollten Sie “Die Evaluierung von Webseitenzugänglichkeit Teil 1, Hintergrund und Vorbereitung” (Deutsche Übersetzung hier) lesen bevor Sie diesen Artikel zu lesen beginnen.

Eine komplette Zugänglichkeitsevaluierung ist gründlicher und beinhaltet mehr Prüfschritte, einige davon werden im dritten Teil dieser Serie behandelt. Trotzdem sind die grundlegenden Prüfschritte ein guter Anfang:

  1. Validieren Sie HTML und CSS
  2. Keine Frames, bitte
  3. Automatisierte Tools zur Zugänglichkeitskontrolle
  4. Bilder und alternativer Text
  5. Stellen Sie sicher, dass sich JavaScript unaufdringlich verhält
  6. Erhöhen Sie die Schriftgröße
  7. Suchen Sie nach semantischem Markup
  8. Schalten Sie CSS ab
  9. Benutzen Sie Fangs, um einen Screenreader zu simulieren

1. Validieren Sie HTML und CSS

Benutzen Sie die Validatoren des W3C, um zu überprüfen, ob HTML und CSS valide sind. Die Erweiterung Web Developer Toolbar ist dafür sehr praktisch: Tools - Validate CSS und Tools - Validate HTML. Ich empfehle Ihnen, für diese beiden Funktionen Tastatur-Shortcuts festzulegen, da Sie sie oft benutzen werden.

Natürlich können Sie auch die Online-Validatoren des W3C benutzen:

Beachten Sie, dass die HTML-Validation von vielen schlecht aufgebauten Websites schwierig ist, da weder DOCTYPE/Dokumententyp noch Zeichenkodierung angegeben wurden. Für derartige Seiten ist eine manuelle Eingabe im Validatoreninterface angebracht.

Noch schlimmer sind Seiten, die den Zugriff von Validatoren vollkommen abblocken. Ja, ich habe Seiten gesehen, die das tun. Warum man eine Seite vor Validatoren verstecken will, ist mir rätselhaft. Wie auch immer, für solche Fälle müssen Sie Tools - Validate Local CSS und Tools - Validate Local HTML in der Web Developer Bar verwenden. Je nachdem wie invalid das HTML ist, sollten Sie Tools - Validate Local CSS auch bei Seiten verwenden, die die Validatoren nicht blockieren – einige Auszeichnungsfehler behindern den CSS-Validatoren in der Ausführung.

Mit der Erweiterung HTML Validator können Sie auch Seiten validieren, die den W3C-Markup-Validator blockieren. Die Erweiterung sendet keine Informationen zu einem Server und ist somit auch für den Einsatz hinter einer Firewall oder bei passwortgeschützten Seiten nützlich.

Der HTML Validator informiert Sie automatisch bei Fehlern und warnt Sie bei möglichen Zugänglichkeitsproblemen bei jedem neuen Laden einer Seite. Sie können die Stufe der Warnungen im Optionsdialog anpassen. Sie sollten berücksichtigen, dass diese Erweiterung auf Tidy basiert. Das bedeutet, dass in einigen Fällen Fehler nicht angezeigt werden, die vom W3C Validator erkannt werden.

Seien Sie sich bewusst, dass Validität nicht Zugänglichkeit bedeutet. Ich habe viele Seiten gesehen, die valides HTML verwenden aber trotzdem weit entfernt von Zugänglichkeit sind. Dieses Szenario ist teilweise auf Seiten vertreten, die auf Content Management Systemen basieren, deren Entwickler die Verwendung von Webstandards missverstanden haben.

Warum? Weil valides Markup wichtig ist, um eine Unabhängigkeit der Hilfmittel sicherzustellen, eine der fundamentalen Säulen des Webs. Valides Markup zu verwenden erhöht die Möglichkeit, Informationen korrekt von allen Geräten interpretieren zu können.

2. Keine Frames, bitte

Im Firefox können Sie über das Kontextmenü (Rechtsklick innerhalb der Seite) oder die Ansicht des Quelltextes herausfinden, ob eine Seite Frames benutzt oder nicht. Falls eine Seite Frames verwendet, enthält das Kontextmenü eine Option, die “Aktueller Frame” heißt. Iframes sind ein wenig komplizierter zu finden, da Sie innerhalb des Bereiches klicken müssen, der den Iframe beinhaltet, erst dann erscheint die Anzeige “Aktueller Frame”. Glücklicherweise können Iframes mit der Funktion Outline - Outline Frames der Web Developer Bar angezeigt werden.

Warum? Obwohl Frames (und Iframes) nicht zwangsläufig unzugänglich sein müssen, verschlechtern sie generell Zugänglichkeit und Benutzbarkeit einer Seite. Frames sind außerdem ein Anzeichen dafür, dass die Seite von einem Entwickler erstellt wurde, der wenig Wissen über Zugänglichkeit und Benutzbarkeit hat. Für mehr Informationen über den Einfluss von Frames auf die Benutzbarkeit lesen Sie meinen Artikel “Who framed the web – frames and usability”.

3. Automatisierte Tools zur Zugänglichkeitskontrolle

Automatisierte Tools zur Zugänglichkeitskontrolle werden zunehmend von Neulingen der Zugänglichkeit verwendet. Das ist absolut verständlich – wäre es nicht großartig, wenn die Kontrolle der Zugänglichkeit einer Seite ebenso leicht wäre wie die der Validität? Das Problem ist, dass die existierenden automatischen Tools technisch unausgereift und nicht verlässlich sind.

Diese Tools können bei der Suche nach einigen Problemen helfen und dazu benutzt werden, einen schnellen und sehr allgemeinen Überblick über die Zugänglichkeit einer Website zu erhalten. Deshalb denke ich, dass ihr Einsatz lohnenswert ist. Bedenken Sie dennoch, dass es viele mögliche Zugänglichkeitsprobleme gibt, die diese Tools nicht erkennen und teilweise von Problemen berichten, die gar keine sind. Eine manuelle Betrachtung ist immer notwendig.

Die folgenden Tools sind nicht absolut zuverlässig, aber sie können dennoch den Hinweis geben, ob eine Seite zugänglich ist oder nicht und welche Bereiche problematisch sind:

Um es noch einmal deutlich zu machen: Eine Seite, die alle drei automatisierten Zugänglichkeitstest besteht, ist nicht zwangsläufig zugänglich.

Warum? Automatisierte Tools helfen bei der Suche nach Zugänglichkeitsproblemen, die bei einer manuellen Suche in der Auszeichnung wesentlich länger dauern würde. Gehen Sie sicher, dass Sie den automatisch generierten Bericht evaluieren und die als problematisch bezeichneten Bereiche manuell überprüfen.

4. Bilder und alternativer Text

Der HTML-Validator und die Zugänglichkeitskontrolltools, die hier erwähnt werden, sagen Ihnen ob Bilder oder Image-Maps (verweissensitive Grafiken) keinen alternativen Text besitzen, da das alt-Attribut vorgeschrieben ist. Falls der Validator keine fehlenden alt-Attribute beanstandet, wissen Sie, dass alle Bilder im Dokument ein alt-Attribut besitzen. Dennoch können Probleme auftreten, überprüfen Sie also die Verwendung der alt-Attribute.

Benutzen Sie die Web Developer Bar, um alternativen Text aller Bilder anzeigen zu lassen: Images - Replace Images With Alt Attributes. Versuchen Sie dann, die Seite zu verstehen. Überprüfen Sie außerdem, ob der alternative Text sichtbar ist, wenn alle Bilder ausgeschalten sind – viele Browser benutzen die Textfarbe, die für das Bild (oder für eines der Elternelemente) deklariert wurde, um alternativen Text anzuzeigen. Falls diese Farbe zu nah an der Hintergrundfarbe ist, wenn das Bild nicht angezeigt werden kann, wird der alternative Text nur schwer oder gar nicht lesbar sein. Das tritt vor allem bei Seiten auf, die viele Hintergrundbilder verwenden.

Oft wird das alt-Attribut missverstanden. Es dient dazu, aussagefähigen, informativen Text bereitzustellen, der als eine Alternative benutzt werden sollte, falls ein informationelles Bild oder ein anderes graphisches Objekt nicht angezeigt werden kann. Das alt-Attribut ist für img- oder area-Elemente vorgeschrieben.

Informative Bilder sollten eine kurze Beschreibung des Bildes besitzen. Dekorative Bilder sollten einen leeren alternativen Text besitzen. Ich habe Seiten gesehen, die in einem fehlgeleiteten Versuch, hilfreich zu sein, alle dekorativen Bilder und Spacer-GIFs detailliert beschrieben haben. Sie brauchen eine solche Seite nur einmal mit einem Screenreader oder Textbrowser besuchen, um zu bemerken, wie lästig das ist.

Für eine tiefgreifendere Beschreibung des alt-Attributs und seinem Verwandten, dem title-Attribut, empfehle ich meinen Artikel “The alt and title attributes”. Informationen darüber, wann ein Bild informationell oder dekorativ ist, enthält Dimitri Glazkovs Artikel “Keeping “pretties” out of content”.

Warum? Wenn kein alternativer Text bereitgestellt wird oder falsch angegeben ist, wird jeder, der die Bilder nicht sehen kann, entweder die Information verpassen oder in sinnloser Information ertränkt.

5. Aufdringliche Benutzung von JavaScript

Jetzt muss wieder die Web-Developer-Erweiterung zum Einsatz kommen. Schalten Sie JavaScript ab (Disable - Disable JavaScript), versuchen Sie dann, die Seite zu benutzen. Einige Seiten sind unmöglich ohne JavaScript zu benutzen. Das am meisten verbreitete Problem von staatlichen Websites, das ich beobachtet habe, ist die Verwendung von JavaScript zur Navigation. Viele benutzen JavaScript, um Stylesheets zu laden (nachdem sie einige Informationen über den Browser erschnüffelt haben, wie im 20. Jahrhundert), so dass man ein ungestaltetes Dokument erhält, wenn man JavaScript deaktiviert hat.

Ich benutze ebenso Lynx, der keine JavaScript-Unterstützung besitzt, um zu testen, ob eine Seite ohne JavaScript benutzbar ist.

Warum? Eine bescheidene Anzahl an Menschen haben die JavaScript-Unterstützung abgeschaltet oder benutzen ein Gerät, das JavaScript nicht unterstützt. Sie sollten trotzdem in der Lage sein, die Seite zu benutzen.
Das heißt nicht, dass Sie JavaScript nicht benutzen dürfen. Sie können selbstverständlich. Sie müssen dennoch sicherstellen, dass Sie es vorsichtig und unaufdringlich verwenden, und eine geringe Verschlechterung einplanen, falls JavaScript nicht verfügbar ist.

6. Erhöhen Sie die Schriftgröße

Um diesen Punkt zu überprüfen, müssen Sie den Internet Explorer unter Windows benutzen oder das CSS betrachten. Sie suchen danach, wie die Schriftgröße festgelegt ist.

Falls die Schriftgröße mit relativen Einheiten wie em oder Prozent deklariert ist, funktioniert die Veränderung der Schriftgröße in allen Browsern. Falls die Schriftgröße in Pixeln festgelegt wurde, können Benutzer des Internet Explorer für Windows die Schriftgröße nicht ändern ohne vorher nicht die Einstellungen des Browsers zu verändern, was nur sehr wenige Personen tun.

Laden Sie die Seite nun im IE/Win, falls Sie ihn besitzen, und versuchen Sie, den Text in der Größe zu verändern (Strg Scrollrad der Maus or Ansicht - Schriftgrad - Sehr groß). Falls nichts passiert, benutzt die Seite vermutlich Pixel, um die Schriftgröße festzulegen.

Falls Sie IE/Win nicht benutzen können, betrachten Sie das CSS. Auch hier kann die Web Developer Bar verwendet werden: CSS - Edit CSS. Suchen Sie nach der Einheit in allen font-size-Deklarationen. Falls Sie nur px finden, benutzt die Seite keine relativen Einheiten (technisch tut sie das schon, aber nicht für den Zweck dieses Dokuments). Sie wollen em oder % sehen.

Ob Browser in Pixeln festgelegten Text vergrößern sollten oder nicht, ist eine andere Frage, und eine, die seit Jahren debattiert wird. Eine solche Diskussion finden Sie in meinem Artikel “Setting font size in pixels”.

Selbst wenn die Schriftgröße in einer relativen Einheit festgelegt wurde können immer noch Probleme beim Vergößern des Textes entstehen. Das Layout muss in die Betrachtung einbezogen werden, dass Benutzer die Textgröße um einige Nummern hochschrauben. Viele Layouts werden schnell unnutzbar, wenn die Schrift vergrößert wird. Offensichtlich bricht jedes Layout letztendlich, aber ein gutes Layout sollte in der Lage sein, zusammen zu halten, wenn der Text um einige hundert Prozent erhöht wird. Es muss nicht so gut aussehen wie mit normaler Textgröße, aber der Inhalt sollte nicht verschwinden oder unlesbar werden.

Warum? Weil viele Leute größeren Text benötigen oder wollen, um ihn komfortabel lesen zu können. Sie könnten sehbehindert sein, älter als 40 oder mögen es einfach, sich beim Surfen zurück zu lehnen.

7. Suchen Sie nach semantischem Markup

Um festzustellen, ob die Seite semantisches Markup verwendet, betrachten Sie den Quelltext und suchen Sie nach Überschriften (


), Listen (
    ,
      ,
      ), Zitaten (
      , ) und Betonungen (, ). Sie können diese recht schnell erkennen, da Seiten ohne semantisches Markup Kontrukte wie Überschrift benutzen, obwohl sie

      Überschrift

      verwenden sollten.

      Warum? Semantisches Markup ist wichtig, da es dem Browser die Möglichkeit gibt, den Inhalt in einer Weise zu interpretieren, die der Bedeutung angemessen ist. Zusätzlich bevorzugen auch Suchmaschinen semantisches Markup.

      Durch die richtige Verwendung von Überschriften können Hilfsmittel eine Dokumentstruktur erstellen, die für Benutzer von Screenreadern sehr nützlich sein kann.

      Selbst wenn nicht alle verfügbaren semantischen Informationen von den Hilfsmitteln benutzt werden, ist es für einen Browser unmöglich, Bedeutung aus dem Text zu erhalten, wenn die Website kein semantisches Markup benutzt.

      8. Schalten Sie CSS ab

      Schalten Sie CSS über die Web Developer Bar ab: Disable - Disable Styles - All Styles. So können Sie die Struktur des zu Grunde liegenden HTML in der Standarddarstellung Ihres Browsers sehen.

      Falls sehr wenig passiert, wenn sie CSS abgeschlatet haben, betrachten Sie möglicherweise ein Dokument, dass Tabellen zur Umsetzung des Layouts benutzt und viel auf die Präsentation bezogenes Markup. Sie haben in diesem Falle sicher schon eine Menge anderer Zugänglichkeitsprobleme gefunden, wenn Sie mit einem solchen Dokument diesen Prüfschritt erreicht haben.

      Warum? Ein zugängliches Dokument sollte wohlstrukturiert, bedeutungsvoll und ohne CSS lesbar sein.

      9. Benutzen Sie Fangs, um einen Screenreader zu simulieren

      Fals sie keine Screenreader-Anwendung benutzen können, können Sie mit Fangs dennoch einen guten Eindruck dafür bekommen, wie es klingt, wenn die Seite von einem Screenreader vorlesen wird. Fangs ist eine Firefox-Erweiterung (deren Installation ich im Teil 1 dieser Artikelserie empfohlen habe), die einen der am meisten vertretenen Screenreader nachbildet, indem sie den Text darstellt anstelle der gesprochenen Sprache.

      Warum? Screenreader sind bedeutende technische Hilfsmittel. Zu wissen, wie eine Screenreader den Inhalt einer Seite spricht, hilft Ihnen festzustellen, ob beispielsweise die Reihenfolge des Inhalts sinnvoll ist, ob Links und Überschriften gut gewählt sind und ob alternativer Text angemessen benutzt wird.

      Evaluieren Sie die Ergebnisse

      Wenn Sie durch diese Checkliste gegangen sind, haben Sie auf Ihrer Seite sicher viele wirklich ernste technsiche Zugänglichkeitsprobleme gefunden. Falls Sie nicht der Entwickler sind, kontaktieren Sie einen Verantwortlichen und lassen Sie ihn wissen, dass sie Probleme gefunden haben, die behoben werden müssen.

      Es gibt trotz allem immer noch viele potentielle Zugänglichkeitsprobleme. In der Evaluierung von Webseitenzugänglichkeit Teil 3, Nachhaken, dem dritten und letzten Artikel der Serie, werde ich Dinge betrachten, die schwierig mit automatisierten Tools zu bewerten sind und ein wenig mehr manueller Evaluierung benötigen, ich werde aber auch etwas diskutieren, das oftmals übersehen wird, wenn es um Zugänglichkeit geht: Inhalt.

      Dieser Artikel ist eine Übersetzung des Artikels “Evaluating Website Accessibility Part 2, Basic Checkpoints” von Roger Johansson. Alle Rechte am Artikel bleiben beim Autoren. Für weitere Informationen und Artikel zum Thema Webstandards besuchen Sie seine Seite 456 Berea Street.

      Original “Evaluating Website Accessibility Part 2, Basic Checkpoints” von Roger Johansson.

Kategorie: Webstandards

von

Hallo, ich bin Nadja und arbeite als freie Webdesignerin in Berlin. Seit den 2000er-Jahren ist das Internet mein berufliches Zuhause, hier im cne _LOG schreibe ich erst seit Anfang 2006 zu den Themen Webdesign, Webstandards und vor allem auch Wordpress.

14 Kommentare

  1. Pingback: » Die Evaluierung von Webseitenzugänglichkeit: Teil 3, Das Nachhaken — cne _LOG Archiv

  2. Pingback: » Die Evaluierung von Webseitenzugänglichkeit Teil 1, Hintergrund und Vorbereitung — cne _LOG Archiv

  3. Pingback: Cyberoog, die Insel im Web (Blog)

  4. Du schreibst so nett über Webstandards, reflektierst über valides Markup mit den Worten “..valides Markup wichtig ist, um eine Unabhängigkeit der Hilfmittel sicherzustellen, eine der fundamentalen Säulen des Webs”.

    Doch warum legst Du diese Messlatte nicht bei Dir selbst an und prüfst Deine Seite mal nach. Allein diese Seite hat mehr als 20 Markup-Fehler.

    Das ganze unter dem Hintergrund, dass Du mit “Standardkonforme Websites(n)” Geld verdienst/verdienen willst.

  5. Hallo Magkes, dass diese Seite mal nicht validiert, liegt zum einen daran, dass das zugrundeliegende WordPress mit all seinen Plugins auch manchmal nicht valides (X)HTML produziert. Das kann sicher jeder bestätigen, der mit einem CMS/Blogsystem arbeitet.
    Die Fehler im Bereich “Andere letzte Beiträge” sollten jetzt behoben sein.

    Auch wenn das ein Fehler meinerseits war, hätte ich ihn längst erkennen können. Aber ich habe mich auf Tidy verlassen, der den vergessenen End-Tags keine Beachtung schenkte.

    Dieser Artikel ist eine Übersetzung von Roger Johanssons Artikelserie, und die enthaltene Botschaft versuche auch ich umzusetzen: Valides Markup allein erzeugt keine zugänglichen Seiten, wichtig für die Erstellung von standardkonformen Websites ist eben auch die logische und semantische Auszeichnung von Inhalten.

    Übrigens (auch wenn ich mich nicht auf den Verdiensten anderer ausruhen möchte): Viele Webseiten der bekannten Größen aus dem Bereich validieren ebenfalls nicht immer, trotzdem ist es auch mit Screenreader oder mobilen Geräten einfach, die Seiten zu benutzen. Und das liegt zum großen Teil am semantischen Markup.

  6. Sven sagt

    Mir sind viele Bemerkungen hier ein wenig zu ideologisch, Beispiel die Aussagen über den Einsatz von Frames oder von Javascript.
    Ich habe nicht so richtig das Motiv verstanden. Alle Websites Lynx-konform? Purismus pur? Den Titel “Aufdringliche Benutzung von JavaScript” verstehe ich nicht. Was ist aufdringlich? Ich würde sagen: Entweder Oder. Wenn ich eine Technologie wie JavaScript nutze, warum dann nicht die Möglichkeiten ausschöpfen?

  7. Hallo Sven: Natürlich hat das Streben nach Zugänglichkeit mit Ideologie zu tun. Das Motiv dahinter ist die Nutzbarmachung von Webseiten für alle (Besucher, Browser, OS). Mit der Verwendung von Webstandards kann man den Grundstein für diese Zugänglichkeit legen.

    Unaufdringliches JavaScript bedeutet der Einsatz von JavaScript nur in dem Maße, dass die Seite auch ohne JS nutzbar ist.
    Mittlerweile gibt es viele JavaScript-Techniken, die so funktionieren und die Seite benutzbar lassen, wenn man JS nicht aktiviert hat.

    Purismus heißt in diesem Sinne eben nur so viel “Spielerei” wie nötig, um dem Besucher alle Möglichkeiten offen zu lassen. Und wenn die Seiten ohne Probleme mit Lynx immer noch nutzbar sind (schau dir die gängigen Blogs mal mit deaktiviertem CSS an), dann um so besser.

  8. Hi Nadja,
    natürlich hast Du da grundsätzlich recht. Eine Webseite, die auch ohne CSS gut lesbar ist, bringt sicher viele Vorteile.
    Andererseits lese ich in dem Text viel von Vorschriften, Problemen, sicherstellen und so fort. Das erinnert mich an Reglementierung. Und genau das ist es was das Web früher nie kannte.

    Kein Mensch hat sich früher in die Richterposition emporgeschwungen und mit dem Finger auf all diejenigen gezeigt welche die Gesetze eines selbsternannten Gurus nicht befolgt haben. Wieso jetzt?

    Können wir nicht anerkennen, dass das Web viele verschiedenartige Interessen befriedigt ? Und gehören die Eigenheiten einer Website nicht auch zur elektronischen Persönlichkeit des Betreibers? Seit wann braucht eine Website den Stempel “Valide” und “Barrierefrei” um für gut befunden zu werden ?

    Mal ehrlich: es sind die Inhalte, die letztlich eine Website auszeichnen – nicht die Formalien. Mit Formalien beeindruckt und verunsichert nur derjenige den Laien, der auf der inhaltlichen Ebene nichts zu bieten hat.

    Darum soll es doch ein jeder halten wie er mag. Wer irgendwelche wild ausgerufenen Standards einhalten will, kann es tun – und wem eine theoretische Zugänglichkeit ohne CSS mit einem Textbrowser, den eh fast keiner kennt geschweige denn einsetzt, gleichgültig ist, der kann tun wie es ihm beliebt.

    Und wenn eine Website frei von erklärenden Alt-Tags und semantischem Markup ist und dafür mit Flash-Clips in HTML-Tabellen die Bedürfnisse der Zielgruppe voll erfüllt, so ist das okay. Und wenn die Zielgruppe Javascript aktiviert hat, dann ist es auch okay, wenn die Website Javascript verwendet.

    Auch muss man nicht die Schriftgröße beliebig vergrößern und verkleinern können. Wenn sich der Designer der Website für ein bestimmtes Erscheinungsbild entschieden hat, dann soll es eben so sein, dass die Inhalte genau so erscheinen und nicht anders. Da muss man auch nichts dem Besucher überlassen.

    Bin gespannt auf Deine Antwort.

    Gruß, Klaus.

  9. Hallo Klaus,

    ich habe leider erst jetzt deinen Kommentar gefunden, Akismet hätte ihn zwar akzeptiert, aber Spam Karma wollte nicht.

    Die Diskussion, die du hier einführst, ist genau die, die bereits an anderen Stellen geführt wird. Und ja, du hast Recht: Jeder kann mit seiner Website tun und lassen, was er will. Und auch jeder Besucher kann damit machen, was er will, dagegen können wir uns wohl nicht wehren.

    Mir persönlich geht es aber nicht darum, mich als Richter aufzuspielen. Ich schätze die Möglichkeiten, die sich mir mittels der vorhandenen Standards bieten. Und ich lege Wert auf semantischen und auch validen Code, da meine Website so von verschiedenen Hilfsmitteln gelesen werden kann.
    Wenn die Technik irgendwann einmal soweit ist, dass man sich früh von einer Art Browser beim Frühstücken oder in der S-Bahn die letzten Nachrichten, Posts etc. vorlesen lassen kann oder andere Dinge, dann liegt das hoffentlich teilweise an der Auszeichnung der Webseiten.

    Und mir persönlich geht es auch nicht darum, dass meine Website auf allen Browsern gleich aussieht, auch wenn eine große Übereinstimmung erfreulich ist. Mir geht es um den Transport meiner Inhalte. Wenn das in einem optisch ansprechenden Rahmen geschieht, umso besser. Und der Benutzer kann mit dem Aussehen machen was er will. Mein Design ist ein Angebot. Vielleicht interessiert das niemanden mehr in ein paar Jahren, weil man dann jeder Seite den eigenen Look überstülpen kann. Die Informationen, die immer irgendwie ausgezeichnet werden müssen, müssen verstanden werden, ob nun in blau oder rot.

    Eine hohe Kompatibilität, darum geht es doch bei Standards. Und umso besser ein Browser eine Website versteht desto besser versteht der Besucher sie.

    Und noch eine Frage: Stört es denn den Benutzer, eine valide, logisch ausgezeichnete Website zu besuchen?

    Man könnte auch Architekten fragen, ob ein Dach und 4 Wände nicht genügten.
    Auch wenn ein unsicheres Haus gefährlicher ist als eine nichtvalide Webseite.

  10. Sehr schöner Artikel, lässt sich gut lesen. Ich bin auch schon eine Weile daran, ein paar Homepages zu erstellen. Einige wichtige Sachen hab ich erst durch diesen Artikel erfahren. Danke für die Übersetzung!

    Gruß, Urs

  11. Hallo,

    also soweit ganz gut, danke für die Übersetzung. Allerdings finde ich den Javascript Teil nicht wirklich treffend.

    Website Tracker von verschiedensten Webprojekten teilen mir an, dass bei den Besuchern JavaScript zu 100% aktiviert war.

    Ich denke den Absatz könnte man streichen!

  12. Hallo Rob, natürlich kommt es beim EInsatz von JavaScript immer auf die Zielgruppe an. Wenn man die eigene Website zugänglicher gestalten möchte, solte man darauf achten, dass JavaScript nicht die einzige Möglichkeit ist, Informationen zu erhalten. Einige Browser/Hilfsmittel, gerade auf dem Vormarsch von mobilen Geräten, unterstützen JS nicht und auch einige Menschen fühlen sich sicherer ohne es. Deshalb sollte es immer eine Fallback-Option geben.

    Ich selbst kenne außerdem Leute, die JS generell deaktiviert haben, aus Prinzip. Sie von JavaScript zu überzeugen, ist unmöglich.

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *

Du kannst folgende HTML-Tags benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>