Manuel-Bieh.de – Web-Development & Consulting

… oder doch nicht?

Kurze Einleitung

Eine große Klappe zu haben und Andere mit eben dieser großen Klappe zu kritisieren ist meist viel einfacher als Dinge selbst von vornherein richtig zu machen. Ich habe mir heute Zeit genommen, um den brandaktuellen, neuen und barrierefreien Internetauftritt meiner geliebten Heimatstadt Dortmund einem sehr ausgiebigen Test zu unterziehen. Da Ich denke, dass die Dortmund Agentur, welche laut eigenen Aussagen ein gutes Jahr brauchte um den kompletten Auftritt zu modernisieren, mit Sicherheit noch einmal einen Tag investieren kann, um aus Ihren Fehlern zu lernen bzw. um diese nun auszubessern, werde ich gefundene Beanstandungen hier möglichst ausführlich und konstruktiv schildern und diskutieren (lassen).

Da ich davon ausgehe, dass die zuständigen Personen begründeten Beanstandungen gegenüber nicht abgeneigt sind, und auch von diesem Beitrag Kenntnis nehmen werden, werde ich mich bemühen möglichst konkrete Lösungsansätze zu beschreiben von denen sowohl meine Leser, als auch die Zuständigen etwas haben. Auf, für die Anfangszeit typische, »shit-morgen-ist-bereits-Deadline-Fehler« werde ich versuchen Rücksicht zu nehmen. ;)

Gleich zu Anfang muss ich der Agentur ein mittelgroßes Lob aussprechen, die Seite hat gegenüber der alten Version deutlich an Klarheit und Übersichtlichkeit zugelegt, es wurde (logisch), auf Tabellen verzichtet und auch weniger verbreitete Browser wie der Firefox, Opera und, wenn ich die Stylesheets richtig deute, selbst der Mac IE, wurden nicht außen vorgelassen.

Soviel zum Lob. Kommen wir zu den Fakten.

Der Code

Als Erstes möchte ich einmal einen Blick in und auf den Code werfen. Korrekterweise befindet sich ein Doctype an erster Stelle. Der Browser fällt somit nicht in den Quirksmode, so daß sich selbst der Internet Explorer zumindest annähernd an gängige Standards hält. Angeführt wird ein HTML 4.0 loose Doctype – zumindest eine strict-Version hätte es als Zeichen des »hier hat sich etwas getan« meiner Meinung nach sein dürfen.

Wobei sich hier nur spekulieren lässt, ob es die Dortmund-Agentur schlichtweg nicht für nötig befunden hat, im Zuge einer barrierefreien Umsetzung auf eine dafür ausgelegte, strikte Dokumententypendeklaration zurückzugreifen, oder ob der Aufwand, ein mehrere tausende Seiten umfassendes CMS von loose auf strict umzustellen einfach zu umfangreich gewesen wäre.

Warum auf eine XHTML-Auslieferung verzichtet wird kann ich mir jedenfalls noch dadurch zusammenreimen, dass nicht alle Browser den bei XHTML empfohlenen application/xml+xhtml Mime-Type unterstützen, es also prinzipiell keinen großen Unterschied macht ob man nun letztendlich HTML oder XHTML ausliefert.

Der Doctype an sich ist aber kein ausschlaggebender Punkt für »barrierefrei oder nicht«, weswegen wir uns damit nicht weiter aufhalten wollen, und zum Markup kommen.

Was macht der Webentwickler, der Wert auf Webstandards und somit auf eine (rein theoretisch) größtmöglichste Kompatiblität zu den verschiedenen Browsern legt? Er validiert! Auf der Startseite der Dortmund Seite mängelt der W3C Validator 15 Errors an, in meinen Augen jedoch noch relativ vertretbare, da es ausschließlich um falsche Sonderzeichenkodierung, und um (vermutlich durch das CMS erzeugte) fehlerhafte Entities (&) in Links geht. Selbst wenn man gegen HTML 4.0 strict validiert, werden auf der Startseite »nur« 5 Errors mehr (also 20 insgesamt) gefunden: Ein target-, zwei align– und ein language-Attribut (deprecated), sowie ein <br clear="all">, was sich im übrigen korrekterweise <br style="clear: both;"> schreibt, liebe Dortmund-Agentur ;). Dies gehört jedoch sicherlich in die Kategorie »passiert schonmal, ist aber ruckzuck behoben«.

Semantische Aspekte

Bemängeln kann der Validator auf Grund von fehlender künstlicher Intelligenz natürlich nur Fehler in der Struktur, nicht bei der Semantik. So setzt die Seite, wie sollte es anders sein, auf einen tabellenloses Code. Zurückgegriffen wird nur dort auf Tabellen, wo sie gebraucht werden: bei tabellarischen Daten. Es wird semantisch korrekt auf Listen in der Navigation zurückgegriffen und Paragraphen werden dort ausgezeichnet, wo sie gebraucht werden. <div>s werden häufig, aber im noch gesunden Maß eingesetzt. Überschriften werden als eben solche gekennzeichnet, lediglich die Hierarchie ist ein wenig konfus.

