JavaScript SEO, Barrierefreiheit und JavaScript/AJAX/JSON unter einen Hut zu bekommen?

[benneq]

Moin,

Folgendes liegt an: Ich möchte eine Seite erstellen mit hübschen Effekten und Tralalala. Gleichzeitig soll aber auch die Barrierefreiheit garantiert werden und die Suchmaschinen sollen die Seiten indizieren können.

Ich bin mir aktuell nicht im Klaren darüber, ob sowas mit reinem JS zu bewerkstelligen ist. Falls ja, wie? Was muss man beachten?

Falls nein: Wie konstruiere ich meine Webseite am Besten, um alles unter einen Hut zu bekommen?
Aus dem jQuery-UJS Paket konnte ich zumindest folgendes erfahren:
1. Ganz normale HTML Seite wird geladen
2. Darin sind spezielle Hyperlink enthalten mit data-remote="true" (also z.B. <a href="www.google.de" data-remote="true">Link</a>)
3. jQuery UJS durchsucht alle Links nach dem data-remote="true" Flag
4. jQuery ändert das Verhalten der Links, sodass statt dem Hyperlink eine JS-Funktion ausgeführt wird.
5. Diese JS-Funktion lädt dann z.B. per AJAX irgendwelchen Content nach

Das funktioniert auch soweit und sowohl SEO als auch Barrierefreiheit sollten damit abgedeckt sein. Das heißt quasi: Nach dem erstmaligen Laden der Seite kann der ganze Rest über AJAX laufen und für Browser ohne JS funktioniert trotzdem alles wie gehabt.

Wie stell ich aber nun das Ganze an, wenn ich den ersten Aufruf der Seite schon per AJAX am laufen haben möchte? Beispiel: Das CB Forum. Hier würde JSON ganz schön viel Traffic sparen, weil es eine große Menge an 'ähnlichen/identischen' Konstrukten gibt, die aufgelistet werden.
Das Problem ist einfach zu beschreiben: Wenn ich den Ablauf von oben nehme, dann wird ein Haufen HTML Code geladen, der mit AJAX/JSON um ein Vielfaches gekürzt werden könnte. Aber wenn ich direkt auf JS setze, dann ist die Seite am Ende wohl nicht mehr barrierefrei und die Suchmaschinen beißen sich bestimmt auch die Zähne dran aus.

Vielleicht hat ja jemand noch eine großartige Idee? Würde mich auf jeden Fall sehr freuen.

Grüße

 

[ice-breaker]

Du hast dir ja selbst die Antwort gegeben
Nur mit HTML ist es barrierefrei und 100% SEO tauglich, sobald der Inhalt über JavaScript gerendert wird, hast du verloren. Denn dann müsstest du dich darauf verlassen, dass eine Suchmaschine zum Beispiel die Webseite wie ein vollwertiger Browser behandelt und das macht selbst Google noch nicht.

 

[benneq]

Hmm... wie verpönt sind eigentlich Redirects? Oder harmoniert das auch nicht mit SEO und Barrierefreiheit?

 

[ice-breaker]

Du solltest deinen Gedankengang eventuell noch genauer beschreiben
Ich persönlich sehe aber gar kein Problem dadin die erste Seite als reines HTML auszuliefern.

 

[Ruheliebhaber]

Das wäre eine Möglichkeit. Leider wird dann aber nicht die ganze Seite barrierefrei sein, da nachfolgende durch JavaScript erzeugte Funktionalität, eventuell nicht durch einen Screenreader erfaßt wird. Es wäre also nur für die Indizierung der Seite durch eine Suchmaschine hilfreich. Oder habe ich etwas übersehen?

@TE: Wie wichtig ist das Thema "Barrierefreiheit"? Wenn man nach der 80-20-Regel geht, könnte man versucht sein, das Thema wegzulassen. Alternativ müßte man 2 Webseiten bauen oder wenigstens versuchen, Javascript so sparsam wie möglich einzusetzen. Man kann JS z.B. dafür nutzen, vorhandene Menüstrukturen auszublenden, anstatt neue Menüs per JS zur Laufzeit zu generieren. Generell sollte eine barrierefreie Seite möglichst einfach gestrickt sein und man sollte sie mit mehreren Screenreadern testen. Yahoo hat übrigens einen Guide über das Thema veröffentlicht.

Kannst Du sagen, wie viel Formulare und wieviel Navigation die Seite enthalten wird?

 

[benneq]

