Wäre es nicht Zeit für HTML 4.1...

[Gunther]

Einen schönen Sonntagabend zusammen!

Nachdem ich mich jetzt eine Woche lang ziemlich intensiv mit diesem Forum hier und allen möglichen anderen Quellen zum Thema Barrierefreiheit beschäftigt habe, stellen sich mir als Hobby-Webseiten-Ersteller mehrere Fragen. Mich würde mal eure (fachkundige/private) Meinung dazu interessieren, deshalb schon jetzt mein Dank an alle, die sich die Zeit nehmen, und eine Antwort schreiben.

Ich glaube sagen zu können, dass folgende Aussagen in etwa den Trend der vorherrschenden Meinung hier im Forum wieder geben:

• man sollte seine Webseiten dem W3C Standard konform aufsetzen
• Webseiten sollten so weit wie möglich browser- und plattformunabhängig sein
• Webseiten sollten barrierefrei sein

Um keine Missverständnisse aufkommen zu lassen  mir geht es_nicht_um diese Punkte (von denen jeder einzelne mit Sicherheit seine Berechtigung hat), sondern vielmehr darum, wie man diese Forderungen mit den zur Verfügung stehenden Mitteln noch alle unter einen Hut bringen soll.

Validen Code zu schreiben erscheint mir hierbei noch die geringste Schwierigkeit zu sein (u.a. dank SelfHTML), nur was nutzt mir der letztendlich, wenn die Anzeige nachher doch in jedem Browser (sofern überhaupt etwas angezeigt wird) anders aussieht?

Ein Standard ist ja sicher auch sinnvoll & notwendig, aber inwieweit kann man denn überhaupt von Standard sprechen, wenn es AFAIK keinen einzigen Browser gibt, der den kompletten Standard auch standardgemäß beherrscht? Wäre da eine Bezeichnung wie Schnittmenge von W3C-Standard und Browser nicht viel eher zutreffend?

Wie schwierig es zu sein scheint, einen solchen Browser zu entwickeln, würde ich alleine mal daraus ableiten, dass es ja selbst dem W3C nicht gelingt (Stichwort: Amaya). Und wenn man dann mal guckt, wie alt die meisten von diesen heute noch aktuellen Standards sind

Browserunabhängigen Code schreiben  schön und gut. Aufgrund des wohl noch relativ hohen Einsatzes des Netscape Communicators 4.7, soll also die Webseite auch noch in den Browsern der 4. Generation funktionieren (in einer brauchbaren Form angezeigt werden).

Da fangen die Probleme dann schon an. Wie stelle ich denn fest, welche Methoden und Objekte der vom User verwendete Browser unterstützt bzw. kennt? Ich persönlich z.B. kenne nur wenige Möglichkeiten, dies alleine mit Hilfe von HTML zu bewerkstelligen (<noframe>, <noscript>, <noembed>, und die Bereiche z.B. zwischen <object></object> oder <iframe></iframe>). Hier sehe ich mich dann als Hobby-Bastler eigentlich das erste mal gezwungen, auf Alternativen zurückzugreifen. Aber welche kommen da in Frage? Na ja, eigentlich wäre Javascript ja wunderbar, wenn da nicht das Problemchen wäre, dass der User dieses einfach deaktivieren kann in seinem Browser (und schon klappt nix mehr). Aber laut unserer selbst gestellten Anforderung, soll die Seite ja auch dann noch funktionieren. Das größte Problem, was sich für mich dann stellt ist, dass man keinerlei Informationen über den vom User benutzten Browser (und z.B. die Fenstergröße) mehr erhält.

Aber selbst wenn man einmal annimmt, das Javascript nicht deaktiviert wurde, ist man noch lange nicht aus allen Problemen raus.
Dazu ein kurzer Auszug aus SelfHTML 8: Vom W3-Konsortium erhielt das Modell die Bezeichnung Document Object Model (DOM). Am 1. Oktober 1998 wurde das DOM eine offizielle W3-Empfehlung (recommendation) in der Version 1.0, die seit dem 29. September 2000 in einer zweiten Ausgabe vorliegt. Seit 13. November 2000 ist die Version 2.0 des DOM eine offizielle W3-Empfehlung. Das entsprechende Dokument ist jedoch aufgesplittet in mehrere Einzeldokumente. Version 3.0 ist in Arbeit.
Der MS Internet 5.0 unterstützt einiges von DOM 1.0, die Version 5.5 schon mehr, ebenso wie Netscape 6.x. Die JavaScript-Version, die DOM erstmals umsetzt, ist die Version 1.5.
Folglich scheidet die (ausschließliche) Verwendung des DOM also aus (denn wir wollen ja auch die nicht DOM-fähigen Browser der 4. Generation noch unterstützen). Streng genommen scheidet sie ja eigentlich ganz aus (siehe oben, Einschränkung Javascript) ;-)
Also sind wir auch in diesem Fall wieder auf die Differenzierung je nach verwendetem Browser abhängig. Hier kann man dann ja noch relativ leicht nach den bekannten Methoden/ Objekten eine einigermaßen treffsichere Unterscheidung vornehmen. Wobei ich mich dabei immer frage, warum die Browserhersteller es so eingerichtet haben, dass man bspw. den navigator.userAgent als User verändern kann (was ihn ja im Prinzip fast völlig wertlos macht)?

Auf diese Art & Weise kriege ich dann die verschiedenen Browser ziemlich sicher nach Hersteller auseinander sortiert (was ja de fakto notwendig ist, um die jeweiligen Bugs auszugleichen), aber damit habe ich immer noch nicht die jeweilige Version des betreffenden Browsers ermittelt, was aber eigentlich genauso zwingend notwendig wäre, da ja die verschiedenen Versionen eines Browsers von ein und demselben Hersteller durchaus verschiedene Macken haben kann.

Kommen wir jetzt mal zu den gestalterischen Möglichkeiten (Stichwort CSS). Eine wunderbare & mächtige Erweiterung zu HTML  leider aber auch wieder mit denselben Problemen behaftet. Es gibt zwar wiederum einen Standard, aber die Browser interpretieren diesen ebenfalls in anderer Art & anderem Umfang, womit wir wieder bei dem (Javascript-)Problem der effizienten Browserunterscheidung wären. Vielfach trifft man heutzutage die Variante an, dass man Code verwendet, der von bestimmten Browsern dann ignoriert (da ihnen unbekannt) wird, um damit vorhergehende Anweisungen (für die anderen Browser) zu überschreiben. Was mache ich aber dann, wenn der Nachfolger die Anweisungen dann plötzlich versteht? Alles neu?

Und plötzlich (ich formuliere das bewusst etwas provokant) fällt allen Beteiligten auf, dass man (mal wieder) eine Minderheit vergessen hat, nämlich die behinderten Menschen (Stichwort Barrierefreiheit). So gerne wie ich meine Webseite auch an die Bedürfnisse dieser Menschen anpassen möchte, muss ich sagen, dass hier der Punkt erreicht ist, an dem ich endgültig nicht mehr weiß, wie ich meine Webseite noch gestalten soll, um die notwendigen Inhalte zu transportieren.

Das hat mehrere Gründe. Zum einen muss man sich ja erst einmal mit den Bedürfnissen dieser Gruppe vertraut machen. Ich z.B. kenne gar keine alternativen Ausgabegeräte. Folglich weiß ich auch nicht, welche Anforderungen diese nun an eine benutzbare Webseite stellen (mal ganz davon abgesehen, dass ich es auch nicht testen kann). Ich spreche in diesem Zusammenhang nicht von leicht umzusetzenden Dingen, wie bspw. einem sinnvollen ALT-Attribut. Meiner Ansicht nach muss z.B. eine Navigationsstruktur für sehende und nicht sehende Menschen fast zwangsläufig anders aufgebaut sein.

Jetzt komme ich mal auf den eigentlichen Titel des Threads zurück. Meiner Meinung nach ergeben sich aus der Praxis der letzten Jahre, der Browserentwicklung und den veränderten Anforderungen an Webseiten (um jetzt nur mal drei der wichtigsten Punkte zu nennen) doch nun langsam aber sicher mal die Notwendigkeiten, den HTML-Standard auch diesbezüglich mal zu erweitern. Ich empfinde die Empfehlungen des W3C nämlich langsam so, dass ich (als Webseitenersteller) mit HTML etwas umsetzen soll, was HTML IMHO nicht mehr in der Lage ist zu leisten. Als Beispiel möchte ich hierzu nur mal den Fall Redirect nennen. Das W3C empfiehlt auf die Verwendung von <META HTTP-EQUIV=REFRESH CONTENT="1; URL=http://machine/doc3.html"> zu verzichten (siehe http://www.w3.org/2001/06tips/reback). Stattdessen empfiehlt man auf serverseitige Techniken auszuweichen (wenn ich das aus den angegebenen Links richtig interpretiert habe) also nix mehr mit HTML, wobei doch gerade das noch mein Rettungsanker gewesen wäre für den Fall, dass ein User Javascript deaktiviert hat. Wo bleibt denn da eine sinnvolle HTML-Alternative?

Warum führt man keine neuen Elemente/ Attribute ein? Gerade aufgrund der Tatsache, dass die meisten Browser ihnen unbekannte Angaben einfach ignorieren, wäre es doch eigentlich ein Leichtes. Speziell in punkto Barrierefreiheit. Hier würden zusätzliche Attribute bei einigen Elementen, die dann eben auch nur von speziellen Ausgabegeräten interpretiert werden, doch die Sache enorm vereinfachen.

Ursprünglich war ich mal der Meinung, dass das Internet seinen sprunghaften Aufstieg u.a. der Einfachheit der zugrunde liegenden Auszeichnungssprache verdankt. Dank Softwareherstellern und einem (in meinen Augen) fern jeder Realität agierenden Konsortiums wird es um die allseits so wehemend geforderte allgemeine Zugänglichkeit von Internetseiten in Zukunft schlecht bestellt sein.

Von einem, der auszog ins WWW, um seine Seite allgemeiner zugänglich zu machen, und jetzt gar nicht mehr weiß, wie er seine Seiten noch aufsetzen soll...

Gruß Gunther

[Fabian Transchel]

Hallo Gunther,

Einen schönen Sonntagabend zusammen!

Danke gleichfalls.

Nachdem ich mich jetzt eine Woche lang ziemlich intensiv mit diesem Forum hier und allen möglichen anderen Quellen zum Thema Barrierefreiheit beschäftigt habe, stellen sich mir als Hobby-Webseiten-Ersteller mehrere Fragen. Mich würde mal eure (fachkundige/private) Meinung dazu interessieren, deshalb schon jetzt mein Dank an alle, die sich die Zeit nehmen, und eine Antwort schreiben.

Kein Problem, interessanten Fragen antworte ich gern.

• man sollte seine Webseiten dem W3C Standard konform aufsetzen

Absolut.

• Webseiten sollten so weit wie möglich browser- und plattformunabhängig sein

Absolut.

• Webseiten sollten barrierefrei sein

Absolut.

Validen Code zu schreiben erscheint mir hierbei noch die geringste Schwierigkeit zu sein (u.a. dank SelfHTML), nur was nutzt mir der letztendlich, wenn die Anzeige nachher doch in jedem Browser (sofern überhaupt etwas angezeigt wird) anders aussieht?

Das stimmt so sicher nicht. In den "modernen" Browsern ab 5.x denke ich kann man _gleichaussehend_ coden, wennauch nicht pixelgenau.

Ein Standard ist ja sicher auch sinnvoll & notwendig, aber inwieweit kann man denn überhaupt von Standard sprechen, wenn es AFAIK keinen einzigen Browser gibt, der den kompletten Standard auch standardgemäß beherrscht? Wäre da eine Bezeichnung wie Schnittmenge von W3C-Standard und Browser nicht viel eher zutreffend?

Nein, denn stell dir mal vor, wie es ohne Standard wäre...
Opera und Mozilla kommen dem Standard extrem nahe und werden doch mit jeder Version besser.

Wie schwierig es zu sein scheint, einen solchen Browser zu entwickeln, würde ich alleine mal daraus ableiten, dass es ja selbst dem W3C nicht gelingt (Stichwort: Amaya). Und wenn man dann mal guckt, wie alt die meisten von diesen heute noch aktuellen Standards sind

Alt? Das W3C schläft nicht, die Entwicklungen zu XHTML 1.2 und CSS 3 sind doch in vollem Gange!?

Browserunabhängigen Code schreiben  schön und gut. Aufgrund des wohl noch relativ hohen Einsatzes des Netscape Communicators 4.7, soll also die Webseite auch noch in den Browsern der 4. Generation funktionieren (in einer brauchbaren Form angezeigt werden).

Deine Entscheidung, ich ignoriere alles was 4.x heißt und erläutere es auch den Kunden so. Wer meint, er müsse 4.x-Unterstützung haben, für den wird ein Aufschlag fällig. IMHO versteht sich.

Da fangen die Probleme dann schon an. Wie stelle ich denn fest, welche Methoden und Objekte der vom User verwendete Browser unterstützt bzw. kennt?

Imdem du sie Abfragst?

Ich persönlich z.B. kenne nur wenige Möglichkeiten, dies alleine mit Hilfe von HTML zu bewerkstelligen (<noframe>, <noscript>, <noembed>, und die Bereiche z.B. zwischen <object></object> oder <iframe></iframe>). Hier sehe ich mich dann als Hobby-Bastler eigentlich das erste mal gezwungen, auf Alternativen zurückzugreifen. Aber welche kommen da in Frage? Na ja, eigentlich wäre Javascript ja wunderbar, wenn da nicht das Problemchen wäre, dass der User dieses einfach deaktivieren kann in seinem Browser (und schon klappt nix mehr).

Ich habe kein Problem damit einen Alternativtext/-bild bereitzustellen. Wer ein PlugIn nicht hat, der weiß in aller Regel warum. Von Flash reden wir mal nicht ;-)))))

