XHTMLforum

XHTMLforum (http://xhtmlforum.de/index.php)
-   Barrierefreiheit (http://xhtmlforum.de/forumdisplay.php?f=78)
-   -   Relevanz von Barrierefreiheit in einer Administration (http://xhtmlforum.de/showthread.php?t=41032)

superbursche 31.07.2006 17:10

Relevanz von Barrierefreiheit in einer Administration
 
Hallo,
Ich habe vor ein spezielles CMS zu programmieren, in der Planung ist klar geworden das in der Administration viel Javascript und evtl. AJAX verwendung finden wird. Ich bin nun am überlegen in wie weit die Barrierefreiheit in einer Administrationsoberfläche eines CMS relevant/wichtig ist.

Mir ist aufgefallen das die meisten Administrationen nicht einen Pfifferling auf Barrierefreiheit geben und auch JS ohne Fallback verwendet wird.

Was denkt ihr darüber?

Gruß, SB

Lloyd Larkin 01.08.2006 12:42

Barrierefrei wird ein CMS Backend wohl nicht zu realisieren sein, aber wie barrierearm es sein soll hängt wie immer von der Zielgruppe ab.

Ich persönlich würde versuchen das Backend so barrierearm wie möglich zu gestalten, ohne aber allzuviel Zeit dahingehend zu investieren.

Peter Buenemann 03.08.2006 09:16

Hi,

meiner bescheidenen Meinung nach wuerde ich sagen, wenn du den Benutzerkreis klar auf Personen eingrenzen kannst, die damit zurecht kommen, dann brauchst du dir zur Barrierefreiheit keine Gedanken machen. Wenn du aber vor hast, das CMS-System der breiten Öffentlichkeit zur Verfügung zustellen, dann schon. Allerdings wird das sicher keine leichte Aufgabe. Alles eine Frage des Aufwands den du betreiben willst. Das einzige CMS-System, das ich keine, das auch im Backend versucht möglichst barrierarm zu sein ist Papoo. Vielleicht kannst du dir was abschauen.

so long ...

Peter

The Doc 04.08.2006 14:16

Naja, halte dich an diesen Grundsatz (imho einer der wichtigsten im Webdevelopment):

a) Erst Programmlogik (d.h. funktional ohne JS) und Basis Design
b) Tweeks am Design
c) einbetten von JS Widgets, die das ganze verbessern - aber nicht zwangsweise notwendig sind

Dadurch erlangst du automatisch ein unaufdringliches System und wenn du schonmal Joomla / Mamo benutzt hast und plötzlich im JS irgendwas nicht funktionierte (und das bei einem simplen submit button) - dann fragst du dich wirklich, weshalb man soviel JS braucht.

Siegfried 11.08.2006 16:23

Zweierlei:
 
  1. Die Barrierefreiheit des CMS selber ist ziemlich wurscht, da der Umgang damit nur den Administrator was angeht.
  2. Die Barrierefreiheit der damit erzeugten Seiten hingegen ist absolut von Bedeutung! Und wenn man den Kundenkreis nicht definitiv auf ein paar Wenige eingrenzen kann (Intranet), dann sollte man Himmel und Hölle in Bewegung setzen, um das Resultat so barrierearm wie möglich zu bekommen.

Gruß
Siegfried

ciccy 11.08.2006 17:34

ich handhabe das immer so, dass im admintool keine barrierefreiheit besteht, wenn der "admin" es nicht unbedingt benötigt, aber ich für das backend sehr auf barrierearmheit achte, je nach zielgruppe.

barrierearmheit umzusetzen ist wie schon gesagt viel arbeit, man muss sich je nach zielgruppe, adminnutzer etc. fragen, ob das notwendig ist fürs admintool.

so meine persönliche meinung.

grüße
ciccy

Siegfried 12.08.2006 09:59

Arbeit
 
Hi,

eine Seite Barrierearm zu gestalten ist nur in der Anfangsphase schwer und mit Mehrarbeit verbunden. Im Laufe der Site-Entwicklung zahlt sich das aber aus, so daß man auf längere Sicht sogar mit weniger Arbeit auskommt.

