• Apfeltalk ändert einen Teil seiner Allgemeinen Geschäftsbedingungen (AGB), das Löschen von Useraccounts betreffend.
    Näheres könnt Ihr hier nachlesen: AGB-Änderung
  • Viele hassen ihn, manche schwören auf ihn, wir aber möchten unbedingt sehen, welche Bilder Ihr vor Eurem geistigen Auge bzw. vor der Linse Eures iPhone oder iPad sehen könnt, wenn Ihr dieses Wort hört oder lest. Macht mit und beteiligt Euch an unserem Frühjahrsputz ---> Klick

AJAX installieren?

stk

Grünapfel
Registriert
05.01.04
Beiträge
7.141
Moin,


Aber gern. Jeseits von päpstlichen Lehrmeinungen praktiziere ich schliesslich auch alltägliche, christliche Nächstenliebe. Warum sollte man es mit vergleichsweise unbedeutenderen Dingen wie Barrierefreiheit nicht ebenso halten ;)?!

Gruß Stefan
 

Sir Q

Rheinischer Winterrambour
Registriert
12.04.05
Beiträge
923
Im Prinzip kann man AJAX-Seiten auch so bauen, das sie AJAX aufgewertet werden, aber auch ohne JavaScript laufen. Also, wenn ich eine Konfiguraitonsseite aufrufe und aus einer Drop-Down-Box einen eintrag auswähle, dann kann AJAX eben andere inhalte auf der Seite verändern. Wenn jemand jedoch JavaScript ausgeschaltet ist, lässt sich im <noscript>-Bereich eine Reihe von Buttons und beschreibungen eben für ganz herkömmliche Submits anbringen - AJAX und Barrierefreiheit schließen sich nicht PerSé aus - es macht aber viel arbeit (im Konzept und bei der Umsetzung) es richtig zu machen ...

~

Andererseits wir AJAX natürlich (wie schon erwähnt) gern für Eye-Candy eingesetzt - und auch in diesem fall gibt es keine diskussion ob das im Sinne des Erfinders war/ist - es ist einfach so. Ob das nun WordPress-Blogs sind, wo bilder irgendwie in die Seite faden anstelle in einem schnöden popup aufzugehen, oder shoutboxen in irgendwelchen Foren …

~

Um auf den Eingangspost zurück zu kehren: AJAX ist nichts, was man einfach so mal installiert. Es ist eine (vielleicht sogar: „neue”) Art der Programmierung von WebSeiten resp. von teilen der Webseite.

Bisher werden Webseiten vom Server ausgeliefert, anfragen gestellt und eine ganz neue Seite geliefert. Mit JavaScripten kann man schon sehr lange etwas Dynamik in die Seite bringen (popups die sich über den Bildschirm bewegen, menüs, …) - mit AJAX werden die JavaScript um eine Idee reicher: Das Script muß nicht mehr im Vorfeld ALLE möglichen Inhalte kennen, es kann sie von Server anfordern.

Um AJAX einsetzen zu können, braucht man grundsätzlich erfahrung in der Erstellung serverseitig dynamischer Webseiten (egal ob mit PHP, JSP, ASP, PERL, …) und mann braucht Erfahrung mit JavaScript und seinem Verhalten im Browser.

Mit ziemlichen Aufwand (den verschiende Frameworks versuchen zu minimieren in dem sie eine standardisierter API anbieten wollen) kann mann die ganze serielle Prozessfolge jetzt ohne das Neuladen der ganzen Seite quasi virtuell abbilden. Das ist knifflig und ein neues „Denken” bei der Erstellung der Webseiten.

~

Um das ganze noch abzurunden: wer die Grundlagen intus hat, und die BITV nicht aus den Augen verliert und sich während des gesamten erstellungsprozesses überwacht und die Seite sowohl AJAX-enhanced als auch mit LYNX betrachtbar hat, schlägt drei Fliegen mit einer Klappe:

1. Die Seite ist für 90% der User anwenderfreundlich (denn das ist ein Vorteil, den AJAX in der Tat bringen kann)

2. Die Seite ist für die Menschen mit Behinderungen ebenfalls zugänglich und

3. Auch Suchmaschinen sind behindert und die Seite bekommt durch die meisten 2. tangierenden Punkt auch eine sehr hohe zugänglichkeit für google und konsorten …
 