Geplant ist eine Art CMS mit integriertem Forum, also vom Umfang ähnlich wie Computerbase selbst. Allerdings für eine viel kleinere Benutzergruppe
Das Thema Barrierefreiheit ist eigentlich irrelevant, aber wenn es sich berücksichtigen lässt, dann möchte ich das tun. Vor allem aber auch, damit die Suchmaschinen mit der Seite klarkommen.

Das ganze Steckt noch ganz am Anfang in der Planungsphase. Bisher hab ich nur ein paar kleine Testseiten geschrieben, um zu schauen, was mit JavaScript in Richtung Barrierefreiheit möglich ist. Dabei ist dann z.B. Folgendes entstanden:

1. Eine Reihe von (Foren-)Einträgen wird angezeigt und darunter ist ein Link für "Neuen Kommentar schreiben". Wenn JS ausgeschaltet ist wird man auf die Seite mit dem Formular weitergeleitet. Wenn JS angeschaltet ist, überschreibt JQuery die onClick Funktion des Links und dann wird per AJAX das Formular geladen und das <div> in dem vorher "Neuen Kommentar schreiben" stand, wird restlos durch das Formular ersetzt.
Wichtig: Ich lade einfach das Komplette Formular als HTML-Code, also wird da nichts generiert oder so. D.h. ich kann mit und ohne JS jeweils identischen Code verwenden.
2. An jedem Eintrag ist ein Link "Löschen". Ohne JS wird die Seite neugeladen und der Eintrag gelöscht. Mit JS überschreibt JQuery wieder die onClick Methode und schickt den Befehl zu löschen per AJAX ab. Dann ist natürlich ein 'onSuccess'-Callback eingebaut, das dann den Eintrag per fadeOut ausblendet und danach aus dem DOM-Tree löscht.

Das funktioniert problemlos und ist programmiertechnisch ein Aufwand von jeweils 3-4 Zeilen.

Für die Globale Navigation wäre der JQuery UJS Ansatz überhaupt kein Problem:
- Ohne JS lädt einfach die Seite, die man möchte
- Mit JS lädt man die Seite per AJAX und kann dann beliebige grafische Spielereien machen (Überblendung oder das alte div aus dem sichtbaren Bereich schieben oder was auch immer)


Viel wichtiger wäre das AJAX Zeug halt, wenn man z.B. die 'Startseite' des Forums aufbauen möchte. Hier werden viele unnötige Kilobytes übertragen. Es sind ja immer wieder die selben Fragmente, die benutzt werden. Wenn man das CB-Forum als Beispiel nimmt braucht jeder Aufruf ca. 30-40KB.
Vielleicht kommt mir das gerade auch nur alles so viel vor, weil ich mit ISDN-Geschwindigkeit über Tethering surfe

Also insgesamt geht es mir nur um die Stellen auf der Seite, wo man durch JS sehr viel Code generieren könnte, der sonst auf dem Server generiert werden müsste und danach über die Leitung geschickt.



EDIT: Interessant wird das dann auch wieder, wenn ich einen InPlace-Editor integrieren möchte. Das wird bestimmt eine schwierigere Angelegenheit. Das stelle ich mir grob so vor:
- Die Einträge werden ganz normal in HTML generiert und dargestellt
- Jeder Eintrag hat einen Link "Editieren"
- JQuery UJS soll dann die Elemente innerhalb des Formulars durch InPlace-Editoren ersetzen und aus dem Link "Editieren" wird dann ein Link "Speichern", der die Daten per AJAX speichert.

Alternative (ohne InPlace):
Beim Klick auf "Editieren" lädt JQuery das normale Formular zum editieren und ersetzt einfach die vorherige Darstellung des Eintrags durch das Formular.

 

[Daaron]

Viel wichtiger wäre das AJAX Zeug halt, wenn man z.B. die 'Startseite' des Forums aufbauen möchte. Hier werden viele unnötige Kilobytes übertragen. Es sind ja immer wieder die selben Fragmente, die benutzt werden. Wenn man das CB-Forum als Beispiel nimmt braucht jeder Aufruf ca. 30-40KB.
Vielleicht kommt mir das gerade auch nur alles so viel vor, weil ich mit ISDN-Geschwindigkeit über Tethering surfe

