Archiv der Kategorie: Accessibility – Zugänglichkeit

Als Accessibility (deutsch Zugänglichkeit) bezeichnet man das Fehlen von Barrieren, die die Benutzung von Webseiten erschweren oder sogar unmöglich machen. Das gilt insbesondere für Menschen mit Behinderungen oder für Situationen, in denen die Bedienung von Webseiten erschwert ist (z. B. bei wechselnden Lichtverhältnissen, Lärm oder Rütteln, wie in einem fahrenden Bus).

Webseiten zum anhören: Tipps für die Sprachausgabe

Lesen lassen – nicht nur für Blinde eine Hilfe

Webseiten sind in den meisten Fällen mit viel Aufwand optisch ansprechend gestaltet. Sie lassen sich heute in der Regel sowohl an einem großen Bildschirm, als auch auf dem kleinen Smartphone-Display bequem betrachten und bedienen.

Aber habe Sie sich Ihre Webseite schon einmal vorlesen lassen? Zwar sind die Computerstimmen nicht so nett anzuhören, wie ein Mensch, aber es wurde eine Menge Aufwand in die einzelnen Systeme gesteckt, damit die Sprache weitgehend natürlich klingt. Na ja, das klappt nicht hundertprozentig, aber heutige Vorleseautomaten sind einwandfrei zu verstehen. Wenn man seine Hände frei haben möchte, ist das Hören einer Webseite – insbesondere bei einem längeren Text – eine nicht zu verachtende Alternative zum Selberlesen.

Safari im Lesemodus mit aktivierter Vorlesefunktion

Besonders gut ist das auf iOS-Geräten umgesetzt. In den Bedienungshilfen lässt sich aktivieren, dass eine Seite vorgelesen werden soll, wenn man mit zwei Fingern von oben nach unten streicht. Dann erscheint auch ein kleiner Player, mit dem man die Geschwindigkeit bestimmen und das Vorlesen pausieren kann. Der Browser Safari bietet darüber hinaus einen Lesemodus, der sich aktivieren lässt, indem man in der Adressleiste des Browsers auf ein Text-Symbol klickt, ähnlich dem Symbol für linksbündigen Text in einer Textverarbeitung wie Word.

Dann werden Navigation, Kopf- und Fußbereich und Werbung ausgeblendet und gezeigt wird nur noch der Hauptinhalt der geöffneten Seite. Sehr angenehm zu lesen (Einstellungen zu Schriftgröße, Darstellung usw lassen sich auf die persönlichen Wünsche abstimmen).

Diese Darstellung ist aber auch sehr gut geeignet, um vorgelesen zu werden.

Wenn Sie die Seite nicht nur lesen möchten, sondern auch mit ihr interagieren wollen, ist der Lesemodus natürlich nicht geeignet, denn ohne Links und Schlatflächen, keine Interaktion.

Mit einer freien Hand beim Essen oder Kaffetrinken, kann man sich per Tastatur durch die Webseite bewegen. Mit der Tabulator-Taste beispielsweise springt man von Link zu Link.

In vielen Situationen ist das eine echte Hilfe. Noch freier wird man in der Bedienung, wenn man nicht ständig auf den Bildschirm schauen muss. Dazu benötigt man eine Sprachausgabe. Auch diese ist in iOS bereits integriert (in Android auch, aber als Apple-User kann ich zur Bedienung wenig sagen – auch unter Windows und Windows für mobile Geräte wird es sicher so etwas geben).

Manche von uns sind sogar auf die Bedienbarkeit ohne Bildschirm angewiesen, weil sie nicht oder so schlecht sehen, dass die Seite auch ohne Bild funktionieren muss, um von ihnen bedient werden zu können.

Auf vielen modernen Webseiten gehrt das schon ganz gut, weil diese meistens einige wichtige Aspekte beachten. Sonst würden auch so Dinge wie der Lesemodus von Apple nicht funktionieren.

Um Blinde so zu unterstützen, dass eine Webseite nicht nur irgendwie vorgelesen wird, sondern auch noch ein komfortabel zu bedienen ist, braucht es dann noch ein bisschen mehr. Man kann exklusiv für die Nutzer von Screenreadern mit mehreren Methoden Hinweise geben, die das Layout der Seite für Sehende nicht „stören“, weil sie nicht angezeigt werden.

