nicht angemeldet
Hallo,
Wobei grundsätzlich an den Cookies ja nichts auszusetzen wäre - wenn man über diese zu den _nicht_ barierefreien Seiten gelangen würde!
Die ganze Cookie-Diskussion ist müßig, da bereits die Entscheidung, zwei unterschiedliche Versionen anzubieten - eine (angeblich) kompatible und (angeblich) barrierefreie Version und eine »normale«, gutaussehende für die sogenannten »normalen Menschen« -, auf einer grundlegenden Fehleinschätzung beruht. Sowohl WCAG als auch BITV weisen ausdrücklich darauf hin, dass trennende Parallelversionen nicht erstrebenswert sind und eine für alle benutzbare Version vorzuziehen ist. Es existieren keine nachvollziehbaren, praktischen Gründe, wieso die »reguläre« Version nicht barrierefrei sein könnte. Wenn man der Pressemitteilung glauben schenkt, haben die Verantwortlichen sogar verstanden, dass die sogenannte barrierefreie Version nicht nur den der Definition nach behinderten Seitenbesuchern Vorteile bringt.
Die aktuelle »reguläre« Version unterscheidet sich strukturell nur wenig von der »barrierefreien« (vor allem auf den Unterseiten, welche weitesgehend aus Text bestehen, welcher nicht barrierekritisch ist), sodass bis auf die Schriftgröße, das einfachere Layout (zwei- anstatt vier- beziehungsweise fünfspaltig) und die Dekografiken keine Unterschiede bestehen, welche einer Vereinigung der Versionen im Weg stünden. Die Dekografik links nimmt nicht sonderlich viel Platz weg, die Schrift zu vergrößern bzw. eventuell eine Einstellmöglichkeit anzubieten (gemeinsam mit dem Farbschema), halte ich für tolerabel für eine Einheitsversion. Die Farbgestaltung der blauen/orangenen Hinterlegung wird teilweise auch in der »barrierefreien« Version angewandt, ich halte sie auch nicht für problembehaftet, wenn sie durchgehend Bereiche nach ihrer Funktion formatiert und hervorhebend verwendet wird. Konsistente Symbole verbessern die Benutzbarkeit nur, das Nur-Text-Dogma ist also nur kontraproduktiv. Die Hauptrubrik-Navigation kann durchaus wie in der »regulären« Version gestaltet sein, sofern die Schrift vergrößert wird und der Kontrast verbessert wird; sie muss nicht unbedingt so platzraubend wie in der jetzigen »barrierefreien« Version sein (vor allem fehlt dort die Hervorhebung der aktuellen Rubrik). Wenn man auf eine WCAG-Konformität hinarbeiten würde, eventuell auch CSS-Layout, würde sich der Rest ergeben...
Die »barrierefreie« Version hat meiner Meinung nach sogar punktuell Nachteile, beispielsweise verstehe ich den Sinn von auf sich selbst verweisende Links nicht:
<h1 class="mainheadline"><a accesskey="3" class="acc" href="#content">Stadtportrait</a><a name="content"></a></h1>
Da hat anscheinend jemand das Konzept der »Überspringen«-Links missverstanden. Es gibt auch Schnitzer wie:
<b>Position:</b> <img src="/Images/icon-misc-location.gif" border="0" align="middle" alt="Position"> [Brotkrumenpfad]
»Position: Position«, ahja, da wäre wohl ein explizit leerer Alternativtext angemessener. Ein ähnlicher Fehler findet sich auf der der Version-Auswahlseite, dort . Die Layouttabelle wird Zeile für Zeile, Spalte für Spalte von links nach rechts vorgelesen, dadurch geht der Zusammenhang zwischen Link und Erklärungstext verloren.
summary="Inhalt und Navigation" ist eine Nullinformation. Solche Layouttabellen brauchen m.M.n. kein summary, und wenn, dann nicht dermaßen lapidar (ob es bei verschachtelten Tabellen ). Zudem ist der Inhalt auf der rechten Seite und die Navigation auf der linken, was aus der Zusammenfassung nicht hervorgeht. Kurioserweise sind gerade die relevanten Datentabellen im Inhaltsbereich nicht mit dem passenden Markup ausgezeichnet, kein summary, caption, thead, th, abbr, scope/headers.
<a accesskey="4" href="#bottom"> </a><a name="bottom"></a> - Autsch!
Soviel zu eindeutigen Linktexten und aussagekräftigen Listenstrukturen:
<li><a> Bevölkerung</a><br>
Eckdaten zur Bevölkerung <a>mehr</a></li>
<li><a> Bevölkerung</a><br>
Bevölkerungsentwicklung <a>mehr</a></li>
<li><a> Bevölkerung</a><br>
Bevölkerungsstrukturdaten <a>mehr</a></li>
Der Sinn der »mehr«-Links erschließt sich mir generell nicht...
Mathias