Zuletzt bearbeitet:

MacMark

Jakob Lebel
Registriert
01.01.05
Beiträge
4.874
Sir Q,
richtig, Applets sind ebenfalls eine Barriere.

Ebenfalls richtig ist, daß man mit JavaScript nur barrierefrei sein kann, wenn man alle Inhalte auch redundant ohne JavaScript anbietet.

Daher kann man JavaScript gleich ganz weglassen und hat mindestens die folgenden Vorteile:
- Nicht die doppelte Arbeit.
- Kein Sicherheitsproblem für die Besucher wegen JS.
- Eine einfach für alle zu benutzende Seite.
 

Sir Q

Rheinischer Winterrambour
Registriert
12.04.05
Beiträge
923
Daher kann man JavaScript gleich ganz weglassen und hat mindestens die folgenden Vorteile:
- Nicht die doppelte Arbeit.
- Kein Sicherheitsproblem für die Besucher wegen JS.
- Eine einfach für alle zu benutzende Seite.
Ich kann nur einem der Argumente zustimmen: nicht die doppelte Arbeit.

~

Die Frage nach den Sicherheitsproblemen z.B. stellt sich doch garnicht. Wer JS abgeschaltet hat, wird auch von AJAX nicht tangiert. Wer JS an hat, profitiert von einer guten und einfacher funktionierenden Seite als ohne JS. JS ist nämlich nicht böse. Eine Pistole bringt niemanden um - der, der sie abfeuert tut das jedoch unter umständen. Eine sauber programmierte JS-Seite ist keine Gefahr, und ein sauber arbeitendes AJAX-Framework ebensowenig.

Da sind ganz klassische Gästebücher oder NewsBoxen mit XSS-Schwachstellen deutlich gefährlicher …

~

Entschuldig, aber ich sehe nicht ein, warum ca. 85% der Besucher einer Seite (denn mehr als 5% haben JS nicht deaktivert) nicht von den neuesten Errungenschaften profitieren sollen? E-Mail ist ursprünglich als reines ASCII-Format entwickelt worden und die krücke mit der base64codierung für attachments war eine improvisation. Deiner Argumentation nach, dürfte es auch keine HTML-E-Mails (dem würde ich mich sogar anschließen :) und keine Datei-Anhänge für E-Mails geben.

Nein, das KnowHow der Entwickler und die technischen Möglichkeiten entwicklen sich weiter und ich finde es richtig, das diese möglichkeiten auch genutzt werden. Du schreibst ja auch XHTML und nicht mehr HTML 3.2 - von daher geht auch evolution nicht ganz spurlos an dir vorbei …
 

MacMark

Jakob Lebel
Registriert
01.01.05
Beiträge
4.874
Email ist plaintext für einfachen Nachrichtenaustausch. HTML-Mails sind nicht mehr einfach und machen diverse Probleme. Anhänge sind ok.

Mir geht es nicht darum, das Neueste zu nutzen, sondern das Beste. HTML ist unzulänglich und ungeeignet bzgl. Barrierefreiheit, XHTML ist hingegen geeignet.

Ich mute meinen Besuchern nicht zu, JS aktivieren zu müssen und sich dadurch möglichen Sicherheitsrisiken auszusetzen.
 

Sir Q

Rheinischer Winterrambour
Registriert
12.04.05
Beiträge
923
Email ist plaintext für einfachen Nachrichtenaustausch. HTML-Mails sind nicht mehr einfach und machen diverse Probleme. Anhänge sind ok.
Sie sind aber eine zumutung und stellen ein enormes gefahrenpotential dar - machst du es dir da nicht etwas zu bequem? Der Witz ist doch, das genau diese Diskussion, die hier gerade um AJAX geführt wird vor annähernd zwei Jahrzehnten zum Thema Mail-Anhäge geführt wurde ...