So sehe ich auf keiner Seite eine Überschrift die als Headline ersten Grades (<h1>) ausgezeichnet ist. Selbst Überschriften die ganz offensichtlich den Seitentitel enthalten, und sich somit wunderbar als Überschrift erster Ordnung anbieten, werden nur als Überschrift dritter Ordnung (<h3>) ausgezeichnet. Dafür hingegen werden selbst Überschriften die für den Nutzer offensichtlich relativ unwichtig zu sein scheinen (da ausgeblendet) als Überschrift zweiter Ordnung ausgezeichnet. Dabei wird auch vor Markup in der Form <h3>&nbsp;</h3> nicht zurückgeschreckt. Hierbei stellt sich mir die Frage, ob der barrierenbehaftete User eines Screenreaders, in Erwartung es würde eine Überschrift dritter Ordnung folgen, verwirrt werden soll. Sehr gut punkten könnte man mit den Headlines in Sachen Suchmaschinenoptimierung. Chance jedoch vertan, Abzüge deshalb in der B-Note.

Navigationsstruktur

In der Navigation wird, wie oben bereits kurz angeschnitten, auf eine ungeordnete Liste (<ul>) mit Links zurückgegriffen. Statt einen Hinweis in unmittelbarer Nähe, vor dem betreffenden Menüpunkt zu platzieren, wird der jeweils aktive Menüpunkt nur einmal (weit vor der Menüliste) durch ein plumpes »Sie befinden sich hier: Rubrik« kenntlich gemacht. Was an sich recht gut bedacht ist, da dem User die Möglichkeit gegeben ist das Menü zu überspringen, sobald er liest, dass er in der richtigen Rubrik ist. Eine generelle Kennzeichnung in der Form:
<li class="selected">Aktuell aktiv: Rubrik<li>
wäre dennoch wünschenswert, da zumindest ich bei einer 15 Punkte (ohne Unterpunkte) umfassenden Liste wohl spätestens nach dem zehnten Punkt vergessen habe, welcher denn jetzt der war, den ich momentan gewählt habe, bzw. weiß, wann ich in die zweite Ebene, der Unternavigation, gelange. Wünschenswert, aber auch nicht weiter dramatisch. Realisieren ließe sich dies (für anständige Browser) im Übrigen vielleicht schon durch ein simples
.selected > a:before {content: "Aktuell aktiv: ";}
im Stylesheet. Da dieser Hinweis allerdings für den »sehenden« Besucher eine ziemlich unnütze Information darstellt, er kann dies schließlich anhand des ausgeklappten Menüs sehen, kann hier auch auf ein für den Bildschirm ausgeblendetes <span>-Element zurückgegriffen werden. Inwiefern es Sprachbrowser gibt, die das :before-Pseudoelement unterstützen kann ich jetzt leider auch nicht sagen.

Plus für die Dortmund-Agentur: an die wichtigsten Sprungmarken wurde gedacht: »Allgemeine Funktionen und Angebote dieser Seite«, »zum Hauptmenü« und »zum Inhaltsbereich dieser Seite«. Diese befinden sich direkt am Anfang des Dokuments und bieten dem zielstrebigen Benutzer direkt zu Beginn die Chance, möglicherweise irrelevante Informationen wie der Erklärung der Accesskeys, die Wahl des Kontrasts, oder des Layouts (fixiert/flexibel) zu überspringen. Interessant wäre es vielleicht, diese Sprungmarken für den »sehenden« Benutzer ebenfalls anzubieten. Dazu bietet sich die Methode der sichtbaren »Skiplinks« an, die ich hier einmal beschrieben hatte.

Design- und Usability-Aspekte

Funktionelles

Usern mit eingeschränkter Sehkraft oder Sehbehinderung wird durch den (auch ohne JavaScript funktionellen!) Styleswitcher die Möglichkeit gegeben, den Kontrast, die Breite und die Schriftgröße zu verändern. Problem an der Sache: Ohne JavaScript bekomme ich den Styleswitcher garnicht erst zu Gesicht. Eleganter wäre es hier vielleicht, die drei Menüs (Schriftgröße, Breite/Kontrast und Accesskeys) ohne JavaScript einblendbar zu machen. Oder alternativ einfach das JavaScript zugänglich zu machen. So könnte man versuchen statt drei mal ein Menü, das komplette Menü in nur einem div unterzubringen, welches standardmäßig sichtbar ist, für User mit aktivierten JavaScript aber durch <body onload="tool_off()"> beim Laden des Dokuments vorerst ausgeblendet wird.

