Kommentare zu dieser Meldung: 10

Peter Königsdorfer meinte am 05.11.2007:

Ich bin Webentwickler und gerade dabei, ein CMS auf .NET und AJAX-Basis zu erstellen. Dabei habe ich mir Gedanken zu dessen Barrierefreiheit in Verbindung mit meinen anderen Ansprüchen gemacht.

Das CMS soll ein echtes Software-Erlebnis bieten und dabei besser aussehen, als alles, was auf dem Markt ist.

Dass die Ausgabe barrierefrei sein muss, darüber gibt es keine Zweifel.

Im Backend hingegen stellt sich die Frage. Es ist mit heutigem CSS und HTML kaum möglich, ein perfektes und skalierbares Interface-Layout ohne tief verschachtelte Tabellen und extremem Einsatz von JS hinzukriegen * , im Gegensatz zum Frontend, wo es auch bei anspruchsvollen Layouts auf ein paar Pixel mehr oder weniger nicht drauf ankommt.

* Wobei das zum Teil am unglaublich schlecht rendernden IE 7 liegt, den ich geradezu für eine Frechheit halte, wenn man seine nicht vorhandenen Fähigkeiten mit den Werbesprüchen vergleicht und dabei bedenkt, dass wir heute 2007 haben, mit gut ausformulierten Standards.

Mit perfektem Backend-Layout meine ich ein Interface, dass auf den Design-Guidelines von Windows Vista beruht, und vom Betriebssystem nicht zu unterscheiden ist und das z.B. auch ein MAC-Theme beinhaltet.

Ein weiteres Hindernis ist AJAX. Die Vorteile für Benutzer ohne Behinderung sind in Performance und Bedien-Feeling gewaltig, so dass ich es fast als technischen Fehler ansehen würde, das nicht zu verwenden. Ausserdem bietet JavaScript enorme Vorteile in HTML-Handling gegenüber jeder serverseitigen Sprache und ich kann damit auf manches Server-Script verzichten und benötige nur noch wenige Schnittstellen für das Auslesen aus der Datenbank und Bereitstellen von Daten als XML.

In dieser Grössenordnung sind Fallbacks aber nur noch mit riesigem Aufwand zu verwirklichen, auf eine Weise, dass sich die Vorteile von AJAX für mich als Entwickler praktisch in der Luft auflösen.

Jetzt stellt sich die Frage, ob Benutzer mit (Seh-)Behinderungen überhaupt CMS-Bediener sind.

Wenn nein, liegt es daran, dass CMS grundsätzlich nicht darauf ausgelegt sind? Da ich praktisch schon alle frei erhältlichen CMS getestet habe, liegt dieser Schluss nahe. Wenn diese schon für mich teilweise kaum benutzbar sind, wie auch für Nutzer mit Einschränkungen?

Wenn nein, kann es daran liegen, dass Web-Editoren grundsätzlich nicht von sehbehinderten Nutzern bedient werden können, da diese auf visuelle Interaktion ausgelegt sind?

Wenn ja, welche CMS werden verwendet?

Diese Fragen stellen sich für mich aus zwei Gründen:
1. moralische Überlegung: einfach für alle
2. finanziell, da Backend-Barrierefreiheit nur mit enormem Aufwand umzusetzen ist: gibt es überhaupt eine genügend grosse Zielgruppe?

Wenn es eine Zielgruppe gäbe, die aber aktuell nicht bedient wird, könnte ich mir das neben der Moral als enormes Marketing-Argument vorstellen.

Wenn Backend-Barriere-Freiheit erstrebenswert wäre: welche Methoden der Bedienung würden z.B. sehbehinderte Nutzer vorziehen? Gibt es da Untersuchungen oder hat jemand eigene Erfahrungen gemacht?

Jan Eric Hellbusch meinte am 06.11.2007:

Zur Klärung der Kritik an Typolight: Ich bezweifele nicht, dass ohne Weiteres standardkonforme Seiten hergestellt werden können. Das Backend ist im Allgemeinen gut strukturiert und macht einen positiven Eindruck. Allerdings ist mit einem standardkonformen Backend noch leider keine Barrierefreiheit erreicht. Ich habe eine Installation im Sommer 2007 vorgenommen und das CMS war für Screenreader zwar zugänglich, aber sicher nicht gut nutzbar. Insbesondere die Navigationsmenüs bereiteten durch die onclick-Geschichte (offenbar auch von TYPO3 übernommen ...) Probleme. Ich habe eine Liste der offensichtlichsten Barrieren dem Anbieter mitgeteilt, aber keine Antwort mehr bekommen.

Peter Königsdorfer meinte am 06.11.2007:

Das die Ausgabe semantisch einwandfrei sein muss, darüber gibt es keine Zweifel.