Aber laut unserer selbst gestellten Anforderung, soll die Seite ja auch dann noch funktionieren. Das größte Problem, was sich für mich dann stellt ist, dass man keinerlei Informationen über den vom User benutzten Browser (und z.B. die Fenstergröße) mehr erhält.

Richtig. Deswegen lautet die Devise mit CSS und Skalierbar zu schreiben. Ganz einfach.

Folglich scheidet die (ausschließliche) Verwendung des DOM also aus (denn wir wollen ja auch die nicht DOM-fähigen Browser der 4. Generation noch unterstützen).

Nein, wollen wir nicht. Punkt.

Streng genommen scheidet sie ja eigentlich ganz aus (siehe oben, Einschränkung Javascript) ;-)

Gut, man kann es auch übertreiben. Meine Meinung. Wenn ich mit Lynx unterwegs bin, dann weiß ich, welche Probleme ich in Kauf zu nehmen habe.

Also sind wir auch in diesem Fall wieder auf die Differenzierung je nach verwendetem Browser abhängig.

Nein. Ein Dokument für alle Browser. Wenn einem Browser das nicht schmeckt - Pech gehabt. Es kann doch nicht so schwer sein, einmal validen Code zu schreiben.

Hier kann man dann ja noch relativ leicht nach den bekannten Methoden/ Objekten eine einigermaßen treffsichere Unterscheidung vornehmen. Wobei ich mich dabei immer frage, warum die Browserhersteller es so eingerichtet haben, dass man bspw. den navigator.userAgent als User verändern kann (was ihn ja im Prinzip fast völlig wertlos macht)?

Richtig so. Ich bin manchmal als "USS Enterprise NCC-1701-E 2358 SE" unterwegs. Wo ist das Problem? Verabschiede dich davon, die Brtowser erkennen zu wollen. Schreibe so, als kenntest du die Browser nicht.

Auf diese Art & Weise kriege ich dann die verschiedenen Browser ziemlich sicher nach Hersteller auseinander sortiert (was ja de fakto notwendig ist, um die jeweiligen Bugs auszugleichen), aber damit habe ich immer noch nicht die jeweilige Version des betreffenden Browsers ermittelt, was aber eigentlich genauso zwingend notwendig wäre, da ja die verschiedenen Versionen eines Browsers von ein und demselben Hersteller durchaus verschiedene Macken haben kann.

Du redest vom IE, ne? ;-)

Kommen wir jetzt mal zu den gestalterischen Möglichkeiten (Stichwort CSS). Eine wunderbare & mächtige Erweiterung zu HTML  leider aber auch wieder mit denselben Problemen behaftet. Es gibt zwar wiederum einen Standard, aber die Browser interpretieren diesen ebenfalls in anderer Art & anderem Umfang, womit wir wieder bei dem (Javascript-)Problem der effizienten Browserunterscheidung wären. Vielfach trifft man heutzutage die Variante an, dass man Code verwendet, der von bestimmten Browsern dann ignoriert (da ihnen unbekannt) wird, um damit vorhergehende Anweisungen (für die anderen Browser) zu überschreiben. Was mache ich aber dann, wenn der Nachfolger die Anweisungen dann plötzlich versteht? Alles neu?

Ich dachte, du redest schon die ganze Zeit von CSS und DOM.
HTML 4 kann jeder UA der unterwegs ist perfekt!

Was CSS-Probleme angeht: Für fast alle Bugs gibt es Hacks, die relativ simpel das Problem umgehen.

Und plötzlich (ich formuliere das bewusst etwas provokant) fällt allen Beteiligten auf, dass man (mal wieder) eine Minderheit vergessen hat, nämlich die behinderten Menschen (Stichwort Barrierefreiheit). So gerne wie ich meine Webseite auch an die Bedürfnisse dieser Menschen anpassen möchte, muss ich sagen, dass hier der Punkt erreicht ist, an dem ich endgültig nicht mehr weiß, wie ich meine Webseite noch gestalten soll, um die notwendigen Inhalte zu transportieren.

Gerade CSS ist ein großer Fortschritt in Sachen behindertengechtem Webdesign, Stichwort ruby etc.

Jetzt komme ich mal auf den eigentlichen Titel des Threads zurück. Meiner Meinung nach ergeben sich aus der Praxis der letzten Jahre, der Browserentwicklung und den veränderten Anforderungen an Webseiten (um jetzt nur mal drei der wichtigsten Punkte zu nennen) doch nun langsam aber sicher mal die Notwendigkeiten, den HTML-Standard auch diesbezüglich mal zu erweitern. Ich empfinde die Empfehlungen des W3C nämlich langsam so, dass ich (als Webseitenersteller) mit HTML etwas umsetzen soll, was HTML IMHO nicht mehr in der Lage ist zu leisten. Als Beispiel möchte ich hierzu nur mal den Fall Redirect nennen. Das W3C empfiehlt auf die Verwendung von <META HTTP-EQUIV=REFRESH CONTENT="1; URL=http://machine/doc3.html"> zu verzichten (siehe http://www.w3.org/2001/06tips/reback). Stattdessen empfiehlt man auf serverseitige Techniken auszuweichen (wenn ich das aus den angegebenen Links richtig interpretiert habe) also nix mehr mit HTML, wobei doch gerade das noch mein Rettungsanker gewesen wäre für den Fall, dass ein User Javascript deaktiviert hat. Wo bleibt denn da eine sinnvolle HTML-Alternative?

Gibt es nicht, aus dem einfachen Grund, dass das ohne HTML nun mal besser geht. Wo ist das Problem etwas, was nicht im Geringsten mit MarkUp zu tun hat, auch nicht damit zu machen?

Warum führt man keine neuen Elemente/ Attribute ein?

Hier ist der Punkt erreicht, an dem ich mich fragen muss, ob du die XML_Kapitel von SelfHTMl gelesen hast. Schade, die Erläuterungen vorher waren gut, aber hier schießt du ein Eigentor.

Gerade aufgrund der Tatsache, dass die meisten Browser ihnen unbekannte Angaben einfach ignorieren, wäre es doch eigentlich ein Leichtes. Speziell in punkto Barrierefreiheit. Hier würden zusätzliche Attribute bei einigen Elementen, die dann eben auch nur von speziellen Ausgabegeräten interpretiert werden, doch die Sache enorm vereinfachen.

Nochmal: Danbn schreib dir halt eine dir genehme DTD.

Ursprünglich war ich mal der Meinung, dass das Internet seinen sprunghaften Aufstieg u.a. der Einfachheit der zugrunde liegenden Auszeichnungssprache verdankt. Dank Softwareherstellern und einem (in meinen Augen) fern jeder Realität agierenden Konsortiums wird es um die allseits so wehemend geforderte allgemeine Zugänglichkeit von Internetseiten in Zukunft schlecht bestellt sein.

Dann tu was dagegen.

Fabian

[Christian Seiler]

Hallo Fabian,

Zum Rest äußere ich mich vielleicht später noch, aber eines kann ich so nicht stehen lassen:

HTML 4 kann jeder UA der unterwegs ist perfekt!

http://selfhtml.teamone.de/html/kopfdaten/beziehungen.htm#quellen, dritter Absatz.

Desweiteren kenne ich keinen gängigen Browser, der

<p/Hallo/<p>Hallo</p>

korrekt interpretiert. (Laut HTML4 müßte das als <p>Hallo</p><p>Hallo</p> zu interpretieren sein, fast alle Browser machen darauf aber <p>Hallo</p>, einige uralte Lynx-Versionen haben es mal richtig gemacht, allerdings haben die Lynx-Entwickler das wieder rausgenommen)

Viele Grüße,
Christian

[molily]

Hallo,

HTML 4 kann jeder UA der unterwegs ist perfekt!

[link-Elemente]

Metainformationen werden beispielsweise auch nicht regulär dargestellt. abbr-/acronym-Elemente mitunter ebenfalls nicht. Kein Browser »unterstützt« alle Feinheiten von HTML 4.01 im Sinne von »intelligent umsetzen/visualisieren«.

[SHORTTAG/OMITTAG]

Welches Problempotenzial ergibt sich daraus im Hinblick darauf, eine Seite interoperabel zu gestalten (siehe ursprüngliche Debatte)?

Mathias

[Christian Seiler]

Hallo molily,

Welches Problempotenzial ergibt sich daraus im Hinblick darauf, eine Seite interoperabel zu gestalten (siehe ursprüngliche Debatte)?

Gar keins. Es ging mir nur um die folgende Aussage:

HTML 4 kann jeder UA der unterwegs ist perfekt!

Gut, vielleicht hätte ich besser, um bei der Debatte zu bleiben, die Kombination <fieldset>, <label> und Netscape 4 anbringen sollen...

Viele Grüße,
Christian

[Gunther]

Hallo Fabian,

• man sollte seine Webseiten dem W3C Standard konform aufsetzen
  Absolut.

[1]»» »» - Webseiten sollten so weit wie möglich browser- und plattformunabhängig sein

Absolut.

• Webseiten sollten barrierefrei sein
  Absolut.

Validen Code zu schreiben erscheint mir hierbei noch die geringste Schwierigkeit zu sein (u.a. dank SelfHTML), nur was nutzt mir der letztendlich, wenn die Anzeige nachher doch in jedem Browser (sofern überhaupt etwas angezeigt wird) anders aussieht?
Das stimmt so sicher nicht. In den "modernen" Browsern ab 5.x denke ich kann man _gleichaussehend_ coden, wennauch nicht pixelgenau.

siehe [1], aber ich habe schon verstanden, wie deine Meinung dazu ist ;-) (geht ja auch aus deinem Kommentar 3 Absätze weiter deutlich hervor)

Ein Standard ist ja sicher auch sinnvoll & notwendig, aber inwieweit kann man denn überhaupt von Standard sprechen, wenn es AFAIK keinen einzigen Browser gibt, der den kompletten Standard auch standardgemäß beherrscht? Wäre da eine Bezeichnung wie Schnittmenge von W3C-Standard und Browser nicht viel eher zutreffend?
Nein, denn stell dir mal vor, wie es ohne Standard wäre...
Opera und Mozilla kommen dem Standard extrem nahe und werden doch mit jeder Version besser.