Nach meiner Erfahrung ist der häufigste Fehler, den man macht, der, daß man im html Klassennamen vergibt, um eine Handhabe für css Styles zu haben. Also Klassennamen als Vehikel für visuelle Gestaltung. Davon muß man sich lösen. Klassennamen haben zunächst rein gar Nichts mit visueller oder sonstiger Gestaltung zu tun, sondern sind für die Datenstrukturierung da und zur Unterstützug der Semantik (was Beides im Wesentlichen auf das Selbe rausläuft). Die Datenstrukturierung mit html und Klassennamen ist ein Entwicklungsschritt, der vollkommen unabhängig von der medialen Aufbereitung erfolgen kann und erfolgen sollte. Um das zu lernen, hilft es übrigens sehr, die Seite von vornherein mit vielen grundverschiedenen Stylesheets zu erstellen: Ein- und derselbe html-Code soll in der Lage sein, ganz unerschiedlich auszusehen. Und damit meine ich nicht nur ein bisschen Farbe.

Wie wre es z.B. mit einer html-Seite, deren Navigationsbereich mal links als sogenannte Nav-Leiste plaziert wird, und mit einem anderen Style als Tab-Reiter? Welchen Klassennamen gibt man so einem Container? Vielleicht class="links"? Geht nicht, es wäre blöd, wenn ein div class="links" stattdessen oben erscheint. Oder was wäre, wenn in einem anderen Stylesheet dieser Cotainer nun rechts erscheint? Alles möglich, Alles kann Sinn machen. Welcher Klassenname ist also angebracht? Nun, auf jeden Fall einer, der unabhängig ist von der medialen Präsentation. Ein Klassenname, der die Bedeutung, die Funktion des Contaners trägt. Ein div class="navigation" bleibt immer der selbe Container, egal, wo er plaziert wird und ob er vertikal oder horizontal ausgerichtet wird.

Wenn man diese Herangehensweise konsequent durchzieht, bekommt man sehr wahrscheinlich barrierearmen und semantischen Code, der leicht zu pflegen und anzupassen ist.

o_anonym 12.08.2006 13:36

Gut gebrüllt Löwe - bin ganz Deiner Meinung.

Siegfried 12.08.2006 16:02

Brüll
 
Hi,
naja, ich hoffe nicht, daß sich hier Jemand angebrüllt fühlt :) Aber danke für das positive Feedbck.

Dr Snuggles 12.08.2006 17:51

Hallo :)

Fühl mich auch nicht angebrüllt, möchte aber ergänzen & auch widersprechen. Oder halt zurückbrüllen ;)

Den Ausführungen am Beispiel "Klassenname für einen Navigationscontainer" kann ich nur zustimmen. Ist immer sinnvoll & nachhaltiger, selbst bei einer kleinen "statischen" Seiten, die niemals den Anspruch erhebt barrierearm zu werden. Schließlich kann man sie so als Grundlage für das nächste Projekt nehmen oder andere können sich leichter einarbeiten.

Finde das passt gut in die Rubrik Semantik bzw. Trennung von Inhalt und Layout. Beides sehr wichtige Punkte, denn es sind absolut notwendige Grundlagen zur barriereärmeren Umsetzung & darauf sollte sich ein Konzept zur barrierefreieren Gestaltung aufbauen lassen. Anfängliche Mehrarbeit, welche sich später auszahlt wegen leichterer Pflege usw. passt zu diesen Punkten sehr gut. Aber es gehören natürlich noch eine ganze Menge andere Bestandteile dazu.

Zitat:

Die Barrierefreiheit des CMS selber ist ziemlich wurscht, da der Umgang damit nur den Administrator was angeht.
Einspruch ;) Ich finde den Ansatz nicht richtig. Administratoren müssen ja nicht zwangsläufig auf potentielle Barrieren abfahren. Oder auf wurscht ;)

