Was könnte ich in sachen Barrierefreiheit verbessern?
 

Hier sind ja viele Webautoren unterwegs, die in Sachen Barrierefreiheit ziemlich versiert sind.
Ich selbst betreibe eine typische "Meine-Haustiere-meine-Pickel-meine-Fotos-Homepage". Natürlich habe ich versucht, die Seite "fließend" zu gestalten und darauf zu achten, daß sie auch weitgehend ohne CSS bzw. mit ausgeschalteten Bildern nutzbar ist. Mich würde allerdings interessieren, was aus Sicht der "Profis" in sachen Barrierefreiheit noch getan werden könnte.
Daher wäre ich für einen Blick auf http://www.k-faktor.com/home/ und Unterseiten dankbar.

Gruß Jürgen

Mir ist beim ersten Überfliegen nur eines aufgefallen: Du könntest Sitemap in Inhaltsverzeichnis umbenennen.

Ansonsten: Respekt - wären im Netz alle Seiten so barrierearm wie Deine, wären viele Zugangsprobleme Vergangenheit!

Noch was: die Hintergrundfarbe bei Links im Inhalt beim Hovern ist sehr kontrastarm.

Und unterschiedliche Hintergrundfarben beim Hovern für externe und interne Links werden möglicherweise eher verwirren als Unterscheidungshilfe bieten.

Hi,

ich hab mal ein Bisschen im Quellcode gestöbert, und muß sagen: Respekt! Saubere Arbeit. Semantisches Markup wohin man schaut. Naja, fast jedenfalls. Ein div id="rahmen" macht jetzt nicht sooo viel Sinn. Versuch Dir mal vorzustellen, was "rahmen" bedeutet, wenn die Seite vorgelesen wird.

Eine Kleinigkeit: I.A. ist es besser, wenn man den Skiplink nach dem Seitentitel vor der Navigation einfügt. Du hast den Seitentitel relativ weit hinten. Der Seitentitel (h1) gehört ganz an den Anfang. Danach der Skiplink, danach dann z.B. navi, gefolgt vom Inhalt.

Generell kann ich Dir für die Sorgfalt Deiner Arbeit nur gratulieren. Erstklassig.

Nachtrag: Klassennamen wie "kruemelnavi" find ich witzig. Aber warum nicht.

Also bevor ich mit der "Barrierefreiheit" beschäftige, schaue ich mir immer den CSS/HTML Code an. Siehe hierzu die WAI Checkliste, Punkt 11.1 :)

CSS:

Typisch Windows, unter Linux/Unix sollte alles klein geschrieben sein.

Cool, aber was machst du mit MS Internet Explorer 7.0 beta 3?

Und zum Schluss :D
Der CSS-Validator findet im "basis.css" tatsächlich 7 Fehler und zig Warnungen. Interessant hierbei, das ich dein CSS nicht per URL checken kann und das doch die typische "Vordergrund/Hintergrund" Problematik ebenfalls auftaucht. Siehe hierzu WAI Checkliste, Punkt 2.2

HTML:
Klasse gemacht, alles wirklich valide. Aber...
Hier fehlen die <noscript>-Bereiche (Seite "Der Traum vom Fliegen"). Ist laut WAI Checkliste. Punkt 1.1 nicht regelkonform.

Abgesehen davon, das der "Accessibility Valet Report" ein "Probable pass - check warnings" für das WAI Level AAA bringt, was gut ist, hat die ScreenReader Simulation "Wave" ein unlogisches Ergebnis zu Tage gefördert.

Bevor man einen kurzen Inhaltstext zur Erläuterung bekommt, wo man sich befindet oder was diese Seite beinhaltet, muss man schon aus Links auswählen (Seite "Der Traum vom Fliegen"). Unschön...

Teste ich diese Seite nach dem Regelsatz der BITV (automatischer Test) werden 2 Punkte als Fehler und 20 Punkte als mögliche Fehler ausgegeben. Ok, das geht vielleicht zu weit, aber ich konnte nicht widerstehen :)

Um aber jetzt zum Schluss zu kommen, die Unterseiten zur "Person" verlieren das "Corporate Design". Die Navi verändert sich und es taucht ein "WoBinIch" auf. Finde ich nicht gut, alle Seiten sollten identisch aufgebaut sein. Und weiter testen will ich jetzt nicht mehr...

Herzlichen Dank für die zahlreichen Kommentare und Anregungen. Über einige Dinge muß ish noch nachdenken, manches werde ich ausprobieren und zu einigen Punkten kann ich gleich eine Antwort geben.

