nicht angemeldet
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