Eine Frage, die leider viel zu selten gestellt wird: ist das Content Management System (CMS), das man nutzt, auch zugänglich und barrierearm.
456 Berea Street sammelt gerade CMS-Systeme, die auch zugänglich sind.
In my dayjob as a front-end developer I always make sure that whatever CMS we use will at least allow the published content to be accessible and standards compliant. But the admin interface used to publish content is a different matter.
Quelle: Content management systems and accessibility
Stimmt: man wählt den x-ten WYSIWYG-Editor aus, damit publizierte Inhalt des CMS standardkonform ist. Aber die Benutzeroberfläche … Interessant ist auch die Fragestellung, ob Open-Source-Systeme größeren Wert auf Barrierefreiheit und Standards legen als große kommerzielle Systeme.
Im Gegensatz zum Frontend, ist das Backend in meinen Augen keine Webseite im eigentlichen Sinn, sondern eine Webanwendung und man sollte hier vielleicht auch mehr in Zugänglichkeit eines Betriebssystems oder einer Software denken, als von den Regeln zur Zugänglichkeit einer Webseite.
Für ein Backend halte ich wichtig Übersicht, Komfort in der Bedienung, Adaption und leicht verständliche Erklärungen und Status/Fehlermeldungen.
Aber auf der einen Seite einen WYSIWYG Editor zu erwarten, auf der anderen Seite kein JavaScript einsetzen zu wollen ist halt irgendwo ein Widerspruch in sich…
Eher ich hier noch als Javascript-Kostverächterin ende: natürlich halte ich es für durchaus nützliche Javascript einzusetzen im Back- und Frontend, wenn es Usability und Bedienbarkeit fördert. Bei AJAX sehe ich derzeit nur ein wenig den Übereinsatz für mitunter an und für sich „leichte“ Einsätze.
Klar, über Usability und Bedienbarkeit – die Punkte haben Sie ja alle gut angespochen – sollte man eigentlich gar nicht diskutieren müssen, das Streben danach sollte Pflicht sein.
Schliesslich unterstützen diese Richtlinien ja auch die Barrierefreiheit.
Ich denke, ich unterscheide nicht so strikt zwischen Webseite und – anwendung, weil z.B. wenn beide auf PHP und Datenbank basieren und beide eine Ausgabe von Templates haben, ist das für mich egal – dann ist alles für mich Webseite. 🙂 Aber das ist eher der technische Blick. Andererseits sind Backendsysteme, die im Web erreichbar sind, auch Webseiten oder?
Aber vielleicht ist das Haarspalterei und führt nicht weiter. Wahrscheinlich ist der Begriff Webanwendung dann allgemein gängiger.
Im übrigen wird der WYSIWYG Editor vom Kunden erwartet, nicht von mir. Ich würde im Sinne einer valideren und erwartbareren Ausgabe gerne darauf verzichten wollen. 🙂
Ich seh halt nur 2 Möglichkeiten, entweder ich kenne html oder eben eine vom CMS verwendete Metasprache, ich baue einen Editor für Inhalte mit möglichst wenigen Optionen (wegen den vielen Formularfeldern) und biete eine rein in HTML gebaute Seite an, über welche Inhalte ins System gestellt werden. Da setze ich fast schon vorraus, dass der Benutzer sehr viel Wissen mit sich bringt und im Prinzip Erfahrung in Webdesign hat.
So ein Bakcend ist dann natürlich sogar durch einen einfachen Textbrowser nutzbar.
Oder aber ich baue ein System, welches beim User sehr wenig voraussetzt und intuitiv bedienbar ist und im Idealfall per dynamsicher Adaption sich an das Verhalten des Users auch anpasst. Dazu brauche ich aber die Möglichkeit Elemente ohne eine Seite komplett neu zu laden dynamsich (per Ajax) einzubinden.
Streng ich mich noch etwas an kann ich es vielleicht sogar schaffen, ein System zu bauen, welches beide Formen des Backends liefern kann.
Ich frage mich aber einfach wie baue ich ein leicht zu beidehnendes System für Benutzer ohne Weberfahrung, mit Verzicht auf Javascript (und damit WYSIWYG)
Es ist kein Problem ein nach WCAG barrierefreies Backend zu gestalten – nur wer kann das dann noch nutzen ohne sich sehr lange darin einzuarbeiten, zumindest eben in markup
Hm – sicherlich, das stimme ich Ihnen weitgehend zu. Ich kenne auch nur CMSe, die in wesentlichen Funktionalitäten auf Javascript aufbauen. Also ohne Javascript würden da auch Schwierigkeiten auftreten. 🙂
Diese HTML-Variante, die Sie beschreiben, wäre dann wirklich nur für denjenigen, der weiss was er gebaut hat und tut.
Sowas hat man sich früher selbst mit ein paar HTML/PHP Seiten zusammengeschustert, und selbst fand man es exrem unkomfortabel. 🙂
Vielleicht finde ich die Frage von 456 Berea Street schlicht ein Startpunkt, um immer mal nachzuhaken, etwa der Frage nachzugehen, wie updatefähig ist ein AJAX Framework in die Zukunft. Kann man nur Pixel einsetzen oder läßt sich da auch em em oder Prozente integrieren.
Ich denke, dass man auf so eine Form von AJAX ähnlichem Konstrukt im Backend nicht verzichten kann, wenn man a. Usabililty und Komfort im Auge hat und b. mit anderen CMSen konkurrieren will.
Entgegen weitverbreiteter Meinung ist Javascript nicht (mehr) per se der Barrierefreiheit abträglich. Moderne Screenreader kommen damit ganz gut zu Recht. Problematisch ist lediglich, wenn durch die Verwendung von AJAX sich an mehren Stellen des Dokumentes, die bereits gelesen wurden, Änderungen ergeben.
CMS sind (oder sollten zumindest sein) hochoptimierte Anwendungen, für die mMn. der Grundsatz für öffentlich zugängliche Sites – „Eine Version für Alle!“ – nicht mehr gelten kann.
Was soll eine Blinder mit einer WYSIWYG-Ansicht? Hier ist eine semantische Auszeichnungsmöglichkeit, z.B. mittels einer einfachen Syntax evtl. in Verbindung mit Accesskeys sinnvoll.
Eine Bilderdatenbank für blinde Redakteure muss auch ganz anders funktionieren, als für Sehende.
Gruß, Kai
Hallo Kai, 🙂
Richtig, Javascript ist nicht per se ein Hürde. Jedoch AJAX meisthin immer noch. In letzter Zeit durfte ich einige derartige Beispiele mit Screenreadern durchsehen. Am schönsten war die Reaktion von Blindows auf einen durch AJAX eingesetzte Layer: „OOhhh“ und dann hörte man nichts mehr. 🙂
Auf diese und ähnliche Schwierigkeiten stosse ich dabei immer wieder in der Praxis. Bei AJAX fangen schon etliche Probleme an.
Das mit dem Backend ist halt so eine Sache. Wo fängt man mit einer Optimierung an. Klar – das hört sich markig an, was macht ein Blinder mit einem WYSIWYG-Editor. Aber was meint man genau damit? Ein Blinder kann auch mit einer einfachen Webseite Schwierigkeiten haben. So what?! Wenn der Editor standardgemäß erreicht und benutzt werden kann, hat auch ein Blinder damit bessere Möglichkeiten oder? Aber ich denke, so hast Du das ja auch gemeint.
Ich schlage mich derzeit eher mit solchen Fragen im Backend rum. Wenn das Backend etwa vollstängig auf einem Javascript Framework aufbaut, was bedeutet das für die Zugänglichkeit. Kann man das dann ganz vergessen usw..
[quote comment=“1521″]CMS sind (oder sollten zumindest sein) hochoptimierte Anwendungen, für die mMn. der Grundsatz für öffentlich zugängliche Sites – „Eine Version für Alle!“ – nicht mehr gelten kann.
Was soll eine Blinder mit einer WYSIWYG-Ansicht? Hier ist eine semantische Auszeichnungsmöglichkeit, z.B. mittels einer einfachen Syntax evtl. in Verbindung mit Accesskeys sinnvoll.[/quote]
Nein, natürlich _muß_ es nicht die eine Version für alle geben. Allerdings, und da komme ich zu der WYSIWYG-Frage, kann es ein Problem sein, wenn eine Firma ein CMS anschafft, daß nur _mit_ WYSIWYG-Ansicht (vernünftig) funktioniert. Was, wenn die eine sehbehinderte Kollegin einstellen möchten. Dann hat das Programm plötzlich eine Einstellungsbarriere. Oder denke ich da falsch / zu kurz?
[quote comment=“1534″]Hallo Kai, 🙂
… Blindows …
Auf diese und ähnliche Schwierigkeiten stosse ich dabei immer wieder in der Praxis. Bei AJAX fangen schon etliche Probleme an.
[/quote]
Hallo Sylvia
Schon richtig. Es kommt noch auf die Software an. JAWS kann das mWn. schon recht gut.
Aber es nützt ja nichts, zu trauern – AJAX kommt und da wird die Barrierefreiheitsdiskussion nichts dran ändern. Und wenn wir nicht schnell Lösungen aufzeigen, werden die Fortschritte der letzten Jahre überall dort, wo nicht Gestze zwingen, einfach weggespült.
[quote]
Das mit dem Backend ist halt so eine Sache. Wo fängt man mit einer Optimierung an. Klar – das hört sich markig an, was macht ein Blinder mit einem WYSIWYG-Editor. Aber was meint man genau damit? Ein Blinder kann auch mit einer einfachen Webseite Schwierigkeiten haben. So what?! Wenn der Editor standardgemäß erreicht und benutzt werden kann, hat auch ein Blinder damit bessere Möglichkeiten oder? Aber ich denke, so hast Du das ja auch gemeint.
[/quote]
Das war nicht „markig“ gemeint und sollte auch kein billiger Gag sein. Ich meine es so: Ein WYSIWYG-Editor soll einem unerfahrenen Nutzer anhand eines optischen Vergleichs das Formatieren von Texten erleichtern. (Wer jemals einem erfahrenen Latex-Nutzer bei der Arbeit zugesehen hat weiß, dass es wesentlich schnellere Methoden des Layoutens gibt, als Icosn anzuklicken.)
Nur kann ein Blinder eben diese Vereinfachung nicht nutzen. Warum also einen WYSIWYG-Editor tatstaturfähig machen (ok, es schadet auch nicht)? Wichtiger wäre, einen schnell per Tatstatur bedienbaren Editor zu haben – egal wie der Output aussieht.
Gruß, Kai
[quote comment=“1535″]
Nein, natürlich _muß_ es nicht die eine Version für alle geben. Allerdings, und da komme ich zu der WYSIWYG-Frage, kann es ein Problem sein, wenn eine Firma ein CMS anschafft, daß nur _mit_ WYSIWYG-Ansicht (vernünftig) funktioniert. Was, wenn die eine sehbehinderte Kollegin einstellen möchten. Dann hat das Programm plötzlich eine Einstellungsbarriere. Oder denke ich da falsch / zu kurz?[/quote]
Nö. Ein gutes CMS erlaubt es, unterschiedliche Editoren zu verwenden oder hat zumindest einen, der auch ohne WYSIWYG funktioniert.
Gruß, Kai
btw: auch JAWS hatte Schwierigkeiten mit diesem AJAX Layer. 🙂 Die Aufgabe war nun, nachzusehen, was man optimieren kann, damit die Zugänglichkeit trotzdem möglich wird.
Ja – das mit AJAX sehe ich genauso. Ich denke auch, dass man sich schnell und intensiv damit befassen muss, wo man da zuarbeiten kann, damit Barrierearmut (von Freiheit möchte ich da weniger sprechen wollen) gewährleistet werden kann. Ich sehe das auch nicht als Trauerphase, sondern schlicht als Phase, wo man eben genauer hinsehen sollte, was sinnvoll ist und auf was man (noch) verzichten kann.
Ich bin auch kein unbedingter Fürsprecher des WYSIWYG-Editors. 🙂 Aber die Praxis zeigt, dass der Kunde sich da eben wohl fühlt. Da ich keine Erfahrung in diese Optimierungs-Richtung habe, muss ich hier auch passen.
[quote comment=“1555″]Ein gutes CMS erlaubt es, unterschiedliche Editoren zu verwenden oder hat zumindest einen, der auch ohne WYSIWYG funktioniert.[/quote]
🙂 Das ist ja mal ein wirklicher Ansatz! Verschiedene Editoren auswählen zu können. Find ich gut! Werde ich gleich weitertragen.