AJAX installieren?

[Hilarious]

stk hatte in einem anderen Thread einen Querverweis auf seine, ähem, Beleidigung hier gesetzt, daher weise ich auch hier nach, wer richtig liegt.

Ja, ist gut. Schreib ihm eine persönliche Mail oder ruf ihn an. Das ewige Klarstellen nervt.

[MacMark]

Ja, ist gut. Schreib ihm eine persönliche Mail oder ruf ihn an. Das ewige Klarstellen nervt.

Wenn er mich in einem öffentlichen Forum beleidigt, ist es durchaus legitim, ihm dort auch öffentlich zu antworten. Wenn dich das nervt, leg dir eine Elefantenhaut zu

[xenxox]

Wenn Du Ajax für eine barrierefreie Seite einsetzen willst, dann mußt Du alles doppelt entwickeln: Einmal mit Ajax und einmal ohne. Das ist absurd.

Nein dass muss mein nicht und selbst wenn ist es nicht absurd. Wenn man die Technik so implementiert dass sie nur eine optionale Ergänzung darstellt benötigt man keine zweite Implementierung als Fallback.

Ja Eyecandy, der ohne JavaScript nicht geht.

Es bleibt ja jedem überlassen wie er es nutzt, dein Horizont scheint bei Eyecandy aufzuhören wobei man doch mit AJAX bzw. den Zugrundelegungen Technologien sehr sinnvolle Dinge machen kann.

Stichworte Barrierefreiheit und Sicherheit.

Kannst du auch etwas anderes als irgendwelche Buzzwords ablassen?

Das einzige Problem mit AJAX ist dass es auf den XMLHTTPRequest aufsetzt und der redmonsche Browser dies nach wie vor als ActiveX Objekt implementiert hat. Aber auch editable Iframes sind afaik beim IE über ActiveX realisiert und das ist kein grund darauf zu verzichten. Es muss halt eine Ergänzung darstellen die ohne spezielle Fallbacklösung genutzt werden kann.

Aber das ist ja möglich - nun beim editable IFrame muss man alternativen schaffen - aber dass muss man sowieso das Mozilla und Opera das ganze anders implementiert haben - über Safari will ich mal gar nicht sprechen.

[stk]

Moin,

Nur um mal einen ganz anderen Gout reinzubringen. Auf A-List-Apart wurde heute morgen ein JS-Lösung vorgestellt, die Textvergrößerung (ein klassisches Element der Barrierefreiheit) erkennt und verhindert das ich überlappende (sprich: unleserliche) Texte ergeben:

http://www.alistapart.com/articles/fontresizing

Auch wenn das nicht explizit unter "Barrierefreiheit" gefeatured wurde, so ist durch den Zugewinn an Usability genau diese entstanden.

Gruß Stefan

[MacMark]

der Faktor,
deine "optionale Ergänzung" ist dann jedoch nicht barrierefrei.

Schon allein anhand deines Postings kann man doch sehen, daß Ajax dir einen Haufen Probleme bzgl. funktionaler Natur und Sicherheit beschert.

Apropos Buzzword: Barrierefreiheit ist im Gegensatz zu Ajax keines. Außer dem XmlHttpRequest aus dem Jahre 2001 bietet Ajax nichts Neues, wenn man bei 2001 noch von "neu" sprechen kann.

[MacMark]

Moin,

Nur um mal einen ganz anderen Gout reinzubringen. Auf A-List-Apart wurde heute morgen ein JS-Lösung vorgestellt, die Textvergrößerung (ein klassisches Element der Barrierefreiheit) erkennt und verhindert das ich überlappende (sprich: unleserliche) Texte ergeben:

http://www.alistapart.com/articles/fontresizing

Auch wenn das nicht explizit unter "Barrierefreiheit" gefeatured wurde, so ist durch den Zugewinn an Usability genau diese entstanden.

Gruß Stefan

Das basiert auf JavaScript und ist per Definition daher nicht barrierefrei. Textvergrößerung kann jeder Browser von Hause aus. Eine barrierefreie Seite fliegt auch nicht auseinander, wenn man den Text mit der browsereigenen Funktion verkleinert oder vergrößert.

Textvergrößerung mit JavaScript ist daher vollkommen unnötig.

Warum vergessen die Leute, daß HTML ausgabeunabhängig ist? Wenn ihr den ursprünglichen Sinn von HTML noch wüßtet, dann würdet ihr euch a) eine Menge Probleme ersparen und b) solche "Lösungen" an die Wand klatschen. Absolut krank sowas.

[stk]

Moin,

Erst lesen, dann auf der Zunge zergehen lassen, ggf. verstehen und dann posten

Es geht nicht um Textvergrößerung per JS, sondern darum zu verarbeiten was passiert, wenn jemand Textvergrößerung nutzt.

Gruß Stefan

[MacMark]

stk, sowas ist bei einer barrierefreien Seite vollkommen unnötig. Man muß überhaupt nicht darauf reagieren, wenn der Besucher die Textgröße ändert, wenn die Seite barrierefrei ist. Sie bleibt nämlich weiterhin lesbar und benutzbar. Solche Probleme haben nur nicht-barrierefreie Seiten und, um ehrlich zu sein, ich gönne sie ihnen aus tiefstem Herzen, Strafe für den, der sie verdient.

[Hilarious]

Danke, stk, prima Fund und interessanter Ansatz!

[stk]

Moin,

Barrierefreiheit ist dazu gedacht, das alle mit einer Webseite umgehen können. Barrierefreiheit ist nicht dazu gemacht, allen einen kleinsten gemeinsamen Nenner unterzuschieben. Nur weil Seiten barrierefrei sind, müssen sie nicht sch…e aussehen. Hochwertiges Design, hohe Funktionalität, valider Code und in der Erweiterung Barrierefreiheit lassen sich (zumindest in meiner Welt) sehr wohl in Übereinstimmung bringen. Dort wo Design oder Funktion die Gefahr bergen der Barrierefreit in den Füßen zu stehen braucht es zusätzliche "Versöhnungsmechanismen". Im Falle von Funktionsanreicherung durch AJAX kann dies durch serverseitiges Fallback geschehen. Im (vorliegenden) Fall von optischen Einschränkungen (schau Dir mal das Beispiel mit der Navigation, die aus länglichen, zusammengesetzten Hauptwörtern - nicht unüblich in unserem Sprachgebrauch - besteht) können eben andere Konstrukte hilfreich sein.

Im Prinzip ist die Diskussion einigermassen deckungsgleich mit der "wir schreiben doch nicht Seiten für Suchmaschinen, sondern für Benutzer". Das ist genauso falsch oder richtig wie "wir schreiben doch nicht Seiten für Behinderte, sondern 'Nomale'". Eine Mehrheit von Usern sollte man nicht aus den Augen verlieren, schon gar nicht den Kunden, den i.d.R. Barrierefreiheit noch wesentlich weniger interessiert als Suchmaschinentauglichkeit und dennoch kann man mit einer wirklich gut gemachten Seite neben den "Normalo"-Ansprüchen auch noch Barrierefreiheit und Suchmaschinentauglichkeit unterbringen.

Gruß Stefan