So ist es beispielsweise eine große Hilfe, wenn die einzelnen Bereiche einer Webseite mit Überschriften versehen sind. Haben Hauptnavigation, Inhaltsbereich, Seitenleiste und Fußbereich sinnvolle Überschriften, wissen Blinde, die von Überschrift zu Überschrift navigieren können, auf Anhieb, wo sie sich innerhalb einer Seite befinden.

Sinnvolle Überschriften wären beispielsweise

  • „Navigation“ für die Hauptnavigation,
  • die Artikelüberschrift für den Hauptbereich (möglichst identisch mit dem Titel der Seite und mit den Links, die auf diese Seite führen),
  • „Weiterführende Informationen“ für die Seitenleiste und
  • „Über diese Webseite“ für den Fußbereich, der in der Regel Copyright-Hinweis, Kontakt-Adresse des Betreibers u.ä. enthält

Anhand der Positionierung und des Layouts sollten alle diese Bereiche auf den ersten Blick für sehende Besucher erkennbar sein. Man ist gewohnt, die Navigation oben oder links zu finden und weiß, wie die ungefähr gestaltet ist (ein zusammengehöriger Block mit einer Liste von Links – oft fahren Unterpunkte bei Berührung mit der Maus oder Touch-Kontakt aus).

Also benötigen Sehende diese Informationen in der Regel nicht. Es gibt nämlich Ausnahmen – haben Sie sich mal eine komplexe Webseite ohne Layout angeschaut? – Sicher haben Sie so etwas schon mal gesehen, weil hin und wieder kommt es bei der einen oder anderen Seite zu so einem Fehler, weil ein Entwickler sich vertan hat, im Server etwas falsch konfiguriert ist oder bei der Übertragung etwas schief gelaufen ist. Die Formate (CSS) lassen sich aber auch vom Besucher gezielt ausschalten oder durch eigene Formatierungen ersetzen. In diesen Fällen ist nicht mehr sichergestellt,  dass die geannnten Bereiche auf Anhieb erkannt werden.

Darum ist es sinnvoll, die Überschriften der Seite nur dann auszublenden, wenn das Original-Autoren-Stylesheet des Seitenbetreibers verwendet wird.

Das geht recht einfach: die nicht anzuzeigenden Inhalte sollen vorgelesen werden, aber nicht zu sehen sein. Screenreadern (und Blinden) ist es egal, ob ein Text in ein Element hinein passt oder ob es sich außerhalb des sichtbaren Bereiches befindet. Wenn die entsprechende Stelle im Quelltext „an der Reihe ist“, vorgelesen zu werden, gibt das Vorleseprogramm den Text aus.