siehe nochmal [1]..., und wenn halt doch sehr viele User mit einem MSIE unterwegs sind..

Wie schwierig es zu sein scheint, einen solchen Browser zu entwickeln, würde ich alleine mal daraus ableiten, dass es ja selbst dem W3C nicht gelingt (Stichwort: Amaya). Und wenn man dann mal guckt, wie alt die meisten von diesen heute noch aktuellen Standards sind
Alt? Das W3C schläft nicht, die Entwicklungen zu XHTML 1.2 und CSS 3 sind doch in vollem Gange!?

mit alt ist gemeint, wie lange eine Umsetzung eines Standards in einen Browser dauert - einige Standards von 1999/2000 sind bis heute (noch) nicht in den Browsern implementiert.

Browserunabhängigen Code schreiben  schön und gut. Aufgrund des wohl noch relativ hohen Einsatzes des Netscape Communicators 4.7, soll also die Webseite auch noch in den Browsern der 4. Generation funktionieren (in einer brauchbaren Form angezeigt werden).
Deine Entscheidung, ich ignoriere alles was 4.x heißt und erläutere es auch den Kunden so. Wer meint, er müsse 4.x-Unterstützung haben, für den wird ein Aufschlag fällig. IMHO versteht sich.

ich sehe das eigentlich genauso, nur hier im Forum findet man (wie ich finde) sehr häufig auch eine gegenteilige Meinung.

Da fangen die Probleme dann schon an. Wie stelle ich denn fest, welche Methoden und Objekte der vom User verwendete Browser unterstützt bzw. kennt?
Imdem du sie Abfragst?

und wie (hier geht es mir ausschließlich um HTML, nicht um andere Methoden. Den Absatz bitte als Ganzes ansehen)

Ich persönlich z.B. kenne nur wenige Möglichkeiten, dies alleine mit Hilfe von HTML zu bewerkstelligen (<noframe>, <noscript>, <noembed>, und die Bereiche z.B. zwischen <object></object> oder <iframe></iframe>). Hier sehe ich mich dann als Hobby-Bastler eigentlich das erste mal gezwungen, auf Alternativen zurückzugreifen. Aber welche kommen da in Frage? Na ja, eigentlich wäre Javascript ja wunderbar, wenn da nicht das Problemchen wäre, dass der User dieses einfach deaktivieren kann in seinem Browser (und schon klappt nix mehr).
Ich habe kein Problem damit einen Alternativtext/-bild bereitzustellen. Wer ein PlugIn nicht hat, der weiß in aller Regel warum. Von Flash reden wir mal nicht ;-)))))

nein, weder von Flash noch von anderen Plug-In abhängigen Methoden

Aber laut unserer selbst gestellten Anforderung, soll die Seite ja auch dann noch funktionieren. Das größte Problem, was sich für mich dann stellt ist, dass man keinerlei Informationen über den vom User benutzten Browser (und z.B. die Fenstergröße) mehr erhält.
Richtig. Deswegen lautet die Devise mit CSS und Skalierbar zu schreiben. Ganz einfach.

na ja, ob das für 'Hobbyisten' wie mich 'ganz einfach' ist (siehe weiter unten) mag mal dahingestellt bleiben ;-)

Folglich scheidet die (ausschließliche) Verwendung des DOM also aus (denn wir wollen ja auch die nicht DOM-fähigen Browser der 4. Generation noch unterstützen).
Nein, wollen wir nicht. Punkt.

Annahme war ja: wollten wir doch..., aber nach der Aussage von oben schon klar...

Streng genommen scheidet sie ja eigentlich ganz aus (siehe oben, Einschränkung Javascript) ;-)
Gut, man kann es auch übertreiben. Meine Meinung. Wenn ich mit Lynx unterwegs bin, dann weiß ich, welche Probleme ich in Kauf zu nehmen habe.

Also sind wir auch in diesem Fall wieder auf die Differenzierung je nach verwendetem Browser abhängig.
Nein. Ein Dokument für alle Browser. Wenn einem Browser das nicht schmeckt - Pech gehabt. Es kann doch nicht so schwer sein, einmal validen Code zu schreiben.

auch eine Meinung dazu - bei Letzterem sind wir uns ja sogar einig (ich verweise aber auf weiter oben)

Hier kann man dann ja noch relativ leicht nach den bekannten Methoden/ Objekten eine einigermaßen treffsichere Unterscheidung vornehmen. Wobei ich mich dabei immer frage, warum die Browserhersteller es so eingerichtet haben, dass man bspw. den navigator.userAgent als User verändern kann (was ihn ja im Prinzip fast völlig wertlos macht)?
Richtig so. Ich bin manchmal als "USS Enterprise NCC-1701-E 2358 SE" unterwegs. Wo ist das Problem? Verabschiede dich davon, die Brtowser erkennen zu wollen. Schreibe so, als kenntest du die Browser nicht.

schon klar, kein Problem, nur worin besteht dann der Sinn dieser Eigenschaft?

Auf diese Art & Weise kriege ich dann die verschiedenen Browser ziemlich sicher nach Hersteller auseinander sortiert (was ja de fakto notwendig ist, um die jeweiligen Bugs auszugleichen), aber damit habe ich immer noch nicht die jeweilige Version des betreffenden Browsers ermittelt, was aber eigentlich genauso zwingend notwendig wäre, da ja die verschiedenen Versionen eines Browsers von ein und demselben Hersteller durchaus verschiedene Macken haben kann.
Du redest vom IE, ne? ;-)

auch, aber nicht nur - Opera und Netscape sind genau solche Kandidaten

Kommen wir jetzt mal zu den gestalterischen Möglichkeiten (Stichwort CSS). Eine wunderbare & mächtige Erweiterung zu HTML  leider aber auch wieder mit denselben Problemen behaftet. Es gibt zwar wiederum einen Standard, aber die Browser interpretieren diesen ebenfalls in anderer Art & anderem Umfang, womit wir wieder bei dem (Javascript-)Problem der effizienten Browserunterscheidung wären. Vielfach trifft man heutzutage die Variante an, dass man Code verwendet, der von bestimmten Browsern dann ignoriert (da ihnen unbekannt) wird, um damit vorhergehende Anweisungen (für die anderen Browser) zu überschreiben. Was mache ich aber dann, wenn der Nachfolger die Anweisungen dann plötzlich versteht? Alles neu?
Ich dachte, du redest schon die ganze Zeit von CSS und DOM.

nö, bisher eher von HTML und Javascript (das dann allerdings auch unter Berücksichtigung des DOM)

HTML 4 kann jeder UA der unterwegs ist perfekt!

das finde ich nur dann zutreffend, wenn man deine Meinung berücksichtigt und von Browsern ab der 5. Generation ausgeht

Was CSS-Probleme angeht: Für fast alle Bugs gibt es Hacks, die relativ simpel das Problem umgehen.

mag sein, und wieviele davon benötigen Javascript und sind cross-browser-fähig?

Und plötzlich (ich formuliere das bewusst etwas provokant) fällt allen Beteiligten auf, dass man (mal wieder) eine Minderheit vergessen hat, nämlich die behinderten Menschen (Stichwort Barrierefreiheit). So gerne wie ich meine Webseite auch an die Bedürfnisse dieser Menschen anpassen möchte, muss ich sagen, dass hier der Punkt erreicht ist, an dem ich endgültig nicht mehr weiß, wie ich meine Webseite noch gestalten soll, um die notwendigen Inhalte zu transportieren.
Gerade CSS ist ein großer Fortschritt in Sachen behindertengechtem Webdesign, Stichwort ruby etc.

das mag ja sein, aber was nutzt das in den älteren Browsern - Annahme war möglichst browser- und plattformunabhängig zu coden.

Jetzt komme ich mal auf den eigentlichen Titel des Threads zurück. Meiner Meinung nach ergeben sich aus der Praxis der letzten Jahre, der Browserentwicklung und den veränderten Anforderungen an Webseiten (um jetzt nur mal drei der wichtigsten Punkte zu nennen) doch nun langsam aber sicher mal die Notwendigkeiten, den HTML-Standard auch diesbezüglich mal zu erweitern. Ich empfinde die Empfehlungen des W3C nämlich langsam so, dass ich (als Webseitenersteller) mit HTML etwas umsetzen soll, was HTML IMHO nicht mehr in der Lage ist zu leisten. Als Beispiel möchte ich hierzu nur mal den Fall Redirect nennen. Das W3C empfiehlt auf die Verwendung von <META HTTP-EQUIV=REFRESH CONTENT="1; URL=http://machine/doc3.html"> zu verzichten (siehe http://www.w3.org/2001/06tips/reback). Stattdessen empfiehlt man auf serverseitige Techniken auszuweichen (wenn ich das aus den angegebenen Links richtig interpretiert habe) also nix mehr mit HTML, wobei doch gerade das noch mein Rettungsanker gewesen wäre für den Fall, dass ein User Javascript deaktiviert hat. Wo bleibt denn da eine sinnvolle HTML-Alternative?
Gibt es nicht, aus dem einfachen Grund, dass das ohne HTML nun mal besser geht. Wo ist das Problem etwas, was nicht im Geringsten mit MarkUp zu tun hat, auch nicht damit zu machen?

warum hat das nicht das geringste mit HTML zu tun? Gehören Meta-Tags nicht zu HTML? Und die Methode ist doch sogar valide, das einzige Problem an diesem Weg ist doch der Zurück-Button im Browser (Abhilfe würde IMHO eine einfache zusätzliche Möglichkeit schaffen, z.B. anzugeben, dass der refresh bei einem reload der Seite nicht nochmals ausgeführt werden soll).

Warum führt man keine neuen Elemente/ Attribute ein?
Hier ist der Punkt erreicht, an dem ich mich fragen muss, ob du die XML_Kapitel von SelfHTMl gelesen hast. Schade, die Erläuterungen vorher waren gut, aber hier schießt du ein Eigentor.

das habe ich schon die ganze Zeit befürchtet... ;-) es nur schwierig die wesentlich umfangreicheren Gedanken zu dem Thema einigermaßen treffend und noch in akzeptabler Länge in Worte zu fassen

Gerade aufgrund der Tatsache, dass die meisten Browser ihnen unbekannte Angaben einfach ignorieren, wäre es doch eigentlich ein Leichtes. Speziell in punkto Barrierefreiheit. Hier würden zusätzliche Attribute bei einigen Elementen, die dann eben auch nur von speziellen Ausgabegeräten interpretiert werden, doch die Sache enorm vereinfachen.
Nochmal: Danbn schreib dir halt eine dir genehme DTD.

wenn ich das könnte, müsste ich mir wahrscheinlich auch keine Gedanken über die anderen Dinge machen ;-) sorry...

Ursprünglich war ich mal der Meinung, dass das Internet seinen sprunghaften Aufstieg u.a. der Einfachheit der zugrunde liegenden Auszeichnungssprache verdankt. Dank Softwareherstellern und einem (in meinen Augen) fern jeder Realität agierenden Konsortiums wird es um die allseits so wehemend geforderte allgemeine Zugänglichkeit von Internetseiten in Zukunft schlecht bestellt sein.
Dann tu was dagegen.

hast du eine Idee was?

Ich denke schon, dass ich deine Meinung hier aus dem Posting richtig herausgelesen habe - also vielen Dank für deinen Beitrag

Gruß Gunther

[Michael Jendryschik]

Validen Code zu schreiben erscheint mir hierbei noch die geringste Schwierigkeit zu sein (u.a. dank SelfHTML), nur was nutzt mir der letztendlich, wenn die Anzeige nachher doch in jedem Browser (sofern überhaupt etwas angezeigt wird) anders aussieht?
Das stimmt so sicher nicht. In den "modernen" Browsern ab 5.x denke ich kann man _gleichaussehend_ coden, wennauch nicht pixelgenau.

Unter der gegebenen Voraussetzung, dass jeder Benutzeragent auf jedem System so eingerichtet ist wie in deiner Entwicklungsumgebung, dies kann man jedoch nicht voraussetzen und daher liegst du imo falsch.