Statisch geliefertes HTML ist schneller, weil es wunderbar komprimiert und gecached werden kann. Die .htaccess ist dein Freund.
Im Endeffekt ist es doch sowieso egal, ob du jedes Element mit JS generierst und manipulierst, oder ob du die Daten direkt sauber statisch überträgst. Statische Lösungen sind schneller, weil sie nicht erst den JS-Parser bemühen müssen. Spätestens wenn du dann mit AJAX-Requests arbeitest kann es, durch das Verbindungslimit zwischen Browser und Server, zu hässlichen Effekten kommen. PageSpeed würde dir solche Konstrukte um die Ohren hauen, wenn es sie denn erkennen würde.

 

[benneq]

Stimmt. In diesem konkreten Fall wäre es 1 Request mehr zum Server für die JSON Daten... Außer man embedded sie im HTML Code
Für alle folgenden Aufrufe wäre die JSON Übertragung von der Datenmenge her viel geringer. Werden AJAX Request etwa nicht mit gzip komprimiert? Für den Server sieht es doch wie eine ganz normale Browser-Anfrage aus. Also müsste das da doch dann auch zum Zuge kommen oder irre ich mich?

 

[Daaron]

Stimmt schon, die sollten durch den Zipper gehen. JSON-Data kann aber nicht so stark komprimiert werden wie pures HTML. Wenn man sich HTML/XML so anguckt, dann besteht es größtenteils aus Leerzeichen, Tabs, Zeilenumbrüchen,... Is dasselbe wie mit SQL: Ne 3MB große MySQL-Datenbank gibt n 280KB großen gz-Dump. Is viel komprimierbare Luft. In JSON ist alles eng gepackt, da sparst du nicht mehr viel.
Spätestens beim Caching hast du aber Probleme. Manche Ressourcen sollten gecached werden, andere hingegen dürfen nicht.

Beispiel Live-Chat/Shoutbox: In regelmäßigen Abständen kommt n asynchroner Request an den Server, der die aktuellen Chat-Logs aus der Datenbank holt. Hier kann dir nicht nur der DB-Cache in den Hintern beißen (5x nacheinander SELECT username,message,timestamp FROM chat => 1x abgefragt, 4x aus dem Cache), sondern erst recht der Browsercache. Wenn du nur die chatlist.php aufrufst, die dir den aktuellen Inhalt ausgibt, dann kriegst du in aggressiv cachenden Browsern wie Chrome keine Updates sondern immer und immer wieder dieselbe File


Ich halt echt nix davon, aus JSON-Daten irgend welchen HTML-Code zusammenzufrickeln, der genauso gut auch direkt übertragen werden könnte. Du sparst, wenns hoch kommt, ne einstellige Menge an Kilobyte, opferst dafür aber Requests, Parser-Geschwindigkeit beim User (denk nicht nur an 3GHz-Quadcores, denk an Smartphones. Die reagieren viel langsamer auf JS) und zu guter Letzt: Übersicht im Code. So n gut strukturierten HTML/XML-Code überblickt man sofort mit nem guten Editor.
Wenn man Datenrate sparen will, dann sollte man das woanders machen, nicht an den Textkomponenten. Man kann viel mehr Speed gewinnen, wenn man z.B. möglichst viele JS- oder CSS-Dateien jeweils zu einer zusammenfasst. Noch mehr Gewinn gibts, indem man CSS Sprites verwendet. Cleverer Sprite-Einsatz spart gern mal 10-15 Requests und n Dutzend KB.

 

[benneq]

chatlist.php .. haha PHP habe ich schon lange abgeschworen. Ich nutze Rails Das löst nebenbei auch gleich fast alle anderen von dir angesprochenen Punkte:
- Sämtlicher JS Code in einer einzigen Datei
- Sämtlicher CSS Code in einer einzigen Datei
- Bilder und Schriftarten können mit einer halben Zeile Code als Base64 Encoded Strings direkt in der CSS gespeichert werden. D.h. kein Request zum Server (vor allem sehr gut, wenn man 30-40 kleine Icons benutzt). Und diese Teile kann man natürlich einfach als Sprite benutzen.

Allerdings hast du mich auf was interessanten hingewiesen: DB-Caching und Browser-Caching
Ich werd die Tage mal so eine Art Chat aufsetzen und schauen was passiert

 

[Daaron]

- Sämtlicher JS Code in einer einzigen Datei
- Sämtlicher CSS Code in einer einzigen Datei

Das ist kein Problem von PHP sondern einfach nur eine Frage des cleveren Zusammenfügens.