Mir geht es nicht darum, das Neueste zu nutzen, sondern das Beste. HTML ist unzulänglich und ungeeignet bzgl. Barrierefreiheit, XHTML ist hingegen geeignet.
Ich glaube nicht. Wenn du HTML3.2 schreibst und CSS verwendest, kannst du auch ohne DIVs sehr gut barrierefreie Seiten bauen. <h1>, <h2>, <h3>, <h4> - Überschriften, <p> Textblöcke, <fieldset>, und so weiter - alles schön und einfach und »Abwärtskompatibel« vor allem „Semantisch”.
Zugegeben, floatende oder fest positionierte DIVs sind schon sexy, aber es geht auch ohne. Und das ist dann auch Barrierfrei (wenn man auf Tabellen für's Layout verzichtet und keine Frames ... du kennst die BITV).


Ich mute meinen Besuchern nicht zu, JS aktivieren zu müssen und sich dadurch möglichen Sicherheitsrisiken auszusetzen.
Du gibst also zu, kein vertrauen in deine JS-Programierung zu haben, und daher die Besucher am besten nicht damit zu belästigen. Das ist OK. Aber was ist mit den Leuten die JS wirklich gut beherschen, die wirklich X-Browser-code schreiben und die keine bösen überraschungen eingebaut haben? Selbst die düfren kein JS machen, nur weil du es nicht kannst und angst hast, beim Besucher der Seite was kaputt zu machen?
Andererseits, da nur ein geringer Prozentsatz tatsächlich JS deaktiviert hat, möchtest du allen anderen Verbieten AJAX zu schreiben, nur weil irgendjemand mal was schlimmes damit angestellt hat?
Du selbst schlägst JavaApplet vor - wo nachgewiesen ist, das die Sandbox löcher hat und über die VM richtig tief ins System eingegriffen werden kann - schlimmer als es mit JS jemals möglich währe (ich lasse hier mal bewusst außenvor, das der IE so marodeist, das sich mit JS die eine oder ander eSicherheitslücke bedrohlich ausnutzen ließe - wie gesagt: Microsofts InternetExplorer ist da das Problem, nicht JS).
 

Juuro

Schafnase
Registriert
07.11.05
Beiträge
2.256
Naja, aber das alles kann doch eh auch nur passieren wenn man seinen Computer nicht selbst irgendwie geschüzt hat, oder?
Ich hab zumindest noch nie wegen JavaScript einen Web-Unfall erleiden müssen.
 

Sir Q

Rheinischer Winterrambour
Registriert
12.04.05
Beiträge
923
Ich hab zumindest noch nie wegen JavaScript einen Web-Unfall erleiden müssen.
• Du gibst deine PIN/TAN-Listen ja auch nicht auf der Seite deiner Bank ein, nur weil diese dich per Mail darum bittet.
• Du versuchst ja auch nicht Cracks für nicht gekaufte Spiele illegal im Netz zu finden.
• Du hast ja auch kein Interesse an „Fotos deiner Nachbarin ganz privat“
• ...

Die Möglichkeiten mit JS Schaden anzurichten sind durchaus da. Aber, das liegt nicht in der Sprache selbst. Wer regelmäßig sicherheitsupdates seines Browserherstellers einspielt, ist auch vor zufälligen Angriffen (z.B. durch XSS in Gästebüchern, eBay-Anzeigen etc.) ganz gut geschützt.

~

Wer aber mit Absicht nach illegalen dingen bei kriminellen leuten sucht, soll sich nicht wundern, wenn die ein paar unfeine Dinge anstellen die man eigentlich nicht so gern hätte (z.B. Viren im KeyGen, der Spuckt dann zwar die Seriennummer aus, aber die bösen jungs wissen beim nächsten einkauf in Netz eben deine Kreditkartennummer) - denn nur in diesen „Kreisen” kursieren die wirklich bösen JS-Hacks und Browser-Lücken-Ausnutzer. Und in HTML-E-Mails die für Outlook-Express optimiert sind und in E-Mail-Attachments, die die Mail-Programme als vertrauenswürdig einstufen und daher gleich abspielen ...
 

MacMark

Jakob Lebel
Registriert
01.01.05
Beiträge
4.874
Sir Q,

HTML schreibt das Schließen von Tags nicht zwingend vor. Das ist einer der Gründe, warum XHTML genommen wird. Es ist eindeutig interpretierbar. Valides XHTML ist minimale Grundvoraussetzung für barrierefreie Seite.

Ich habe nichts über meine JS-Skills geschrieben. Ich wollte ausdrücken: Wenn ich meine Besucher zu JS zwinge, dann werden sie es nicht für andere Seiten extra wieder ausschalten und dort lautert evtl. ein bösartiges JS.
 

Sir Q

Rheinischer Winterrambour
Registriert
12.04.05
Beiträge
923
Welche Tags müssen denn in HTM3.2 nicht geschlossen werden?
<hr> zumbeispiel ist leer. In XHTML schreibt man daher <hr /> (beim Zeilenumbruch analog). Aber Überschrifte, Absätze, formatierungen wie fett, kursiv, unterstrichen - Links, ... deine argumentation ist ziemlich schwach, denn in HTML ging es in den Anfangstagen um eine Auszeichnungssprache und da ist es nun einmal wichtig, das ein tag auch einen Text umschließt. Das dies bei Ausnahmen (z.B. <hr/>, <br/>, <img .../>, <input />, ...) damals nicht konsequent bedacht wurde, tut der eigentlichen funktion in diesem Fall jedoch kein Abbruch ...

~

Der Kern meine Aussage war doch der, allen 85% eine enhanced version dank AJAX vorzuenthalten ist engstirnig. Die 5% die JS abgeschaltet haben, sollten trotzdem eine voll funktionsfähige seite sehen und diese auch barrierefrei nutzen können. Nur weil ein verschwindet geringer Prozentsatz (weit unter 0,01%) aller JavaScripte im Netz tatsächlich Schaden anrichten können (indem sie spezifische Browserschwächen ausnutzen) darf AJAX oder JS im Allgemeinen nicht vertäufelt werden ...

Außedem zwingst du ja niemanden JS zu aktivieren. Nur die Besucher die JS aktiv haben, werden einen echten gewinn daran haben, wenn du echt coole funktionen mit AJAX realisiert hast …
 

MacMark

Jakob Lebel
Registriert
01.01.05
Beiträge
4.874
Mir ist keine Seite in Erinnerung, die gleichzeitig auch eine vollwertige Alternative ohne JS angeboten hätte. Schau dir beispielsweise apfeltalk an oder andere Mac-Seiten: Schaltest du JS ab, wird die Seite in weiten Teilen unzugänglich.

Die meisten Betreiber sind verspielt und ihnen ist Schnickschnack wichtiger als Zugänglichkeit. Schnickschnack ist beim ersten Besuch evtl. noch lustig, aber ab dann nur noch lästig. Außerdem bricht Ajax und Konsorten mit dem Vor- und Zurück-Knopf, den Bookmarks und verwendet meistens Frames.

Unzugänglichkeit bzw. JS wird auch von Suchmaschinen bestraft. Meine Lieblinsdarstellung dazu ist diese:
http://www.woodshed.de/publikationen/dialog-robot.html
 
Zuletzt bearbeitet:

Sir Q

Rheinischer Winterrambour
Registriert
12.04.05
Beiträge
923
Mir ist keine Seite in Erinnerung, die gleichzeitig auch eine vollwertige Alternative ohne JS angeboten hätte. Schau dir beispielsweise apfeltalk an oder andere Mac-Seiten: Schaltest du JS ab, wird die Seite in weiten Teilen unzugänglich.
In der Tat - nur ist Apfeltalk auch nicht unser „Paradebeispiel“. Ich meine: Tabellen werden wo man nur hinsieht für das Layout verwendet. Aber OK: Es ist auch nicht das Anliegen von AT Barrierefrei zu sein.

~

Ich erstelle seit 2002 Webseiten für Theater und Museen - und die sogar nach den Maßgaben der BITV - weil: diese Einrichtungen müssen ja Barrierefreie Webseiten haben.
Also: Ich mach mir den Aufwand Seiten so zu bauen, das sie ohne JS funktionieren, mit JS aber eben noch etwas Pfiffiger sind …

~

Ein beliebtes Beispiel ist hier schon genannt worden: URLs die in einem neuen Fenster aufgehen sollen. XHTML hat keine Frames mehr und daher gibt es kein target mehr. Mit einen winzigen schnipsel JS wird der Link nun „aufgewertet“:
<a href="http://angel-and-vampires.de" onclick="window.open('http://angel-and-vampires.de'); return false;">Angel &amp; Vampires</a>
Jeder Browser, der JS unterstützt fürht das onclick vor dem href auf, es wird ein neues Fenster aufgemacht und das JS signalisiert durch das return false, dass der Browser das href nicht mehr anspringen braucht. Ergo: Die Seite selbst bleibt erhalten und der Link geht im neuen Fenster auf. Kann der Browser kein JS, wird onclick komplett ignoriert und das href ausgeführt. Die aktuelle Seite wird verlassen und der Link aufgerufen.

~

Ich möchte noch als Beispiel einer beliebten AJAX-Anwendung mal das Suchformular nennen:
» Ohne JS ist es nur ein Eingabefeld und nach dem Submit wird das Ergebnis ausgegeben.
» Mit JS erscheinen, bereits während des Tippens Hinweise auf vollständige Suchbegriffe und „erleichtern“ so die Suche.


Die meisten Betreiber sind verspielt und ihnen ist Schnickschnack wichtiger als Zugänglichkeit. Schnickschnack ist beim ersten Besuch evtl. noch lustig, aber ab dann nur noch lästig. Außerdem bricht Ajax und Konsorten mit dem Vor- und Zurück-Knopf, den Bookmarks und verwendet meistens Frames.
Frames sind überdies nach XHTML garkein thema mehr und da deine hauptargumentation sich auf die Barrierefreiheit bezieht können wir annahmen, das Frames garnicht zur Disposition stehen.

Das oben angeführte Beispiel ist eventuell auch nur „SchnickSchnack“ aber mir als Legasteniker hilft es sehr, wenn ich z.B. nach dem Begründer der modernen Archeologie suchen möchte, und nicht genau weiß, wie mann denn „Winckelmann“ schreibt (auf das ck kommt nämlich niemand, der durch Mundpropaganda gesagt bekommt: „Ey, such einfach auf der Seite mal anch Winkelmann.“) ...
Und solche Funktionen sind AJAX - vieleicht vestehtst du nun auch, warum ich deine »AJAX ist grundsätzlich böse«-Argumentation für engstirnig und sogar für falsch ansehe.


Unzugänglichkeit bzw. JS wird auch von Suchmaschinen bestraft. Meine Lieblinsdarstellung dazu ist diese:
http://www.woodshed.de/publikationen/dialog-robot.html
Ich scheite bei diesem Text auch - und zwar an der Anforderung der BITV §14: Verständlichkeit. Es ist mir nahezu unmöglich das zu lesen - auch ohne AJAX ...
 

MacMark

Jakob Lebel
Registriert
01.01.05
Beiträge
4.874
Korrekte Suchbegriffe schlägt Google auch ohne Ajax vor: "Meinten Sie ...?"

Neue Fenster öffnen ist Browser-Hijacking. Man sollte dem Benutzer die Kontrolle über seine Maschine lassen. Er kann selbst entscheiden, ob er (k)ein neues Fenster/Tab aufmachen möchte mit einem Link. Darüber hinaus bricht window.open auch den Back-Button. Seiten, die so etwas machen, vermeide ich zu besuchen.
 

Sir Q

Rheinischer Winterrambour
Registriert
12.04.05
Beiträge
923
Korrekte Suchbegriffe schlägt Google auch ohne Ajax vor: "Meinten Sie ...?"
1. Wenn ich „Winkelmann“ schreibe, aber „Winckelmann“ meine - schlägt google das NICH vor - es sucht einfach nach „Winkelmann“ ...
Wenn es aber beim Tippen von „Win“ schon eine Liste Suchbegriffen die mit „Win...“ anfangen schreibt, ist das SEHR nützlich - und wird auch von den Besuchern der Seite sehr geschätzt (wie eine Umfrage unserer gezeigt hat) ...
2. Google selbst arbeitet seit einiger Zeit an einer entsprechenden Funktion: Google Suggest
3. Du drehst dir die Argumente nur so, dass sie dir passen. Das ist arg kontraproduktiv. Mein Beispiel zeigte eindeutig auf, das AJAX eben nicht den von dir bemängelten Effekt (Seite ist ohne JS nicht mehr nutzbar; AJAX bricht die Hostorie) haben muß - aber anstelle darauf einzugehen, jammerst du rum, das man es auch ohne JS machen kann - das ist doch enorm verbohrt ...
4. Dein Browser (es sei denn du hast diese Werkseinstellung abgeschaltet) merkt sich bei den Google-Eingebefelder ja auch, was du schon mal eingegeben hast und wenn du tippst, kommt die auswahlliste noch mal: „Ausfüllhilfe“ oder so nennen die das. Haben die Browserhersteller da auch Mist gebaut?


Neue Fenster öffnen ist Browser-Hijacking. Man sollte dem Benutzer die Kontrolle über seine Maschine lassen. Er kann selbst entscheiden, ob er (k)ein neues Fenster/Tab aufmachen möchte mit einem Link. Darüber hinaus bricht window.open auch den Back-Button. Seiten, die so etwas machen, vermeide ich zu besuchen.
Ich hoffe doch nur, dass du deine Kunden besser berätst als du hier argumentierst, ansonsten kann man mit den Kunden ja nur mitleid haben. Was heißt den hier „Browser-Hijacking“?! Es wird doch nicht die Kontrolle über den Browser übernommen, sondern externe Links werdeb auch in einem neuen Fenster geöffnet. Damit gibt es auf der neuen Seite auch eine eigene Browsing-Historie und auf der neuen Seite funktioniert Back/Forward immer noch.

Jeder User der mit Apple+Click den Link in neuem Tab aufmacht, macht sich deiner Argumentation nach ja auch „strafbar“. Deine Browser-Button-Argumentation ist doch aufgrund deiner Forderung nach Bookmarkbarkeit der Seiten inkoseqzent. Eine gebookmarkte Seite enthält auch keine Informationen mehr darauf, wie man auf diese Seite gekommen ist ...
 

MacMark

Jakob Lebel
Registriert
01.01.05
Beiträge
4.874
Browser-Hijacking ist der gängige Fachausdruck dafür unter Usability-Experten. Wenn die Webseite neue Fenster beim Anklicken eines Links öffnet, ist es genau das. Die Webseite übernimmt die Browser-Kontrolle. In dem Punkt gibt nichts zu diskutieren.

Wenn der User das selbst macht, ist das seine Entscheidung, seine Kontrolle, aber die Webseite hat es so etwas nicht zu tun.

Ajax-Seiten und Frame-Seiten etc. ermöglichen nicht das Bookmarken einer speziellen Stelle, was aber bei rein serverseitiger Programmierung und ohne Frames immer möglich ist.

Bookmarks haben mit der Historie einer Sitzung nichts zu tun. Du würfelst hier einiges durcheinander und ich bin mir sicher, daß du nicht verstanden hast, was ich meine.
 

Sir Q

Rheinischer Winterrambour
Registriert
12.04.05
Beiträge
923
Browser-Hijacking ist der gängige Fachausdruck dafür unter Usability-Experten. Wenn die Webseite neue Fenster beim Anklicken eines Links öffnet, ist es genau das. Die Webseite übernimmt die Browser-Kontrolle. In dem Punkt gibt nichts zu diskutieren.
Das ist ja nun wirklich die paranoideste Auslegung von Browser-Hijacking die ich je gehört habe. Auch wenn man doch eher davon ausgeht, das hinter dem „Hijacking” ein krimineller Ansatz stehst, kriminalisierst du einfach jeden, der Seiten anders baut als du es „für sinnvoll hältst”.
~
Ich werde hier den letzten Versuch unternehmen ein sinnvolles JavaScript vorzuschlagen um deine engstirnige Sichtweise, das alles JS und erst recht AJAX grundsätzlich böse sind, mit Beispielen aus der Praxis zu wiederlegen:
Auf der noch in Entwicklung befindlichen Webseite eines Kunden gibt es zu diversen Stücken Galerien. Dazu gibt es Vorschaubildchen und der User kann nun auf ein Thumbnail clicken um das große Bild zu sehen: Beispiel (link entfernt).
Dann wird eben direkt das Bild angezeigt, anderfalls wird ein Bild-Austausch vorgenommen - JS-enhanced eben, und nicht perse böse ...


Wenn der User das selbst macht, ist das seine Entscheidung, seine Kontrolle, aber die Webseite hat es so etwas nicht zu tun.
Die „Webseite“ macht das auch nicht. Der Entwickler der Seite denkt sich (im besten Fall) etwas dabei, wenn er es für Sinnvoll erachtet, das sich eine URL in einem neuen Fenster öffnet.
~
Ich persönlich hasse auch Postkarten-Webseiten-Fenster, aber wenn eine redaktionelle Webseite einen Artikel mit Fußnoten und Quellenangaben enhtält, dann ist es sehr sehr sinvoll, wenn die seite in einem neuen fenster aufgeht, denn ich als Mensch vergesse zuweilen einfach mal [Apple] zu drücken bevor ich auf einen Link klicke. Die ganze history ist nämlich für die Katz, wenn der Browser geschlossen wird, weil der Link den man sich angeschaut einem nicht weiter bringt, und man daher einfach mal die Seite zumacht ...
~
Warst resp. bist du auch so „besessen“ als (weil) es sich dieser Computerhersteller Apple einfach erdreistete und in neue Computer kein Diskettenlaufwerk mehr eingebaut hat? Das ist doch eine eklatante Missachtung jeglichen über die Jahre gelehrten defakto Anwenderverhaltens?


Ajax-Seiten und Frame-Seiten etc. ermöglichen nicht das Bookmarken einer speziellen Stelle, was aber bei rein serverseitiger Programmierung und ohne Frames immer möglich ist.
Du verallgemeinerst wieder und ignoriest gänzlich das angeführte Beispiel für „sinvollen“ AJAX-Einsatz beispielsweise im Suchformular.
Und wenn du schon weiterhin mit den Frames argumentierst: ich habe schon damals meine Framesetzs immer so gebaut, das sie bookmarkbar waren. Wahnsinns Aufwand: die URL des Hauptframes definiert alle im Frameset verwendeten Frames.
Aber darum geht es hier doch garnicht. Es geht um AJAX und darum, dass du es perse vertäufelst ohne einsehen zu können, das Deine generelle Ablehung falsch ist.
~
Außerdem ist auch diese Verallgemeinerung „... was aber bei rein serverseitiger Programmierung ... immer möglich ist“ faktisch falsch. Es gibt genügend serverseitig erstellter Seiten die nicht bookmarkbar sind, weil die eigentlichen Information WO ich gerade bin, in der Session gespeichert ist - und die ist auch nicht bookmarkbar.
Eine ganz klassische Formular-Ergebnissseite ist eben nur dann bookmarkbar, wenn das Formular per GET aufgerufen wird oder per URL-Rewrite (wie bei AT) eine (wenn auch nur für einen begrenzten Zeitraum gültige) Seite eindeutig referenzierbar ist.
~
Ich glaube weiterhin, dass das Grundporblem unserer Auseinandersetzung Deine einseitige und absolute Verneinung dieser Technik ist …


Bookmarks haben mit der Historie einer Sitzung nichts zu tun. Du würfelst hier einiges durcheinander und ich bin mir sicher, daß du nicht verstanden hast, was ich meine.
Komisch - genau dieses Gefühl hab ich immer, wenn du auf die Posts und nach deinen belieben Antortest ohne auf den Inhalt des Posts ansich einzugehen ;)
 