Das W3C schläft nicht, die Entwicklungen zu XHTML 1.2 und CSS 3 sind doch in vollem Gange!?

XHTML 1.2? Das wäre mir neu. ;-)

Warum führt man keine neuen Elemente/ Attribute ein?
Hier ist der Punkt erreicht, an dem ich mich fragen muss, ob du die XML_Kapitel von SelfHTMl gelesen hast.

Was hat das eine mit dem anderen zu tun?

Gerade aufgrund der Tatsache, dass die meisten Browser ihnen unbekannte Angaben einfach ignorieren, wäre es doch eigentlich ein Leichtes. Speziell in punkto Barrierefreiheit. Hier würden zusätzliche Attribute bei einigen Elementen, die dann eben auch nur von speziellen Ausgabegeräten interpretiert werden, doch die Sache enorm vereinfachen.
Nochmal: Danbn schreib dir halt eine dir genehme DTD.

Und was sollte das bringen?

MI

[Chräcker Heller]

Hallo,

• Webseiten sollten barrierefrei sein

was soll das nur sein, frage ich mich immer. Habe da echt keine Ahnung. Schon alleine die Voraussetzung eines Computers um Zugang zur Information zu bekommen stellt doch für einige Menschen eine arge Barriere dar. (Und darum gehts doch letztenldich, oder? Informationen zu menschen zu transportieren)

Könnte man da nicht sagen, eine Webseite sollte nicht noch durch den Einsatz ungeeigneter Techniken (worüber man eben dann sprechen könnte)  zu viele zusätzliche Barieren aufbauen?

Aber eine barierefreie Webseite (barierefrei für wehn?) ist eine pauschale nett klingende Formulierung die aber nichts weiter hergibt.

Chräcker

[Christian Seiler]

Hallo Chräcker,

Aber eine barierefreie Webseite (barierefrei für wehn?) ist eine pauschale nett klingende Formulierung die aber nichts weiter hergibt.

Ich verweise da mal auf </archiv/2003/3/39897/#m220087>. Hmmm, aber eigentlich müßtest Du das Posting kennen.

Viele Grüße,
Christian

[Chräcker Heller]

Hallo,

Hmmm, aber eigentlich müßtest Du das Posting kennen.

ich schon ;-) Aber ich forderte ja auch nicht

"Webseiten sollten barrierefrei sein"

;-) (Außerdem verweise ich auf mein zu:] ;-))))

Chräcker

[emu]

Hallo!

• Webseiten sollten barrierefrei sein

was soll das nur sein, frage ich mich immer.

Ich würde es als Zugänglichkeit aller Daten[1] für alle Benutzer ohne Rücksicht auf Browser, Betriebssystem, Ort, Zeit, Körperhaltung, temporäre oder ständige Behinderung, etc. definieren[2].

[1] Ja, ich weiß, Taube können keine Töne hören und Blinde keine Bilder sehen (aber immerhin ertasten).
[2] Das Gegenargument »Sprache« ist mit bekannt.

Schon alleine die Voraussetzung eines Computers um Zugang zur Information zu bekommen stellt doch für einige Menschen eine arge Barriere dar.

Zweifellos. Aber das ist kein Argument, das beweist, dass man nicht auf die Barrierefreiheit innerhalb des Webs zu achten habe. Zwar ist es klar, dass Benutzer ohne technische Hilfsmittel (ohne mich auf den Computer beschränken zu wollen) eben diese Seiten nicht sehen werden, aber das lässt nicht den Umkehrschluss zu, dass es »ohnehin schon egal sei, ob ein paar andere Leute es nicht sehen können«, sei.

Aber eine barierefreie Webseite (barierefrei für wen?) ist eine pauschale nett klingende Formulierung die aber nichts weiter hergibt.

Du hast natürlich insofern recht, dass »barrierefrei« und »zugänglich« etwas unglücklich gewählte Wörter sind und nicht annähernd exakt das beschreiben, was sie eigentlich sagen wollen, sprachlich gesehen. Es ist im Prinzip Definitionssache, was man unter solchen Begriffen versteht.

Sicher, man könnte jetzt anfangen, über »Barriereminimierung« zu sprechen, aber das sind meiner Meinung nach Haarspalterein.

emu

[Armin G.]

Tach auch,

Ich würde es als Zugänglichkeit aller Daten[1] für alle Benutzer ohne Rücksicht auf Browser, Betriebssystem, Ort, Zeit, Körperhaltung, temporäre oder ständige Behinderung, etc. definieren[2].

Und wie definierst Du Daten?

Und wie lade ich mir die 5MB grosse Textbeschreibung des folgenden Bildes auf mein Handheld herunter wenn ich gerade auf dem Gipfel des Ben Nevis stehe und mein Mobiltelefon zufaellig gerade eine Verbindung bekommt?

<img src="http://www.ministryofpropaganda.co.uk/images/avebury-preview.jpg" border="0" alt="">

Jegliche Kleinigkeit auf diesem Bild (und diese Version ist nur ein Preview!) betrachte ich als Datenpunkt, jeder einzelne der Steine, wie diese beschaffen sind, jede Person, jedes Kleidungsstueck das diese Personen tragen, jeder Baum, jede Grasflaeche, die Farbe des Grases, die Sandflaechen, die Haeuser, alles. 5MB ist da wahrscheinlich noch viel zu wenig.

Ach ja, das Handheld kann keine Bilder darstellen. Der Browser ist so'n ganz obskures Ding das nur HTML 1 kann. Mit dem Telefon bekomme ich im besten Fall 9.6kb Geschwindigkeit. Ich bin ziemlich fertig von dem Aufstieg und mir verschwimmt manchmal die Sicht. Scrollen laengerer Texte auf dem Handheld ist ein ziemlicher Umstand. Und am Horizont ziehen gerade ziemlich dicke Gewitterwolken auf, so dass ich vorsichtshalber in spaetestens 5 Minuten wieder mit dem Abstieg beginnen sollte.

Und wie funktioniert jetzt die Barrierefreiheit die Du oben beschrieben hast?

Sicher, man könnte jetzt anfangen, über »Barriereminimierung« zu sprechen, aber das sind meiner Meinung nach Haarspalterein.

Vielleicht. Aber wenigstens waere es ehrlich. Weswegen ich ja auch hier </archiv/2003/3/39897/#m219910> von Barrierereduzierung gesprochen habe.

Gruss,
Armin

[emu]

Hallo!

[Schönes Bild und Probleme des Beschreibens]

Und wie funktioniert jetzt die Barrierefreiheit die Du oben beschrieben hast?

Sicher nicht unter der Prämisse, dass das Bild vollständig bis ins Detail beschrieben werden muss. Das dürfte schon allein aus den Beschränkungen der Sprache heraus unmöglich sein.

Es stellt sich natürlich die Frage, ob es sinnvoll ist, einen »Alternativtext« dazu zu schreiben. Da ich annehme, dass das Bild im Text irgendwie erklärt ist (denn das hoffe ich - mich beeindruckt zwar die Landschaft, aber irgendwie würde ich gerne wissen, warum diese Steine da stehen, wo dieses Foto geschossen wurde und warum), würde ich das als ausreichend barriererefrei betrachten. Eine Erklärung des kompletten Bildes wäre meiner Meinung nach ähnlich kontraproduktiv wie die ominöse Nurtext-Seite, reine Gewissensberuhigung.

Ich weiß natürlich, worauf die hinauswillst. Barrierefreiheit in dem Sinn, dass tatsächlich jeder alles erleben kann, kann alleine deswegen nicht funktionieren, weil eben nicht alle Menschen die gleiche Möglichkeit haben, ihre Umwelt wahrzunehmen. Man könnte beliebig viele Beispiele finden, bei denen die strenge Auslegung des Begriffes zu absurden Situationen führen würde. Aber Barrierefreiheit ist ja nicht wie Validät irgendeine abstrakte Größe, zu der es fixe Normen gibt und bei der jeder, der eigentlich keine Ahnung hat, was er tut, die Seite als konform zu allen Spezifikationen auszeichnen lassen kann (wie es manchmal bei explizit validen Seiten passiert.) Vielmehr ist Barrierefreiheit für mich eine Einstellung, eine Art nie ganz erreichbares Ziel, das uns aber im Web sehr wichtig sein sollte (nirgends sonst kann man Barrieren so leicht und problemlos abbauen wie im Netz).

Das gerne zitierte Flash kann nicht als eine Barriere gelten, die, wie in deinem Beispiel, nicht vermieden werden kann bzw. wo eine Alternativversion unsinnig wäre (Ausnahme: Reines Fangenspielen irgendwelcher Formen und Farben). Sind wir da einer Meinung?

Sicher, man könnte jetzt anfangen, über »Barriereminimierung« zu sprechen, aber das sind meiner Meinung nach Haarspalterein.

Vielleicht. Aber wenigstens waere es ehrlich.

Dann einigen wir uns auf Barriereminimierung. Jetzt müssen wir nur noch eine umfangreiche Erklärung der Sachlage schreiben und alle maßgeblichen Menschen davon überzeugen (das stelle ich mir übrigens gar nicht unbedingt aussichtslos vor, zumindest was den deutschsprachigen Bereich angeht)

Im übrigen bin ich der Meinung, dass es einen Themenbereich Barriereminimierung (oder vielleicht besser, weil allgemeiner: Zugänglichkeit) geben sollte.

emu

[AlexBausW]

Hallo,

[Bild]

Jegliche Kleinigkeit auf diesem Bild (und diese Version ist nur ein Preview!) betrachte ich als Datenpunkt, jeder einzelne der Steine, wie diese beschaffen sind, jede Person, jedes Kleidungsstueck das diese Personen tragen, jeder Baum, jede Grasflaeche, die Farbe des Grases, die Sandflaechen, die Haeuser, alles. 5MB ist da wahrscheinlich noch viel zu wenig.

Dann würde ich sagen, Du siehst den Wald vor lauter Bäumen nicht mehr. Vermutlich waren zu Schulzeiten Deine Inhaltsangaben länger als die Literaturvorgabe, und Du konntest Dir noch nie die Menschen und Szenarien eines Romans anhand der knappen (sicherlich < 5MB) Beschreibungen des Autors nur in Deiner Fantasie ausmalen. ;þ Reduktion auf das Wesentliche ist nicht nur möglich, sonder auch nötig.
Auch ein nicht gehandicapter Betrachter (sei es körperlich oder technisch) wird nicht jedes Detail bis ins kleinste analysieren oder überhaupt erfassen. Dazu reicht sein Erfahrungsschatz bzw. seine Imaginationskraft aus. Wenn ich von Wiese rede muss man den meisten Menschen nicht mehr sagen, daß es sich dabei um eine flächendeckende Ansammlung grüner (wobei das schon für von Geburt an blinde schwer vorzustellen sein dürfte) Pflanzen von niedrigem Wuchs handelt, deren Blätter länglich lanzetförmig sind und eine parallele Blattaderung aufweisen. Und graue Steinblöcke 3-4m hohe Steinblöcke kann ich mir auch gerade noch so vorstellen. ;)
Wenn das Bild noch eine darüber hinausgehende "Aussage" beinhaltet, dann wird diese sicherlich erst aus dem Kontext, in den dieses Bild eingebunden ist, ersichtlich. Sonst ist es nur eine Wiese mit einem Graben und einigen großen Steinblöcken, auf der an einem sonnigen Winter(Herbst-)tag sich einige Spaziergänger, evtl. aus der im Hintergrund gelegenen Ortschaft, aufhalten.

Und wie funktioniert jetzt die Barrierefreiheit die Du oben beschrieben hast?

Es ist imho ein Fehler zu glauben, Bildinformationen wären ausschließlich und immer von den Bilddetails abhängig. Unsere Auffassungsgabe ist imho darauf ausgelegt, fehlende Informationen sinnvoll zu ergänzen, bzw. redundante Informationen zur kürzen. Und genau so oder genau deshalb funktioniert imho "Barrierefreiheit".

[...]

Gruß Alex

[Armin G.]

