Webstandards

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 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.