nicht angemeldet Rolf Rost
Felix Riesterer
Rolf Rost
Felix Riesterer
molily
xwolf
molily
Glück auf!
Ich habe hier für die Dokumentation eines Projektes einen kurzen Artikel geschrieben, der mit "Barrierefreiheit vs. technische Möglichkeiten" überschrieben ist. Es geht darum zu erklären, was barrierefreies Design bedeutet und ob man unter bestimmten Umständen teilweise drauf verzichten kann.
Ich würde euch bitten, den Artikel (besonders die ersten beiden Absätze) zu lesen und mir Vorschläge für Ergänzungen/Verbesserungen zu machen.
Vielen Dank schonmal!
Gruß,
der Juve
P.S.: Der Artikel selbst ist weder barrierefrei noch sonst irgendwie technisch brauchbar, sondern nur fix aus Word heraus exportiert - für diesen Zweck muss es reichen :)
Hi Juve,
Ich habe hier für die Dokumentation eines Projektes einen kurzen Artikel geschrieben, der mit "Barrierefreiheit vs. technische Möglichkeiten" überschrieben ist. Es geht darum zu erklären, was barrierefreies Design bedeutet und ob man unter bestimmten Umständen teilweise drauf verzichten kann.
Es ist gut, dass Du Dich damit befasst und darüber schreibst. Seitens WebPublisher gibt es dazu immer noch viele Missverständnisse, die sich darin äußern, dass viele dieser Publisher ihre Webseiten in 2 Versionen anbieten:
1. Seiten für Nicht Behinderte
2. Seiten für Behinderte
Wer immer auch einmal mit Behinderten zu tun hatte, oder selbst behindert ist, kann es nachvollziehen, wie diskriminierend sowas auf einen Menschen wirkt, der sich über jede eine noch so kleines Hilfe freut, was ihm hilft, sich in die normale Welt zu integrieren.
Behinderte wollen ganz einfach auch nur das erleben, was auch die Anderen erleben.
Also: Barrierefreie Seiten für Alle und siehe da: die sind somit auch für Nichtbehinderte lesbar.
Falls Du also wirklich darüber schreibst, nimm diesen Gedanken als Preampel auf.
Viele Grüße, Rolf
Lieber Rolf,
nimm diesen Gedanken als Preampel auf.
heißt es nicht "Präambel"?
Liebe Grüße aus Ellwangen,
Felix Riesterer.
Bräampel, würde ich sagen...;
Hi Felix,
nimm diesen Gedanken als Preampel auf.
heißt es nicht "Präambel"?
Rechtschreibung ist doch Ländersache ;-)
Liebe Grüße aus Ellwangen,
VLG aus Lkrs. Karlsruhe-Nord
Rolf (ehem. Thüringer belg. Herkunft)
Lieber Juve,
mich stört folgender Unterpunkt:
- Keine Verwendung von clientseitigen Technologien, bei denen nicht sichergestellt werden kann, dass sie auf allen Clients verfügbar sind. Dazu zählen v.a. JavaScript, ActiveX, Flash, Java-Applets etc.
So formuliert, klingt das nach "das alles ist böse". Du solltest meiner Meinung nach diese Technologien nicht von vornherein ausschließen, sondern verlangen, dass eine Benutzbarkeit ohne diese Technologien trotzdem gewährleistet bleibt.
Beispiel: Eine Seite setzt Javascript ein, um die Bedienung durch kleine Popup-Fenster zu erleichtern. Ohne Javascript bleibt die Seite aber trotzdem voll nutzbar, wenn auch nicht so bequem, da alle Dialoge über Zwischenseiten im Browser geführt werden, die bei Javascript über die Popups abgewickelt würden.
Ebenso wäre eine Flash-Navigation denkbar, die natürlich nur erscheint, wenn Flash beim Client verfügbar ist. Eine solche Seite bietet zunächst eine CSS-Navigation an (auf <ul>s basierend), die mittels Javascript durch die Flash-Version ersetzt wird, falls das Flash-Plugin verfügbar ist.
usw.
Klar, was ich meine?
Liebe Grüße aus Ellwangen,
Felix Riesterer.
Hallo,
gute Einwände, aber ich möchte sie angesichts der unglücklich gewählten Beispiele etwas umdeuten und in eine andere Richtung weiterführen:
So formuliert, klingt das nach "das alles ist böse". Du solltest meiner Meinung nach diese Technologien nicht von vornherein ausschließen, sondern verlangen, dass eine Benutzbarkeit ohne diese Technologien trotzdem gewährleistet bleibt.
Ja, das ist ein wichtiger Punkt. Allerdings erachte ich es als viel wichtiger, dass nicht nur alternativen zur Verfügung stehen, sondern die Techniken auch zum Zwecke der Usability und Accessibility eingesetzt werden.
Beispiel: Eine Seite setzt Javascript ein, um die Bedienung durch kleine Popup-Fenster zu erleichtern. Ohne Javascript bleibt die Seite aber trotzdem voll nutzbar, wenn auch nicht so bequem, da alle Dialoge über Zwischenseiten im Browser geführt werden, die bei Javascript über die Popups abgewickelt würden.
Das Szenario »JavaScript ist nicht verfügbar« zählt gar nicht soviel, höchstens im vollen Maße für Suchmaschinen. Für die meisten Anwender ist eher die sinnvolle und barrierefreie Verwendung von JavaScript relevant. Damit meine ich nicht den möglichen Fallback auf eine Version ohne JavaScript, sondern die Beschränkung auf zugängliche JavaScript-Operationen. Zum Beispiel Popup-Fenster erschweren grundsätzlich die Bedienbarkeit, es muss eine Dialogführung gefunden werden, die in jedem Fall optimalen Bedienkomfort und optimale Zugänglichkeit bietet (alert()-Fenster sind vielleicht etwas anders als eigenständige window.open()-Fenster).
Ebenso wäre eine Flash-Navigation denkbar, die natürlich nur erscheint, wenn Flash beim Client verfügbar ist. Eine solche Seite bietet zunächst eine CSS-Navigation an (auf <ul>s basierend), die mittels Javascript durch die Flash-Version ersetzt wird, falls das Flash-Plugin verfügbar ist.
Flash-Navigationen durch Alternativinhalte zugänglich machen ist Humbug, weil sie inhärent barrierebehaftet sind, selbst wenn man die Accessibility-Features von Flash vollkommen ausschöpft.
Flash für konventionelle Navigationen zu benutzen ist in der Regel eine Milchmannrechnung, weil der Mehrwert hinsichtlich besserer Orientierung und einfacherer Informationsfindung gegenüber einer statischen Navigation meist gering ist. Will man Barrieren abbauen, so ist Alternativ-Version selbstverständlich zwingend, i.d.R. würde man aber darauf kommen, auf eine Flash-Navigation zu verzichten. (Oder die Flash-Navigation verfolgt einen ganz anderen Ansatz als die statische und ist eher ein zusätzliches Navigationsangebot. Die statische wäre dann nicht dessen äquivalente Textalternative.)
Mathias
Lieber Mathias,
Allerdings erachte ich es als viel wichtiger, dass nicht nur alternativen zur Verfügung stehen, sondern die Techniken auch zum Zwecke der Usability und Accessibility eingesetzt werden.
Im Prinzip hatte ich das mit meinen Beispielen gemeint, aber Du kannst es besser ausdrücken.
Zum Beispiel Popup-Fenster erschweren grundsätzlich die Bedienbarkeit, es muss eine Dialogführung gefunden werden, die in jedem Fall optimalen Bedienkomfort und optimale Zugänglichkeit bietet (alert()-Fenster sind vielleicht etwas anders als eigenständige window.open()-Fenster).
Deinen von Dir verlinkten Artikel habe ich jetzt inpuncto "erschweren grundsätzlich Bedienbarkeit" nicht ganz verstanden... Meintest Du "erschweren die Umsetzung für optimale Bedienbarkeit"?
Ich möchte ein Beispiel nennen: In meinem Forum gibt es einen Link "FAQ", der mit Javascript ein Popup öffnet, so dass man zwischen Forum und FAQ hin- und herschalten kann. Ist Javascript nicht verfügbar/deaktiviert, so öffnen sich die FAQ im bereits vorhandenen Fenster. In den FAQ ist ein Link "zurück zum Forum", der im Popup das Popup lediglich schließt, bei nicht verfügbarem Javscript jedoch auf die Forumsseite zurückführt. Ist das nun Usability/Accessibility?
Flash für konventionelle Navigationen zu benutzen ist in der Regel eine Milchmannrechnung, weil der Mehrwert hinsichtlich besserer Orientierung und einfacherer Informationsfindung gegenüber einer statischen Navigation meist gering ist.
Da stimme ich Dir zu. Lediglich die grafischen Effekte lassen Javascript und CSS weit hinter sich. Daher wird es zum "designen" halt gerne eingesetzt.
(Oder die Flash-Navigation verfolgt einen ganz anderen Ansatz als die statische und ist eher ein zusätzliches Navigationsangebot. Die statische wäre dann nicht dessen äquivalente Textalternative.)
Damit wäre aber ohne Flash dem Benutzer nicht möglich, alle Inhalte der Seite zu erreichen. Aber wenn es nur um Usability geht, dann kann man das sicherlich gutheißen.
Liebe Grüße aus Ellwangen,
Felix Riesterer.
hallo juve,
ist doch verständlich geschrieben. das mit der barrierefreiheit gabs übrignes schonmal für cinemascope-format. das war im kino so breit, dass für die tv-auswertung nur ausschnitte gewählt werden konnten. statt 5 personen sind dann nur noch 2 sichtbar etc.; allerdings ist im kino cinemascopt schlicht unschlagbar!
im dritten absatz erwähnts du ja, dass barrierefreiheit immer relativ ist, d.h. im intranet einer firma, die keine behinderten beschäftigt und nur 1024-monitore angeschafft hat, wäre ja zu fragen, warum auf die technischen möglichkeite zu verzichten wären, denn im intranet werden dadurch ja keine barrieren aufgebaut.
es lebe das hörspiel.
frankx
Hallo,
im dritten absatz erwähnts du ja, dass barrierefreiheit immer relativ ist, d.h. im intranet einer firma, die keine behinderten beschäftigt und nur 1024-monitore angeschafft hat, wäre ja zu fragen, warum auf die technischen möglichkeite zu verzichten wären, denn im intranet werden dadurch ja keine barrieren aufgebaut.
Ich wittere da ein Missverständnis: Die Accessibility fordert kein Herunterwirtschaften auf den kleinsten gemeinsamen Nenner. Wer glaubt, Accessibility heißt zwangsläufig und notwendigerweise, auf technische Möglichkeiten zu verzichten, hat sie m.M.n. von Grund auf falsch verstanden.
Technische Möglichkeiten sollten möglichst immer überall genutzt werden, sofern sie die Bedienbarkeit und den Komfort vermehren. Dabei sollten System mit begrenzteren Möglichkeiten möglichst nicht benachteiligt werden, sondern ebenfalls deren Möglichkeiten voll ausgeschöpft werden.
Wenn man beides unter einen Hut bekommt, dann hat man eine barrierefreie Seite: Jeden nach seinen Fähigkeiten und Bedürfnissen bedienen. Das Konzept nennt sich graceful degradation.
Mathias
Hi,
Ich habe hier für die Dokumentation eines Projektes einen kurzen Artikel geschrieben, der mit "Barrierefreiheit vs. technische Möglichkeiten" überschrieben ist. Es geht darum zu erklären, was barrierefreies Design bedeutet und ob man unter bestimmten Umständen teilweise drauf verzichten kann.
Den Satz " Auch für die Suchmaschinenoptimierung ist ein barriefreies Design sehr hilfreich." würde ich noch besser betonen:
"Seiten die nach den Prinzipien der Barrierefreiheit gebaut wurden, beinhalten bereits viele Aspekte, die auch bei der Optimierung für Suchmaschinen eine Rolle spielen. Eine Seite mit wenig Barrieren wird besser gefunden als Seiten, die nicht barrierefrei sind."
Den 3ten Punkt deiner AUfzählung:
"- Keine Verwendung von Frame-Technologien"
würde ich weglassen, da dies eigentlich bereits durch den vorherigen Punkt vertreten wird. Die klassischen Frames sind garnicht mehr in XHTML strict enthalten.
Den zweiten AUfzählungspunkt würde ich auch eher so schreiben:
"Strenge EInhaltung der internationalen Standards des W3C, insbesondere in Bezug auf Markup-Sprachen und Accessibility."
Was du in dem Zusammenhang auch ansprechen sollte ist der Aspekt der Nachhaltigkeit.
Jeder weiss ja, das bei vielen Sites nach 3-5 Jahren ein Relaunch ansteht.
Bei Websites die nach den Richtlinien der Barrierefreiheit gestaltet wurde, hat dies spätestens zum Zeitpunkt des Relaunches enorme Vorteile.
Im Prinzip muss bei einem Relaunch nur mehr das CSS ausgetauscht werden.
Inhalte, xHTML etc. können unangetastet bleiben, so das Kosten für Migration oder SOftwareupdates (neues CMS) entfallen und nur mehr ein CSS-Designer bezahlt werden muss.
Ebenso sollte man erwähnen, daß die EInhaltung der Standards eine Zukunftssicherheit gegenüber kommende Browserentwicklungen bietet. Die Nutzung von properitären Techniken dagegen kann in Sackgassen führen.
Mit den letzten Absatz hab ich so meine Probleme.
Ich kann mir nicht vorstellen, daß es "Design-Tags" gibt, die bewirken daß das Design versaut wird. Und das wird es nämlich, wenn man sich auf eine feste Breite festlegt.
Keep in mind: Verkaufte Bildschirme heute und gestern.
Heute kriegt man kein 15Zoll Bildschirm mehr zu kaufen. Stattdessen kriegt man bei Neukauft eigentlich immer ab 17 Zoll. Firmen, die große Sammelaufträge machen, werden sicherlich 19 oder 20 Zoll in Betracht ziehen.
Dort sind dann Browserauflösungen drin, die bis zu 200 Pixel gehen, je nach Einstellung. Das bedeutet aber nicht mehr, daß die Leute dann auch noch wirklich Fullscreen arbeiten, sondern es bedeutet, daß die Leute immer mehr dazu übergehen, Browserfenster zu skalieren in eine variable Größe, je nachdem wie es den Leuten gefällt.
Das Argument, daß bei einem Webauftritt Teile nicht valide sein können, kann ich nicht nachvollziehen. Das kann allenfalls für die Teile der Site anfallen, die durch andere Programme dynamisch erzeugt werden.
Aber auch dort kann man ein Kompromiss finden, indem man dann nicht XHTML strict nimmt, siondern HTML4 Transistional.
Denn das sollte nun jedes Programm erreichen, ansonsten kann man es in die Wüste kicken.
Ciao,
Wolfgang
Tach auch,
Nach den ganzen Gratulationen mit nur leichten Ergaenzungen will ich dann mal ein bisschen meckern.
Ich habe hier für die Dokumentation eines Projektes einen kurzen Artikel geschrieben, der mit "Barrierefreiheit vs. technische Möglichkeiten" überschrieben ist.
Schoen. Mit "Barrierefreiheit vs. technische Möglichkeiten" ueberschrieben. Und dann ist gleich der erste Satz "Eine wesentliche Überlegung bei Webanwendungen jeder Art ist das Thema Barrierefreiheit". Das passt dann aber nicht mehr richtig zu der Ueberschrift. Barrierefreiheit (mal davon abgesehen dass ich den Begriff hasse, aber das ist ein anderes Thema, siehe Archiv) ist mehr als "technische Moeglichkeiten". Weitaus mehr.
Was ist denn z.B mit farbenblinden Benutzern? Benutzt Deine Anwendung eventuell irgendwelche Farbcodierungen oder sogar etwas wie "klicken Sie auf die gruene Schaltflaeche"? Und wie gehst Du damit um?
Was ist mit Leuten die "webunerfahren" sind? Welche Hilfen werden denen zur Seite gestellt und wie ist die Benutzerfuehrung gestaltet? Werden Fachbegriffe und Jargon weitestmoeglich vermieden?
Was ist mit Leuten die nicht gut lesen koennen aber wunderbar mit einem grafischen System zurechtkommen bei dem sie nur auf irgendwelche Abbildungen klicken muessen? Du gibst nicht an was Deine Anwendung denn nun macht, vielleicht waere gerade das eine barrierefreie Anwendung fuer jemanden in einem Lager?
Es geht darum zu erklären, was barrierefreies Design bedeutet
Was denn nun? Barrierefreies Design oder nur wie man sicherstellen kann dass eine Anwendung mit allen moeglichen Geraeten benutzt werden kann?
Irgendwann solltest Du Dich entscheiden...
Ich würde euch bitten, den Artikel (besonders die ersten beiden Absätze) zu lesen und mir Vorschläge für Ergänzungen/Verbesserungen zu machen.
Entscheide Dich fuer ein Thema und beschraenke Dich dann darauf ;-)
In meinen Augen liest sich das ganze etwas unstruktiert und als ob Du nicht genau weisst wo Du nun eigentlich hinwillst.
Und lies Dir noch einmal einige der Saetze genau durch, z.B. "oder es wird in der gesamten Firma nur ein Betriebssystem entwickelt", entweder fehlt da ein Wort oder Du benutzt ein falsches Wort.
Der Artikel selbst ist weder barrierefrei noch sonst irgendwie technisch brauchbar
Je nach Addressat wirklich nicht. Insbesondere der letzte Absatz, der vor Jargon nur so strotzt ;-)
Hallo,
Keine Verwendung von clientseitigen Technologien, bei denen nicht sichergestellt werden kann, dass sie auf allen Clients verfügbar sind. Dazu zählen v.a. JavaScript, ActiveX, Flash, Java-Applets etc.
Verzeihung, aber ich halte diese Herangehensweise für kontraproduktiven Unsinn, sie verhindert jede unvoreingenommene Diskussion über die Zugänglichkeit und Nützlichkeit solcher Techniken, vor allem im Dienste der Barrierefreiheit.
Zunächst einmal: Es kann niemals sichergestellt werden, dass alle verwendeten clientseitige Techniken wie gewünscht funktionieren. Vor allem gilt das für HTML und CSS. Die Trennung von strukturiertem Inhalt und der Präsentation, die ganze Semantikdebatte hat den Sinn, die Präsentation optional zu machen. Gemäß dem obigen Satz müsste man auf CSS vollkommen verzichten - es ist nicht sichergestellt, dass CSS auf allen Clients hinreichend verfügbar ist. Aber auch HTML-Features werden unterschiedlich korrekt und vollständig implementiert. Nein, allein der Verzicht auf alles, was irgendein Client nicht unterstützt, kann kein Ansatz sein.
Wie in meinen anderen Beiträgen gesagt lautet das Zauberwort »graceful degradation«. Man baut eine umgekehrte Pyramide, ganz unten das allerwichtigste, der Textinhalt und gegebenenfalls die grundlegende interaktive Funktionalität (etwa Formulare). Wenn sonst nichts klappt, ist die Seite dadurch immer noch nutzbar. Darauf setzt man weitere Techniken, Grafiken als bessere Repräsentationen von Texten, CSS für die Präsentation, die den Inhalten erst eine benutzerfreundliche Form gibt, sowie unobtrusive JavaScript für den Behavior Layer, der den Bedienkomfort weiter verbessert.
Wenn man dieses Gerüst hat, beschränkt sich der Einsatz von weiteren aktiven Inhalten auf die Fälle, die bisher prinzipiell nicht abgedeckt wurden. Und in diesen Fällen sind solche Inhalte »erlaubt« und unproblematisch, denn sie bauen auf dem bereits vorhandenen abwärtskompatiblen Gerüst auf und bilden die oberste Stufe. Natürlich muss gewährleistet sein, dass ihre Funktion im Gesamtkonzept stimmt, dass sie den besagten Mehrwert bieten, dass solche genuin neue Inhalte wiederum in sich zugänglich sein sollten. Es ist jedoch unter der Annahme dieses – sicher nicht universalen, aber als ein Modell der Barrierefreiheit brauchbaren – Konzeptes nichts prinzipiell gegen den Einsatz von aktiven Inhalten einzuwenden.
Mathias
Glück auf!
Zuerstmal vielen Dank an alle für eure Anregungen und Kritiken. Ich habe versucht, sie soweit wie möglich aufzugreifen und den Artikel zu überarbeiten. Die neue Version befindet sich wieder hier.
Nochmal zur Erklärung: Es handelt sich hierbei um den Ausschnitt aus einer kompletten Projektdokumentation. Der erste Abschnitt beschäftigt sich mit den grundlegenden technischen Überlegungen zur Barrierefreiheit, der zweite analysiert das Web-Frontend des Projekts unter den in 1. genannten Gesichtspunkten. Da es sich um ein Projekt im Rahmen des Studiums handelt, ist der Adressat der betreuende Dozent, somit ist der "Fachjargon" nicht unangemessen.
Dank und Gruß,
der Juve