Tach auch,

Dann würde ich sagen, Du siehst den Wald vor lauter Bäumen nicht mehr. Vermutlich waren zu Schulzeiten Deine Inhaltsangaben länger als die Literaturvorgabe, und Du konntest Dir noch nie die Menschen und Szenarien eines Romans anhand der knappen (sicherlich < 5MB) Beschreibungen des Autors nur in Deiner Fantasie ausmalen. ;þ Reduktion auf das Wesentliche ist nicht nur möglich, sonder auch nötig.

Wie man sich doch taeuschen kann: Meine Inhaltsangaben waren immer mit die kuerzesten und auch heute sind meine Texte und Praesentationen eigentlich immer extrem kurz. Und ich kann mir sehr gut ausmalen wie die Menschen und deren Umwelt in einem Roman aussehen.

Wenn ich jetzt also eine billige Retourkutsche ablassen wollte koennte ich antworten: Du hast vermutlich zu Schulzeiten oft das Thema verfehlt oder eine Aufgabenstellung nicht verstanden.

Auch ein nicht gehandicapter Betrachter (sei es körperlich oder technisch) wird nicht jedes Detail bis ins kleinste analysieren oder überhaupt erfassen. Dazu reicht sein Erfahrungsschatz bzw. seine Imaginationskraft aus. Wenn ich von Wiese rede muss man den meisten Menschen nicht mehr sagen, daß es sich dabei um eine flächendeckende Ansammlung grüner (wobei das schon für von Geburt an blinde schwer vorzustellen sein dürfte) Pflanzen von niedrigem Wuchs handelt, deren Blätter länglich lanzetförmig sind und eine parallele Blattaderung aufweisen. Und graue Steinblöcke 3-4m hohe Steinblöcke kann ich mir auch gerade noch so vorstellen. ;)

In der Ausgangsdefinition war aber von "allen Daten" die Rede und nicht von irgendeiner Abstraktion. Ebenso sind fuer verschiedene Leute verschiedene Informationen wichtig, die diese aus dem Bild ziehen. So koennte z.B fuer jemanden der sich detailliert mit Steinkreisen beschaeftigt die genaue Form der individuellen Steine und ihre Stellung zueinander extrem wichtig sein. Das sind Daten und nicht etwas was man sich irgendwie ausdenken und vorstellen kann.

Wenn das Bild noch eine darüber hinausgehende "Aussage" beinhaltet, dann wird diese sicherlich erst aus dem Kontext, in den dieses Bild eingebunden ist, ersichtlich. Sonst ist es nur eine Wiese mit einem Graben und einigen großen Steinblöcken, auf der an einem sonnigen Winter(Herbst-)tag sich einige Spaziergänger, evtl. aus der im Hintergrund gelegenen Ortschaft, aufhalten.

Sicher, das Bild wuerde in einen Zusammenhang eingebunden sein, aber nur in einen grob eine Uebersicht gebenden Text. Die Ortschaft befindet sich innerhalb des Steinkreises, die Leute kommen von ueberall her. Und das Ding heisst Avebury. Weniger bekannt aber einiges besser als Stonehenge. Weshalb fuer jemanden der sich dafuer interessiert die Details durchaus wichtig sind.

Ach ja, das Bild wurde am 23ten Maerz, also wenige Stunden vor meinem Posting gemacht. Nach meiner Rechnung ist das Fruehling ;-)

Es ist imho ein Fehler zu glauben, Bildinformationen wären ausschließlich und immer von den Bilddetails abhängig. Unsere Auffassungsgabe ist imho darauf ausgelegt, fehlende Informationen sinnvoll zu ergänzen, bzw. redundante Informationen zur kürzen. Und genau so oder genau deshalb funktioniert imho "Barrierefreiheit".

Und wer entscheidet welche Informationen redundant sind? Der Autor oder der Betrachter? Du hast oben selber gesagt dass der Betrachter filtert...

Gruss,
Armin

[molily]

Hallo, Armin,

man könnte jetzt anfangen, über »Barriereminimierung« zu sprechen, aber das sind meiner Meinung nach Haarspalterein.

Vielleicht. Aber wenigstens waere es ehrlich. Weswegen ich ja auch hier </archiv/2003/3/39897/#m219910> von Barrierereduzierung gesprochen habe.

Ich verstehe nicht, was an der Idee hinter dem Begriff »Barrierefreiheit« unehrlich sein soll, vielleicht ohne jegliche Vorkenntnis irreführend.

Wie ich in meiner Antwort auf dein Posting ausführte, wird der Begriff »Barrierefreiheit« von niemandem verabsolutiert verstanden. Der Begriff mag für sich alleine beim ersten Lesen missverständlich sein, weshalb ich ihn auch nicht für besonders passend halte.

Allgemein gesehen können aber gegen den Begriff »Zugänglichkeit« dieselben Einwände vorgebracht werden, schließlich geht es dabei ebensowenig um die voll äquivalente »Funktionalität« gleich welcher Inhalte, et cetera. Diese Liste ließe sich beliebig fortsetzen und die Grundskepsis auf dutzende Begriffe aus dem Bereich des Webauthorings ausdehnen. Trotzdem verwende ich lieber »Zugänglichkeit« beziehungsweise verallgemeinernd »Benutzbarkeit«/»Usability«.

Vielleicht kann ich die Kritik nachvollziehen, wenn beispielsweise hypothetisch »Benutzbarkeit« doppelt negiert würde und durch »Fehlen von jeglichen unbenutzbaren Elementen« ersetzt würde. In dieser Form würde ich den neuen Begriff beziehungsweise sogar die augenscheinliche Bedeutung zunächst auch anzweifeln.

Dennoch, sobald erst einmal bekannt ist, was die meisten mit »Barrierefreiheit« meinen, besteht über die Idee meiner Auffassung nach kein Zweifel. Insofern stellt der Begriff möglicherweise selbst mangels intuitiver Verständlichkeit eine Barriere dar, welche aber bei näherer Betrachtung wahrlich schnell aufgelöst wird.

Noch einmal, es ist eine Definitionsfrage, und wenngleich der Begriff unpassend sein mag, sollte m.E. eher über die Bedeutung/Idee diskutiert werden. Und wenn »Zugänglichkeit« ebenfalls als Ideal definiert wird, sehe ich kein Problem darin, eine »zugängliche« Webseite als Annäherung an dieses Ideal zu definieren.

Grüße,
Mathias

[Armin G.]

Tach auch,

Ich verstehe nicht, was an der Idee hinter dem Begriff »Barrierefreiheit« unehrlich sein soll, vielleicht ohne jegliche Vorkenntnis irreführend.

Weil xy-freiheit in meinem Sprachgebrauch vollkommen frei von was immer xy ist bedeutet. Und xy-reduziert bedeutet das halt noch Restelemente von xy vorhanden sein koennen.

Wenn xy z.B eine Allergien erzeugende Substanz ist, kann der Unterschied zwischen -freiheit und -reduziert den Unterschied zwischen Leben und Tod bedeuten.

In dieser Diskussion ist xy die (ungenuegend definierte) Barriere zum Zugang zu einer Website. Und da ich nicht glaube dass absolut alle diese Barrieren beseitigt werden koennen, halte ich den Begriff Barrierefreiheit fuer unehrlich.

Wie ich in meiner Antwort auf dein Posting ausführte, wird der Begriff »Barrierefreiheit« von niemandem verabsolutiert verstanden.

Ich bin also "niemand"?

Der Begriff mag für sich alleine beim ersten Lesen missverständlich sein, weshalb ich ihn auch nicht für besonders passend halte.

Eben. Er weckt Hoffnungen die in meinen Augen nicht erfuellt werden koennen.

Noch einmal, es ist eine Definitionsfrage, und wenngleich der Begriff unpassend sein mag, sollte m.E. eher über die Bedeutung/Idee diskutiert werden. Und wenn »Zugänglichkeit« ebenfalls als Ideal definiert wird, sehe ich kein Problem darin, eine »zugängliche« Webseite als Annäherung an dieses Ideal zu definieren.

Wo Du wieder Recht hast, der Hauptdiskussionspunkt sollte die Idee sein, womit ich auch keine Probleme habe. Was aber nicht ausschliesst dass man dafuer einen passenden und ehrlichen Begriff verwendet ;-)

Gruss,
Armin

[Sven Rautenberg]

Moin!

Um mal direkt auf deine Titelzeile zu antworten: HTML geht nicht mehr weiter, XHTML ist schon da.

Validen Code zu schreiben erscheint mir hierbei noch die geringste Schwierigkeit zu sein (u.a. dank SelfHTML), nur was nutzt mir der letztendlich, wenn die Anzeige nachher doch in jedem Browser (sofern überhaupt etwas angezeigt wird) anders aussieht?

Ist das ein Problem? Du wirst in einem CSS-unfähigen Browser wie Netscape 3 niemals das Aussehen erreichen können, was Mozilla bietet. Du wirst in einem ungrafischen Browser wie Lynx sowieso kaum die Darstellung beeinflussen können, zumindest nicht die grafische. Also ist dein Ziel schon mal falsch: Mit HTML kannst du niemals identische Darstellung auf allen Systemen erreichen. Was du erreichen kannst, ist die identische Strukturierung von Informationen - denn das ist Aufgabe von HTML.

Ein Standard ist ja sicher auch sinnvoll & notwendig, aber inwieweit kann man denn überhaupt von Standard sprechen, wenn es AFAIK keinen einzigen Browser gibt, der den kompletten Standard auch standardgemäß beherrscht? Wäre da eine Bezeichnung wie Schnittmenge von W3C-Standard und Browser nicht viel eher zutreffend?

Die Frage ist, welche Standards du genau meinst. HTML können die meisten Browser bestens darstellen - mit ihren jeweiligen Möglichkeiten. Du darfst natürlich von Netscape 1.0 nicht erwarten, dass er HTML 4.01 versteht. Das ist eben das Dumme: Es gibt so viele verschiedene Standards.

Aber da haben sich die Browserhersteller in der Vergangenheit nicht unbedingt mit Ruhm bekleckert. Derzeit ist es doch eigentlich ideal: Das W3C läuft, was die Standard-Definitionen angeht, vorneweg, und nach und nach werden die Standards in Browser umgesetzt. Andersherum ging es früher mal: Jede neue Browserversion kam mit neuen, tollen Features, die die Konkurrenz zunächst einmal nicht beherrschte. Netscape 4 ist das Ergebnis dieses damals endenden Wettlaufs: Stylesheets wollte Netscape damals mit Javascript umsetzen (JSSS) und hatte das auch als Vorschlag beim W3C eingereicht, aber die Entscheidung fiel zugunsten von CSS. Netscape hat dann noch schnell eine CSS-to-JSSS-Umsetzung einprogrammiert, und das war's. Über das Ergebnis meckert heute jeder. Pech - ist halt die Zeit des Umbruchs bzw. des Überholens der Entwicklung durch das W3C gewesen.

Browserunabhängigen Code schreiben  schön und gut. Aufgrund des wohl noch relativ hohen Einsatzes des Netscape Communicators 4.7, soll also die Webseite auch noch in den Browsern der 4. Generation funktionieren (in einer brauchbaren Form angezeigt werden).

Definiere "relativ hohen Einsatz". Und definiere "in einer brauchbaren Form angezeigt werden".

Aber eigentlich ist diese Diskussion im Prinzip uninteressant. Man kann Netscape 4 relativ leicht von allen oder den problematischen CSS-Definitionen ausschließen und hat somit das Problem nicht mehr, was dieser mit CSS darstellt. Und auch Javascript macht keinerlei Probleme, wenn man es mit Javascript selbst nicht übertreibt (in diesem Fall lauern noch ganz andere Fallstricke in anderen Browsern).

Da fangen die Probleme dann schon an. Wie stelle ich denn fest, welche Methoden und Objekte der vom User verwendete Browser unterstützt bzw. kennt?

if (document.getElementById)
{
  alert ("Browser kennt getElementById");
}

