Veröffentlichungen Leitfäden Intranet Leitfaden zur Gestaltung eines barrierefreien Intranets für Programmierer
Dieser Leitfaden entstand im Auftrag des "Aktionsbündnisses für barrierefreie Informationstechnik (AbI-Projekt)" und gibt Programmierern konkrete Hinweise und Anregungen zu einer barrierefreien Gestaltung eines Intranet-Auftrittes.
Zusätzlich steht noch eine 
PDF-Version des Leitfadens zur Erstellung barrierefreier Intranetseiten für Programmierer zum Download zu Verfügung.
Die im Folgenden aufgezeigten 14 Anforderungen stammen aus Teil 1 der Anlage zur Barrierefreie Informationstechnik-Verordnung (BITV) und den Zugänglichkeitsrichtlinien für Web-Inhalte in der Version 1.
Hinweis zur Aktualität: Die Barrierefreie Informationstechnik-Verordnung (BITV) von 2002 des Bundes ist im Jahr 2011 überarbeitet worden. Dieser Leifaden bezieht sich noch auf die Version von 2002. Allerdings sind die hier dargestellten Anforderungen auch in der neuen Version enthalten.
Für jeden Audio- oder visuellen Inhalt sind geeignete äquivalente Inhalte bereitzustellen, die den gleichen Zweck oder die gleiche Funktion wie der originäre Inhalt erfüllen.
Autoren sollten Bilder und grafische Elemente, die der Vermittlung von Informationen dienen, mit Alternativtexten zu versehen. Diese Alternativtexte ermöglichen es blinden und sehbehinderten Menschen, die mit der Grafik transportierte Information wahrzunehmen.
Alternativtexte werden über das alt-Attribut des img-Elementes angegeben. Bieten Sie daher den Autoren im verwendeten Editor eine (komfortable) Möglichkeit, dieses Attribut mit Inhalt zu füllen ohne den HTML-Quelltext direkt bearbeiten zu müssen. Beschränken Sie das dazu erforderliche Eingabefeld auf maximal 80 Zeichen, da diese Zahl im Allgemeinen als Obergrenze für Alternativtexte empfohlen wird.
Stellen Sie den Autoren ergänzend dazu eine Möglichkeit bereit, das longdesc-Attribut des img-Elementes zu nutzen, ohne über HTML-Kenntnisse verfügen zu müssen. Das longdesc-Attribut wird verwendet, falls eine ausreichend detaillierte Beschreibung des in der Grafik dargestellten Inhalts weder in den maximal 80 Zeichen des alt-Attributs noch in dem die Grafik umgebenden Fließtext möglich ist.
Stellen Sie durch eine entsprechende Logik im genutzten Editor sicher, dass die eingefügte Grafik um einen Hyperlink zum longdesc-Text ergänzt wird. Diesen Hyperlink können Sie per CSS "unsichtbar" gestalten (etwa durch eine absolute Positionierung außerhalb des dargestellten Anzeigebereichs). Das ist sinnvoll, da nicht alle Screenreader auf das Vorhandensein eines longdesc-Textes oder eines Links dazu hinweisen. Ein der Grafik folgender Hyperlink wird dagegen immer vorgelesen.
Ergänzende Informationen zu einer (komplexen) Grafik sind nicht nur für sehbehinderte Anwender nützlich. Auch Anwendern, denen sich der Inhalt des Dargestellten nicht direkt erschließt, kann eine ergänzende Beschreibung helfen. Dazu sind beispielsweise Menschen mit Lernschwierigkeiten zu zählen.
Abbildung 1 zeigt eine mögliche Lösung zur (automatischen) Integration des longdesc-Textes. In diesem Beispiel wurde als semantische Ergänzung eine Definitionsliste (dl) verwendet.
Details zur technischen Realisierung dieser auf CSS und XHTML basierenden Lösung sind bei Pro-Barrierefreiheit nachzulesen.
Abbildung 1: Screenshot einer Integration des longdesc-Links durch XHTML und CSS
Bei Bildern wird zwischen Informationsgrafiken (Schriftgrafiken, Symbole, Logos, Abbildungen, Illustrationen) und Layoutgrafiken unterschieden. Beide Typen werden nicht nur in von Redakteuren verfassten Artikeln, sondern auch in den von den Programmierern entwickelten Templates/Themes verwendet.
Enthält eine Grafik geschriebenen Text, ein Symbol oder ein Logo, so muss der Alternativtext die in der Grafik optisch erkennbare Information enthalten. Das bedeutet, dass ein abgebildeter Text oder die Funktion des Symbols wiedergegeben werden muss. Generell sollten Schriftgrafiken vermieden werden, da sie nicht oder nur eingeschränkt den individuellen Bedürfnissen des Betrachters angepasst werden können.
Alternativtexte für Grafiken, die der Illustration eines Sachverhalts dienen, wie der Darstellung eines Aktienkurses oder der Bedienung eines technischen Gerätes, müssen die wesentlichen Informationen, die die Grafik vermittelt, enthalten. Oftmals ist es zum Finden einer aussagekräftigen Beschreibung hilfreich, sich vorzustellen, die Beschreibung der Grafik telefonisch vornehmen zu müssen.
In vielen Intranets werden zur Visualisierung der Zuständigkeiten innerhalb des Unternehmens Organigramme verwendet und als einzelne Grafik im Intranet für die Mitarbeiter veröffentlicht. Solche und ähnliche Diagramme vermitteln umfangreiche Information in kompakter, visueller Form.
Der Alternativtext zu einem Diagramm sollte die zentrale Aussage des Diagramms wiedergeben. Eine detaillierte Beschreibung sollte im Fließtext oder über das longdesc-Attribut erfolgen. Als Alternative zu einer grafischen Version (plus Alternativtext) sind verschachtelte Listen eine gute Möglichkeit Organigramme – auch semantisch korrekt – abzubilden.
Grafiken, die als Bedienelement (beispielsweise zum Abschicken eines Formulars) oder als Link (etwa zu einer vergrößerten Ansicht der jeweiligen Grafik) verwendet werden, sollten im Alternativtext die Aktion des Bedienelements (zum Beispiel "Formular absenden") oder das Linkziel ("zu einer vergrößerten Ansicht der Grafik XY") enthalten.
Layoutgrafiken enthalten keine Information und dienen ausschließlich gestalterischen Zwecken. Sie benötigen daher in der Regel keinen Alternativtext. Vermeiden Sie, das alt-Attribut vollständig aus dem img-Element zu entfernen, da Screenreader ein fehlendes alt-Attribut (je nach Einstellung durch den Anwender) anders handhaben als ein leeres. Lassen Sie daher bei Layout-Grafiken den Alternativtext leer.
Als Ergänzung zum Alternativtext einer Grafik und als Alternative zur longdesc-Beschreibung können Sie Bildunterschriften im Stil des Beispiels in Abbildung 1 verwenden. Dies stellt oftmals auch für sehende Nutzer einen Mehrwert dar, beispielsweise wenn es um die Vorstellung von in der Grafik abgebildeten Personen geht.
Moderne Intranet-Lösungen weisen eine Vielzahl von multimedialen Inhalten auf. Der Einsatz ist durch eine einfache und günstige Produktion und in der Steigerung der Attraktivität des Intranets bei den Mitarbeitern motiviert.
Diese "Webcasts" (Audio- und Video gleichermaßen) erfüllen verschiedene Funktionen: Sie dienen in der beruflichen Weiterbildung als Lehrmedien und ermöglichen Unternehmern eine individuelle Außendarstellung.
Im Kontext der Barrierefreiheit sind multimediale Inhalte oftmals problematisch und es müssen daher in der Produktion und beim Einsatz von Audio oder Video besondere Vorgehensweisen beachtet werden.
Stellen Sie daher für Multimedia-Produktionen eine Infrastruktur bereit, die es den Produzenten/Autoren ermöglicht, ihre multimedialen Inhalte zugänglich zu gestalten. Dazu gehören bei Videos eine Audiodeskription und eine Untertitelung. Optional kann eine vollständige Transkription erfolgen. Bei Audiomaterial ist eine Transkription immer erforderlich. Weisen Sie die Autoren an den entsprechenden Stellen im Editor auf die Notwendigkeit und Möglichkeit der barrierefreien Gestaltung ihrer Medien hin.
Verwenden Sie für die in Intranetseiten eingebetteten Medien barrierefrei bedienbare Abspielprogramme wie den "
JW FLV Player" oder " ccforFlash". Stellen Sie (ergänzend zur eingebetteten Version) eine Download-Möglichkeit bereit, um den multimedialen Inhalt lokal auf dem Rechner zu speichern. Dort können die Anwender den Inhalt abspielen und dazu eine zu ihren Hilfsmitteln kompatible Software verwenden. Auch herunterladbare und lokal abspielbare Medien sollten barrierefrei gestaltet sein, beispielsweise sollten Videos über eine Untertitelung und Audiodeskription verfügen.
Sofern Ihre Intranet-Software es unterstützt, sollten Sie die Generierung beider Möglichkeiten für die Autoren automatisiert anbieten: Die Wiedergabe in einem eingebetteten, barrierefreien Wiedergabeprogramm und eine Download-Möglichkeit. Sollte das nicht möglich sein, weisen Sie die Redakteure – etwa in Form eines Hilfe-Textes – auf die Notwendigkeit einer herunterladbaren Version hin, damit sie dieses Angebot manuell erstellen.
Texte und Graphiken müssen auch dann verständlich sein, wenn sie ohne Farbe betrachtet werden.
Menschen mit Farbfehlwahrnehmungen oder anderen Sehschwächen können einige Farben nicht korrekt wahrnehmen. So leiden in Deutschland etwa drei Prozent der Männer an einer Rot-Grün-Blindheit (Dyschromatopsie). Diese Menschen können die Farben Rot und Grün nicht immer voneinander unterscheiden.
Moderne Intranet-Lösungen basieren zumeist auf einer Template-Architektur, die im Wesentlichen aus zwei Teilen besteht: Ein (X)HTML-Gerüst mit speziellen Markern, die zur Laufzeit durch die Inhalte der Redakteure ersetzt werden und eine oder mehrere Vorlagedateien, die das optische/farbliche Erscheinungsbild beinhalten. Die Vorlagedateien basieren auf leicht veränderbaren CSS-Definitionen (Cascading Stylesheets). Mit Ihren Vorlagedateien bestimmen Sie maßgeblich, inwieweit eine Intranetseite barrierefrei ist, da Sie damit auch Schriftfarben festlegen.
Unabhängig von der einheitlichen Ausstattung der Arbeitsplatz-PCs innerhalb Ihres Intranets, sollten Seiteninhalte (Schrift, Grafiken) so gestaltet sein, dass ihr Kontrast auch auf einem Schwarz-Weiß-Bildschirm ausreichend groß ist, um wahrnehmbar zu sein.
Insbesondere auf einen hohen Kontrast zwischen Vorder- und Hintergrundfarbe ist zu achten. Setzen Sie dazu entweder helle Textfarben auf dunklem Hintergrund oder dunkle Textfarben auf hellem Hintergrund ein.
Um den Kontrast zu überprüfen ist es zweckmäßig, kritische Passagen auf einem Schwarz-Weiß-Drucker auszudrucken und den Kontrast im Ausdruck zu bewerten. Sind farbiger Text oder Grafiken nur schlecht lesbar, könnten Mitarbeiter bei der Wahrnehmung der Informationen Schwierigkeiten haben. Passen Sie in solchen Fällen die Farben dieser Elemente in Ihren Stil-Definitionen an.
Vermeiden Sie es, Informationen ausschließlich über Farbe zu transportieren. Wenden Sie stattdessen eine farbunabhängige Darstellung an.
Ein über das Intranet bedienbares Buchungssystem sollte z.B. die Verfügbarkeit einer Ressource nicht ausschließlich über ein farbiges Symbol anzeigen. Beispiel:
bedeutet: Konferenzraum ist frei
bedeutet: Konferenzraum ist belegt
Die Farbunterschiede der beiden Grafiken sind für rot-grün-blinde Mitarbeiter nicht erkennbar, verwenden Sie daher farbunabhängige Darstellungsweisen. Beispiel:
bedeutet: Konferenzraum ist frei
bedeutet: Konferenzraum ist belegt
In jedem Fall ist für Blinde die Grafik mit einem aussagekräftigen Alternativ-Text ("Konferenzraum frei" bzw. "Konferenzraum belegt") zu versehen. Sollte eine farbunabhängige Darstellung nicht möglich sein, ergänzen Sie die Darstellung um weitere Informationen. Stellen Sie negative und positive Werte nicht nur farblich (300 EUR bzw. 200 EUR) dar, sondern ergänzen Sie diese um ein positives oder negatives Vorzeichen (+300 EUR bzw. -200 EUR).
CSS-Vorlagedateien finden auch im Zusammenhang mit Hyperlinks im Fließtext Anwendung. Achten Sie auf ein einheitliches Schema zur Darstellung von Hyperlinks. Benutzer erwarten, dass Hyperlinks sich nicht nur durch eine farbliche Hervorhebung vom Fließtext unterscheiden, sondern dass sie zusätzlich unterstrichen sind
Stellen Sie sicher, dass für das Layout relevante Grafiken (etwa das Firmenlogo oder automatisch eingefügte Orientierungssymbole) vor wechselnden Hintergrundfarben erkennbar bleiben. Blendempfindliche Mitarbeiter stellen möglicherweise zur Betrachtung des Intranets ein individuelles Farbschema in ihrem Browser ein, da sie die Standard-Darstellung als zu grell empfinden. Daher kann es geschehen, dass Grafiken mit transparentem Hintergrund nicht mehr erkennbar sind, da vielleicht die eingestellte Hintergrundfarbe der Vordergrundfarbe der Grafik entspricht. Verwenden Sie daher Grafiken ohne transparenten Hintergrund.
Markup-Sprachen (insbesondere HTML) und Stylesheets sind entsprechend ihrer Spezifikationen und formalen Definitionen zu verwenden.
Moderne Intranet-Lösungen basieren auf einer Template-Architektur, die im Wesentlichen aus zwei Teilen besteht:
Dieses Vorgehen ermöglicht eine vollständige Trennung von Design/Layout und Inhalt. Daraus resultieren eine einfache Erweiterbarkeit und eine leichte Wartbarkeit für Programmierer.
Verwenden Sie zur Positionierung der einzelnen Elemente Ihrer Intranet-Seite Stylesheets und vermeiden Sie Layout-Tabellen. Falls Sie Layout-Tabellen verwenden müssen, beachten Sie, dass diese linearisierbar sind. Das bedeutet, dass das durch die Tabelle erzeugte optische Erscheinungsbild in der Reihenfolge der Reihenfolge im Quelltext entspricht. Andernfalls kann es zu Verständnisschwierigkeiten führen, wenn die Seite nicht optisch, sondern durch einen Screenreader akustisch wahrgenommen wird.
Beachten Sie, dass das Layout – unnabhängig davon, ob Sie es durch Stylesheets oder Tabellen gestalten – flexibel ist. Das bedeutet, dass es sich auch geringen Auflösungen anpassen kann, ohne dass es zu Überlagerungen einzelner Inhalte kommt. Die Seiten sollen auch für Mitarbeiter, die mit geringen Bildschirmauflösungen arbeiten, lesbar sein. Dazu gehören Mitarbeiter, die aufgrund einer Sehschwäche eine starke Vergrößerung der Bildschirminhalte verwenden, aber auch Mitarbeiter, die im Außendienst über ihren PDA auf das Intranet zugreifen.
Verwenden Sie relative Breitenangaben (Prozent- oder em-Angaben), damit die Darstellung relativ zum Anzeigebereich (Viewport) des Geräts berechnet wird. Feste Angaben (etwa Pixel) verursachen bei kleinen und schmalen Anzeigegeräten einen horizontalen Scrollbalken, der das Lesen von Fließtexten praktisch unmöglich macht.
Verwenden Sie neben dem Layout auch zur Gestaltung der Schriften und Hintergründe Stylesheets. Nutzen Sie auch dabei relative Angaben (Prozent- oder em-Angaben), um variable Schriftgrößen zu erhalten. Dies ist insbesondere für Mitarbeiter, die wegen einer Einschränkung ihrer Sehkraft die Schriftvergrößerung in ihrem Browser verwenden, hilfreich.
Moderne Browser tolerieren (X)HTML-Seiten mit syntaktischen Fehlern in gewissen Grenzen. Sie stellen den Inhalt trotz Fehlern korrekt dar. Bei der Betrachtung fehlerhafter Intranet-Seiten mit Hilfsmitteln können hingegen Probleme auftreten, die ein Betrachten unmöglich machen. Achten Sie daher auf valides (X)HTML in Ihren Template-Dateien. Überprüfen Sie sie mit entsprechenden Werkzeugen, beispielsweise Tidy für den Browser Firefox oder der Web Accessibility Toolbar für den Internet Explorer. Beide Tools weisen nicht nur auf etwaige Fehler hin, sondern bieten auch eine Korrekturhilfe an. Alternativ können Sie auch den Online-Validator des W3C verwenden, um Ihre Dateien zu überprüfen.
Verwenden Sie die zum Umfang von XHTML gehörenden Strukturelemente. Vermeiden Sie es, Inhalten durch eine spezielle Formatierung beispielsweise das Aussehen einer Überschrift zu geben. Nutzen Sie stattdessen die HTML-Sprachelemente h1-h6 für eine Auszeichnung. Hilfsmittel wie Screenreader bieten Anwendern die Möglichkeit, sich anhand der Überschriften auf einer Seite einen groben Überblick über die Struktur und die Inhalte einer Seite zu machen. Diese ist nur möglich, wenn die entsprechenden HTML-Strukturelemente für Überschriften verwendet werden.
Auch für Listen, die korrekt durch HTML-Strukturelemente ausgezeichnet sind, bieten Hilfsmittel Möglichkeiten, um die darin aufbereiteten Inhalte komfortabel wahrzunehmen. Verwenden Sie daher für alle Daten mit Listen-Charakter die entsprechenden Strukturelemente. Dies gilt insbesondere für die Navigation Ihres Intranets: Betrachten Sie jeden Menü-Eintrag als ein Listenelement und formatieren Sie es durch Ihre CSS-Vorlagedateien.
Moderne Intranet-Lösungen bieten über Kommunikationswerkzeuge hinaus auch ausgewachsene Applikationen und Dienste zur gemeinsamen Arbeit im virtuellen Raum, Weiterbildung und Information der Anwender an.
Stellen Sie sicher, dass auch die Oberfläche ein- und angebundener Software barrierefrei ist und dem Erscheinungsbild und der Bedienung ("look and feel") des restlichen Intranets entspricht. Das vereinfacht die Verwendbarkeit integrierter Dienste und Applikationen und verhindert Irritationen beim Anwender.
Üblicherweise stammen die Daten solcher Dienste und Applikationen aus externen Datenverarbeitungssystemen. Zum Datenaustausch und zur Darstellung im Rahmen des Intranets existieren in der Regel dedizierte Schnittstellen.
Beachten Sie bei der Verwendung der Schnittstellen, dass die Datensätze in ein valides und barrierefreies (X)HTML-Format eingebettet werden. Beachten Sie dazu die zuvor aufgezeigten Hinweise zu Überschriften und Listen. Besondere Betrachtung im Hinblick auf eine barrierefreie Gestaltung erfordert die Abbildung tabellarischer Daten in das Intranet (siehe dazu den Abschnitt zur barrierefreien Tabellen-Gestaltung). Je nach Ausgabeformat der tabellarischen Daten aus der Schnittstelle zu der anzubindenden Software muss unter Umständen die Formatstruktur der Daten überarbeitet werden, um eine barrierefreie Darstellung im Intranet zu ermöglichen.
Sprachliche Besonderheiten wie Wechsel der Sprache oder Abkürzungen sind erkennbar zu machen.
Insbesondere in international betriebenen Intranets stehen Inhalte oftmals in mehreren Sprachen zur Auswahl. Geben Sie die primäre Sprache der Seite in der Doctype-Definition an. Das folgende Bespiel stellt die Doctype-Definition einer deutschsprachigen Intranetseite nach "XHTML 1.0 Strict" dar:
Screenreader arbeiten intern mit Wortlisten, welche die verständliche Aussprache der Wörter festlegen. Die Kennzeichnung fremdsprachiger Inhalte ermöglicht es Screenreadern die zu einer korrekten Aussprache benötigte Wortliste zu laden. Dies ist erforderlich, damit fremdsprachiger Inhalt nicht mit der möglicherweise falschen beziehungsweise schwer verständlichen Betonung der Primärsprache ausgegeben wird.
Kennzeichnen Sie daher von der ausgewählten primären Sprache abweichende Begriffe und Orientierungshilfen (beispielsweise Brotkrumen-Navigation/Breadcrumb-Trail oder Überschriften), die sich im Einflussbereich des Template-Designers befinden.
(X)HTML bietet dazu das Universal-Attribut lang, welches das in der ISO 639-1 definierte Sprachkürzel als Wert erhält, also lang="en" für englischsprachige Inhalte oder lang="de" für deutschsprachige Inhalte. Die HTML-Kompatibilitätsrichtlinie empfiehlt für XHTML-Dokumente zusätzlich die Angabe xml:lang mit gleichem Wert wie das lang-Attribut, also xml:lang="en" oder xml:lang="de".
Eine englischsprachige Überschrift in einem deutschsprachigen Text sollte entsprechend
<h1 lang="en">english headline</h1>
oder in einem XHTML-Dokument
<h1 lang="en" xml:lang="en">english headline</h1> lauten.
Tabellen sind mittels der vorgesehenen Elemente der verwendeten Markup-Sprache zu beschreiben und in der Regel nur zur Darstellung tabellarischer Daten zu verwenden.
Layout-Tabellen bereiten Anwendern von technischen Hilfsmitteln Probleme, wenn sie nicht linearisierbar sind. "Linearisierbar" bedeutet, dass die Reihenfolge der Tabellenelemente logisch (Quelltext) und optisch (ausgegebene Interpretation in der Browser-Ansicht) identisch ist. Um den Inhalt der tabellarisch angeordneten Elemente verstehen zu können, ist daher bei einer linearisierbaren Layout-Tabelle keine optische Betrachtung notwendig.
Sind Layout-Tabellen zwingend erforderlich, achten Sie darauf, kein Strukturmarkup zu vergeben, da dies ausschließlich Datentabellen vorbehalten ist. Vermeiden Sie daher das table-header-Element (<th>) in Layout-Tabellen.
In modernen Intranet-Lösungen ist die Darstellung von Daten aus extern eingebundenen Applikationen oder Diensten oft mit einer Aufbereitung in Form von Datentabellen verbunden. Datentabellen präsentieren Informationen wie Kundendaten, Personalzahlen von Abteilungen eines Unternehmens oder Zugriffszahlen auf verschiedene Bereiche des Intranets.
Die Bedeutung der Daten in den einzelnen Zellen beruht dabei auf den Spalten- und Zeilenüberschriften, die gewöhnlich in der ersten Zeile oder Spalte definiert sind. Daher ist die Bedeutung eines Zellenwertes ohne Kenntnis der zugehörigen Spalten- und Zeilenüberschrift – etwa bei einer vorgelesenen, linearisierten Version – nicht verständlich.
(X)HTML bietet mehrere Sprachelemente, um Datentabellen auch für Anwender von Hilfsmitteln verständlich zu machen. Nutzen Sie diese Elemente, damit auch Anwender, die Tabellen nicht visuell sondern durch Hilfsmittel linearisiert wahrnehmen, die darin abgebildeten Zusammenhänge leichter verstehen können.
Die Grundlage der Kommunikation zwischen verschiedenen Datenquellen über ausgewiesene Schnittstellen bildet in modernen Intranet-Lösungen XML. Aus einem durch XML formatierten Datensatz ist es mit geringem Aufwand möglich, eine barrierefreie Datentabelle zu transformieren. Zur Transformation von XML-basierten Inhalten empfiehlt das W3C XSLT (Extensible Stylesheet Language Transformation), siehe auch [W3C-XSLT].
Eine Transformation über XSLT entspricht dabei einer Template-Architektur: Die in einer Quelldatei durch XML formatierten Daten werden in der zugehörigen Stylesheet-Datei durch Marker im (X)HTML-Quelltext positioniert.
Sie können sich bei der Entwicklung Ihres Transformations-Stylesheets an dem Leitfaden zum korrekten Aufbau barrierefreier Datentabellen orientieren.
Es kann auch sinnvoll sein, für Datentabellen leichter zugängliche und damit verständlichere, äquivalente Alternativen bereitzustellen, etwa in Form eines zusammenfassenden und ergänzenden Textes. Dies erfordert jedoch im Allgemeinen eine manuelle Bearbeitung und ist nicht automatisiert möglich.
Internetangebote müssen auch dann nutzbar sein, wenn der verwendete Benutzeragent neuere Technologien nicht unterstützt oder diese deaktiviert sind.
Vermeiden Sie in Ihren Inhalten Bezüge auf das Standard-Erscheinungsbild der Intranet-Seite, wie "…in der rechten Spalte…" oder "… der farblich hervorgehobene Menüpunkt…". Solche und ähnliche Angaben sind nur aussagekräftig, wenn der Anwender das Standard-Erscheinungsbild sieht oder es im Browser des Anwenders eingestellt ist.
Dies ist nicht gewährleistet, wenn ein Anwender die Interpretation des CSS der Intranet-Seite deaktiviert oder ein vom Standard abweichendes Anzeigegerät verwendet.
Viele moderne Intranets werden auch von Mitarbeitern im Außendienst zur Informationsbeschaffung genutzt, etwa per PDA. Die Darstellung des Intranets auf solchen Geräten mit vergleichsweise kleinen Anzeigebereichen (Viewport) ist völlig anders als auf einem Standard-PC-Bildschirm. Teilweise ist die Unterstützung von CSS in Browsern dieser Geräte unbefriedigend oder entspricht nicht dem Standard der PC-Versionen.
Vermeiden Sie in Inhalten die Verwendung von Skriptsprachen oder bieten Sie äquivalente Alternativen an, falls dies nicht möglich sein sollte. Ähnlich wie bei der oben beschriebenen Unabhängigkeit des Inhalts vom optischen Erscheinungsbild gilt auch bei der Anwendung von Skriptsprachen, dass nicht in allen Browsern eine Unterstützung zu Verfügung steht: Manche Anwender schalten Skriptsprachen in ihren Browsern aus oder ihre spezielle Hard- und Software (beispielsweise PDA) unterstützen die Ausführung nicht.
Auch viele Hilfsmittel – insbesondere Screenreader – haben im Umgang mit Skriptsprachen wie Javascript häufiger Probleme. Eine Bedienung von Intranet-Seiten, deren zentrale Funktionen (etwa die Navigation) ausschließlich als Skriptlösung realisiert sind, ist damit nicht möglich.
Zeitgesteuerte Änderungen des Inhalts müssen durch die Nutzerin, den Nutzer kontrollierbar sein.
Vermeiden Sie zeitverzögerte Weiterleitungen oder selbstständige Aktualisierungen des Inhalts ohne Zutun durch den Anwender.
Zeitverzögerte Weiterleitungen beabsichtigen zumeist, dass der Anwender eine bestimmte Information liest und anschließend automatisch eine andere Seite aufgerufen wird. Aufgrund verschiedener Lesegeschwindigkeiten der Anwender ist nicht gewährleistet, dass die zu lesende Information auch tatsächlich vollständig gelesen wird bevor die Weiterleitung einsetzt. Besser ist eine Zwischenseite, die erst nach expliziter Anforderung durch den Anwender (etwa durch Auswahl eines Hyperlinks) verlassen wird.
Aktualisierungen stellen insbesondere für Anwender von Screenreadern ein Problem dar, da sie das Vorlesen von Seiten stören können, selbst wenn sich visuell nichts oder nur Kleinigkeiten verändern. Denn selbst wenn nur Teile einer Seite neu geladen wurden, kann ein Screenreader unter Umständen damit nicht umgehen und beginnt bei jeder Aktualisierung von neuem mit dem Vorlesen am Anfang der Seite.
Vermeiden Sie es, Informationen zeitgesteuert, etwa in Form von Laufschriften oder Nachrichten-Tickern, zu vermitteln. Sollte dies nicht möglich sein, so bieten Sie eine äquivalente, zeitunabhängige Darstellungsart, die sich nur nach ausdrücklicher Anforderung durch den Nutzer aktualisiert.
Laufschriften und sich selbst aktualisierende Nachrichten-Ticker bilden zwar die klassische Darstellung von Nachrichten oder Börsenkursen anschaulich im Intranet ab. Sie können aber behinderte wie auch nicht behinderte Mitarbeiter verwirren und die Bedienung der Intranet-Seite erschweren und die Konzentration auf wesentliche Inhalte erschweren.
Nicht behinderte Mitarbeiter können eine für sie relevante Information verpassen, weil sie gerade einen anderen Bereich der Seite betrachten und müssen im Anschluss warten, bis die Information wiederholt ausgegeben wird.
Ähnlich geht es behinderten Mitarbeitern: Der Screenreader eines blinden oder stark sehbehinderten Mitarbeiters kann das der Darstellungsform zugrunde liegende Skript eventuell nicht verarbeiten und für den Anwender wiedergeben. Manuell-motorisch eingeschränkte Nutzer gelingt es möglicherweise nicht, den Fokus ausreichend schnell auf den zeitgesteuerten Inhalt zu wechseln. Menschen mit Lese-Rechtschreib-Schwäche können den Inhalt von sich schnell ändernden Texten nur schwer begreifen.
Vermeiden Sie blinkende Elemente wie Grafiken oder Schriften. Viele Benutzer haben Schwierigkeiten solche Inhalte zu erfassen und sie erschweren die Konzentration. Menschen mit fotosensitiver Epilepsie können bereits bei geringen Bildwechselraten einen Anfall erleiden.
Die direkte Zugänglichkeit der in Internetangeboten eingebetteten Benutzerschnittstellen ist sicherzustellen.
In modernen Intranet-Lösungen wird eine Vielzahl von programmierten (proprietären) Objekten verwendet.
Dazu zählen komplexe Systeme zur Authentifizierung (etwa biometrische Verfahren) und Autorisierung, die dem eigentlichen Intranet vorgeschaltet sind. Da für die Bedienung des Intranets eine erfolgreiche Authentifizierung erforderlich ist, sollte auch die dazu genutzte Soft- und Hardware barrierefrei sein.
Insbesondere biometrische Verfahren stellen oftmals eine Barriere dar. Empfehlenswert sind Token-Systeme, die auf Basis von Scheckkarten oder USB-Sticks funktionieren. Leistungsfähige Systeme unterstützen damit bei entsprechender Konfiguration auch einen Fernzugriff auf das Intranet. Viele Menschen mit Behinderungen schätzen die einfache Bedienung von Token-Systemen. Testen Sie Ihre Authentifizierungssysteme unabhängig von der zugrunde liegenden Technologie vor dem produktiven Einsatz mit Ihren Mitarbeitern. Ein weiteres Einsatzgebiet programmierter Objekte sind autorenunterstützende Werkzeuge zur Erstellung von Intranet-Inhalten. Auch diese Instrumente sollten barrierefrei bedienbar sein oder es sollte eine äquivalente barrierefreie Version angeboten werden.
Neben der barrierefreien Bedienung der Editoren ist auch der damit produzierte Quellcode auf seine Zugänglichkeit zu prüfen.
Editoren sollten den Autor auf grundlegende Verstöße gegen barrierefreie Inhalte hinweisen, wie fehlende Alternativ-Texte bei Grafiken, und gegebenenfalls eine Korrektur vorschlagen. Wünschenswert wären darüber hinaus gehende, automatische Verbesserungen der Zugänglichkeit, wie die Möglichkeit zur Angabe einer ausführlichen Beschreibung einer Grafik ("longdesc") und die automatische Verknüpfung der Grafik dazu im produzierten Quelltext (siehe auch ) Alternativen für grafische Inhalte.
Vermeiden Sie es, programmierte Objekte ausschließlich für einen speziellen Browser zu implementieren oder optimieren (beispielsweise Active-X-basierte Editoren für den Internet Explorer). Auch wenn die Client-PCs innerhalb des Intranets über eine standardisierte Software-Ausstattung verfügen, sollten auch Mitarbeiter, die im Außendienst per Handheld das Intranet nutzen, die Dienste und Applikationen verwenden können.
Moderne Intranets werden für ihre Anwender immer stärker individualisierbar. Diese Intranet-Lösungen werden auch als Mitarbeiterportale bezeichnet. In einem Mitarbeiterportal werden Informationen, Kommunikation und Applikationen auf einer einheitlichen Web-Oberfläche gebündelt.
Jeder Mitarbeiter ist dazu in der Lage, die zur Erfüllung seiner Aufgaben relevanten Funktionen und Dienste (Module) des Intranets individuell ein- oder auszublenden. Der Anwender kann sich somit einen personalisierten, virtuellen Arbeitsplatz selbstständig einrichten.
Stellen Sie durch eine geeignete technische Realisierung sicher, dass das Zusammenstellen des virtuellen Arbeitsplatzes auch für Mitarbeiter mit Behinderungen möglich ist. Vermeiden Sie daher zum Beispiel auf Ajax-Technologie basierende "Drag&Drop"-Realisierungen zur Positionierung und Auswahl anzuzeigender Arbeitsplatzmodule. Implementierungen dieser Art erfordern die (möglicherweise sehr genaue) Bedienung einer Maus und schließen reine Tastaturnutzer damit aus.
Verwenden Sie stattdessen barrierefreie Formulare mit Standard-(X)HTML-Formularelementen. Bieten Sie beispielsweise alle zu Verfügung stehenden Module in Form einer Liste an und ergänzen Sie jeden Listeneintrag um einen Schalter "sichtbar" oder "unsichtbar" und eine Auswahlliste zur Bestimmung der Position (etwa. "Position 1", "Position2"). Durch ausfüllen des Formulars kann sich so jeder Mitarbeiter individuell seine Umgebung zusammenstellen.
Gewährleisten Sie, dass alle Dienstprogramme, die Sie im Rahmen Ihres Mitarbeiterportals anbieten, barrierefrei bedienbar sind. Beachten Sie in diesem Zusammenhang auch die von IBM veröffentlichten Richtlinien für barrierefreie Software.
Internetangebote sind so zu gestalten, dass Funktionen unabhängig vom Eingabegerät oder Ausgabegerät nutzbar sind.
Gewährleisten Sie, dass alle Bedienelemente Ihres Intranets auch ohne Einsatz der Maus bedienbar sind. Dazu gehören die Navigation, Formulare und andere Elemente, die durch den Nutzer verändert und bedient werden können.
Sorgen Sie durch entsprechende Stil-Definitionen dafür, dass Hyperlinks bei Tastaturbedienung einen gut erkennbaren Fokuszeiger aufweisen. Vermeiden Sie es, den Fokus nur durch ein a:hover für die Maus anzugeben. Denselben Effekt können Sie auch bei Tastaturnutzung oder Verwendung der Tabulator-Taste erzeugen. Beachten Sie dabei die Reihenfolge der Pseudoelemente, damit die Darstellung auch im Internet Explorer > Version 6 korrekt ist. Das folgende Beispiel demonstriert die korrekte Reihenfolge a:link, a:visited, a:focus, a:hover und a:active (lvfha oder "Lord Vaders Former Handle Anakin").
a:link, a:visited{
color:#4C53E0;
}
a:focus, a:hover, a:active {
color:#EB8518;
}
Um Anwender, die per Tabulator-Taste auf einer Seite navigieren, nicht zu verwirren, sollten die Hyperlinks einer Intranet-Seite in einer intuitiv nachvollziehbaren Reihenfolge erreicht werden. Üblich ist die Reihenfolge von links nach rechts oder von oben nach unten. Die Tabulator-Reihenfolge leitet sich aus der Position des auswählbaren Elements im (X)HTML-Quelltext ab. Stellen Sie daher Teile Ihres (X)HTML-Quelltextes um oder ändern Sie Ihre CSS-Definitionen, um eine nachvollziehbare Reihenfolge zu erzielen.
Die Verwendbarkeit von nicht mehr dem jeweils aktuellen Stand der Technik entsprechenden assistiven Technologien und Browsern ist sicherzustellen, so weit der hiermit verbundene Aufwand nicht unverhältnismäßig ist.
(In der Begründung zur Rechtsverordnung der Barrierefreien Informationstechnik-Verordnung (BITV) wird unter "Paragraf 3: Anzuwendende Standards" genauer angegeben, was mit "unverhältnismäßig", "hoher Aufwand", "bestem Bemühen" und Ähnlichem gemeint ist. Insbesondere wird in dieser Begründung deutlich gemacht, dass "Nur-Text-Seiten" keine wünschenswerte Lösung darstellen; siehe auch Anforderungen und Bedingungen 6.5 und 11.3).
Viele Nutzer werden durch das Öffnen neuer Fenster in ihrer Orientierung verwirrt. Ältere Hilfsmittel für blinde und stark sehbehinderte Anwender haben zum Teil Probleme mit neu erscheinenden Fenstern und geben im Folgenden fehlerhafte Informationen an den Nutzer aus.
Die Nutzer bemerken möglicherweise nicht, dass ein neues Fenster geöffnet wurde und verlieren den Überblick. Bei zahlreichen parallel geöffneten Fenstern ist die Gefahr groß, dass versehentlich das falsche Fenster geschlossen wird und somit die History verloren geht. Vermeiden Sie es, Hyperlinks in neuen Fenstern zu öffnen, wenn dies nicht unbedingt erforderlich ist. Entwickeln Sie für von Autoren verfasste Texte eine Logik, die das Dokument analysiert, das Öffnen eines neuen Fensters erkennt und den Leser darauf hinweist. Dies kann durch "Link öffnet in neuem Fenster" als Ergänzung des Linktextes oder durch eine entsprechende Grafik (zum Beispiel Pfeilgrafiken 
) erfolgen.
Die Beschriftung von Formularelementen sollte vor – also über oder links neben – dem zugehörigen Formularelement stehen. Nur die Beschriftung von Radiobuttons und Checkboxen sollte rechts neben dem Formularelement stehen.
Nur wenn dieses Gestaltungsschema eingehalten wird, ist gewährleistet, dass die Bedienung auch von Anwendern, die ältere Hilfsmittel einsetzen, fehlerfrei gelingt. Screenreader verbinden nach festen Regeln die Beschriftungen mit den zugehörigen Eingabefeldern. Auch sehende Nutzer sind dieses Schema gewohnt. Eine Abweichung davon könnte Anwender daher verwirren und die Bedienung des Formulars unnötig erschweren.
Beachten Sie ergänzend die Hinweise zur Verknüpfung des Beschriftungstextes mit dem zugehörigen Formularelement per <label>.
Die zur Erstellung des Internetangebots verwendeten Technologien sollen öffentlich zugänglich und vollständig dokumentiert sein, wie z.B. die vom World Wide Web Consortium entwickelten Technologien.
Achten Sie bei der Entwicklung proprietärer Dokumentenformate darauf, dass Dokumente in diesen Formaten zugänglich sind. Testen Sie neu entwickelte Formate und die zur Anzeige benötigten Applikationen mit Anwendern und verwendeten Hilfsmitteln.
Stellen Sie Autoren die Information zu Verfügung, welche von XHTML abweichenden Dokumentenformate als "zugänglich" bewertet wurden. Schließen Sie mit geeigneten Mitteln die Verwendung anderer Formate in den durch die Autoren produzierten Inhalten aus.
Stellen Sie sicher, dass alle Anwender des Intranets die zur Anzeige des Dokumentenformats benötigten Applikationen oder Plugins auf ihren PCs installiert haben. Viele Intranets verwenden zu diesem Zweck Installations-Dienste. Diese Dienste prüfen bei der Anmeldung des Nutzers die aktuelle Software-Konstellation gemäß einer oder mehreren Richtlinien und installieren gegebenenfalls fehlende Komponenten von einem Server nach. Dieses Vorgehen gewährleistet eine einheitliche Software-Ausstattung auf allen PCs.
Vermeiden Sie es, Elemente und Attribute, die in HTML Version 4.01 als überholt (deprecated) definiert sind, zu verwenden. Dazu gehört beispielsweise das font-Element.
Die Definition von HTML 4.0.1 zielt auf eine klare Trennung zwischen Inhalt und Layout ab. Die Einhaltung dieses Prinzips hilft dabei, Probleme im Zusammenspiel mit assistiven Technologien zu vermeiden. Ein Tool zur Prüfung (bookmarklet) auf veraltete Elemente wird unter http://bitvtest.de/werkzeugliste.php/#deprecated angeboten.
Intranetangebote sollten für alle Mitarbeiter zugänglich gestaltet sein. Spezielle Versionen für behinderte Mitarbeiter (etwa Textversionen) widersprechen der Definition von Gleichstellung im Sinne des Gleichstellungsgesetzes.
Nur ein universelles Design kann die Bedürfnisse aller Mitarbeiter erfüllen, ohne dass "Sonderlösungen" notwendig sind. So kann eine spezielle Textversion zwar für Blinde, die einen Screenreader verwenden, hilfreich sein. Ältere Mitarbeiter, die eine große Schrift benötigen oder mit der Bedienung der Maus Schwierigkeiten haben, können dennoch auf Barrieren - etwa fixe Schriftgrößen - stoßen.
Der Nutzerin, dem Nutzer sind Informationen zum Kontext und zur Orientierung bereitzustellen.
Frame-basierte Seiten bereiten Menschen, die Inhalte über Hilfsmittel wahrnehmen, oftmals Schwierigkeiten. Sie nehmen möglicherweise die Veränderung in einem anderen Frame als dem, in dem sie eine Aktion durchführen ( etwa Klick auf Hyperlink), nicht wahr. Vermeiden Sie daher eine Intranet-Lösung, die Frames verwendet.
Sollte die Verwendung von Frames dennoch notwendig sein, achten Sie darauf, die für das Verständnis der einzelnen Frames relevanten Attribute (title und name) mit sinnvollen und verständlichen Werten zu belegen. Textbrowser und Screenreader werten diese Informationen aus und ermöglichen damit dem Nutzer zu identifizieren, welcher Frame welche Funktion besitzt. Die Angabe title="links" für einen links erscheinenden Frame ermöglicht keine Rückschlüsse auf dessen Funktion, besser ist title="Navigation".
Unterteilen Sie große Informationsblöcke durch passende HTML-Strukturelemente in mehrere kleinere Abschnitte. Mit Blöcken sind im Kontext der Erstellung eines Templates die funktionalen Bereiche der Webseite gemeint. Dazu gehören typischerweise ein Kopf-, ein Navigations-, ein (Haupt-)Inhalts- und ein Fußbereich. Durch entsprechende DIV-Container können diese Bereiche realisiert werden.
Auch Gruppen von Formularelementen in umfangreichen Formularen können mit den XHTML-Strukturelementen in kleinere Einheiten unterteilt werden (fieldset mit legend-Beschriftungen).
Eine Strukturierung oder Gruppierung erleichtert vielen Anwendern das Verständnis. Darüber hinaus ermöglicht es eine schnelle Navigation innerhalb der Intranetseite und beschleunigt das Auffinden gesuchter Informationen. Besonders Anwender, die assistive Technologien wie Screenreader einsetzen, können davon profitieren, da sie sich oftmals von Überschrift zu Überschrift und Absatz zu Absatz bewegen.
Die Verwendung passender HTML-Strukturelemente erzielt eine von der Präsentation unabhängige semantische Struktur. Dies gewährleistet, dass auch Anwender, die die visuelle Standard-Präsentation nicht verwenden, diese Struktur wahrnehmen können.
Die Beschriftung von Formularelementen sollte nicht nur optisch, sondern auch logisch über das Element <label> definiert werden. Die logische Verknüpfung über Label ermöglicht Anwendern durch einen Klick auf die Beschriftung die Eingabemaske auf das zugehörige Formularelement zu setzen und dort direkt Eingaben vorzunehmen. Davon profitieren insbesondere Menschen mit manuell-motorischen Einschränkungen, die über eine geringe Feinmotorik verfügen, aber dennoch die Maus zur Navigation benutzen: Zum Setzen eines Häkchens in einer Checkbox ist es nicht erforderlich, die Checkbox zu treffen; ein Klick auf die Beschriftung reicht bereits aus.
Navigationsmechanismen sind übersichtlich und schlüssig zu gestalten.
Vermeiden Sie gleich lautende Linktext-Phrasen wie "hier klicken" oder "mehr". Blinde Nutzer verwenden Linktexte oft, um einen schnellen Überblick über eine Seite zu erlangen. Dieses Vorgehen ermöglicht ihnen, sich auch auf ansonsten schlecht zugänglichen Seiten zumindest grob zu orientieren. Ist aber eine Vielzahl der Linktexte identisch, funktioniert das nicht. Geben Sie daher eine Information zum Linkziel an.
Verwenden Sie bei der in modernen Intranets populären Blog-Struktur für den "Weiterlesen"-Link den Titel des jeweiligen Artikels. Ein Artikel mit dem Titel "XY" erhält somit einen Link in der Form "XY lesen".
Weisen Sie auf das Dateiformat eines Linkziels hin, falls es von HTML abweicht, etwa bei einem Verweis auf ein PDF-Dokument. Das ist erforderlich, um Verwirrung beim Anwender zu vermeiden, etwa weil das zur Anzeige des Linkziels benötigte Programm oder Plugin nicht auf dem Zielrechner installiert ist. Weiß der Anwender vorher, auf welches Dateiformat der Link verweist, kann er prüfen oder entscheiden, ob die benötigte Software vorhanden ist.
Besonders relevant ist die Angabe des Dateiformats für Anwender, die assistive Technologien einsetzen. Manche Programme arbeiten nur eingeschränkt oder gar nicht mit Hilfsmitteln zusammen und einige Dateiformate (insbesondere proprietäre) sind nicht oder nur schlecht zugänglich.
Vergeben Sie sinnvolle Dokumenttitel nach einem Schema mit einem statischen und einem individuellen seitenspezifischen Teil. Der Seitentitel ist die erste Information zu einer Seite, die ein Screenreader an den Anwender ausgibt. Er stellt also eine wichtige Information über die Relevanz einer Seite für den Anwender dar.
Daneben wird der Dokumenttitel beim Ablegen eines Lesezeichens in der Lesezeichenliste angezeigt. Werden viele Funktionen im Intranet realisiert und werden zu den einzelnen Funktionen Lesezeichen angelegt, hilft eine individuelle Bezeichnung bei der Identifikation der einzelnen Seite und der dort angebotenen Dienste.
Implementieren Sie in Ihrer Intranet-Software eine automatisierte Generierung eines sinnvollen Seitentitels. Das ermöglicht ein einheitliches Schema für den gesamten Intranet-Auftritt und verhindert durch die Autoren erstellte, individuelle Seitentitel.
Viele Intranets erhalten – zur Steigerung der Akzeptanz unter den Mitarbeitern – einen Namen. Verwenden Sie diesen Namen für den statischen Teil Ihres Dokumenttitels oder alternativ "Intranet" falls kein solcher Name existiert.
Für den zweiten, seitenspezifischen Teil des Dokumenttitels bietet sich die Überschrift des in der Intranetseite enthaltenen Textes (beispielsweise "Quartalsbericht 1-2008") oder der Funktion (zum Beispiel "Reservierung eines Konferenzraums") der Seite an.
Bieten Sie den Autoren über den eingesetzten Editor die Möglichkeit, ihre Inhalte um Metainformationen zu ergänzen. Pflegen Sie diese Informationen in den Dokumentenkopf der generierten (X)HTML-Dokumente ein. Sie ermöglichen Besuchern, weitere Informationen über das Dokument zu erlangen und erleichtern das Durchsuchen über eine Intranet-weite Suchfunktion. Zu den Informationen zählen beispielsweise Angaben zum Autor, zum Erstellungsdatum, das Datum der letzten Änderung und Stichwörter.
Anwender können auf Basis dieser Informationen Rückschlüsse auf die Aktualität und Relevanz der auf der Seite enthaltenen Inhalte ziehen.
Bieten Sie Orientierungshilfen, etwa in Form von Übersichtsseiten über die zentralen Informationen Ihrer Inhalte, an.
Gängige Intranet-Lösungen erlauben die automatisierte und dynamische Generierung von Übersichtsseiten (Sitemaps). Üblicherweise wird dabei die Navigationsstruktur bis zu einer definierten Tiefe in eine Liste abgebildet. Jeder Listeneintrag ist mit dem entsprechenden Menüpunkt im Intranet verknüpft und ermöglicht somit eine schnelle Navigation.
Als weitere Orientierungshilfe wird eine Brotkrumen-Navigation empfohlen. Diese Navigation umfasst den Pfad von der Startseite des Intranets zu der aktuell betrachteten Seite. Jeder Bestandteil des Pfades ist dabei mit der zugehörigen Navigationsebene verknüpft und ermöglicht damit neben der Orientierung auch die Navigation über verschiedene Ebenen hinweg.
Die Navigation Ihres Intranets sollte sich an den gängigen Konventionen aus dem Web orientieren und einheitlich sein. Eine einheitliche Navigation verhindert Irritationen der Nutzer und erleichtert die Bedienung.
Nutzer erwarten die Navigation optisch am linken Rand der Anzeige, die linke obere Ecke sollte einen Verweis zur Startseite enthalten.
Das allgemeine Verständnis der angebotenen Inhalte ist durch angemessene Maßnahmen zu fördern.
In Intranets wird gewöhnlich ein unternehmensspezifisches Vokabular (beispielsweise bestimmte Ausdrücke und Abkürzungen) verwendet. Dies erschwert das Textverständnis für neue Mitarbeiter, die mit den Interna noch nicht gut vertraut sind. Menschen mit Lese-Rechtschreib-Schwäche haben Schwierigkeiten, komplizierte Ausdrucksweisen und lange, verschachtelte Sätze zu verstehen.
In multi- oder internationalen Intranets müssen Mitarbeiter oftmals fremdsprachige Informationen aufnehmen und verstehen. In diesen Fällen stoßen auch Mitarbeiter, deren Muttersprache eine andere als die Primärsprache ist, auf Verständnisschwierigkeiten.
Stellen Sie daher durch geeignete Werkzeuge sicher, dass die Inhalte Ihres Intranets leicht und korrekt verstanden werden können. Moderne Intranet-Lösungen bieten zu diesem Zweck Wikis und Glossare an. Diese Tools parsen automatisiert den darzustellenden Text auf Ausdrücke oder Worte, zu denen im Datenbestand Definitionen oder Erklärungen existieren und verknüpfen sie über Hyperlinks damit.
Die Verwendung von Wikis und manchen Glossaren bieten durch den nutzerorientierten Ansatz zum Aufbau des Datenbestandes zwei Vorteile: Da die Anwender gleichzeitig Konsumenten und Produzenten sind, ist eine hohe Qualität der Erklärungen gegeben. Die Nutzer selbst können am besten einschätzen, welche Ausdrücke für sie in der Vergangenheit problematisch waren und für neue Kollegen zukünftig sicher sein werden.
Den zweiten Vorteil stellen die geringen Investitionen für Aufbau und Betrieb dar: Die Installation ist einfach und schnell erledigt und da die Nutzer des Intranets den Bestand selber pflegen, ist dazu kein separates Personal notwendig.
alt-Attribut versehen werden. Für Autoren sollte die Angabe eines Alternativ-Textes bei Verwendung von Grafiken in ihren Inhalten obligatorisch sein. Bieten Sie darüber hinaus im Editor die optionale Verwendung des longdesc-Attributs an. Weisen Sie Autoren bei eingebetteten multimedialen Inhalten (Webcasts) auf die barrierefreie Bedienbarkeit des benötigten Wiedergabeprogramms und die Notwendigkeit einer Transkription hin. Bieten Sie darüber hinaus eine (automatisierte) Option zum Download des Mediums, um es dem Betrachter zu überlassen, mit welchen Abspielprogramm es wiedergegeben werden soll.em). Nutzen Sie auch für Ihre Schriftgrößen-Definitionen relative Werte, damit auch Anwender des Internet Explorer ihre Schriftgröße individuell einstellen können. Gestalten Sie die Ausgaben angebundener Dienste und Applikationen barrierefrei. Überarbeiten Sie dazu die Formatstruktur der Daten.html-Element an. Nur so ist es für Sprachausgaben möglich, die korrekte Sprach-Bibliothek zu laden. Verwenden Sie dazu das universelle lang-Attribut in der Form und bei XHTML-Seiten das XML-Äquivalent xml:lang="Kürzel nach ISO 639-1". Bieten Sie Ihren Autoren in dem genutzten Editor die Möglichkeit, Abweichungen von der Hauptsprache korrekt auszuzeichnen.<label>-Element den Eingabefeldern zugeordnet sein. Eine Plausibilitätsprüfung sollte Fehleingaben der Nutzer abfangen und über gut verständliche Meldungen darauf hinweisen. Usability im Kontext von Internet und Intranet:
Aufbau eines Intranets
Umfragen zum Thema Intranet
Zugänglichkeit, Barrierefreiheit beim W3C
http://www.w3.org/TR/wai-aria/, zuletzt besucht am 26.06.2008.Standards
http://www.loc.gov/standards/iso639-2/php/English_list.php, zuletzt besucht am 08.08.2008 http://www.w3.org/AudioVideo/, zuletzt besucht am 21.08.2008 http://www.w3.org/TR/xslt.html, zuletzt besucht am 28.08.2008Tutoriale
http://www.jimthatcher.com/webcourse9.htm, zuletzt besucht am 11.08.2008