Das ist sinnvoll. Allerdinges hat sich bei mir noch niemand aus der Linux-Fraktion deswegen beschwert. Würde die Verwendung von Großbuchstaben im vorliegenden Fall auf Linux-Systemen zu Fehlern führen, oder sprechen wir hier von einem "nice-to-have"?

Solange der IE 7 noch beta ist, mache ich mir keine Gedanken darum, denn jeder, der Beta-Software installiert, weiß, was er tut. Wenn der IE 7 dann irgendwann non-beta ist, bekommt er mit ein eigenes Stylesheet zur Korrektur der dann noch immer (hoffentlich wenig) verbliebenen Bugs vorgesetzt.

Nicht ganz. Bei Validierung gegen CSS3 sind es ganze 2 Fehler, wie man hier sieht. Die zweimalige Verwendung des proprietären Wertes -mox-inline-box ist gewollt und richtet keinen Schaden an. Die Warnungen wegen fehlender Farbdefinitionen für Vordergrund/Hintergrund kann ich nicht nachvollziehen. Schließlich habe ich im Stylesheet stehen und das sollte eigentlich alles "erschlagen" und die Farbangaben auch genügend "robust" machen. Sollte das nicht der Fall sein, wäre ich für einen Hinweis dankbar.

Das ist aus meiner Sicht definitiv nicht sinnvoll. Ein noscript-Bereich für den Google-Tracking Code ist vollkommen überflüssig. Insofern kann ich die entsprechende Forderung laut WAI Checkliste. Punkt 1.1 nicht nachvollziehen.

Kannst Du diesen Punkt vielleicht näher erläutern. Die Links müssen ja erst dann ausgewählt werden, nachdem der Besucher die Seite gelesen hat und eine andere Seite besuchen möchte.

Das ist ein interessanter Diskussionspunkt. Die Gestaltung meiner Seiten ist insofern schon konsistent, als die Seiten der ersten Ebene keine Krümelnavigation aufweisen, die Seiten der darunter liegenden Ebenen hingegen schon (das Prinzip wird auch recht konsequent eingehalten). Ob ein Besucher dadurch wirklich irritiert wird, weiß ich nicht. Es käme auf eine Versuch drauf an, ein "Wo bin ich" auch auf den Seiten der ersten Ebene einzufügen.


Eine für mich überraschende Anmerkung. Die id-Bezeichnung "rahmen" ist für mich genauso sinnvoll (oder eben nicht) wie das häufig benutzte id=content. Im vorliegenden Fall gruppiert das div-Element tatsächlich alle Seitenelemente, die dann mit einem gemeinsamen Rahmen versehen sind. Insofern erschien mir die id-Bezeichnung zunächst sinnvoll. Überrascht hat mich die Bemerkung mit dem "vorlesen". Ist es tatsächlich so, daß ein Screenreader die id-Bezeichnungen vorliest? Falls ja, sollte ich mir tatsächlich über die Wahl der Bezeichnungen mehr Gedanken machen und IDs so vergeben, daß die Bezeichnungen für den Besucher selbsterklärend wirken. Was würdest Du denn alternativ auf einer Deiner Seiten verwenden?

Diesen Punkt finde ich interessant. Der Skiplink befindet sich auf meinen Seiten ja auch unmittelbar vor der Navigation. Allerdings erscheint das h1-Element erst danach, quasi als Beginn des eigentlichen Textes. Nach meinem bisherigen Verständnis vermittelt das title-Element die Hauptinformation über den Inhalt der betreffenden Seite, quasi die Master-Überschrift nullter Ordnung. Das h1-Element ist für mich dann nachrangig. Wie sehen das die anderen Leser hier?


Ja. Allerdings variiert das sehr, je nach verwendetem Bildschirm. Ich muß aber auch gestehen, daß ich mehr ein Anhänger dezenter Hervorhebungen bin. Vielleicht werde ich hier noch ein wenig experimetieren.

Das ist ein Würgaround, bis auch der IE etwas mit dem Pseudoelement :after anfangen kann, denn dann reicht der kleine Pfeil hinter den sog. externen Links als Kennzeichnung völlig aus. Im übrigen ist der Sachverhalt der unterschiedlichen Kennzeichnung interner und externer Links auch unter http://www.k-faktor.com/info/hinweis.htm erklärt.

Über die Bezeichnung "Sitemap" hatte ich mir auch schon Gedanken gemacht und im Hauptmenü zu dem Link-Element noch ein title-Attribut mit dem Inhalt "Inhaltsverzeichnis der Website" eingefügt. Aber vielleicht wäre es wirklich einfacher, den Link gleich "Inhaltsverzeichnis" zu nennen.