Ich persönlich z.B. kenne nur wenige Möglichkeiten, dies alleine mit Hilfe von HTML zu bewerkstelligen (<noframe>, <noscript>, <noembed>, und die Bereiche z.B. zwischen <object></object> oder <iframe></iframe>).

<noscript> wirkt nur bei ausgeschaltetem Javascript. Wenn Javascript eingeschaltet ist, aber deinen Code nicht versteht, bringt das also nichts. Noframe, noembed etc. haben mit Javascript nichts zu tun, und die Alternativen Inhalte von Object und IFrame sind ja nun wirklich einfach realisierbar.

Hier sehe ich mich dann als Hobby-Bastler eigentlich das erste mal gezwungen, auf Alternativen zurückzugreifen. Aber welche kommen da in Frage? Na ja, eigentlich wäre Javascript ja wunderbar, wenn da nicht das Problemchen wäre, dass der User dieses einfach deaktivieren kann in seinem Browser (und schon klappt nix mehr).

Eben. Deshalb: Übertreibe es mit Javascript nicht. Ich persönlich setze Javascript auf Webseiten eigentlich nur für drei Dinge ein:
1. Mouseover-Bildertausch
2. Ein-/Ausblenden von Ebenen
3. Prüfung von Formularen vor dem Abschicken.

Und das war es dann. Damit habe ich absolut keine Probleme in den einzelnen Browsern.

Aber laut unserer selbst gestellten Anforderung, soll die Seite ja auch dann noch funktionieren. Das größte Problem, was sich für mich dann stellt ist, dass man keinerlei Informationen über den vom User benutzten Browser (und z.B. die Fenstergröße) mehr erhält.

...die man auch absolut nicht benötigt.

Oder meintest du mit "auf Alternativen zurückgreifen" etwa, für einzelne Browser einzelne Seitenversionen zu erstellen. Vergiß das einfach: Zu aufwendig, zu fehleranfällig, zu nervig.

Aber selbst wenn man einmal annimmt, das Javascript nicht deaktiviert wurde, ist man noch lange nicht aus allen Problemen raus.

[...]

Folglich scheidet die (ausschließliche) Verwendung des DOM also aus (denn wir wollen ja auch die nicht DOM-fähigen Browser der 4. Generation noch unterstützen). Streng genommen scheidet sie ja eigentlich ganz aus (siehe oben, Einschränkung Javascript) ;-)

Du kannst unterstützte Methoden und Eigenschaften abfragen und entsprechend verzweigen. Dabei produzierst du im Prinzip Code für 3 verschiedene DOM-Varianten (NS4, IE4, W3C) - ICH habe damit keine Probleme. Wenn man weiß, was man tut bzw. tun muß, und eben Javascript zurückhaltend einsetzt, ist das kein Thema.

Wobei ich mich dabei immer frage, warum die Browserhersteller es so eingerichtet haben, dass man bspw. den navigator.userAgent als User verändern kann (was ihn ja im Prinzip fast völlig wertlos macht)?

Du hast das grundsätzliche Problem nicht verstanden. Wenn du verläßlich abfragen könntest, dass du einen Netscape oder einen IE hast, und je nachdem verzweigst - was machen dann Benutzer anderer Browser? Und wenn du eine Default-Verzweigung benutzt - was ist, wenn die ausgerechnet das falsche DOM verwendet?

Deshalb ist es falsch, anzunehmen, man könne anhand des User-Agents irgendwas entscheiden. Wenn du prüfst, ob die gewünschte Methoden tatsächlich vorhanden ist, erreichst du viel mehr Browser - nämlich alle, die den Standard kennen, den auch dein Skript verwenden, also z.B. das W3C-DOM. Wenn du den User-Agent prüfst, mußt du hingegen Kenntnisse über die DOM-Kenntnisse aller auf dem Markt vorhandenen Browser haben - das ist ein Mega-Aufwand. Und du kriegst dann Probleme, wenn neue Browser erst nach Veröffentlichung deines Skriptes auf den Markt kommen, aber bei dir noch nicht berücksichtigt werden.

(...fortgesetzt in Teil 2...)

- Sven Rautenberg

[Sven Rautenberg]

Moin!

(...Fortsetzung von Teil 1...)

Auf diese Art & Weise kriege ich dann die verschiedenen Browser ziemlich sicher nach Hersteller auseinander sortiert (was ja de fakto notwendig ist, um die jeweiligen Bugs auszugleichen)

Nein, ist de fakto nicht notwendig.

aber damit habe ich immer noch nicht die jeweilige Version des betreffenden Browsers ermittelt, was aber eigentlich genauso zwingend notwendig wäre, da ja die verschiedenen Versionen eines Browsers von ein und demselben Hersteller durchaus verschiedene Macken haben kann.

Verschiedene Browser - verschiedene Macken. Ist halt so. Damit muß man leben, und damit kann man leben.

Kommen wir jetzt mal zu den gestalterischen Möglichkeiten (Stichwort CSS). Eine wunderbare & mächtige Erweiterung zu HTML  leider aber auch wieder mit denselben Problemen behaftet. Es gibt zwar wiederum einen Standard, aber die Browser interpretieren diesen ebenfalls in anderer Art & anderem Umfang, womit wir wieder bei dem (Javascript-)Problem der effizienten Browserunterscheidung wären.

So schlimm ist es bei CSS eigentlich nicht. Gewisse Dinge funktionieren überall gleich, gewisse Dinge funktionieren nicht überall - mit einer gewissen Erfahrung weiß man, was dagegen zu tun ist, bzw. dass dagegen nichts zu tun ist - oder es ist egal, wie z.B. bei gewissen Farbgestaltungen.

Vielfach trifft man heutzutage die Variante an, dass man Code verwendet, der von bestimmten Browsern dann ignoriert (da ihnen unbekannt) wird, um damit vorhergehende Anweisungen (für die anderen Browser) zu überschreiben. Was mache ich aber dann, wenn der Nachfolger die Anweisungen dann plötzlich versteht? Alles neu?

Solche Hacks halte ich nicht unbedingt für sinnvoll, aus genau diesem Grund. Die Alternative ist, eben nicht ganz so aggressiv CSS einzusetzen, und gewisse Gestaltungsmöglichkeiten einfach außen vor zu lassen. Das schränkt natürlich etwas ein, ich habe es aber bislang noch nie so empfunden, dass ich dadurch Dinge nicht machen konnte.

Und plötzlich (ich formuliere das bewusst etwas provokant) fällt allen Beteiligten auf, dass man (mal wieder) eine Minderheit vergessen hat, nämlich die behinderten Menschen (Stichwort Barrierefreiheit). So gerne wie ich meine Webseite auch an die Bedürfnisse dieser Menschen anpassen möchte, muss ich sagen, dass hier der Punkt erreicht ist, an dem ich endgültig nicht mehr weiß, wie ich meine Webseite noch gestalten soll, um die notwendigen Inhalte zu transportieren.

Benutze HTML dazu. Und gucke deine Seiten mal in Lynx an. Dann siehst du, wie gut sie ohne schmückendes Beiwerk aussehen. Wenn du sinnvolles Markup verwendet hast, hast du bezüglich Barrierefreiheit eigentlich kaum Probleme.

Das hat mehrere Gründe. Zum einen muss man sich ja erst einmal mit den Bedürfnissen dieser Gruppe vertraut machen. Ich z.B. kenne gar keine alternativen Ausgabegeräte. Folglich weiß ich auch nicht, welche Anforderungen diese nun an eine benutzbare Webseite stellen (mal ganz davon abgesehen, dass ich es auch nicht testen kann). Ich spreche in diesem Zusammenhang nicht von leicht umzusetzenden Dingen, wie bspw. einem sinnvollen ALT-Attribut. Meiner Ansicht nach muss z.B. eine Navigationsstruktur für sehende und nicht sehende Menschen fast zwangsläufig anders aufgebaut sein.

Deine Gedanken gehen, wie mir scheint, weiterhin davon aus, es allen Besuchern durch eine explizit angepaßte, eigene Seitenversion recht zu machen. Das wird aber nicht funktionieren.

