Kultur von Webseiten

[Gunnar Bittersmann]

@@Camping_RIDER:

nuqneH

„Bequem“ und „wechseln“ schließen einander aus. Bequem ist, nicht wechseln zu müssen, weil man gleich die für das jeweilige Gerät passende Darstellung geboten bekommt.

Nein. Du hast nicht genau gelesen. Die für das jeweilige Gerät passende Darstellung wird automatisch angeboten. Bequem und wechseln schließt sich dann nicht aus, wenn ein Wechsel (oder hier vielmehr eine Wahl) nicht obligatorisch, sondern selbstbestimmt aus eigenem Antrieb erfolgt.

Kann es sein, dass du nicht genau liest? Ein Wechsel der Darstellung sollte überhaupt nicht notwendig sein (wenn der Nutzer gleich die für ihn passende geboten bekommt). Siehe auch meine Antwort an Matthias.

JavaScript ist eine Säule von progressive enhancement.

Ja, mag sein. Trotzdem gilt zumindest für mich die Maxime, dass eine Seite in ihren Eckpunkten ohne JavaScript komplett funktionieren sollte. JS ist für mich kein Werkzeug für Essentials (aka Responsivität und grundlegende Präsentation), sondern ein Tool zur Erschaffung von Komfortfunktionen). Mit dieser extremen Einstellung mag ich alleine stehen.

JavaScript als progressive enhancement – da geh ich mit.

Die Anpassung von Layout und zusätzlichen Funktionen und Inhalten an besondere Eigenschaften des Clients wie z.B. großer Bildschirm (Responsivität) ist auch progressive enhancement. Kann also durchaus mithilfe von JavaScript erfolgen.

Man sollte natürlich nichts mit JavaScript machen, was man auch mit CSS (media queries) tun kann.

Was hat Barrierefreiheit damit zu tun, ob JavaScript eingesetzt wird?

Barrierefreiheit ist für mich nicht nur die Einhaltung von bestimmten Standarts, sondern die Freiheit von möglichst vielen Barrieren. Dazu gehört auch die Freiheit von benötigter Javascript-Benutzung gemäß oben genannter Maxime.

Bei Barrierefreiheit geht es darum, dass Nutzer mit körperlichen (oder geistigen) Einschränkungen Webseiten benutzen können. Nicht um Nutzer, die sich technische Einschränkungen wie Deaktivierung von JavaScript selbst auferlegen.

Zum Thema URI/URL: Das ist der Uniform (einheitlich formatierter) Resource (Ressourcen-) Identifier (Bezeichner) bzw. Locator (Anzeiger). In beidem steht ausdrücklich Ressource - nicht Content. Es geht bei beiden Bezeichnungen nicht um Inhalt, sondern um das Gesamtpaket aus Inhalt, Markup, Präsentation, Bildern ... Das was ich unter verschiedenen URI anbieten würde, wäre zwar inhaltsgleich, aber keinesfalls ressourcengleich (weil: entschlankte Seitenstruktur, evtl andere Stylesheets...). Überhaupt: Der URI identifiziert/bezeichnet Ressourcen. Wer sagt denn, dass eine Ressource (vor allem, wenn du das auf den Inhalt herunterbrichst) nicht zwei Bezeichner haben kann? Das ist doch genau die Eigenschaft eines Identifier. Er bezeichnet Dinge so präzise, dass kein Zweifel darüber aufkommt, was gemeint ist. Das heist nicht, dass es nicht mehrere zweifelsfreie Identifier für ein und dieselbe Sache geben kann. Die Zuordnung zwischen Identifier und Objekt ist sicher injektiv, aber nicht notwendigerweise surjektiv.

OK, man könnte für eine bestimmte Seite auch einen generischen URI (das ist der, der an andere weitergegeben werden sollte) und darstellungsspezifische URIs haben – wie auch generischen vs. sprachspezifische URIs bei language negotiation. Bei Sprachversionen braucht man die sprachspezifischen URIs zum Umschalten; bei Darstellungsversionen sollte man keine Umschaltung brauchen, siehe oben.

Qapla'