Zuletzt bearbeitet:
  • Like
Reaktionen: cws

MacMark

Jakob Lebel
Registriert
01.01.05
Beiträge
4.874
Ich rede von Browser-Hijacking bezüglich User Interface. Das ist nicht kriminell, sondern benutzungsfeindlich.

Ich werde hier den letzten Versuch unternehmen ein sinnvolles JavaScript vorzuschlagen ... Webseite des Schauspiel Leipzig gibt es zu diversen Stücken Galerien. Dazu gibt es Vorschaubildchen und der User kann nun auf ein Thumbnail clicken um das große Bild zu sehen: Beispiel.
Dann wird eben direkt das Bild angezeigt, anderfalls wird ein Bild-Austausch vorgenommen - JS-enhanced eben, und nicht perse böse ...
Das Beispiel zeigt eben kein gleichwertiges Verhalten, weil man mit JavaScript eine aktualisierte Webseite angezeigt bekommt, ohne JavaScript jedoch nur ein Bild und überhaupt keine Webseite mehr.

Das gewünschte Verhalten der Webseite kann man problemlos ohne JavaScript, aber barrierefrei und gleichzeitig gleichwertig benutzbar erzielen mit serverseitiger Programmierung.

Jede Seite, die ohne JavaScript dem Benutzer Abstriche gleich welcher Art (Komfort, Funktionen, Optik) zumutet, bewirkt somit zwei Dinge:
a) Sie riskiert die Sicherheit des Benutzers, weil er zur generellen Einschaltung von JavaScript motiviert wird.
b) Sie bietet keine gleichwertigen barrierefreie Inhalte.