Nur weil Rails so trendy ist, ist es noch lange kein Allheilmittel. Viele coole Sachen kann man auch mit NodeJS machen, oder mit Python, oder oder oder....
Knackpunkt ist aber: Welches Open Source CMS/Shopsystem existiert für die Sprache/existiert überhaupt eins? Wir nutzen z.B. für die meisten Projekte Contao & Magento, sind also an PHP5 und MySQL5 gebunden. Der nächste Punkt ist das liebe Geld. Einen LAMP/WAMP-Server kriegst du bei jedem Hoster für wenig Geld, aber versuch mal einen Server mit aktivem Ruby oder Python zu buchen. Klar, wir hosten selbst, ich könnt hier sogar n NodeJS aufsetzen, aber wozu die Mühe?

- Bilder und Schriftarten können mit einer halben Zeile Code als Base64 Encoded Strings direkt in der CSS gespeichert werden. D.h. kein Request zum Server (vor allem sehr gut, wenn man 30-40 kleine Icons benutzt). Und diese Teile kann man natürlich einfach als Sprite benutzen.

Den Base64-Kram macht nicht jeder Browser sauber mit. Damit hast du nur Probleme. Dann doch lieber Sprites, wo Sprites möglich sind (z.B. hier im Forum wären die Thread-Symbole n perfektes Sprite-Problem). Und was die Fonts angeht: Du kannst eh nicht jede Schriftart frei nutzen, am Ende landet man doch oftmals bei denen, die bei Google Fonts gehostet werden. Schon ist es eine CDN-Quelle und belastet die parallelen Verbindungen kaum bis gar nicht.

 

[benneq]

Ich programmier nun schon seit vielen, vielen Jahren. Und ich bin bei Rails gelandet, weil es mir eben sehr viel abnimmt. Natürlich ist es nicht so etabliert wie PHP, aber wenn man sich erstmal reingefunden hat, dann will man sein PHP auch nie wieder anfassen. Ich hatte bestimmt 10 Jahre mit PHP am Hut und jetzt kann ich guten Gewissens sagen, dass der Code nie wirklich schön und übersichtlich war. Selbst C wirkt in meinen Augen aufgeräumter.
Glasklar: Geschmackssache!

Zurück zum Thema: Wo sollte Base64 denn Probleme machen? Die einzige Beschränkung liefert aktuell der IE mit 64 (oder 32?!) KiloByte. Aber kein Icon dieser Welt kommt an die Größe ran.

Achja: Vielleicht sollte ich das noch erwähnen. Ich entwickel in HTML5. Und ich werde mich nicht bemühen Code zu verbiegen, nur damit ein 10 Jahre alter Browser damit klarkommt. Wenn es eine JS Lib gibt die ich einfach einbinde und gut ist, dann meinetwegen, aber mehr mache ich nicht.
Das Projekt wird vermutlich 1-2 Jahre dauern und bis dahin wird wohl die halbe Microsoft Welt den IE 10 nutzen.
Kein Diskussionsbedarf!

 

[Daaron]

Das Projekt wird vermutlich 1-2 Jahre dauern und bis dahin wird wohl die halbe Microsoft Welt den IE 10 nutzen.

In dem Aspekt besteht definitiv Diskussionsbedarf.
Ich werf grad n Blick ins Analytics einer unserer Seiten, die primär auf Geschäftskunden abzielt: Innerhalb des IE-Anteils entfallen gerade mal 33% auf den IE9, 55% nutzen noch den 8er, der 7er hat noch >10%. Kannst ja raten, was die restlichen Prozente füllt... erbärmlich.

Der IE9 ist nicht erst seit gestern raus, trotzdem wird er um Längen vom uralten 8er geschlagen. Das sagt viel darüber aus, wie es in 2 Jahren aussehen wird: 10er bei 20-25%, 9er bei 20-25%, 8er bei 30%+

 

[Ruheliebhaber]

Die Kunden meiner alten Firma haben zu 100% den IE 6 genutzt und wir reden hier von 20000 PC. Jetzt sind sie dabei den IE 7 auszurollen. Selbst Microsoft will den IE 6 loswerden.

 

[benneq]

Mir ist klar, dass der nicht erst seit gestern draußen ist, aber ich habe ja schon gesagt, dass die Benutzergruppe klein sein wird (zumindest zu Beginn), es wird sich hauptsächlich um Privatpersonen handeln und ich setze halt HTML5 vorraus, genau so wie viele große Firmenwebseiten Flash vorraussetzen (was ich persönlich ziemlich unverschämt finde).