Wenn du dir mal das Chaosradio 79 anhörst (ftp://ftp.ccc.de/chaosradio/cr79/): In der Sendung ruft ein Blinder an, der augenscheinlich mit Webseiten keinerlei Probleme hat, auf Seiten zu navigieren. Nur sollten die Links irgendwie sinnvoll zugänglich und auf der Seite angeordnet sein. Ich glaube auch kaum, dass es dir weiterhelfen würde, wenn du wüßtest, wie ein Blinder surft - weil du dir bestimmt nicht vorstellen kannst, wie es ist, ohne Sehen zu surfen - und wenn du es mal ausprobieren würdest, würde dir schlicht die Erfahrung fehlen, und du würdest das Erlebnis vermutlich als ziemlich entmutigend erleben.

Jetzt komme ich mal auf den eigentlichen Titel des Threads zurück.

Oh, wie schön. ;->

Meiner Meinung nach ergeben sich aus der Praxis der letzten Jahre, der Browserentwicklung und den veränderten Anforderungen an Webseiten (um jetzt nur mal drei der wichtigsten Punkte zu nennen) doch nun langsam aber sicher mal die Notwendigkeiten, den HTML-Standard auch diesbezüglich mal zu erweitern.

Meiner Meinung nach ist der entscheidende Schritt dazu mit Einführung von CSS bereits erfolgt.

Ich empfinde die Empfehlungen des W3C nämlich langsam so, dass ich (als Webseitenersteller) mit HTML etwas umsetzen soll, was HTML IMHO nicht mehr in der Lage ist zu leisten.

Doch, alles, was das W3C unter dem Stichwort WAI empfiehlt, läßt sich prima mit HTML umsetzen.

Als Beispiel möchte ich hierzu nur mal den Fall Redirect nennen. Das W3C empfiehlt auf die Verwendung von <META HTTP-EQUIV=REFRESH CONTENT="1; URL=http://machine/doc3.html"> zu verzichten (siehe http://www.w3.org/2001/06tips/reback). Stattdessen empfiehlt man auf serverseitige Techniken auszuweichen (wenn ich das aus den angegebenen Links richtig interpretiert habe) also nix mehr mit HTML, wobei doch gerade das noch mein Rettungsanker gewesen wäre für den Fall, dass ein User Javascript deaktiviert hat. Wo bleibt denn da eine sinnvolle HTML-Alternative?

Die Empfehlungen vom W3C gehen davon aus, dass du als Anbieter die volle Kontrolle über den HTTP-Datenfluß hast. Ein Redirect wird deshalb sinnvollerweise durch einen entsprechenden HTTP-Header ausgelöst, und nicht durch ein HTML-Metatag. In HTML gibt es dafür schlicht keine Alternative. Und auf der von dir angegebenen Seite steht ja auch, warum.

Warum führt man keine neuen Elemente/ Attribute ein? Gerade aufgrund der Tatsache, dass die meisten Browser ihnen unbekannte Angaben einfach ignorieren, wäre es doch eigentlich ein Leichtes. Speziell in punkto Barrierefreiheit. Hier würden zusätzliche Attribute bei einigen Elementen, die dann eben auch nur von speziellen Ausgabegeräten interpretiert werden, doch die Sache enorm vereinfachen.

Welche zusätzlichen Elemente und Attribute fehlen dir? Und ist dir bekannt, dass du mit CSS die vorhandenen Elemente je nach Ausgabemedium formatieren - auch verstecken - kannst.

Ursprünglich war ich mal der Meinung, dass das Internet seinen sprunghaften Aufstieg u.a. der Einfachheit der zugrunde liegenden Auszeichnungssprache verdankt. Dank Softwareherstellern und einem (in meinen Augen) fern jeder Realität agierenden Konsortiums wird es um die allseits so wehemend geforderte allgemeine Zugänglichkeit von Internetseiten in Zukunft schlecht bestellt sein.

Nein. HTML ist immer noch eine sehr einfache Auszeichnungssprache. Damit kriegst du problemlos deinen Inhalt veröffentlicht. Deine Probleme resultieren lediglich daraus, dass du diese Informationen auch noch überflüssigerweise in einer grafisch aufgemotzten Version übermitteln willst - und dabei zwingenderweise auf die Evolution der Browser stößt.
 - Sven Rautenberg

[Gunther]

Hallo Sven!

Um mal direkt auf deine Titelzeile zu antworten: HTML geht nicht mehr weiter, XHTML ist schon da.

zugegeben: der Titel ist so gesehen falsch, aber immerhin hat er dich doch meinen Beitrag lesen lassen, worauf du dann netterweise auch noch geantwortet hast - Danke!

Validen Code zu schreiben erscheint mir hierbei noch die geringste Schwierigkeit zu sein (u.a. dank SelfHTML), nur was nutzt mir der letztendlich, wenn die Anzeige nachher doch in jedem Browser (sofern überhaupt etwas angezeigt wird) anders aussieht?

Ist das ein Problem? Du wirst in einem CSS-unfähigen Browser wie Netscape 3 niemals das Aussehen erreichen können, was Mozilla bietet. Du wirst in einem ungrafischen Browser wie Lynx sowieso kaum die Darstellung beeinflussen können, zumindest nicht die grafische. Also ist dein Ziel schon mal falsch: Mit HTML kannst du niemals identische Darstellung auf allen Systemen erreichen.

sorry, aber das habe ich doch auch nie geschrieben, dass ich das will...
(ich gebe aber durchaus zu, dass man meine Aussage leicht so interpretieren kann), was ich vielmehr versucht habe auszudrücken, ist die Problematik, dass man durchaus validen Code schreiben kann, der in manchen Browsern dann trotzdem völlig unstrukturiert (oder zumindest nicht gewollt strukturiert) angezeigt wird (ich hoffe das ist etwas klarer formuliert)

Was du erreichen kannst, ist die identische Strukturierung von Informationen - denn das ist Aufgabe von HTML.

schon klar, aber für einen 'Hobbyisten' wie mich schon schwer genug (unter Berücksichtigung der eingangs genannten 3 Forderungen)...

Ein Standard ist ja sicher auch sinnvoll & notwendig, aber inwieweit kann man denn überhaupt von Standard sprechen, wenn es AFAIK keinen einzigen Browser gibt, der den kompletten Standard auch standardgemäß beherrscht? Wäre da eine Bezeichnung wie Schnittmenge von W3C-Standard und Browser nicht viel eher zutreffend?

Die Frage ist, welche Standards du genau meinst. HTML können die meisten Browser bestens darstellen - mit ihren jeweiligen Möglichkeiten.

da fängt's ja schon an - das Dilemma ;-)

Du darfst natürlich von Netscape 1.0 nicht erwarten, dass er HTML 4.01 versteht.

ich hatte es ja deshalb auch schon extra auf die Browser ab der 4. Generation eingeschränkt, und du als Forums-Profi wirst mir sicherlich Recht geben, wenn ich sage, dass hier im Forum 'verstärkt' Wert auch (noch) auf deren Unterstützung gelegt wird.

Das ist eben das Dumme: Es gibt so viele verschiedene Standards.

eigentlich meinte ich bisher nur den HTML 4.01 Standard des W3C...

Aber da haben sich die Browserhersteller in der Vergangenheit nicht unbedingt mit Ruhm bekleckert. Derzeit ist es doch eigentlich ideal: Das W3C läuft, was die Standard-Definitionen angeht, vorneweg, und nach und nach werden die Standards in Browser umgesetzt. Andersherum ging es früher mal: Jede neue Browserversion kam mit neuen, tollen Features, die die Konkurrenz zunächst einmal nicht beherrschte. Netscape 4 ist das Ergebnis dieses damals endenden Wettlaufs: Stylesheets wollte Netscape damals mit Javascript umsetzen (JSSS) und hatte das auch als Vorschlag beim W3C eingereicht, aber die Entscheidung fiel zugunsten von CSS. Netscape hat dann noch schnell eine CSS-to-JSSS-Umsetzung einprogrammiert, und das war's. Über das Ergebnis meckert heute jeder. Pech - ist halt die Zeit des Umbruchs bzw. des Überholens der Entwicklung durch das W3C gewesen.

da hast du völlig Recht - das sehe ich (im Prinzip) genauso, bleibt also nur zu hoffen, dass zukünftige Browser(versionen) sich strikt am Standard orientieren (plus irgendwelcher proprietären Eigenheiten, die dann vielleicht auch mal Standard werden)

Browserunabhängigen Code schreiben  schön und gut. Aufgrund des wohl noch relativ hohen Einsatzes des Netscape Communicators 4.7, soll also die Webseite auch noch in den Browsern der 4. Generation funktionieren (in einer brauchbaren Form angezeigt werden).

Definiere "relativ hohen Einsatz".

...ich wußte, dass das kommt - hab' ich extra vermieden (also bist du der Meinung, dass man ihn vernachlässigen kann?)

Und definiere "in einer brauchbaren Form angezeigt werden".

auch das habe ich vermieden, weil ich befürchtet habe, dass man das als "pixelgenaues Layouten" interpretiert (was du ja schon weiter oben getan hast ;-) - es ging mir hier mehr um Dinge wie eine funktionierende Navigation, alle Inhalte auch erreichbar (bezogen auf den sichtbaren Fensterbereich, also nichts durch z.B. clip oder hidden "abgeschnitten"))

Aber eigentlich ist diese Diskussion im Prinzip uninteressant. Man kann Netscape 4 relativ leicht von allen oder den problematischen CSS-Definitionen ausschließen und hat somit das Problem nicht mehr, was dieser mit CSS darstellt. Und auch Javascript macht keinerlei Probleme, wenn man es mit Javascript selbst nicht übertreibt (in diesem Fall lauern noch ganz andere Fallstricke in anderen Browsern).

der NS4 ist ja nicht der einzige Browser mit Problemen bei der korrekten CSS-Umsetzung und die ursprüngliche Betrachtung setzte ja streng genommen voraus, ganz ohne Javascript auszukommen.

Da fangen die Probleme dann schon an. Wie stelle ich denn fest, welche Methoden und Objekte der vom User verwendete Browser unterstützt bzw. kennt?

if (document.getElementById)
{
  alert ("Browser kennt getElementById");
}

bitte nicht aus dem Sinnzusammenhang reißen - hier geht es um Möglichkeiten mit HTML

Ich persönlich z.B. kenne nur wenige Möglichkeiten, dies alleine mit Hilfe von HTML zu bewerkstelligen (<noframe>, <noscript>, <noembed>, und die Bereiche z.B. zwischen <object></object> oder <iframe></iframe>).

<noscript> wirkt nur bei ausgeschaltetem Javascript.

eben... ;-)

Wenn Javascript eingeschaltet ist, aber deinen Code nicht versteht, bringt das also nichts. Noframe, noembed etc. haben mit Javascript nichts zu tun, und die Alternativen Inhalte von Object und IFrame sind ja nun wirklich einfach realisierbar.

s.o.

Hier sehe ich mich dann als Hobby-Bastler eigentlich das erste mal gezwungen, auf Alternativen zurückzugreifen. Aber welche kommen da in Frage? Na ja, eigentlich wäre Javascript ja wunderbar, wenn da nicht das Problemchen wäre, dass der User dieses einfach deaktivieren kann in seinem Browser (und schon klappt nix mehr).

Eben. Deshalb: Übertreibe es mit Javascript nicht. Ich persönlich setze Javascript auf Webseiten eigentlich nur für drei Dinge ein:

1. Mouseover-Bildertausch
2. Ein-/Ausblenden von Ebenen
3. Prüfung von Formularen vor dem Abschicken.

Und das war es dann. Damit habe ich absolut keine Probleme in den einzelnen Browsern.

und verwendest du Alternativen für User ohne Javascriptunterstützung, wenn ja welche?

Aber laut unserer selbst gestellten Anforderung, soll die Seite ja auch dann noch funktionieren. Das größte Problem, was sich für mich dann stellt ist, dass man keinerlei Informationen über den vom User benutzten Browser (und z.B. die Fenstergröße) mehr erhält.

...die man auch absolut nicht benötigt.

wo du's sagst..., wenn ja eh' keine Javascriptunterstüzung vorhanden ist..., jetzt wo ich's mir genau überlege, hast du da Recht.

Oder meintest du mit "auf Alternativen zurückgreifen" etwa, für einzelne Browser einzelne Seitenversionen zu erstellen. Vergiß das einfach: Zu aufwendig, zu fehleranfällig, zu nervig.

nein,_natürlich_nicht (aus den von dir genannten Gründen)!

Aber selbst wenn man einmal annimmt, das Javascript nicht deaktiviert wurde, ist man noch lange nicht aus allen Problemen raus.
[...]
Folglich scheidet die (ausschließliche) Verwendung des DOM also aus (denn wir wollen ja auch die nicht DOM-fähigen Browser der 4. Generation noch unterstützen). Streng genommen scheidet sie ja eigentlich ganz aus (siehe oben, Einschränkung Javascript) ;-)

Du kannst unterstützte Methoden und Eigenschaften abfragen und entsprechend verzweigen. Dabei produzierst du im Prinzip Code für 3 verschiedene DOM-Varianten (NS4, IE4, W3C) - ICH habe damit keine Probleme. Wenn man weiß, was man tut bzw. tun muß, und eben Javascript zurückhaltend einsetzt, ist das kein Thema.

aha, siehst du, genau hier machst du doch im Prinzip verschiedene Versionen für verschiedene Browser, nur dass sie halt in derselben Datei stehen (was ja bei Alternativen für z.B. Browser ohne Javascriptunterstützung in HTML auch der Fall ist), also doch nix mit ganz ohne 'Fallunterscheidung(en)'.

Wobei ich mich dabei immer frage, warum die Browserhersteller es so eingerichtet haben, dass man bspw. den navigator.userAgent als User verändern kann (was ihn ja im Prinzip fast völlig wertlos macht)?

Du hast das grundsätzliche Problem nicht verstanden. Wenn du verläßlich abfragen könntest, dass du einen Netscape oder einen IE hast, und je nachdem verzweigst - was machen dann Benutzer anderer Browser? Und wenn du eine Default-Verzweigung benutzt - was ist, wenn die ausgerechnet das falsche DOM verwendet?

ne ne, ich hab' das schon richtig verstanden ;-) und wie du ja selbst ausgeführt hast, ist die Browserunterscheidung anhand dieser Eigenschaft denkbar ungeeignet, also warum ist sie dann veränderbar (das war aber auch nur so eine Überlegung von mir am Rande, die ich gar nicht unbedingt weiter vertiefen möchte)?

Deshalb ist es falsch, anzunehmen, man könne anhand des User-Agents irgendwas entscheiden. Wenn du prüfst, ob die gewünschte Methoden tatsächlich vorhanden ist, erreichst du viel mehr Browser - nämlich alle, die den Standard kennen, den auch dein Skript verwenden, also z.B. das W3C-DOM. Wenn du den User-Agent prüfst, mußt du hingegen Kenntnisse über die DOM-Kenntnisse aller auf dem Markt vorhandenen Browser haben - das ist ein Mega-Aufwand. Und du kriegst dann Probleme, wenn neue Browser erst nach Veröffentlichung deines Skriptes auf den Markt kommen, aber bei dir noch nicht berücksichtigt werden.

(das nehme ich ja auch gar nicht an)

(...fortgesetzt in Teil 2...)

schon mal Dank für diesen Teil,

Gruß Gunther

[Michael Jendryschik]

Das ist eben das Dumme: Es gibt so viele verschiedene Standards.
eigentlich meinte ich bisher nur den HTML 4.01 Standard des W3C...

Sicherlich hat HTML 4.01 die eine oder andere Schwäche (Stichwort: Auszeichnung von Zitaten), aber wo genau siehst du Probleme?

BTW: Bitte füge eine Leerzeile vor und nach zitiertem Text ein. Das macht deine Antworten besser lesbar.

MI

[Michael Jendryschik]