Also sorgen Sie dafür, dass solche Texte per CSS aus dem sichtbaren Bereich verschoben werden. Klingt einfacher, als es ist, damit es auch in allen Browsern und Screenreader-Kombinationen funktioniert (siehe auch Diskussion unter https://github.com/h5bp/html5-boilerplate/issues/194/). Ich benutze die Lösung von HTML5 Boilerplate (die diverse Vorläufer hat) seit Jahren ohne Probleme. Sie funktioniert wie folgt:

HTML

<h2 class="visuallyhidden">Navigation</h2>

CSS

.visuallyhidden {
  border: 0;
  clip: rect(0 0 0 0);
  height: 1px;
  margin: -1px;
  overflow: hidden;
  padding: 0;
  position: absolute;
  width: 1px;
}

Auf diese Weise verstecken Sie Elemente vor Sehenden, sorgen aber dafür, dass diese zugänglich sind, wenn Ihre Webseite mit einem Screenreader besucht wird oder Ihre Styles vom Besucher nicht genutzt werden.

Bilder für blinde Hörer beschreiben

Wichtige Informationen zu Bildern, die Sie exklusiv für Nutzer von Screenreadern mitgeben wollen, schreiben Sie in das alt-Attribut des Bildes:

<figure>
  <img alt="Lachendes Mädchen schaut in einen blauen Sommerhimmel" src="Sommer.jpg">
  <figcaption>Auch das Wetter hat bei unserem Urlaub mitgespielt</figcaption>
</figure>

Beachten Sie, dass der Alternativ-Text keine Wiederholung der Bildbeschreibung ist. Der Alternativ-Text informiert zusätzlich über das Motiv und die Stimmung des Bildes.

Nerven Sie Blinde nicht, indem Sie eine Visitenkarte basteln, die mit Max Muster überschrieben ist, dann Vorname: Max, Name: Muster enthält, daneben ein Bild mit der Beschreibung (figcaption) Porträt von Max Muster und demselben Text nochmal im alt– und title-Attribut.

Zusätzlicher Nutzen: steht ein Bild mal nicht zur Verfügung, wird statt des Bildes der alternativ-Text angezeigt (darum heißt der auch so). Gründe für das Fehlen von Bildern sind zahlreich, z.B.:

  • ein Entwickler hat einen Fehler gemacht (z.B. falscher Dateipfad)
  • bei der Übertragung ist etwas schief gegangen
  • das Bild stammt liegt nicht auf dem Server, die das HTML-Dokument und obwohl das HTML-Dokument erreichbar ist, ist der Bilderserver nicht erreichbar
  • das Bild liegt in einer Datenbank, die gerade nicht funktioniert
  • der Besucher Ihrer Webseite ist eine Suchmaschine
  • der Besucher Ihrer Webseite ist im Ausland und kann oder will sich die hohen Kosten für den Download der Bilder nicht leisten oder
  • hat die Darstellung aus anderen Gründen abgeschaltet (beispielsweise um Werbebildchen zu entgehen und so das Laden von Webseiten zu beschleunigen)

Mehr Möglichkeiten mit WAI-ARIA

Wenn es mal nötig und unumgänglich ist, den Sehenden noch einmal denselben Text zu präsentieren, den Sie bereits im alt-Attribut verwendet haben, gibt es eine Wunderwaffe für Barrierefreiheit: WAI-ARIA.

Damit können Sie insbesondere Screenreader-Nutzer über zahlreiche Dinge informieren (z.B. ob ein Untermenü aufgeklappt ist oder nicht). Mit dem Attribut aria-hidden haben Sie aber auch die Möglichkeit, das Vorlesen eines bestimmten Textes zu verhindern:

<p aria-hidden="true">Dieser Text ist sichtbar, wird aber von Screenreadern nicht vorgelesen.</p>

Über WAI-ARIA werde ich sicher in Zukunft noch eine Artikel schreiben – ein weites Feld, das eine genauere Betrachtung verdient.

An dieser Stelle möchte ich noch auf den Artikel von Jan Eric Hellbusch zu alternativ-Texten für Bilder hinweisen, die für Screenreader-Nutzer nicht unbedingt identisch mit dem alt-Attribut sind.

Längere Beschreibungen können Sie einem Element zuweisen, indem Sie einen Text, den Sie schon geschrieben haben (z. B. ein Hinweis in einem aside-Element) in einen logischen Bezug mit dem zu beschreibenden Element setzen.

Diesen Bezug stellen Sie über eine ID her. Das heißt, Sie geben dem informativen Text eine ID und verknüpfen diesen Text, mit dem Element, das beschrieben werden soll mittels aria-describedby:

HTML

<figure>
 <img
    alt="Lachendes Mädchen schaut in einen blauen Sommerhimmel"
    src="Sommer.jpg"
    aria-describedby="bildbeschreibung">
 <figcaption>Auch das Wetter hat bei unserem Urlaub mitgespielt</figcaption>
</figure>
<aside id="bildbeschreibung">Länger Text Lorem ipsum....</aside>

Wo bin ich?  Orientierung geben mittels aria-current

Ein sehr wichtiger Hinweis für Menschen, ist die Angabe des aktuellen Ortes oder auch einer Zeit – beispielsweise „heute“ in einem Kalender. Mit dem Attribut ariacurrent können Sie genau diese Information Blinden mitgeben. Es dient dazu ein Element aus einer Liste von Elementen als „das Aktuelle“ zu markieren. Das kann zum Beispiel der Eintrag in der Hauptnavigation sein, der auf die aktuell geöffnete Seite verweist oder eben „heute“ in einem Kalender. Dazu sind entsprechende Werte erlaubt:

  • page (Aktuelle Seite)
  • step (z.B. In einem Bestellprozess)
  • location (z.B. der aktuelle Aufenthaltsort auf einer Reiseroute)
  • date (z.B. Heute im Kalender)
  • time (z.B. die aktuelle Uhrzeit in einem Veranstaltungsprogramm)
  • true (das Element ist tatsächlich das aktuelle Element)
  • false (Standard-Wert – das Element ist nicht das aktuelle Element einer Liste)

Jeder Wert ungleich „true“ oder „false“ wird von Screenreadern interpretiert und der Hörer bekommt einen sinnvollen Text angesagt – in der Sprache, die im HTML-Attribut lang angegeben ist.

Inklusives Design: EU-Strategie für Menschen mit Behinderungen

Flagge der Europäischen Union

Barrierefreiheit ist ein Qualitätsaspekt, den man nicht (nur) aus Anständigkeit oder Altruismus umsetzen sollte.

Barrierefreiheit ist wirtschaftlich sinnvoll und wird in der EU wohl auch in absehbarerer Zeit in nationale Gesetze gegossen. Dabei handelt es sich um die Durchführung eines VN-Übereinkommens.

Ein paar Zitate aus der

MITTEILUNG DER KOMMISSION AN DAS EUROPÄISCHE PARLAMENT, DEN RAT, DEN EUROPÄISCHEN WIRTSCHAFTS- UND SOZIALAUSSCHUSS UND DEN AUSSCHUSS DER REGIONEN

Europäische Strategie zugunsten von Menschen mit Behinderungen 2010-2020: Erneuertes Engagement für ein barrierefreies Europa

Allgemeines Ziel dieser Strategie ist es, Menschen mit Behinderungen in die Lage zu versetzen, ihre vollen Rechte wahrzunehmen und uneingeschränkt an der Gesellschaft und der europäischen Wirtschaft teilzuhaben

Barrierefreheit ist also keine Geschenk, das man wohlwollend überreicht. Barrierefreiheit ist eine Pflicht!

Wirtschaftliche Bedeutung:

In der Europäischen Union (EU) hat jede sechste Person eine leichte bis schwere Behinderung. Das sind etwa 80 Millionen Menschen, die wegen umwelt- und einstellungsbedingter Barrieren häufig an einer vollen Teilhabe an der Gesellschaft und Wirtschaft gehindert werden.

Also sind zugängliche Webseiten auch wirtschaftlich sinnvoll: wer verzichtet schon gern auf ein sechstel seiner potentiellen Kunden? Weiter heißt es:

Es gilt, für Menschen mit Behinderungen den gleichberechtigten Zugang zur physischen Umwelt, zu Verkehrsmitteln, Informations- und Kommunikationstechnologien und -systemen (IKT) sowie zu anderen Einrichtungen und Diensten zu gewährleisten. In allen diesen Bereichen bestehen noch erhebliche Barrieren. So entsprechen beispielsweise in der EU-27 im Schnitt lediglich 5 % der öffentlichen Internetseiten voll und ganz den Standards für die Barrierefreiheit im Netz.

Wer jetzt also Barriefreiheit umsetzt hat einen klaren wettbewerbs-Vorteil: nur 5% aller Webseiten kümmern sich um ca 17% der Marktteilnehmer! – Wobei es sich bei den barrierefreien Webseiten größtenteils um Behörden-Auftritte handeln dürften, dass heißt, wer heute seine Produkte barrierefrei präsentiert hat diesen Markt praktisch für sich allein!

Und:

Eine uneingeschränkte Teilhabe von Menschen mit Behinderungen am wirtschaftlichen und gesellschaftlichen Leben ist wesentlich, soll die Europa-2020-Strategie für intelligentes, nachhaltiges und integratives Wachstum erfolgreich sein.

Die EU-Kommission erkennt also, dass sie das Potential so vieler Menschen nicht brachliegen lassen darf, wenn sie gesamtgesellschaftliche Ziele erreichen will.

Strategie:

Zugänglichkeit ist eine Voraussetzung für die Teilhabe am gesellschaftlichen und wirtschaftlichen Leben, doch für die EU ist es noch ein weiter Weg bis zur Erreichung dieses Ziels. Die Kommission schlägt vor, auf Rechtsvorschriften und andere Instrumente, etwa Normung, zu setzen, um die Zugänglichkeit zur baulichen Umwelt, zu IKT und zu Verkehrsmitteln in Einklang mit den Leitinitiativen „Digitale Agenda“ und „Innovationsunion“ zu optimieren.

Wer es trotz aller Vorteile jetzt nicht packt, seine Angebote in Ordnung zu bringen, könnte also in naher Zukunft dazu gezwungen werden. Der Wettbewerbsvorteil wird dann allerdings futsch sein…

Inclusives Design: Das „current page“-Problem

Was ist das „current page„-Problem?

Beim „current page„-Problem geht es darum, wie man Nutzer idealerweise darüber informiert, auf welcher Seite man sich in einem Webangebot befindet und wie die geöffnete Seite im Hauptmenü dargestellt und ausgezeichnet werden soll.

Im Fazit am Ende dieser Seite gebe ich zusammenfassende Empfehlungen. Bitte lesen Sie dennoch den gesamten Text, da er die Vor- und Nachteile der verschiedenen Methoden erläutert. Es gibt leider keine Methode, die immer optimal ist.
Inclusives Design: Das „current page“-Problem weiterlesen

Inclusives Design: Formulare mit HTML und CSS

Auf den meisten Ihrer Seiten bieten Sie vermutlich Informationen an, die „nur“ gelesen werden sollen. Vielleicht haben Sie für Ihre Texte schon viel getan, um diese zugänglich zu machen.

Auch  Formularen sollten Sie die gleiche Aufmerksamkeit widmen. Formulare sind schließlich eine Möglichkeit, mit Ihren Besuchern in Kontakt zu treten. Worauf Sie bei der Erstellung von inklusiven Formularen achten müssen, erfahren Sie in diesem Artikel.

Inclusives Design: Formulare mit HTML und CSS weiterlesen

Kleinigkeiten und so

Manchmal reite ich auf scheinbaren „Kleinigkeiten“ herum, welche die Konzentration stören und den Anwender zum Denken zwingen. „Don’t make me think“ war seit jeher meine Prämisse bei der Entwicklung von Webseiten. Wenn es um inclusive Design geht, ist das sogar noch wichtiger, denn Menschen mit Behinderungen, insbesondere Nutzer von assistiver Technik, haben ohnehin schon mehr zu leisten. Jedes weitere Detail das Aufmerksamkeit erfordert, erschwert die Bedienung von Webseiten zusätzlich. Kleinigkeiten und so weiterlesen

Barrierefreiheit erreichen mit WordPress

Mit WordPress kann man Barrierefreiheit nach WCAG 2.0 erreichen, keine Frage. Längst keine Selbstverständlichkeit. Aber es gibt Zugänglichkeit niemals out-of-the-box.

Wp und ein Theme, das Barrierefreiheit für sich beansprucht, ergeben nicht automatisch eine barrierefreie Website.

Zu viel redaktionelle Fragen bleiben offen: sind Texte korrekt ausgezeichnet, Alternativtexte vorhanden, sind alle verwendeten PlugIns ebenfalls in der Lage die Richtlinien zu erfüllen und werden sie so konfiguriert und bedient, dass das Endergebnis kein Zugänglichkeitsalbtraum wird?

Es gibt also eine Menge zu beachten. Warum? Weil WordPress plus Theme keine Website sind. Das wichtigste fehlt: Inhalte.

Die Web Content Accessibility Guidline behandelt eigentlich nur eine Frage: kommt jeder Mensch an den Content / die Inhalte oder wird er dabei behindert?

Darum: WordPress und ein Theme, das sich zu recht „zugänglich“ nennt, sind lediglich die notwendigen Voraussetzungen für eine barrierefreie Webseite.

Siehe auch „Themes are no Websites

Für Schulungsangebote zum Thema Barrierefreiheit (auch ohne WordPress) besuchen Sie bitte mhis.de – web designed for YOU!

Slick – interessanter Slider

Im Moment kann man sich kaum noch in einem Social Media Network bewegen, ohne über den Slider Slick zu stolpern. Scheint im Moment ziemlich angesagt zu sein und die Anleitung ist mit Code als „Copy & Paste“-Vorlagen gespickt.

Dem Einsatz in einer eigenen Website steht also nichts im Weg!

Slick beeindruckt mit einer langen Feature-Liste, umfangreichen Optionen und angeblicher Barrierefreiheit. Klar, dass ich hellhörig geworden bin. Bisher habe ich ihn noch nicht produktiv eingesetzt – ich steh generell nicht besonders auf Slider – aber Slick gefällt mir vom ersten Eindruck her.

Setzt Ihr Slick bereits ein? Welche Erfahrungen habt Ihr gemacht?

w3c Logotype

Umsetzung zugänglicher Webseiten

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