Ohne mich bei euch gross einmischen zu wollen, aber Screenreader lesen Attributwerte i.d.R nicht vor. Ausnahmen bilden hier natürlich title, alt etc. Aber id und class bzw. ihr Wert wird nicht vorgelesen.

Grüsse
lloyd

Hi,

darum geht es ja auch gar nicht. Es geht um folgendes:

Wenn Du einen Rahmen um Etwas wünscht, dann verpasst Du dem Element den Klassennamen "Rahmen". Das bedeutet, daß in einer visuellen Repräsentation Deiner Seite ein Rahmen um diesen Container gezogen wird. So weit so gut. Aber was bedeutet Rahmen in Zusammenhang mit einer akustischen Version dieses Containers? Wie bitte liest man einen Rahmen vor?

Es geht hierbei um Fragen des "Semantic Marcup". Also, in diesem Zusammenhang die Verwendung von Klassennamen, um die Bedeutung dieses Inhalts zu spezifizieren. Wenn Du z.B. einen Klassennamen verwendest wie "kruemelnavi", dann ist das semantisches Markup. Denn dieser Bedeutung des Inhalts dieses Containers kannst Du sowohl visuell als auch akustisch einen bestimmten "Anstrich" verpassen. Es kann z.B. Sinn machen, diesem Container einen Rahmen zu verpassen (visuell), oder es kann Sinn machen, den Inhalt dieses Containers als "inline" anstatt "block" darzustellen (visuell). Oder es kann Sinn machen, den Inhalt dieses Containers mit einer anderen Stimme vorzulesen (akustisch). Wie auch immer, völlig unabhängig davon, wie Du nun genau formatierst, es ergibt einen Sinn.

Nehmen wir mal den umgekehrten Fall an. Nehmen wir mal an, Du hättest diesem Container den Klassennamen "Diana_Ross" gegeben. Ist ja völlig legal. Und in einer akustischen Repräsentation könnte das auch Sinn machen. Aber wie bitte stellt man den Inhalt eines Containers namens "Diana_Ross" visuell dar? Da gibt es zwischen dem Klassennamen und der visuellen Darstellung absolut keinen Zusammenhang. In einer visuellen Darstellung ergibt so ein Name keinen Sinn.

Wie ich bereits an anderer Stelle angemerkt habe: Es gibt keine css-Klassennamen. Klassenamen haben des Zweck, die Bedeutung des Inhalts des entsprechenden Elements näher zu spezifizieren. Und Klassennamen wie "Rahmen" oder "Diana_Ross" spezifizieren bezüglich der Bedeutung rein gar Nichts. Beides sind Klassennamen, die auf die Darstellung in einem bestimmten Medium abzielen. Die Darstellung hat aber im html Nix zu suchen, das ist Aufgabe des css. Inhalt und Struktur kommen ins html, die Darstellungsoptionen kommen ins css. Je konsequenter Du die Trennung vornimmst, um so besser. Die von Dir verwendeten Klassennamen sind also syntaktisch völlig legal. Aber ein paar dieser Klassennamen widersprechen dieser Trennung von Inhalt und Darstellung und sind somit kein semantisches Markup.

Nochmal: Klar liest ein Screenreader dieses Attribut nicht mit vor! Aber wie würdest Du einen Container der Klasse "Rahmen" akustisch stylen? Und warum? Und wie würdest Du einen Container der Klasse "Diana_Ross" visuell stylen? Und warum?

Ein simples Beispiel hierzu:

Ein Dokument geschrieben mit OpenOffice unter Windows (Schriften: Arial oder Times) kommt unter Linux nicht sehr gut. Also kann man unter Linux TTF-Fonts von Windows hinzufügen (z. B. in der KDE). Also nutzen die Browser, wenn angegeben auch Arial zum rendern von Webseiten. Ist allerdings Arial mit einem führenden grossen "A"rial im HTML angegeben, so wird dieser Font nicht gefunden und es wird "sans-serif" verwendet, da Linux nach dem Einfügen als TTF diesen nur mit "arial" zur Verfügung stellt, also kleingeschrieben.

Das ist Ansichtssache und ein riesiges Streitthema. Hier sind die Meinungen sehr weit auseinander, ich persönlich halte das für einen "CSS-Hack". Wie gesagt, meine persönliche Meinung.

Auch hier nur meine persönliche Meinung:

CSS3 ist offiziell noch nicht freigegeben. Als Beispiel nehme ich mal das CSS3 "border-radius" Element. Viele warten darauf und es wird lustig umgesetzt :D

- Mozilla verwendet "border-radius" als "moz-border-radius"
- Safari (inoffizielles WebKit von den Entwicklern) als "webkit-border-radius"