Ich persönlich hasse auch Postkarten-Webseiten-Fenster, aber wenn eine redaktionelle Webseite einen Artikel mit Fußnoten und Quellenangaben enhtält, dann ist es sehr sehr sinvoll, wenn die seite in einem neuen fenster aufgeht
Nein, das ist nicht sinnvoll, weil es Browser-Hijacking ist. Du brichst die Historie, den Backbutton und übernimmst die Kontrolle über den Rechner des Besuchers, der dir nicht gehört. Möchtest du auch, daß dein Zeitungsbote dir deinen Wagen umparkt, weil er das für besser hält? Oder die Zeitung dir nach Gutdünken dorthin liefert, wo er es für richtig hält? Vielleicht in die Dusche, weil er dir den Weg ersparen möchte?

Man sollte überhaupt keine statischen Größen verwenden.
... ignoriest gänzlich das angeführte Beispiel für „sinvollen“ AJAX-Einsatz beispielsweise im Suchformular. ...
Ich sehe dort keinen Nutzen, der ohne JavaScript zur Verfügung steht. Ich sehen da nur eine Webseite, die nicht gleichwertig barrierefrei benutzbar ist.

Meist wird die JavaScript-Logik bei Ajax in einem extra Frame abgelegt. Es setzt also nicht nur JavaScript voraus, sondern auch Frames. Doppelt schlecht bezüglich Barrierefreiheit.