Ich kenne in meinem Umfeld niemanden der den IE nutzt (außer evtl. zur Webentwicklung). Und ich glaube außerhalb der Firmen wird den auch kaum jemand benutzen. Außerdem musst du in deine Prognose Folgendes einbeziehen: Ich sehe Tag für Tag mehr und mehr Menschen die mit Tablets im Netz surfen. Und soweit ich weiß haben die kein Problem mit HTML5. Ich denke in 2 Jahren haben noch mehr Leute ein Tablet (evtl dann auch mit Windows 8 und dem IE 10 ).

Oder drehen wir die Fragestellung einfach mal um: Was hat die Welt davon, wenn sich jeder an CSS-Weichen und co festhält und möglichst alles Neue vermeidet, weil es nicht überall läuft?! Stillstand, statt Fortschritt. Wenn es danach ginge wären auch Canvas und SVG Tabu (außer man nimmt wieder ein JS Lib, die als Weiche fungiert...). Und gerade Canvas ist ziemlich geil für Statistiken, Diagramme, etc.. Bei HTML5 Audio und Video muss ich ja schon Kompromisse eingehen und nach dem Hochladen mit FFMPEG das Video konvertieren, damit es auch jeder sehen kann...
Meinetwegen vergraul ich 20% der potentiellen Nutzer, solang ich jeden hundertsten zum Wechseln bringen kann. Halte mich für engstirnig oder naiv, aber ich habe Prinzipien zu denen ich stehe.

 

[ice-breaker]

Ich kenne in meinem Umfeld niemanden der den IE nutzt (außer evtl. zur Webentwicklung). Und ich glaube außerhalb der Firmen wird den auch kaum jemand benutzen.

Da haben wir schon den dauernden und immer falsch gemachten Trugschluss
Nur weil man persönlich niemandem mit dem IE kennt, nutzt es niemand, basta!
Das ist absolut falsch und es gibt viele die den IE nutzen, das wird dir jede Statistik über Marktanteile für Browser aufzeigen
Aber nicht vergessen: Statistiken von Technikseiten wie CB und Co sind dafür nicht repräsentativ.

StatCounter hat da schon nette Angaben, da nach deren Angaben 3 Millionen Projekte einbezogen werden, da hat man dann genug verschiedene "Nutzergruppen".

 

[Ruheliebhaber]

Du hast Recht. Ich wollte nur ein Beispiel bringen, daß man im Firmenumfeld oft zu merkwürdigen Entscheidungen gezwungen ist. Airbus z.B. verabschiedet sich im Moment gerade von Windows 2000. Das werden die meisten auch nicht für möglich halten.

 

[benneq]

Echt Windows 2000?
Aber selbst bei den XP Maschinen versteh ich es nicht, da hängen viele Firmen noch auf dem IE6 fest...

Nun gut.. Eigentlich ging es ja um SEO und Barrierefreiheit Die Barriere gegen den IE werde ich aufrecht erhalten

 

[Ruheliebhaber]

Hier ist nochmal die Seite von MS: http://www.ie6countdown.com/

Wegen Airbus. Hätte ich auch nicht geglaubt. Mein Kollege hat bis letztes Jahr aber viele Projekte bei denen gemacht und mir davon erzählt.

 

[benneq]

Ha!
Mir ist gerade doch ein Fall eingefallen, wo ich glaube, dass JSON angebracht ist

Schaut mal in die CB News. Da sind ja oft Bildergallerien eingebaut. Mein Plan für eine Gallerie die mit und ohne JS läuft:

<a href="link/zur/gallerie" data-remote="true" class="gallery">
  <img src="galleriebild" />
  Hier geht's zur Gallerie
</a>

Ohne JS wird einfach nur das Bild angezeigt mit dem Text drunter. Ein Klick darauf bringt den Benutzer zur gewünschten Gallerie.
Mit JQuery UJS wird natürlich wieder nach dem data-remote=true Attribut gesucht und wenn zusätzlich class="gallery" gefunden wird, wird das dann einfach so ersetzt (Hier kommen die ein paar Vorzüge von Rails zum Vorschein):
- JS fragt auf der selben URL, wie der Link, nach Daten. Wobei im Header steht, dass als Response JSON sein sollte
- Der Rails Controller liefert nun nicht den HTML Code für die normale Gallerie-Ansicht zurück, sondern ein JSON Array wo jeweils Preview-Bild, Fullscreen-Bild und Beschreibung zusammengefasst sind.
- JS baut aus dem JSON Code eine Gallerie auf und ersetzt den kompletten <a href=...>...</a> Teil durch die JS-Gallerie

Klingt brauchbar oder nicht?