Wobei Konqueror dieses nicht implementiert hat, aber das CSS3 "text-shadow" Element. Safari kann das auch, aber ignoriert die Abstandsangaben. IE lassen wir lieber :D

So, auch hier meine persönliche Meinung, CSS3 Elemente nicht verwenden, da diese offiziell noch nicht freigegeben sind.

Ergänzung:
Wobei ich fairer weise erwähnen sollte, das ich auf meiner Seite im Bereich CSS selber zwei CSS3 Elemente verwende "text-shadow" und "border-radius" :D aber ausschließlich zum Testen für Browser...

Ich hatte mal mit zwei Moderatoren zu meiner eigenen Seite mehrere Auseinandersetzungen zu diesem Thema. Die zwei Moderatoren haben mir folgende Reihenfolge logisch/sematisch/behindertengerecht erklärt:

- Überschrift (mit Skip Möglichkeit)
- kurze Erläuterung
- Navigation (mit Skip Möglichkeit)
- Inhalte
- zurück zum Seitenfang

Die Erklärungen hierzu waren in etwa wie folgt:

Kommt jemand per Suchmaschine auf diese Seite oder per Zufall, so hat er die Möglichkeit anhand der Überschrift oder der kurzen Beschreibung feszustellen, ob das seinem Suchergebnis entspricht. Ist diese Seite nicht das was er sucht, kann er durch "title" in der Navigation eventuell das Gesuchte finden oder er benutzt das Inhaltsverzeichnis oder springt direkt zum Inhalt. Somit sind alle Möglichkeiten offen :D

Siehe ein schönes Beispiel: www.w3.org/WAI. Die ist ähnlich aufgebaut.

Ein extra css, das speziell für den IE per conditional comments eingebunden wird ist kein Hack und durchaus eine Möglichkeit. Allerdings nur für den IE. Alles Andere sindHacks, und die lehne ich persönlich auch ab. Aber wer's unbedingt braucht...

Meine, ebenfalls persönliche, Meinungdazu: Warum nicht verwenden? Solange dasLayout davon nicht abhängt und die Seite z.B. im EI einfach nur etwas weniger schön aussieht, ist das mMn völlig in Ordnung. Unhaltbar wird es, wenn man solche Dinge so verwendet, daß die Seite in Browsern, die das nicht unterstützen, unbenutzbar wird.

Die Erklärung ist gut, erklärt allerdings nicht die Skipmöglichkeit der Überschrift. Diese eine Skipmöglichkeit halte ich für überflüssig.

Sorry, war vielleicht zu oberflächlich :(
Hier die feine Definition dazu:

- Skip Link (Sprachwechsel, z. B. DE oder EN/zum Inhalt)
- Überschrift
- kurze Erläuterung
- Skip Link (über die Navigation zum Inhalt)
- Navigation (mit "title"-Attribute)
- Inhalte
- Link zum Seitenanfang (zurück zum ersten Skip-Link)

Als Beispiel wie ich das meine, für den Fall das ich wieder ein Fehler mache, siehe meine Eigende http://www.aadmm.de/de/index.htm. Wobei ich den Link "Inhaltsverzeichnis" nur in der Fusszeile habe (englisch/international orientiert, wird irgendwann für die "deutsche Fassung" noch geändert).

Schon klar, daß Du das meintest. Nach wie vor halte ich einen Skiplink vor der Überschrift für überflüssig. Eine Überschrift muß nicht übersprungen werden, da die Überschrift die erste relevante Information zum Inhalt der Seite enthält.

Was ich nicht ganz 100% verstehe, ist, was Du mit Sprachwechsel meinst. Meinst Du, in einer Seite mehrere gleiche Inhalte zu haben in jeweils anderen Sprachen? Also auch mit Überschriften in der jeweiligen Sprache? In dem Fall könnte es tatsächlich Sinn machen, einen Skiplink zu der Überschrift der bevorzugten Sprache zu machen.


Nach der Überschrift sieht es natürlich anders aus. Wobei man auf einen Skiplink zum Inhalt verzichten kann, wenn der Inhalt gleich nach der Überschrift kommt.

Meine eigene Seite ist in Deutsch und Englisch verfügbar. Die Inhalte sind aber komplett identisch. Wenn jetzt ein Besucher zufällig die falsche Sprache erwischt hat (z. B. per Suchmaschine) kann er sofort in den deutschen/englischen Part wechseln.
Siehe, wie schon angedeutet, meine eigene Seite :)

Ah ja, kapiert. Ist vielleicht eine Idee, diesen Link ganz an den Anfang zu setzen. Bei mir ist der noch im Footer :)