Die Frage ist, welche Standards du genau meinst. HTML können die meisten Browser bestens darstellen - mit ihren jeweiligen Möglichkeiten. Du darfst natürlich von Netscape 1.0 nicht erwarten, dass er HTML 4.01 versteht. Das ist eben das Dumme: Es gibt so viele verschiedene Standards.

Es gibt eine Entwicklung, das ist überall so, nicht nur im Web. Da es zur Zeiten von Mosaic kein HTML4 gab, kann dieser es auch nicht darstellen. Das ist kein Argument für oder gegen die Entwicklung von neuen Standards, das ist im Grunde genommen noch nicht einmal ein Argument.

MI

[Danny]

Hallo Gunther,

um es kurz zu machen: Informationen sind primär, Layout sekundär.

Setze einfach einen bestimmten Standard voraus und werfe bestimmten, bzw. alten Browsern einfach eine Textversion vor die Füße...

Wichtig ist, daß die Inhalte gut strukturiert sind, also daß z.B. Überschriften, Absätze, Hervorgehobenes, Zitate oder weiterführende Links auch als solche ausgezeichnet sind.

Das Internet wurde erschaffen, um Wissen, bzw. Informationen zu verbreiten. Und nicht um ausgefeilte Designs in allen technischen Umgebungen gleich aussehen zu lassen.

In diesem Sinne: keep is as simple as possible!

Gruß,
Danny

[Michael Jendryschik]

Ich glaube sagen zu können, dass folgende Aussagen in etwa den Trend der vorherrschenden Meinung hier im Forum wieder geben:

• man sollte seine Webseiten dem W3C Standard konform aufsetzen

Ist Voraussetzung für:

• Webseiten sollten so weit wie möglich browser- und plattformunabhängig sein

Ist Voraussetzung für:

• Webseiten sollten barrierefrei sein

Hast du gemerkt, dass deine Aussagen aufeinander aufbauen und sich gegenseitig bedingen?

Validen Code zu schreiben erscheint mir hierbei noch die geringste Schwierigkeit zu sein (u.a. dank SelfHTML), nur was nutzt mir der letztendlich, wenn die Anzeige nachher doch in jedem Browser (sofern überhaupt etwas angezeigt wird) anders aussieht?

Ich möchte Michael Nahrath sprechen lassen (aus [e-mail]):

"Stell Dir vor, Du kaufst eine Zeitung.
   Beim Lesen in der U-Bahn ist es eng, da hat sie A5-Format.
   Auf dem Fussweg zur Arbeit lässt Du dir einen Artikel vom Walkman vorlesen.
   Im Büro liest Du sie auf dem Schreibtisch, da hat sie A2.
   Abends gibst Du sie Deiner Oma zu lesen und machst dafür die Schrift grösser.
   Und das alles mit ein und derselben Zeitung!

Geht leider nicht mit Papier, mit einer Website geht sowas."

Dass Webseiten je nach Ausgabemedium, Benutzeragent und Vorlieben des Benutzers anders aussehen können, ist kein Nachteil, sondern die größte und wichtigste Qualtität von HTML! Gute Webautoren versuchen ihre Webseiten daher so zu entwerfen, dass dieser Vorteil sich frei entfalten kann.

Ein Standard ist ja sicher auch sinnvoll & notwendig, aber inwieweit kann man denn überhaupt von Standard sprechen, wenn es AFAIK keinen einzigen Browser gibt, der den kompletten Standard auch standardgemäß beherrscht? Wäre da eine Bezeichnung wie Schnittmenge von W3C-Standard und Browser nicht viel eher zutreffend?

Was sollte es bringen, eine solche Schnittmenge zu definieren und nur damit zu arbeiten? Und wie überhaupt sollte es möglich sein, eine Schnittmenge zu ermitteln? Über welche Browser reden wir? Über alle auf dem Markt befindlichen? Über die Browser der oberen Zehntausend? Über Browser, die nach 1998 erschienen sind? Oder nach 2000?

Wie schwierig es zu sein scheint, einen solchen Browser zu entwickeln, würde ich alleine mal daraus ableiten, dass es ja selbst dem W3C nicht gelingt (Stichwort: Amaya).

Amaye ist Open Source. Du kannst dich an der Entwicklung beteiligen, wenn du magst: http://www.w3.org/Amaya/Actors.html#contribute

Da fangen die Probleme dann schon an. Wie stelle ich denn fest, welche Methoden und Objekte der vom User verwendete Browser unterstützt bzw. kennt?

Du bringst hier einiges durcheinander. Du willst über HTML nachdenken und sprichst von Browsern, Methoden und Objekten. Das sind andere Begriffe. Im folgenden sprichst du über DOM un JavaScript. Vor allem letzteres verwende ich abgesehen von optischen Spielereien nur dann, wenn die Umgebung des Benutzeres bekannt ist oder im Rahmen eines konkreten Projektes zumindest eingeschränkt werden darf. Ansonsten ist JavaScript im Web nicht zu gebrauchen, aber das ist nur meine persönliche Meinung.

Kommen wir jetzt mal zu den gestalterischen Möglichkeiten (Stichwort CSS). Eine wunderbare & mächtige Erweiterung zu HTML leider aber auch wieder mit denselben Problemen behaftet. Es gibt zwar wiederum einen Standard, aber die Browser interpretieren diesen ebenfalls in anderer Art & anderem Umfang, womit wir wieder bei dem (Javascript-)Problem der effizienten Browserunterscheidung wären.

Ich sehe das alles weniger aufgeregt als du. Wenn ich mein Dokument strukturiert und die darin enhaltenen Informationen adäquat ausgezeichnet habe, habe ich das Wichtigste getan. Ich will nicht behaupten, dass die Gestaltung nun vollkommen unwichtig ist, ganz im Gegenteil, aber ich unterscheide hier. Wer mit NN4 und ähnlich missglückten und veralteten Browsern Webseiten besucht, nimmt dies entweder bewusst in Kauf, vielleicht auch, weil es ihm nicht wichtig ist, oder hat keine andere Wahl, weil der Benutzeragent vorgeschrieben ist, wie z.B. in Firmennetzwerken, Universitäten oder Bibliotheken. In letzteren Einrichtungen wird das Web zumeist ohnehin nicht dazu besucht, sich unterhalten zu lassen, sondern konkret um Informationen zu erhalten oder Hilfestellungen zu bemühen.
In meinem Artikel "Rücksicht auf Netscape 4?" http://www.mywebresource.de/html/guides/nn4.html) formuliere ich meine Gedanken ausführlicher und halte vor allem zwei Thesen fest, die sich vom NN4 hin zu vergleichbar veralteten Browsern verallgemeinern lassen:

"Eine Webseite sollte so geschrieben werden, dass alle Besucher Ihrer Seite
   Zugang zu den gebotenen Informationen erhalten!

Verschwenden Sie nicht zuviel Ihrer Zeit, die optische Darstellung für den
   NN4 zu verfeinern!"

Der einfachste Weg, dies zu erreichen, ist es, problematische CSS-Regeln vor den diversen Browsern zu verstecken. Eine Sammlung von Tipps findest du unter http://www.w3development.de/css/hide_css_from_browsers/. Aber diese Möglichkeit ist dir anscheinend bekannt, denn du schreibst weiter:

Vielfach trifft man heutzutage die Variante an, dass man Code verwendet, der von bestimmten Browsern dann ignoriert (da ihnen unbekannt) wird, um damit vorhergehende Anweisungen (für die anderen Browser) zu überschreiben. Was mache ich aber dann, wenn der Nachfolger die Anweisungen dann plötzlich versteht?

Es ist das Ziel fast aller CSS-Hacks, bestimmte veraltete Implementationen auszuschließen und aktuelle zuzulassen. Welches Problem siehst du daran?

Und plötzlich (ich formuliere das bewusst etwas provokant) fällt allen Beteiligten auf, dass man (mal wieder) eine Minderheit vergessen hat, nämlich die behinderten Menschen (Stichwort Barrierefreiheit). So gerne wie ich meine Webseite auch an die Bedürfnisse dieser Menschen anpassen möchte, muss ich sagen, dass hier der Punkt erreicht ist, an dem ich endgültig nicht mehr weiß, wie ich meine Webseite noch gestalten soll, um die notwendigen Inhalte zu transportieren.

http://www.w3.org/Consortium/Offices/Germany/Trans/WAI/webinhalt.html gibt dir entscheidende Hinweise. Auch http://bobby.watchfire.com/bobby/html/en/index.jsp wird in diesem Zusammenhang oft genannt, allerdings kenne ich diese Website nicht wirklich.

Meiner Ansicht nach muss z.B. eine Navigationsstruktur für sehende und nicht sehende Menschen fast zwangsläufig anders aufgebaut sein.

Woraus leitest du diese Meinung ab?

Jetzt komme ich mal auf den eigentlichen Titel des Threads zurück. Meiner Meinung nach ergeben sich aus der Praxis der letzten Jahre, der Browserentwicklung und den veränderten Anforderungen an Webseiten (um jetzt nur mal drei der wichtigsten Punkte zu nennen) doch nun langsam aber sicher mal die Notwendigkeiten, den HTML-Standard auch diesbezüglich mal zu erweitern. Ich empfinde die Empfehlungen des W3C nämlich langsam so, dass ich (als Webseitenersteller) mit HTML etwas umsetzen soll, was HTML IMHO nicht mehr in der Lage ist zu leisten.

Das liegt vor allem daran, dass du HTML, Javascript, DOM, CSS und Begriffe wie Gestaltung oder Zugänglich, also einen Großteil der von dir zur Erstellung von Webseiten verwendeten Techniken und Konzepte, in einen Topf wirfst und dich dann auf HTML fokussierst. Dabei ist HTML nicht mehr als eine Textauszeichnungssprache, die deine Erwartungen überhaupt nicht erfüllen kann! Du übersiehst, dass HTML seine Aufgaben sehr wohl ausreichend und auch befriedigend erfüllt.

Deine Missverständnisse machst du auch durch dein angeführtest Beispiel deutlich.

Als Beispiel möchte ich hierzu nur mal den Fall Redirect nennen. Das W3C empfiehlt auf die Verwendung von <META HTTP-EQUIV=REFRESH CONTENT="1; URL=http://machine/doc3.html"> zu verzichten (siehe http://www.w3.org/2001/06tips/reback). Stattdessen empfiehlt man auf serverseitige Techniken auszuweichen (wenn ich das aus den angegebenen Links richtig interpretiert habe) also nix mehr mit HTML, wobei doch gerade das noch mein Rettungsanker gewesen wäre für den Fall, dass ein User Javascript deaktiviert hat.

Eine Weiterleitung ("Redirect") mit 'META HTTP-EQUIV=REFRESH' ist keine solche, sondern eben nur ein *Refresh*. Es wird damit versucht, einen HTTP-Header nachzureichen (daher auch "HTTP-EQUIV"), dessen Verhalten allerdings undefiniert ist, da "Refresh" undefiniert ist. Aus diesen Gründen ist die Verwendung dieses Meta-Elementes äußerst unsinnig, und das W3C rät zurecht davon ab. Wie es besser, nämlich serverseitig geht, erklärt dir http://www.modulepool.com/web-pool/System/htaccess_weiterleitung.php4.

Wo bleibt denn da eine sinnvolle HTML-Alternative?

Dinge wie Weiterleitungen oder andere serverseitigen (wie auch clientseitigen) Aktionen sind *nicht* Aufgabe von HTML. Ich empfehle dir die Lektüre von http://jendryschik.de/wsdev/einfuehrung/websprachen.html und http://jendryschik.de/wsdev/einfuehrung/webapplikationen.html, um ein Gefühl dafür zu bekommen, was mit welcher Sprache möglich ist.

Warum führt man keine neuen Elemente/ Attribute ein?

Mit XHTML 2.0 wird genau dies geschehen, jedoch mit einem anderen Ziel als das, das du verfolgst.

Ursprünglich war ich mal der Meinung, dass das Internet seinen sprunghaften Aufstieg u.a. der Einfachheit der zugrunde liegenden Auszeichnungssprache verdankt.

Genau dies ist der Fall.

Gruß, MI