Wieso sollte ein Administrationsbereich also nicht so zugänglich wie möglich sein? Das hieße ja nicht nur spezielle Benutzergruppen auszuschließen, oder gar auch nicht ganz so speziellen Nutzergruppen schwerer als nötig zu machen.
Man sollte hier nicht nur an die für solche Beispiele gerne genommenen Blinden denken. Ein CMS für Blinde oder andere, ähnlich spezielle Nutzerruppen (oder Ausgabegeräte) bedeutet sicher erheblich mehr Aufwand. Vielleicht wäre sogar ein spezielle Version eines Admin-Bereiches sinnvoller? Oder besser sowas in der Richtung "Profi-Einstellungen". Nur mal so als Anregung.

Bei manchen Punkten einer barrierefreien Gestaltung ist es zwar möglich, es (wenigen) Nutzern leichter zu machen und damit bestimmte Kriterien zu erfüllen, aber zum Preis des Komforts für andere (viele) Nutzer. Das widerspricht leider dem Gesamtkonzept der Barrierefreiheit, deshalb gibt es ja immer wieder Diskussionen um die "barriereärmste" Umsetzung mancher Punkte.

Völlige Barrierefreiheit ist nicht möglich & wird es wohl auch niemals sein. Trotzdem finde ich es wichtig, es so einfach wie möglich zu gestalten, denn von einer sinnvollen Zugänglichkeit profitiert jeder Nutzer, selbst Administratoren ;) Damit meine ich eben nicht nur die technische Seite wie Trennung von Layout & Design, validen, semantischen Code usw., sondern auch Benutzerführung, Bedienbarkeit und Sprache die es nicht unbedingt erfordert ein Handbuch zu lesen und es auch Internet-Neulingen ermöglicht ein CMS bedienen zu können. Davon profitieren nunmal auch "Profis", bspw. wenn sich ein CMS (notfalls) ohne Javascript oder per Tastatur administrieren lässt.

Das oben schon genannte papoo geht da sicher den Weg in die richtige Richtung nicht nur die Ausgabeseite barrierefreier zu gestalten. Im Gegensatz zu vielen anderen CMS ist sehr einfach zu bedienen und selbst Internet-Neulinge schaffen es sehr schnell & einfach einen Artikel auf ihrer Webseite zu veröffentlichen. Leider ist es mittlerweile zum Teil kostenpflichtig geworden :(

Soviel erstmal von mir zum Thema, mir fällt aber bestimmt noch was ein ;)

Gruß
Christian

Siegfried 12.08.2006 18:03

wurscht?
 
Hmmm, na gut, mit "wurscht" habe ich wohl etwas übertrieben :) Die Zielgruppe ist aber deutlich überschaubarer.

Bei solchen administrativen Programmen würde ich eher Wert legen auf Usability als auf Accessibility. Beides ist nicht das Selbe. Es gibt zwar reichlich Überschneidungen, aber das Selbe ist es nicht.

Siegfried 13.08.2006 09:52

cms
 
Hi,

übrigens, nur ergänzend: Man könnte hier vielleicht noch weitere zwei Hauptthemen einrichten: xml und xsl. Ich für mich persönlich benutze nämlich dieses als eine Art "cms". Dabei schreibe ich die Dateien in einem sehr html-ähnlichen xml-Dialekt (fast wie gutes ales primitiv-html) und lasse das dann von xalan durch passende xsl Stylesheets in html und xhtml übersetzen. Das wurde notwendig, weil ich erstens sowohl html- als auch xhtml-Version anbiete, und außerdem noch, wenn möglich, in mehr als einer Sprache, und zweitens, weil ich auch innerhalb einer Seite doppelte Arbeit vermeiden wollte. Dies betriefft vor Allem die Navigation. Ich habe beschlossen, die handbearbeitete Version der Site-Navigation in den head-Bereich zu konzentrieren (<link rel=".." ...>) und die sichtbare Navigation daraus per xsl abzuleiten.

So gesehen ist das auch eine Art von cms. Vielleicht gibt es hier im Forum ja Interesse an Diskussionen über xml und/oder xsl. Nur so als Idee...


Alle Zeitangaben in WEZ +2. Es ist jetzt 03:24 Uhr.

Powered by vBulletin® Version 3.8.11 (Deutsch)
Copyright ©2000 - 2021, vBulletin Solutions, Inc.

© Dirk H. 2003 - 2020