Beim Backend allerdings würde ich es vorziehen(um es jetzt mal alleine von meiner technischen Seite her zu sehen), für mich passende Elemente zu nehmen, statt semantische.

Beispiel 1- Menus:
Es gibt für die Funktionalität keinen Grund, Links zu verwenden, wenn der Trigger immer auf die gleiche Seite führt und ich dafür ein überflüssiges href-Attribut habe und PreventDefault einsetzen muss. Ein einfaches span mit tiltle innerhalb li würde ausreichen und das span auch nur, damit ich eine Element mehr zum formatieren habe.

Beispiel 2- Layout: Eigentlich hasse ich floats, da die Neben-Wirkung "Element dehnt nicht Eltern-Element aus" niemals von mir so gebraucht wurde, wie es vom W3C gedacht war.

Ebenfalls fehlen ausser Tabellen jedes HTML-Element und jede aktuell nutzbare CSS-Eigenschaft, die eine Spalte beschreibt, die weiss, wie breit ihre Nachbarn sind und auf die man prozentuale Werte ansetzen könnte. Natürlich könnte ich per JS umfangreiche Berechnungen vornehmen, aber mit Tabellen werden die wenigstens kürzer und das Default-Verhalten reagiert schon halbwegs wie erwünscht.

Beispiel 3- Fieldset:
Ein AJAX-CMS benötigt überhaupt kein form-Element. Ausserdem ist das Element fieldset auch optisch ein Renner und macht nicht unbedingt nur in Formularen Sinn. Man könnte das natürlich auch mit hx und einem Div nachspielen.

Es würde mir allerdings noch eine andere Methode vorschweben:
Da alle Templates in XML hinterlegt sind, wäre eine barrierefreie Version kein Ding der Unmöglichkeit. Alles in einem ist auf einer Webseite kein Problem und es wird technisch nie eine zweite Version benötigt. In einem Backend würde der Code so aber enorm anwachsen und schwerer wartbar werden.

Dazu würde ich gerne mal wissen, wie sich Menschen mit Einschränkungen so ein System überhaupt vorstellen.
Es ist ja eine Sache, ob das System barrierearm ist, weil es semantische Element einsetzt. Das heisst ja nicht automatisch, dass das Arbeiten damit auch Spass macht, sondern nur, dass es mit Mühe möglich ist.

Eben das Beispiel Tree: für Nutzer ohne Einschränkungen ist ein Tree eine platzsparende und leicht begreifliche Methode. Was optisch wunderbar aussieht, kann aber ohne Weiteres 1000 Element beinhalten, was schon für leicht sehbehinderte oder ältere Menschen zum Problem wird.

Wie würden sich eingeschränkte Nutzer das Navigieren in vielen Daten vorstellen? Wäre etwas in der Art eines Wizards denkbar, wo sich auf einem Panel nur aktuell benötigte Daten(z.B. nur ein Teilbaum) befinden?

Tomas Caspers meinte am 06.11.2007:

> Beispiel 2- Layout: Eigentlich hasse ich floats, da die
> Neben-Wirkung "Element dehnt nicht Eltern-Element aus"
> niemals von mir so gebraucht wurde, wie es vom W3C gedacht
> war.

Warum das so ist und was man dagegen mit ein paar Zeilen Code machen kann lässt sich in der YAML-Doku nachlesen.

> Ebenfalls fehlen ausser Tabellen jedes HTML-Element und jede
> aktuell nutzbare CSS-Eigenschaft, die eine Spalte
> beschreibt, die weiss, wie breit ihre Nachbarn sind und auf
> die man prozentuale Werte ansetzen könnte.

Moment, wenn es Spalten und Abhängigkeiten bzw. Zusammenhänge der Spalteninhalte zueinander gibt, dann handelt es sich doch wohl offensichtlich um eine Datentabelle, oder? Dann spricht doch nichts dagegen, diese auch als Datentabelle auszuzeichnen und schon hat man die gewünschten Eigenschaften.

> Eben das Beispiel Tree: für Nutzer ohne Einschränkungen ist
> ein Tree eine platzsparende und leicht begreifliche Methode.
> Was optisch wunderbar aussieht, kann aber ohne Weiteres 1000
> Element beinhalten, was schon für leicht sehbehinderte oder
> ältere Menschen zum Problem wird.

Nein, nicht wenn man den Tree auch als solchen aufbaut. Wie das geht kann man bei WAI-ARIA unter 2.3 Example: building a tree view in XHTML 1.0. Funktioniert in allen modernen Screenreader-/ Browser-Kombinationen (z.B. mit Window Eyes und Firefox ab 1.5!)

Peter Königsdorfer meinte am 06.11.2007:

>Warum das so ist und was man dagegen mit ein paar Zeilen Code machen kann lässt sich in der [YAML-Doku] nachlesen.
Natürlich sind mir die Techniken zur Aufhebung von floats bekannt.