Schön ist, die Seite macht (bei flexibler Breite) Gebrauch von min-width und max-width. Gedacht ist dies dazu, dass die Zeilenlänge auch bei hohen Auflösungen nicht unleserlich lang wird. Optimum ist der – an und für sich gut bedachte – Effekt nicht. So beträgt die max-width: 1400px;, die Panoramagrafik ist jedoch nur 1060 Pixel breit, und wird bei zu hoher Auflösung noch weitere 340 Pixel gekachelt. Ein unschöner Effekt. Lässt sich aber daher ableiten, dass die Box in der sich die gerade beschriebenen Styleeinstellungen befinden, genau diese 340 Pixel breit ist, und man vermutlich nicht wollte, dass etwas vom Panorama abgeschnitten wird. Ist vielleicht nett gemeint, aber mal im ernst: Leute, das sieht nicht aus. Noch dazu sind 1400 Pixel definitiv zu lang. Die Inhaltsspalte ist dann nämlich rund 760 Pixel breit, was bei der 13 Pixel großen Verdana eine Zeilenlänge von rund 130 Zeichen verursacht, was definitiv zu lang ist. Eine maximale Breite von 1060 Pixeln wie im Headerbild ist durchaus Ok, und selbst bei großem Schriftgrad (200 %) noch recht angenehm lesbar. Zudem wird das Hintergrundbild nicht unschön gekachelt.

Ein ebenfalls unschöner Effekt: Bei Auflösungen unter 1024×768 rutscht (im Firefox) die rechte Spalte unter die mittlere. Was hier die Mindestbreite von 550 Pixeln bewirken soll ist mir schleierhaft. Ebensogut könnten dort 800 Pixel stehen, dann klappt’s mit der rechten Spalte auch im Firefox. Ich hoffe es ist hier nicht versucht worden auf User mit einer Auflösung von 640×480 Rücksicht zu nehmen. So etwas gibt es nicht mehr, siehe http://www.w3schools.com/browsers/browsers_stats.asp unter Display Resolutions und January 2005(!). Hier kann also mit einem einzigen Handgriff schonmal sehr viel für 800×600 Surfer getan werden.

Formulare

Auf der Seite finden sich auch einige Webformulare. Erst einmal hat es mich positiv überrascht, dass die Entwickler hier (und das kommt nicht oft vor) schon davon gehört haben, dass Formulare statt unschön mit Tabellen, einzig durch das für stark verbesserte Zugänglichkeit sorgende <label> erstellt werden können. Soviel zum Positiven. Ganz und garnicht im Sinne des Erfinders sind hingegen folgende Auswüchse:
<label for="Name"><div class="form_feldname_left">Name:*</div></label>
Gehört für mich in die Kategorie »nett gedacht, aber bei der Umsetzung schlichtweg versagt«. Klingt hart, kann man aber kaum treffender formulieren. Das label-Element kann nach einem display: block; im Stylesheet, ebenso wie auch ein div, in Höhe und Breite beliebig geändert werden. Diese Methode ist, im Gegensatz zur aktuell genutzten, valide, und sorgt dafür, dass man die label auch wirklich anklicken kann um in das entsprechende Textfeld zu gelangen. Das Kontaktformular daher bitte nochmals im Firefox checken. Leute, ich sag’s Euch, die Alternativbrowser sind im Kommen!

Wie man zugängliche Formulare erstellt, habe ich vor ziemlich genau einem Jahr schon einmal hier beschrieben. Bitte anwenden. Die Ansätze und auch das notwendige Fachwissen scheint ja vorhanden zu sein. fieldset, legend, label sind allesamt im Formular zu finden. Daher Daumen hoch für (halb)gemachte Hausaufgaben.

Formulargestaltung wäre damit erstmal abgehandelt. Kommen wir zum vermutlich fatalsten Punkt im ganzen barrierefreien Redesign. Wie barrierefrei ist eine Seite, bei der barrierenbehaftete User, die öfters gern mal JavaScript deaktiviert haben, weder den Veranstaltungskalender, noch das Kontaktformular vernünftig nutzen können? Vielleicht versteht Ihr worauf ich hinaus möchte.