Eine ganz klassische Formular-Ergebnissseite ist eben nur dann bookmarkbar, wenn das Formular per GET aufgerufen wird oder per URL-Rewrite (wie bei AT) eine (wenn auch nur für einen begrenzten Zeitraum gültige) Seite eindeutig referenzierbar ist.
Das ist die richtige Richtung.

Ich glaube weiterhin, dass das Grundporblem unserer Auseinandersetzung Deine einseitige und absolute Verneinung dieser Technik ist ...
Das Problem ist, daß gewisse Techniken zu Webseiten führen, die nicht gleichwertig barrierefrei nutzbar sind. Das bringt Nachteile für die Nutzer mit sich, da sie auf gleichwertige barrierefreie Inhalte verzichten müssen, beziehungsweise zur Nutzung risikobehafteter aktiver Inhalte motiviert werden. (Siehe dein Beispiel oben.)
Es gibt in diesem Punkt keine Kompromisse, weil man es entweder barrierefrei und gleichwertig nutzbar macht oder nicht.

Du hast ja auch selbst ausgeführt, daß es mit Frames und JavaScript enormen Zusatzaufwand gibt, der trotzdem nicht zu Ergebnissen führt, die sich mit vorbildlichen Seiten messen können bezüglich Barrierefreiheit und damit geforderter gleichwertiger Nutzbarkeit.
 

Sir Q

Rheinischer Winterrambour
Registriert
12.04.05
Beiträge
923
Advocatus Diabolo,

da wir keinen Konsens finden können, und du weiterhin auf der uneingeschränkten JS ist Böse-Meinung beharrst, werde ich nicht weiter versuchen Beispiele für sinvolles JS für dich zu suchen.

Selbst Jakob Nielson ist kein so radikaler Prinzipienreiter. Es ist auch ein Anliegen der BITV die Übertragngsvolumen gering zu halten, um auch technisch eingeschränkte User mit langsamen Modem den Besuch der Seite so angenehm wie möglich zu gestalten. Das komplette Neuladen einer sehr umfangreichen Seite ist in dem Fall eine unzumutbare Belastung für die 85%, die eben nicht auf die Barrierefreiheit angewiesen sind oder JS aufgrund paranoider Gedanken abgeschaltet haben. Deine rigorose kontra-Einstellung läuft dabei den Grundgedanken der BITV zuwieder, indem du nämlich nicht für die „Minderheit“ die entsprechende Darstellung forderst, sondern für die „Mehrheit“ einen Verzicht auf Innovation ...