>Moment, wenn es Spalten und Abhängigkeiten bzw. Zusammenhänge der Spalteninhalte zueinander gibt, dann handelt es sich doch wohl offensichtlich um eine Datentabelle, oder?
Ein Tree neben einer Dialogbox ist meiner Meinung nach keine Datentabelle.

>Nein, nicht wenn man den Tree auch als solchen aufbaut.
Ich weiss schon, wie man einen Tree in XHTML inklusive sämtlicher barrierefreien Elemente aufbaut. Die Frage ist nicht, ob der Baum benutzbar ist, sondern ob es Spass macht und effizient ist, einen tief verschachtelten Baum mit 1000 Elementen zu bedienen. Da würde mich wirklich interessieren, ob es da andere Techniken gibt, bin natürlich ebenfalls intensiv am googlen.

Ich habe nicht vor, tausend Arbeitsstunden in ein CMS basierend auf einigen Annahmen zu werfen, damit einer daher kommt und sagt, es sei einigermassen benutzbar. Wenn ich das mache, dann muss das Ziel sein, dass es sich ernsthaft positiv abhebt und einer das System mit Freude kauft, weil es genau auf seine Bedürfnisse passt.

Tomas Caspers meinte am 06.11.2007:

> Ein Tree neben einer Dialogbox ist meiner Meinung
> nach keine Datentabelle.

Dann habe ich die ursprüngliche Fragestellung nicht oder falsch verstanden. Vielleicht können Sie die nochmal neu formulieren?

> Die Frage ist nicht, ob der Baum benutzbar ist, sondern
> ob es Spass macht und effizient ist, einen tief verschachtelten
> Baum mit 1000 Elementen zu bedienen.

Die Frage stellt sich doch gar nicht - wenn eine Struktur tausende Elemente beinhaltet (ich nehme an, weil so viele Daten vorhanden sind), wenn diese sinnvoll strukturiert und über eine Baumstruktur navigierbar sind - wo sollte da das Problem sein? Dann könnte man ja gleich auch den Windows Explorer oder Mac Finder verbieten wollen, nur weil da so viele Daten drin sind.

Darius-Nikolaus Krupinski meinte am 06.11.2007:

Ich habe noch nicht verstanden, was an dem onclick="this.blur" so schlimm ist?
Ich kann sowohl im IE 6/7 als auch im Firefox (ab 1.5) darin problemlos jeden Link per Tastatur erreichen!
Was habe ich übersehen?

Tomas Caspers meinte am 06.11.2007:

Stimmt natürlich. Ich nehme an der Kollege meinte auch onfocus und nicht onclick, oder?

Peter Königsdorfer meinte am 06.11.2007:

>Dann habe ich die ursprüngliche Fragestellung nicht oder falsch verstanden. Vielleicht können Sie die nochmal neu formulieren?

Es stellt für mich keine Schwierigkeit dar, ein normales Spalten-Layout barrierefrei und mit semantischen Elementen hinzukriegen, aber eines, ein Interface zu erstellen, dass genau so aussieht wie z.B. ein Outlook in Vista. Dazu braucht man mit heutigen HTML/CSS-Mitteln eine Tabellen-Wüste, die intensivst per JS auch bei jedem Resize neu berechnet wird.

>Die Frage stellt sich doch gar nicht - wenn eine Struktur tausende Elemente beinhaltet (ich nehme an, weil so viele Daten vorhanden sind), wenn diese sinnvoll strukturiert und über eine Baumstruktur navigierbar sind - wo sollte da das Problem sein?
Eben frage ich mich, ob das wirklich so ist, ich möchte mich da eben nicht auf ein Bauchgefühl verlassen: er wird es dann schon bedienen können, wenn alles schön semantisch ist.
Ich stelle mir vor, dass ein Navigieren per Maus durch 1000 verschachtelte Einträge nicht gerade lustig ist, selbst wenn man alle Regeln einhält.
Ich hatte auch schon in einem anderen Forum Diskussionen darüber. Das Problem dabei ist, dass ich nie das Wort eines Betroffenen gehört habe.

Darius-Nikolaus Krupinski meinte am 06.11.2007:

Was Jan Eric gemeint hat, weiß ich nicht! ;-)

Fakt ist, daß sowohl im Frontend als auch im Backend (meiner Testinstallation) nur onclick=... verwendet wird.

onfocus wäre natürlich "böse"!

Kommentar abgeben?

 

Ihr Kommentar:

Tipp: HTML ist nicht zulässig; Webadressen können Sie so: [url=domain.de]Text[/url] eingeben.

Ihr Name:

Ihre E-Mail-Adresse: (wird nicht veröffentlicht)

URL: (wird bei Spamverdacht gelöscht)

Kommentar senden