Es wird bei der Ankündigung zur Umstellung der Seite damit geworben, dass in der alten Version nur aktuelle Meldungen und Veranstaltungshinweise barrierefrei angeboten wurden, nun aber nahezu alles Services barrierefrei sind. Soso? Wieso kann ich mir denn nun die Veranstaltungen nicht im Textbrowser, oder meinetwegen auch im grafischen Browser mit deaktivierten JavaScript ohne Einschränkungen anschauen? Glaubt Ihr nicht? Probiert’s aus. Deaktiviert JavaScript im Browser. Geht nun zu: Veranstaltungskalender. Jetzt öffnet sich die (aus unerfindlichen Gründen) standardmäßig ausgeblendete Zeitraumauswahl. Öffnen hab ich gesagt. Tut sich nichts? Ups! Mein Fehler. Wird ja per JavaScript eingeblendet. Na macht nichts. Sucht Euch nun halt den Bereich aus, für den Ihr Euch am meisten interessiert. In meinem Fall ist das Nightlife. Ausgewählt? Ok, nun »Durchsuchen« klicken. Feste! Tut sich nichts? Nanu? Aha: Es wird hier versucht per javascript:{document.event_suche.submit()}; das Formular abzuschicken. Hab ich nicht bedacht. Schade. ;)

HALLO? Das ist ein simples Formular. Für gewöhnlich schickt man die Dinger ab, indem man irgendwo ins Formular den folgenden, magischen Code einbaut:
<input type="submit">. Das hat momentan in etwa soviel mit Barrierefreiheit zu tun, wie Schalke mit gutem Fußball. Oder Köln mit gutem Bier.

Ganz im Ernst, ich weiß nicht ob das einen tieferen Sinn erfüllen soll, aber zu einem barrierefreien Internetauftritt gehört nun mal, dass die Seite uneingeschränkt oder zumindest gleichwertig für Nutzer mit Browseralternativen zugänglich ist. Dortmund.de ist dies somit erst einmal nicht ohne Weiteres. Und wenn dort auch noch 1000 mal mit der Barrierefreiheit geworben wird. Auf barrierearm lasse ich mich gerne ein. Aber barrierefrei, ne!

Schluss und Ende

Die Seite ist in meinen Augen ein sehr guter und vor allem großer Schritt in die richtige Richtung. Vor allem kenne ich den alten Auftritt sehr gut. Es ist eine Steigerung, ja eine starke Verbesserung. Aber es ist nicht die totale Ausschöpfung des Möglichen. Ganz und garnicht. Und das muss ich anprangern. Nicht weil ich Euch, liebe Dortmund-Agentur einen reinwürgen oder Eure mitunter gute Arbeit schlecht reden möchte, oder ich mich von der Stadt Dortmund ausgebeutet oder als Bürger schlecht behandelt fühle. Nein, sondern weil ich es traurig finde. Es sitzen durchaus fähige Leute IN Dortmund die sicherlich eine wirklich barrierefreie, oder zumindest etwas »barrierefreiere« Version hinbekommen hätten als die, die jetzt als »barrierefreies dortmund.de« unter www1.dortmund.de zu finden ist. Alleine 3 dieser fähigen Leute sind hier in den ersten 10 Ergebnissen zu finden.

Also tut mir den Gefallen, und nehmt Euch meine durchaus gut gemeinten Vorschläge zu Herzen. Ich könnte jetzt noch ewig so weiter kritisieren. Jedoch sollte das erst einmal reichen. Jetzt würde ich mich sehr freuen wenn Ihr handelt und die von mir beschriebenen Einschränkungen und Fehler (soweit es Euer CMS zulässt) behebt. Auf Wunsch komme ich gerne mal auf einen Kaffee bei Euch am Stadtgarten vorbei und stehe Euch beratend zur Seite. Gerne helfe ich auch bei der Fehlerbehebung mit. Letzteres allerdings nur wenn die Bezahlung stimmt ;)

Negativ aufgefallen aber durchaus mit Potential zu mehr:

• Teilweise schwerwiegende Mängel was die absolute Barrierefreiheit betrifft
• An einigen Stellen Code jenseits von gut und böse
• Einige kleinere Schönheitsfehler wie z.B. bei der Kachelung des Headerbildes und der zu langen Zeilenlänge bei hoher Auflösung
• Keine Kennzeichnung von PDF-Downloads
• Mangelhaftes Druck Stylesheet – dafür oft fehlerhafte (unnötige?) Druckversion
• Popups an Stellen an denen auf diese hätte verzichtet werden können
• Inkonsequente Nutzung von Headline Hierarchie

Positiv aufgefallen und den Verantwortlichen anzurechnen:

• Es ist durchaus viel Fleiß und Arbeit erkennbar
• Der Code ist bis auf einige Ausnahmen durchdacht und nachvollziehbar
• Es ist in Sachen Übersichtlichkeit, Aufmachung und auch in der Bedienung ein großer Fortschritt
• Die offensichtlich einzige Seite einer Stadt im Ruhrgebiet, die zeigt, dass von der BITV Kenntnis genommen wurde
• Viele Browser wurden berücksichtigt, an einigen Stellen jedoch leider nicht konsequent
• … dennoch Cross-Browser kompatibel

Link: www.dortmund.de