WebDesign by mts

Startseite » barrierefrei » barrierefreies Webdesign

barrierefreies Webdesign

in Webdesign Tutorial barrierefrei, von mts

Wie wird eine vorhandene Software wie WordPress barrierefrei. Barrierefreies WebDesign in der Praxis.

Barrierefreies Webdesign ist einfach und kostet kaum zusätzliche Zeit. Das Aufschreiben all der Dinge, die ich hier auf webdesign-in.de berücksichtige und gemacht habe, um barrierefreies Webdesign so gut als möglich umzusetzen, hat mich sicher mehr Zeit gekostet als all die Maßnahmen, die ich setzte. Wenn man weiß worauf man achten sollte.

Barrierefreiheit wird meist so definiert:
“Barrierefreiheit” bedeutet die uneingeschränkte Nutzung von Gegenständen, Gebrauchsgütern und Objekten durch alle Menschen.

barrierefreie Formulare:

Kommentarfunktion:
Zuerst “label” und dann die “input” Felder, damit man vorher weiß, was man reinschreiben muss.
Außerdem auf den “tabindex” geachtet – zumindest bei Formularen sollte er vorhanden sein. z.B.:

<label for="author"><small>Name <?php if ($req) echo "(unbedingt)"; ?></small></label>
<input type="text" name="author" id="author" value="<?php echo $comment_author; ?>" size="30" tabindex="100" />

barrierefreies Email Formular:
Ein Formular verwendet, dass sowohl visuell wie schriftlich anzeigt, wenn etwas nicht stimmt.

Links:

Niemals öffnet sich ein Link im neuen Fenster! – Eine sehr wichtige Regel für barrierefreies Webdesign wurde damit erfüllt.

Bei allen Links den “title” tag verwendet und darauf geachtet, dass dieser soweit als möglich immer anders lautet.

Aussagekräftige Linktexte:
Ich achte darauf, dass ich weder “hier” noch “weiter” verwende, sondern den Linktext so schreibe, dass man sich vorstellen kann was passiert, wenn man draufklickt.

Bei Links, die von webdesign-in.de wegführen, schreibe ich im “title tag” immer “Externer Link” dazu.

Manches automatische Programm, das auf Barrierefreiheit testet, zeigt an, dass ich auf der Startseite sehr oft ” Lesen Sie weiter…” stehen habe, denn es sollen keine Linktexte zweimal verwendet werden.

Wenn dieser Link stets anders heißt oder der Titel des Artikels X-Mal wiederholt wird, erachte ich persönlich für verwirrender. Hier gibt es unterschiedliche Meinungen und sehr viele Diskussionen unter den Praktikern und Theoretikern für Webstandards.

Nicetitle

Sprungmarken im Quelltext für Screenreader Nutzer und Nutzerinnen.

<!-- zu den Menues und zum Inhalt-->
<a class="invisible" href="#artikel"  accesskey="1" title=" zum Inhalt">
zu den Artikeln oder Inhalt</a>
<span class="invisible">|</span>
<a class="invisible" href="#inhalt"  accesskey="2" title=" zu den inhaltlich weiterführenden Links">Inhalt</a>
<span class="invisible">|</span>
<a class="invisible" href="#vorstell"  accesskey="3" title=" zur Hauptnavigation">Kontaktlinks</a>
<span class="invisible">|</span>

Auch bei diesen Sprungmarken einen Trennstrich gesetzt, denn nutzt jemand einen Textbrowser, dann sind die Links auch für diese Person getrennt.

Im Cascading Style Sheet, also der style.css definierte ich die “class invisible” so:

.invisible{
position:absolute;
  left:-999px;
  width:500px;
}

Display none wird ja von einigen Screenreadern nicht erkannt und da gibt es sogar welche, die dann einfach aufhören weiter zu lesen.

In den jeweiligen Templates den Anker für diese Sprungmarken geschrieben z.B.::

<a name="vorstell" title="Zur Hauptnavigation" class="invisible"></a>

Accesskey: Ich habe die Links zu Home, E-Mail, Impressum, Sitemap und Hilfe mit einem Accesskey versehen. Genauso wie die Sprungmarken.

Jeden Link mit einem Accesskey zu versehen ist bei einem dynamischen System wie WordPress oder Content Management Systeme kaum möglich und ich erachte dies auch nicht wirklich für nötig.

Das Attribut “tabindex” verwendete ich nur für Formulare. Jeden Link mit einem “tabindex” zu versehen, erachte ich als unnötig, denn Menschen, die gerne die Tastatur zum Surfen benutzen und nicht die Maus, haben in den allermeisten Fällen einen Browser, der dies unterstützt.
Definiere ich jetzt sehr oft das Attribut “tabindex”, dann kann es passieren, dass ich die individuellen Einstellungen des Nutzers überschreibe. Es kann nicht Sinn einer Webstandard Regel sein, die Individulität wieder aufzuheben, nur damit ein automatisches Programm keinen Barrierefreiheitsfehler meldet.

Ich definiere die Sprache eines Wortes oder längerer Textabschnitte, ob die unterschiedlichen Screenreader dies auch immer berücksichtigen ist nicht immer gewährleistet, aber sehr viele tun es.

<span lang="en"  xml:lang="en">Hi! Webstandards are  easy! </span>

Soweit ich es kann, nutze ich eine einfache Sprache.

Bilder:

Ich verwende den “alt tag”, um kurz zu beschreiben was auf dem Bild zu sehen ist. Bei Bilderlinks nutze ich dafür den “title tag”. Verwende kaum Bilder, die für das Verstehen des Artikels unbedingt nötig sind. Wenn doch, dann beschreibe ich den Inhalt des Bildes im Text. Selten verwende ich das Attribut “longdesc”, weil es derzeit kaum nötig ist, doch würde ich einmal eine Statistik auf einem Bild zeigen, dann nutze ich auch dieses.

Sehtest

Die verwendeten Styles haben alle den Sehtest überstanden.

Verwendung von Überschriften

Korrekt wäre die Reihenfolge h1-h6 zu verwenden. Doch dies ist bei einer dynamischen Website fast unmöglich. So massiv in den Ursprungscode einzugreifen, um diese Regel einzuhalten ist kaum möglich.

Ich biete eine Sitemap an und eine Hilfe, um sich leichter zu orientieren und all die fremden Worte (wie trackback, pingen) erklären zu können.

Navigation

Ich nutze für jede Navigation eine Liste, egal ob diese vertikal oder horizontal angezeigt wird. Dies ist eine Erleichterung für Screenreader Nutzern und Nutzerinnen. (Außerdem erleichterte es mir das Gestalten. )

Klickt jemand auf eine Kategorie ( barrierefrei , dann sieht derjenige wo er sich soeben befindet.

Hier finden Sie alle Beiträge, die unter *barrierefrei* abgelegt sind.

Listen

Am Ende jedes Listenpunktes setze ich einen Punkt, denn dies erkennt ein Screenreader und zeigt so die einzelnen Punkte gut hörbar an.

XHTML1 strict

Ich nutze die strict Version und achte, dass mein HTML immer valide ist.

Ob ich jetzt alles aufgezählt habe, weiß ich nicht, doch eines weiß ich ganz sicher:
Es geht alles viel schneller, als es sich niederschreibt.

Soweit als möglich barrierefrei zu gestalten und zu schreiben ist einfach. Nur daran denken muss man.

Basis Know-how CSS
Internetmarketing

• Website optimieren-usability
• accessibility
• Barrierefrei.

Top

2 zu : barrierefreies Webdesign