Barrierefreiheit vs. Design oder Barrierefreiheit und Design?

[Axel]

Hallo,

ich habe auf Grund einiger Beiträge einmal den Artikel http://aktuell.de.selfhtml.org/artikel/design/barrierefrei/index.htm#a1 durchgearbeitet und denke, das ich da noch einiges an Nachholbedarf bei einigen meiner Webseiten habe.

Mir stellt sich aber die Frage, ob die hohen Ansprüche des Artikels mit einem modernen (auch grafischen) Design vereinbar sind, oder ob die Erfüllung der Anforderungen nicht zwangsläufig zu einer optisch minimalistischen Seite führen muss.

Mich würde einmal interessieren, ob es ein paar Beispielseiten gibt, die neben gutem optischen Design auch die Anforderungen an Barrierefreiheit erfüllen?

Grüße

Axel

[Sven Rautenberg]

Moin!

Mir stellt sich aber die Frage, ob die hohen Ansprüche des Artikels mit einem modernen (auch grafischen) Design vereinbar sind, oder ob die Erfüllung der Anforderungen nicht zwangsläufig zu einer optisch minimalistischen Seite führen muss.

Bis zu einem gewissen Grade sind Barrierefreiheit und Design absolut miteinander vereinbar.

Schritt 1: Alles, was man aufgrund der Barrierefreiheit zusätzlich angeben kann, was das Design aber absolut nicht beeinflusst - beispielsweise alt-Attribute sinnvoll füllen.

Schritt 2: Gimmicks nur optional einsetzen - wie z.B. Javascript. Man muß ohne auskommen können, und dennoch auf der Seite vorwärtskommen.

Schritt 3: Sinnvolles, logisches Markup. <h1>, <h2>, <p> statt <div>, <div>, <div>.

Wenn man nach diesen drei Schritten die Seite mal im Lynx betrachtet und damit erstens versteht, was geschrieben wurde, zweitens alle Seiten erreichen kann und drittens die Seite vom Aufbau her sogar Sinn macht, dann ist ein großer Schritt getan. Nach meiner Erfahrung ist dieses Stadium absolut ohne Designeinschränkungen erreichbar. Außerdem erhält man für Suchmaschinen wertvollere Seiten - IMHO.

Damit sollte man schon mal einen recht großen Schritt in Richtung "WAI-A-Level" getan haben. Das "AA" oder sogar "AAA" hingegen ist nicht mehr so leicht erreichbar.

Mich würde einmal interessieren, ob es ein paar Beispielseiten gibt, die neben gutem optischen Design auch die Anforderungen an Barrierefreiheit erfüllen?

Du weißt ja: Meine Seite ist angeblich häßlich - aber sie ist (wieder mal IMHO) ziemlich barrierefrei. Zumindest sieht sie im Lynx _auch_ gut aus. Und ja, dass dort die Links ganz unten auf der Seite stehen, ist Absicht. Zur Vernetzung mit <link> bin ich leider noch nicht gekommen.

- Sven Rautenberg

[Axel]

Hi,

Du weißt ja: Meine Seite ist angeblich häßlich - aber sie ist (wieder mal IMHO) ziemlich barrierefrei.

? Ich finde jetzt nicht, das (Du meinst sicher www.rtbg.de) der Renner in Bezug auf besonders aufsehenerregendes Design ist - aber "hässlich"? Ich finde diese Seiten hier z.B. wirklich hässlich:

http://www.t-online.de/
http://www.popfile.de/

und diese hier ziemlich schick:

http://www.pixel-empire.com/
http://www.fork.de/

diese besonders interessant

http://www.endoflow.com/
http://www.nivea.de/showerpower/

...außergewöhnlich..

http://www.db-db.com/
http://pixeljam.com/core/index.html

Aber Hässlichkeit liegt im Auge des Betrachters - die Macher der o.g. Seite finden sie bestimmt toll.

Zumindest sieht sie im Lynx _auch_ gut aus. Und ja, dass dort die Links ganz unten auf der Seite stehen, ist Absicht. Zur Vernetzung mit <link> bin ich leider noch nicht gekommen.

Ich hab's mir mal mit der Windows-Version von Lynx angesehen und die ist in der Tat lesbar.

Ich denke aber, das zum Erreichen eines Barrierefreien Designs auch eine gewisse Ignoranz gegnüber älteren Browsern entwickelt werden müsste. Manche Dinge schaffen diese Browser nicht, unzureichend oder mit erhöhtem Aufwand - aber macht es Sinn, ältere Browser auszuschließen? Ist das nicht auch eine Barriere?

Grüße

Axel

[Sven Rautenberg]

Moin!

Zumindest sieht sie im Lynx _auch_ gut aus. Und ja, dass dort die Links ganz unten auf der Seite stehen, ist Absicht. Zur Vernetzung mit <link> bin ich leider noch nicht gekommen.

Ich hab's mir mal mit der Windows-Version von Lynx angesehen und die ist in der Tat lesbar.

Ich denke aber, das zum Erreichen eines Barrierefreien Designs auch eine gewisse Ignoranz gegnüber älteren Browsern entwickelt werden müsste. Manche Dinge schaffen diese Browser nicht, unzureichend oder mit erhöhtem Aufwand - aber macht es Sinn, ältere Browser auszuschließen? Ist das nicht auch eine Barriere?

Definiere "ältere Browser". Da gibts nämlich mindestens zwei Gruppen: "ganz uralte Browser" und "'nur' alte Browser".

Zur ersten Gruppe würde ich Netscape bis Version 3 rechnen: Kein CSS, nur HTML. Und die können mit dem Markup prima umgehen - genauso wie Lynx auch. Sieht natürlich absolut langweilig aus, ja. Das hat den "klassischen" Times-New-Roman-Look ohne weitere Formatierung - mit Ausnahme einiger <i> und <b>.

Zur zweiten Gruppe zähle ich die CSS-Halbkönner: IE 3, Netscape 4. Den IE3 hab ich mangels Installation einer lauffähigen Version nicht testen können (vermutlich versagt er aufgrund irgendwelcher CSS-Unzulänglichkeiten), aber Netscape 4 funktioniert.

Ich habe bis heute eigentlich bei keiner der von mir beruflich produzierten Seiten den Netscape 4 ausschließen müssen. Ok, manchmal kriegt er einfach ein eigenes Stylesheet, um gewisse Dinge zu umgehen (was schade ist: background-repeat und background-position kann er nicht - dann kriegt er eben gar kein Hintergrundbild), aber das Problem liegt fast ausschließlich im CSS-Bereich, nicht bei HTML. Also ist es immer möglich, die CSS-Angaben soweit zu reduzieren, dass er nicht abstürzt oder Fehler produziert. Sowas kann man natürlich nur machen, wenn man dem Kunden kein "identisches Aussehen in allen Browsern" verkauft, sondern ein "die Seite läuft in allen Browsern" bzw. "wir 'optimieren' für alle Browser" - das ernüchternde Netscape4-Aussehen ist eben "optimiert". ;)

- Sven Rautenberg

[AnalphaBestie]

Moin

Also ich mag die seite wirklich sehr!
Soll jetzt nicht wie geschleime klingen, aber wenn ich ne website haben wötte würd ich zu euch gehen.

Nette farben, kein zu vollgekleckstes layout, und gute useability.
So sollte ne firmen seite aussehen...

Mfg

[Sven Rautenberg]

Moin!

Also ich mag die seite wirklich sehr!
Soll jetzt nicht wie geschleime klingen, aber wenn ich ne website haben wötte würd ich zu euch gehen.

Das ist nett, aber...

Nette farben, kein zu vollgekleckstes layout, und gute useability.
So sollte ne firmen seite aussehen...

...das ist leider keine Firmenwebsite, sondern meine private Homepage. :) Dennoch finden täglich zwischen 90 und 100 Menschen auf meine Seite.

Die Firma, bei der ich arbeite, gibt sich etwas grafischer, aber (weil ich eben für's HTML zuständig bin - hehe) nicht weniger zugänglich: http://www.rb3m.com

- Sven Rautenberg

[Axel]

Hi Sven,

Die Firma, bei der ich arbeite, gibt sich etwas grafischer, aber (weil ich eben für's HTML zuständig bin - hehe) nicht weniger zugänglich: http://www.rb3m.com

Sieht nett aus - aber ich komme mit der (den) Navigation(en) nicht so recht klar.

Warum berauben immer mehr Menschen die Hyperlinks ihrer Unterstreichung?

Grüße aus München

Axel

[molily]

Hallo, Axel und Sven,

Ich finde diese Seiten hier [...] ziemlich schick:

http://www.pixel-empire.com/

Das ist ein schlechtes Beispiel für eine gut designte Seite, zwar ist sie zweifellos optisch hochwertig, mit einer gemeinen Netzseite, welche Inhalte anbietet wie beispielsweise deine TCPA-Seite. Die Benutzbarkeit lässt meines Erachtens zu wünschen übrig, sie ist sehr ... experimentell. Die Schrift ist nur durch meine Mindestschriftgröße nach unten begrenzt und die Seite ist für eine Bildschirmauflösung von scheinbar 1200 Pixel Breite oder ähnliches gemacht.

http://www.fork.de/

Mein Browser crasht. Die Flash-Animation belegt 100% Prozessorauslastung. Die Navigation funktioniert nicht, trotz angeschaltetem JavaScript, Flash et cetera.

http://www.endoflow.com/

DHTML-Demoseite, kontrastlos. Draußen ist es dunkel, ich habe alle Lichter aus und erkenne erst etwas, wenn ich die Monitorhelligkeit hochdrehe.

http://www.nivea.de/showerpower/

Scheinbar eine Java-Demo oder ein Spiel - ich habe Java nicht installiert.

http://www.db-db.com/

Eine Flash-Demo (?). Viel Bewegung und Animation, läuft sehr langsam. Die Gestaltung spricht mich persönlich nicht sehr an.

http://pixeljam.com/core/

Schön, ich liebe choatische Netzkunst, sofort gebookmarkt.

Ich verstehe nur nicht, was du mit der Nennung der Seiten bezweckst, die Barrierefreiheit setzt wahrlich nicht an grafischen Demonstrationen an, welche per se Barrieren darstellen und auch keine Alternativversionen zur Verfügung gestellt werden können beziehungsweise es wenig sinnvoll wäre. Insofern beißt sich in den von dir genannten Fällen, in welchen die Bildgestaltung zum Selbstzweck verwendet wird und nicht eine Einheit mit primär auf Text basierendem Inhalt bildet, tatsächlich die Barrierefreiheit mit dem »Design«.

Dies lässt sich natürlich nicht auf »reguläre« Seiten übertragen, bei welchen für gewöhnlich auch Anderes im Vordergrund steht.

Zumindest sieht sie im Lynx _auch_ gut aus. Und ja, dass dort die Links ganz unten auf der Seite stehen, ist Absicht. Zur Vernetzung mit <link> bin ich leider noch nicht gekommen.

Ich hab's mir mal mit der Windows-Version von Lynx angesehen und die ist in der Tat lesbar.

Ich denke aber, das zum Erreichen eines Barrierefreien Designs auch eine gewisse Ignoranz gegnüber älteren Browsern entwickelt werden müsste. Manche Dinge schaffen diese Browser nicht, unzureichend oder mit erhöhtem Aufwand

Gewissermaßen: ja, es stimmt, dass ältere Browser nicht primär von einer WCAG-konformen Seite profitieren. Dies hängt vor allem damit zusammen, dass eine solche Seite ihre Zugänglichkeit in vielen Fällen direkt aus der Trennung des Markups und der Styles schöpft, weil dadurch in der Regel ein benutzbar strukturiertes Dokument übrig bleibt, wenn der Benutzer das Autorenstylesheet deaktiviert, beispielsweise zugunsten eines Benutzerstylesheets, oder der Browser sowieso nur den Text sowie das die Struktur (Überschriften, Listen, Tabellen) »kommunizieren« kann (Hilfsmittel wie Braillezeilen oder Screenreader). Gemäß der Richtlinie 3.3 sollen die grundlegenden Formatierungen und Layoutpositionierungen mit Stylesheets gelöst werden (»sobald Benutzeragenten Positionierung mit Hilfe von Stylesheets unterstützen«), womit Tabellenlayout, sofern es keine Barriere darstellt, nicht explizit ausgeschlossen wird. Dennoch kann man einige Richtlinien als direkt bindend sehen und ein CSS-Layout einsetzen, zweifellos würde Netscape 4 daran ab einem gewissen Punkt scheitern.

Meiner Erfahrung nach stürzt Netscape 4 durchaus auch reproduzierbar ab, wenn er beispielsweise auf Barrierefreiheit optimierte Formulare darstellen soll - in diesem Punkt ist tatsächlich die Kehrseite des barrierefreien Webdesigns sichtbar, sie zielt in vielen Vorschlägen auf die Fähigkeiten von zukünftigen beziehungsweise state-of-the-art-Browsern, weshalb zahlreiche Richtlinien mit »sobald Benutzeragenten [eingebautes HTML-Zugänglichkeitsfeature] verstehen, verwenden Sie eine Übergangslösung« beginnen.

aber macht es Sinn, ältere Browser auszuschließen? Ist das nicht auch eine Barriere?

Ja, da gebe ich dir recht - gewissermaßen ist es eine Barriere, aber nicht im Sinne der Zugänglichkeitsinitiative. Die WAI zielt meines Wissens eher darauf ab, dass die Abwärtskompatiblität (»graceful degradation«) gewahrt wird, das bedeutet, dass in Kauf genommen wird, dass ein Browser, welcher selbst auf Zugänglichkeit optimierte Seiten nur unvollständig darstellen kann, eine weniger anspruchsvoll gestaltete Seite präsentiert bekommt. Die Praxis ist bekannt, Netscape 4 würde eine voll benutzbare Seite mit einem weniger komplexen Autorenstylesheet geliefert. Dies stellt IMHO keine Barriere der Definition nach dar.

Grüße,
Mathias

[Axel]

Hi,

Ich verstehe nur nicht, was du mit der Nennung der Seiten bezweckst

Einfach ein paar Seiten, die mir in irgendeiner Weise im "Gedächtnis" geblieben sind. Sicherlich...Einiges ist recht experimentell und stellt recht hohe Anforderungen.

Weiß auch nicht, warum sie mir rausgerutscht sind...

Und ehrlich gesagt... Pixel-Empire ist rattenscharf gestaltet - ich denke, es kommt Marc Klein hier mutmaßlich nicht auf Bedienbarkeit an.

Grüße

Axel

[Cyx23]

Hallo Sven,

Schritt 3: Sinnvolles, logisches Markup. <h1>, <h2>, <p> statt <div>, <div>, <div>.

da frage ich mich ob die Entwicklung der Trennung von Auszeichnungen,
also Darstellung per CSS, nicht schon zu weit geht.

Es gibt Auszeichnungen, z.B. strike, die so stark mit einem Text dicht
am Inhalt verwoben sein können dass die Darstellung per Span und Klassen
eigentlich im Arbeitsablauf beim Erstellen des Dokumnents unpraktisch,
und später als Ergebnis auch weniger barrierefrei ist.

Grüsse

Cyx23

[Kai Lahmann]

hi

Es gibt Auszeichnungen, z.B. strike, die so stark mit einem Text dicht
am Inhalt verwoben sein können dass die Darstellung per Span und Klassen
eigentlich im Arbeitsablauf beim Erstellen des Dokumnents unpraktisch,
und später als Ergebnis auch weniger barrierefrei ist.

<strike>? Oder meinst du <strong>?
Ersteres ist "durchgestrichen", wieso es aber durchgestrichen ist, besagt es nicht. Letzteres besagt start betont (und nichts darüber, wie es denn nun hervorzuheben ist, _empfielt_ aber fett). Will man nun bei <strong> einen bestimmten Effekt sicherstellen, gibt's eben CSS. Schließt sich also beides keineswegs aus, sondern erzwingt sich fast gegenseitig.

Grüße aus Bleckede

Kai

[Cyx23]

Hallo Kai,

gibt's eben CSS

da wir hier in diesem Thread über Barrierefreiheit oder gar Lynx
als Maßstab posten, gibt es CSS womöglich nicht.

Sowohl aus Sicht des effizienten Erstellens von Markierungen im
Text, als auch aus Sicht der Barrierefreiheit ist CSS ab einem
bestimmten Punkt kontraproduktiv.
Oder erst durch andere Anforderungen an Software, ob nun Lesehilfen
für Behinderte oder HTML-Editoren, komfortabel handhabbar.
Damit entfernt sich HTML aber tendeziell von der freien, einfachen
Anwendung.

Ersteres ist "durchgestrichen", wieso es aber durchgestrichen ist, besagt es nicht.

Mit CSS besagt es dass ja wohl noch weniger?

Grüsse

Cyx23

[Kai Lahmann]

hi

Ersteres ist "durchgestrichen", wieso es aber durchgestrichen ist, besagt es nicht.

Mit CSS besagt es dass ja wohl noch weniger?

da gibt's dann <del>, was eben besagt "dieser Abschnitt gilt nicht mehr". Was der UA damit macht, ist ihm überlassen. Nun wird empfohlen das ganze als durchgestrichen darzustellen. Zusätzlich kann man für grafische UAs[1] eine andere Darstellung (kontrastarme Farbe, ganz weg) über CSS erzwingen).

[1] dieser Zusatz fehlte da eben

Grüße aus Bleckede

Kai

[Cyx23]

Hallo,

Ersteres ist "durchgestrichen", wieso es aber durchgestrichen ist, besagt es nicht.

Mit CSS besagt es dass ja wohl noch weniger?

da gibt's dann <del>, was eben besagt "dieser Abschnitt gilt nicht mehr". Was der UA damit macht, ist ihm überlassen. Nun wird empfohlen das ganze als durchgestrichen darzustellen. Zusätzlich kann man für grafische UAs[1] eine andere Darstellung (kontrastarme Farbe, ganz weg) über CSS erzwingen).

also doch ein ziemlicher Unfug in der Praxis, falls ich Tags sinnvoll
einsetzen möchte.
<strike> ist unerwünscht, aber ganz W3C konform geht es (HTML/CSS)
andererseits auch voraussichtlich nie, denn CSS-Weichen die ggf.
nötig sind um Tags richtig zu benutzen sind auch nicht konform.
Die m.E. bestehenden Widersprüche von Barrierefreiheit und W3C
sind peinlich, weil Barrierefreiheit ja gerne als Argument für
W3C instrumatalisiert wird, aber gut, vielleicht bin ich auch
dabei die neuere Entwicklung etwas zu überinterpretieren...

Grüsse

Cyx23

[Kai Lahmann]

hi

also doch ein ziemlicher Unfug in der Praxis, falls ich Tags sinnvoll
einsetzen möchte.

schreib' ich irgendwie undeutlich?

<strike> ist unerwünscht, aber ganz W3C konform geht es (HTML/CSS)
andererseits auch voraussichtlich nie, denn CSS-Weichen die ggf.
nötig sind um Tags richtig zu benutzen sind auch nicht konform.

du nimmst <del> und gut is.
Nun kannst du _*ZUSÄTZLICH*_ noch dieses Element mittels CSS anders darstellen (ex behält die Aussage "Text gilt nimma"), verstanden?

Grüße aus Bleckede

Kai

[Cyx23]

Hallo Kai,

schreib' ich irgendwie undeutlich?

[]oberlehrer
[]vaterkomplex
[]choleriker
[]weihnachtsneurotiker
[]zensiert

<strike> ist unerwünscht, aber ganz W3C konform geht es (HTML/CSS)
andererseits auch voraussichtlich nie, denn CSS-Weichen die ggf.
nötig sind um Tags richtig zu benutzen sind auch nicht konform.

du nimmst <del> und gut is.

Nein, nicht gut. Abgesehen von deinem unmöglichen Ton, kommt es auch inhaltlich nicht hin.

Nun kannst du _*ZUSÄTZLICH*_ noch dieses Element mittels CSS anders darstellen (ex behält die Aussage "Text gilt nimma"), verstanden?

Nein, du hast es offenbar nicht ganz verstanden, nochmal Details:

Bedeutung und Wirkung von <del ist offenbar etwas anders als bei
<strike, dazu nicht zukunftsicher weil nicht eindeutig, und für
viele Browser gar nicht geeignet.
Da ich sowieso bei der verstärkten Verwendung richtiger Tags
an die Grenzen der W3C Valdität stosse, wenn ich z.B. für Listen
Opera und Mozilla per nicht CSS-valider Weiche auseinanderhalten
muss, klappt es sowieso nicht, vmtl. nie, mit 100% Validität.
W3C Validität ist also schon deshalb ein weniger wichtiges Kriterium,
da es sich in der Praxis immer wieder selbst wiederspricht. Somit ist
die Vermeidung von <strike nochmals weniger notwendig als bislang
angenommen, zumal <strike bei nahezu allen Browsern funktioniert.

Zum W3C stellt sich die Frage was an <strike unerwünscht sein soll,
ausser dass es alle Browser verstehen und man als industrienaher
Verband die Verbreitung neuer Browser fördern möchte, auch auf
Kosten der Zugänglichkeit. Womit wir fast wieder beim Thema wären,
jetzt Barrierefreiheit vs. Zugänglichkeit.

Frohe Weihnachten,

Cyx23

[Christian Seiler]

Hallo Cyx23,

Nein, nicht gut. Abgesehen von deinem unmöglichen Ton, kommt es auch inhaltlich nicht hin.

Was willst Du denn semantisch gesehen mit <strike> erreichen? <strike> hat keine semantische, sondern eine visuelle Bedeutung. Eine Antwort auf diese Frage habe ich nach mehrfacher Lektüre Deiner Postings nicht finden können.

Grüße,

Christian

[Cxy23]

Hallo Christian,

Was willst Du denn semantisch gesehen mit <strike> erreichen? <strike> hat keine semantische, sondern eine visuelle Bedeutung. Eine Antwort auf diese Frage habe ich nach mehrfacher Lektüre Deiner Postings nicht finden können.

bei Unterstreichungen ist die Frage vielleicht interessanter,
weil aus einer Hervorhebung eine Funktion geworden ist, eine
Auszeichnung avanciert zum Link, mit Rückwirkung auf die Darstellung
in anderen Medien.

Bei strike will ich erstmal nur das was zu sehen ist erhalten.
Also durchgestrichen, nicht deleted. Sichtbar.

Ob das bedeutet dass ein Artikel nicht mehr erhältlich ist weil
Artikelnummer oder Preis durchgestrichen sind, ob ein Link
durchgestrichen ist, oder irgendetwas anderes, ist doch egal.
Jedenfalls scheint mir ein <strike> barrierefreier, und auch
ohne CSS darstellbarer, als wenn Klassen benutzt werden.
Und <del> trifft es nicht ganz, zumal unklar ist ob es zukünftig
angezeigt wird, und ältere Browsern brauchen sowieso eine CSS
Ergänzung.

Grüsse

Cyx23

[Christian Seiler]

Hallo Cyx,

Bei strike will ich erstmal nur das was zu sehen ist erhalten.
Also durchgestrichen, nicht deleted. Sichtbar.

Du fixierst Dich auf die Visualisierung. Wenn ein Browser jetzt Text nicht durchsteichen _kann_? (z.B. Textmodebrowser)

Ob das bedeutet dass ein Artikel nicht mehr erhältlich ist weil
Artikelnummer oder Preis durchgestrichen sind, ob ein Link
durchgestrichen ist, oder irgendetwas anderes, ist doch egal.

Warum sollte das egal sein? Du willst Doch mit dem Durchstreichen etwas erreichen, oder etwa nicht? Dann suchst Du Dir den Tag aus, der logisch am besten zu diesem Zweck passt.

Jedenfalls scheint mir ein <strike> barrierefreier, und auch
ohne CSS darstellbarer, als wenn Klassen benutzt werden.

Ja klar, _DARSTELLBAR_. Aber hier geht es nicht um die Darstellbarkeit, sondern um den semantischen Wert. Und strike hat _absolute gar keinen_ semantischen Wert.

Und <del> trifft es nicht ganz, zumal unklar ist ob es zukünftig
angezeigt wird, und ältere Browsern brauchen sowieso eine CSS
Ergänzung.

Gib mir endlich mal ein Beispiel, wo Du strike Deiner Meinung nach brauchst.

Grüße,

Christian

[Kai Lahmann]

hi

bei Unterstreichungen ist die Frage vielleicht interessanter,
weil aus einer Hervorhebung eine Funktion geworden ist

nein. Eine Unterstreichung ist eine Unterstreichung (mir bekannt als Form der nachträglichen Hervorhebung). Ein Link ist ein Link, ein strukturelles Element.

Bei strike will ich erstmal nur das was zu sehen ist erhalten.
Also durchgestrichen, nicht deleted. Sichtbar.

und was ist wenn der Browser nicht durchstreichen kann? Genau, gar nix.

Und <del> trifft es nicht ganz, zumal unklar ist ob es zukünftig
angezeigt wird, und ältere Browsern brauchen sowieso eine CSS
Ergänzung.

DEL  { text-decoration: line-through }
...was ist daran nun bitte unklar? (aus CSS2)

Grüße aus Bleckede

Kai

[Cyx23]

Hallo nochmal,

bei Unterstreichungen ist die Frage vielleicht interessanter,
weil aus einer Hervorhebung eine Funktion geworden ist

nein. Eine Unterstreichung ist eine Unterstreichung (mir bekannt als Form der nachträglichen Hervorhebung). Ein Link ist ein Link, ein strukturelles Element.

eine Unterstreichung hat die Bedeutung Link, Unterstreichung als
Form der nachträglichen Hervorhebung wird zwar solange gebräuchlich
sein solange nicht alle mit Markern in Texten rummatschen und Bücher
versauen, aber die Bedeutung hat sich geändert wie überhaupt das
Layout von Printmedien Fragmente und Bedeutungen der neuen Medien
adaptiert. Umgekehrt ist die Verwendung von Unterstreichung
besonders in "neuen" Medien als Hervorhebung nicht sinnvoll oder
sinnrichtig möglich.

und was ist wenn der Browser nicht durchstreichen kann? Genau, gar nix.

Eben genau das Problem gibt es bei del und nicht bei strike.

Und <del> trifft es nicht ganz, zumal unklar ist ob es zukünftig
angezeigt wird, und ältere Browsern brauchen sowieso eine CSS
Ergänzung.

DEL  { text-decoration: line-through }
...was ist daran nun bitte unklar? (aus CSS2)

Dass es so wie von dir angewandt eben nicht bei älteren Browsern
funktioniert.

Grüsse

Cyx23

[Kai Lahmann]

hi

eine Unterstreichung hat die Bedeutung Link

für dich.
Frag' mal jemanden, der mit dem Internet nichts am Hut hat, für den hat eine Unterstreichung eine ähnliche Funktion, wie <em> oder <strong>.

und was ist wenn der Browser nicht durchstreichen kann? Genau, gar nix.

Eben genau das Problem gibt es bei del und nicht bei strike.

du vertauschst die beiden die gesamte Zeit (siehe anderer Beitrag).

Grüße aus Bleckede

Kai

[Cyx23]

Hallo,

eine Unterstreichung hat die Bedeutung Link

für dich.
Frag' mal jemanden, der mit dem Internet nichts am Hut hat, für den hat eine Unterstreichung eine ähnliche Funktion, wie <em> oder <strong>.

eben nicht, die Bedeutung ändert sich, das merkt indirekt auch
jemand irgendwann, der  mit dem Internet nichts am Hut hat,
ausserdem wer war noch nicht im Internet.
Die Bedeutung im Internet ändert die Wahrnehmung in anderen
Medien auch, Grafiker setzen den Effekt ja auch überall schon
lange in der Werbung gezielt ein, wie auch Sprache der Jugendkultur
usw. in den Alltag einfließt.

und was ist wenn der Browser nicht durchstreichen kann? Genau, gar nix.

Eben genau das Problem gibt es bei del und nicht bei strike.

du vertauschst die beiden die gesamte Zeit (siehe anderer Beitrag).

Sorry, du vertauschst vielleicht die Zeit? Heute kann nahezu jeder
Browser strike, del nicht jeder.
Bei strike also erreicht 98% die Information, bei del nur 86%.
Oder was meintest du?
Ich hatte darauf hingewiesen dass dein Vorschlag
 DEL  { text-decoration: line-through }
bei älteren Browsern nicht funktioniert, es würde mich wundern
wenn dein Linux-NC4 es doch verstehen würde.

Grüsse

Cyx23

[Kai Lahmann]

hi

Bei strike also erreicht 98% die Information, bei del nur 86%.

und 0% der nicht-visuellen Clients.

bei älteren Browsern nicht funktioniert, es würde mich wundern
wenn dein Linux-NC4 es doch verstehen würde.

accessibility heißt nicht eine Seite auch für den größten Murks kompatibel zu machen, den sich ein Besucher freiwillig antun kann, sondern für Leute, die keine alternative haben, aufgrund von körperlichen Einschränkungen.
Selbst ein völliges Aussperren von Netscape 4 würde nicht gegen derartige Bestimmungen verstoßen (daher kommt man gegen denys in den USA auch nur gegenan, wenn man behauptet irgendwie behindert zu sein)...

Grüße aus Bleckede

Kai

[molily]

Hallo, Cyx23 und Kai,

[durchgestrichener Text]

<del>

also doch ein ziemlicher Unfug in der Praxis, falls ich Tags sinnvoll einsetzen möchte.

Warum? Wieso ist das kein sinnvoller Einsatz des Elements?

<strike> ist unerwünscht, aber ganz W3C konform geht es (HTML/CSS) andererseits auch voraussichtlich nie

Doch, aus welchem Grund sollte es nicht W3C-konform möglich sein?

Der einzige Grund, der gegen die von Kai vorgestellte Auszeichnungsart spricht, ist die mögliche fehlende Kompatibilität mit alten Browsern, bei welchen dann womöglich das Ausgezeichnete falsch, das heißt nicht wie vom Autor beabsichtigt, dargestellt wird. In der Regel dürfte dies aber keinen Verlust der Dokumentstruktur zur Folge haben, da das del-Element in der Regel weit verstanden wird. <del><s>...</s></del> ist auch im Notfall möglich, wenn alles andere schiefläuft.

denn CSS-Weichen die ggf. nötig sind um Tags richtig zu benutzen sind auch nicht konform.

Weshalb? Was meinst du damit? Natürlich sind CSS-Hacks erlaubt, damit auch die etwas älteren Browser erreicht werden.

Die m.E. bestehenden Widersprüche von Barrierefreiheit und W3C sind peinlich, weil Barrierefreiheit ja gerne als Argument für W3C instrumatalisiert wird, aber gut, vielleicht bin ich auch dabei die neuere Entwicklung etwas zu überinterpretieren...

Du lieferst immer weder Grund noch Erklärung. Wieso widersprechen sich Barrierefreiheit und W3C? Ich verstehe dich nicht.

Im anderen Posting habe ich übrigens unterstrichen mit durchgestrichen verwechselt, aber die Kernpunkte sind IMHO davon unabhängig, das Beispiel für »durchgestrichen aufgrund von Kürzungen« hat Kai bereits geliefert. Es geht im Grunde genommen, wie du auch sagst, um die Verwebung von Markup und Präsentationsanweisungen zum Selbstzweck, das heißt ohne dass darüber nachgedacht wurde, warum ein Element eine bestimmte Formatierung erhält.

Grüße,
Mathias

[Cyx23]

Hallo Mathias,

ein CSS-Hack den ich hier z.B. meinte ist html:root wegen Opera 7
und Mozilla, für ältere Browser gibt es andere Möglichkeiten.

Zur Frage der Textauszeichnung meine ich dass es Vorteile hat
dicht am Text auszuzeichnen und diese Auszeichnungen ggf. auch
im Code zu erkennen, also ggf. höhere Notwendigkeit einen
aufwändigeren Editor zu verwenden (als Autor).

Wenn dann die Eindeutigkeit höher ist, beim Autor, beim Leser,
wenn der Code kompakter ist, macht es keinen Sinn viele tags
durch <span class=xy> zu ersetzen.

Und strike hat zudem eine andere Bedeutung als del.

"Wieso widersprechen sich Barrierefreiheit und W3C?"
Ich unterstelle einfach dass eine Auflösung /Darstellung für
Hilfsmittel Behinderter mit Tags besser gelingt, dass dazu
sowieso eine Darstellung ganz ohne CSS möglich sein muss, und
auch ist ein Minimalbestand an Tags vorteilhaft.
Es ist m.E. nötig eine Gegenstrategie zu CSS zu forcieren,
wenn HTML noch irgendwie universell funktionieren soll.

Wobei ich allerdings zuwenig Informationen über die reale Bedeutung
der Barrierefreiheit habe, da kann ich mich natürlich bei meinen
Vorstellungen oder Vermutungen wie eine Website von einer Software
vorgelesen oder anders dargestellt wird irren.
Und auch hier die Frage ob jeder Behinderte gleiche und aktuelle
Software hat.

Aber, W3C, der Widerspruch i.d. Praxis wenn W3C-Empfehlungen nicht
umgesetzt werden können, weil eine Website für möglichst viele
Browser zugänglich sein soll. Da kann man strike auch als W3C
gut beibehalten, aber vielleicht verselbstständigt sich da
bei denen irgendetwas, oder man bildet sich als Browserhersteller
ein Umsatz bzw. Updates generieren zu müssen (ob die Browser was
kosten ist in dem Zusammenhang gar nicht so wichtig).

"die Verwebung von Markup und Präsentationsanweisungen zum Selbstzweck,"
Nein, sondern da wo eindeutiger einfacher sicherer geschrieben,
korrigiert und gelesen werden kann, möglichst ohne speziellen
Editor. Da, wo es so unmittelbar in der Struktur naheliegt wie
das auch bei Tabellen vorkommt.

Grüsse

Cyx23

[Christian Seiler]

Hallo Cyx,

Zur Frage der Textauszeichnung meine ich dass es Vorteile hat
dicht am Text auszuzeichnen und diese Auszeichnungen ggf. auch
im Code zu erkennen, also ggf. höhere Notwendigkeit einen
aufwändigeren Editor zu verwenden (als Autor).

Das hat niemand bestritten.

Wenn dann die Eindeutigkeit höher ist, beim Autor, beim Leser,
wenn der Code kompakter ist, macht es keinen Sinn viele tags
durch <span class=xy> zu ersetzen.

Wer will denn viele Tags druch <span class="xy"> ersetzen? Genau das soll ja _nicht_ passieren.

Und strike hat zudem eine andere Bedeutung als del.

strike hat _gar keine_ Bedeutung. strike heißt nur, dass ein Text druchgestrichen sein soll, mehr nicht. del heißt, dass dieser Text gelöscht wurde. Was willst Du denn mit strike erreichen?

"Wieso widersprechen sich Barrierefreiheit und W3C?"

Tun sie das?

Ich unterstelle einfach dass eine Auflösung /Darstellung für
Hilfsmittel Behinderter mit Tags besser gelingt, dass dazu
sowieso eine Darstellung ganz ohne CSS möglich sein muss, und
auch ist ein Minimalbestand an Tags vorteilhaft.

Das hat niemand bestritten, nicht mal das W3C. Das W3C wirft zwar alle Präsentationstags raus, aber die haben sowieso keine semantische Bedeutung.

Es ist m.E. nötig eine Gegenstrategie zu CSS zu forcieren,
wenn HTML noch irgendwie universell funktionieren soll.

Warum? CSS ist dafür gedacht, HTML-Tags wie del, ins, kbd, code, strong, em, etc. zu gestalten. Diese HTML-Tags haben eine _semantische_ Bedeutung. Tags wie strike oder u oder b oder i haben _keine_ semantische Bedeutung.

"die Verwebung von Markup und Präsentationsanweisungen zum Selbstzweck,"
Nein, sondern da wo eindeutiger einfacher sicherer geschrieben,
korrigiert und gelesen werden kann, möglichst ohne speziellen
Editor. Da, wo es so unmittelbar in der Struktur naheliegt wie
das auch bei Tabellen vorkommt.

Ich verstehe Dich nicht so ganz...

Grüße,

Christian

[Cyx23]

Hallo Christian,

strike hat _gar keine_ Bedeutung. strike heißt nur, dass ein Text druchgestrichen sein soll, mehr nicht. del heißt, dass dieser Text gelöscht wurde. Was willst Du denn mit strike erreichen?

wenn ich z.B. als Koch als eine Tageskarte habe, und Trüffel sind aus,
werd ich doch nicht so dumm sein und Trüffel von der Karte zu entfernen
oder löschen oder bei einer Tafel abzuwischen.
Ich würde selbstvertändlich druchstreichen, "es gab Trüffel" ist doch
wahrscheinlich auch noch gute Werbung, und informativ dazu.

Grüsse

Cyx23

[Christian Seiler]

Hallo Cyx23,

wenn ich z.B. als Koch als eine Tageskarte habe, und Trüffel sind aus,
werd ich doch nicht so dumm sein und Trüffel von der Karte zu entfernen
oder löschen oder bei einer Tafel abzuwischen.
Ich würde selbstvertändlich druchstreichen, "es gab Trüffel" ist doch
wahrscheinlich auch noch gute Werbung, und informativ dazu.

Dann nimm' doch <del> - genau dafür ist es nämlich gedacht: Für eine Information, die nicht mehr gültig ist. Du kannst sogar angeben, ab welchem Zeitpunkt sie nicht mehr gültig war. <del> schließt ja nicht per se aus, dass das später wieder gültig sein kann.

Grüße,

Christian

[Cyx23]

Hallo Christian,

wenn ich z.B. als Koch als eine Tageskarte habe, und Trüffel sind aus,
werd ich doch nicht so dumm sein und Trüffel von der Karte zu entfernen
oder löschen oder bei einer Tafel abzuwischen.
Ich würde selbstvertändlich druchstreichen, "es gab Trüffel" ist doch
wahrscheinlich auch noch gute Werbung, und informativ dazu.

Dann nimm' doch <del> - genau dafür ist es nämlich gedacht: Für eine Information, die nicht mehr gültig ist. Du kannst sogar angeben, ab welchem Zeitpunkt sie nicht mehr gültig war. <del> schließt ja nicht per se aus, dass das später wieder gültig sein kann.

ich hatte dass so verstanden dass die Sichtbarkeit nicht so
selbstverständlich ist, und "del" hat m.E. eine andere Bedeutung,
und bei "strike" gehe ich nach wie vor von einer semantischen
Bedeutung aus, die sich stimmiger aus dem Kontext erschliesst als
bei del. Bei del hätte ich bei o.g. Beispiel die Vermutung, dass es
ungewisser ist nochmals am nächsten Tag oder eine Woche später
Trüffel zu bekommen.
"Delete" kann neben ausradieren und löschen zwar auch als streichen
übersetzt werden, aber "strike" bedeutet wohl erst als "strike off"
etwas ähnlich endgültiges?

Ist die Frage was erfährt ein Surfer bei welchem Browser überhaupt
über die Tags. Wie zukunftsicher ist z.B. dass del sichtbar ist.

Und natürlich der Unfug etablierte Tags zu ersetzen statt ältere
Browser kompatibel zu bedienen, hier seitens des w3c m.E. absolut
unnötig, und wie schon dargestellt, da w3c Kompatibilität
letztendlich nicht erreichbar ist, scheint es noch fragwürdiger
heute auf strike zu verzichten, selbst wenn man text-decoration:
line-through; für NC4 ergänzen kann.

Grüsse

Cyx23

[Christian Seiler]

Hallo Cyx23,

ich hatte dass so verstanden dass die Sichtbarkeit nicht so
selbstverständlich ist,

Warum? Alle Browser, die ich kenne, stellen <del> durchgestrichen dar. Nirgendwo steht, dass das nicht sichtbar sein soll. Du _kannst_ es unsichtbar machen, _musst_ es aber nicht.

und "del" hat m.E. eine andere Bedeutung,

http://www.w3.org/TR/1999/REC-html401-19991224/struct/text.html#h-9.4
| INS and DEL are used to markup sections of the document
| that have been inserted or deleted with respect to a
| different version of a document (e.g., in draft legislation
| where lawmakers need to view the changes).

Du hast die vorige Version einer Speisekarte (mit Trüffeln) und jetzt die spätere.

Bei del hätte ich bei o.g. Beispiel die Vermutung, dass es
ungewisser ist nochmals am nächsten Tag oder eine Woche später
Trüffel zu bekommen.

Wenn ich mal die Annahme akzeptiere, dass strike eine semantische Bedeutung hat, dann ist es IMHO die gleiche wie del, nämlich etwas, was nicht mehr der Fall ist. Es gibt keine Aussage darüber, ob das später nicht wieder der Fall sein wird, Du kannst es aber, im Gegensatz zu strike, mit ins erklären. (<del>Trüffel</del><ins>Trüffel sind heute ausverkauft</ins>)

"Delete" kann neben ausradieren und löschen zwar auch als streichen
übersetzt werden, aber "strike" bedeutet wohl erst als "strike off"
etwas ähnlich endgültiges?

Nein, IMHO ist strike genauso endgültig/nicht-endgültig wie delete. (es gibt übrigens auch ein undelete, von daher ist bei 'delete' auch nicht sicher, ob es endgültig ist)

Ist die Frage was erfährt ein Surfer bei welchem Browser überhaupt
über die Tags.

Das verstehe ich nicht.

Wie zukunftsicher ist z.B. dass del sichtbar ist.

Im Moment ist die Interpretation von del, die vorherrschend ist, einfach ein druchgestrichener Text. Wenn zukünftige Browser <del> unterstützen, unterstützen sie sicherlich auch CSS, zumindest so viel, dass man angeben kann, dass es _nicht_ unsichtbar sein soll. Und ältere Browser zeigen es sowieso immer an - da sehe ich auch kein Problem.

Und natürlich der Unfug etablierte Tags zu ersetzen statt ältere
Browser kompatibel zu bedienen, hier seitens des w3c m.E. absolut
unnötig, und wie schon dargestellt, da w3c Kompatibilität
letztendlich nicht erreichbar ist, scheint es noch fragwürdiger
heute auf strike zu verzichten, selbst wenn man text-decoration:
line-through; für NC4 ergänzen kann.

Warum? Statt _einfach nur_ strike zu haben, hast Du jetzt del _und_ ins. Strike ist nichts anderes als ein visualisierendes Element ohne semantische Bedeutung. (Bedenke: etwas durchgestrichenes hat in _unserem_ Kulturkreis die Bedeutung, dass es nicht mehr gültig ist, jedoch könnte ein grün eingerahmter Text in einem anderen Kulturkreis die bedeutung "nicht mehr gültig haben" - von daher _kann_ strike aus Prinzip keine semantische Bedeutung haben)

Grüße,

Christian

[Cyx23]

Hallo Christian,

... need to view the changes).

immerhin, schonmal ein gutes Beipiel.

Nein, IMHO ist strike genauso endgültig/nicht-endgültig wie delete. (es gibt übrigens auch ein undelete, von daher ist bei 'delete' auch nicht sicher, ob es endgültig ist)

Ein "undelete" gibt es trotz Norton Utilities eigentlich nicht, "IMHO".

Ist die Frage was erfährt ein Surfer bei welchem Browser überhaupt
über die Tags.

Das verstehe ich nicht.

Ob es z.B. irgendeine Blindensoftware gibt, die versucht Tags
irgendwie auszuwerten, und unterschiedliche Informationen ausgibt.
Ob irgendwie anders ein Surfer merkt ob del oder strike da im Code
steht, wobei natürlich alle älteren Browser ohne strike einfach
falsche Informationen ausgeben.

Im Moment ist die Interpretation von del, die vorherrschend ist, einfach ein druchgestrichener Text. Wenn zukünftige Browser <del> unterstützen, unterstützen sie sicherlich auch CSS, zumindest so viel, dass man angeben kann, dass es _nicht_ unsichtbar sein soll. Und ältere Browser zeigen es sowieso immer an - da sehe ich auch kein Problem.

s.o.

Warum? Statt _einfach nur_ strike zu haben, hast Du jetzt del _und_ ins.

warum nicht strike und ins ?

(Bedenke: etwas durchgestrichenes hat in _unserem_ Kulturkreis die Bedeutung, dass es nicht mehr gültig ist,

ist doch Unfug, strike kann so wie gewünscht definiert werden, zumal
du gerade behauptet hast die Bedeutung der Worte wäre nahezu gleich.
Und du argumentierst über eine bildhafte Vorstellung der Teilbedeutung
eines Wortes, die gar nicht gegeben ist.
At the docks there is a strike which the company dont like.

Grüsse

Cyx23

[Christian Seiler]

Hallo Cyx,

Ein "undelete" gibt es trotz Norton Utilities eigentlich nicht, "IMHO".

Das kommt auf das Dateisystem an - in anderen Dateisystemen ist dies durchaus möglich.

Ob es z.B. irgendeine Blindensoftware gibt, die versucht Tags
irgendwie auszuwerten, und unterschiedliche Informationen ausgibt.

Sicherlich. Und genau deshalb sollte man semantische Tags verwenden.

Ob irgendwie anders ein Surfer merkt ob del oder strike da im Code
steht,

Nur, wenn der Surfer ein Benutzerstylesheet hat.

wobei natürlich alle älteren Browser ohne strike einfach
falsche Informationen ausgeben.

Was heißt 'falsche Informationen' - ich muss dich erinnern, dass Netscape 2.0 kein Strike darstellen kann, von daher muss man irgendwo die grenze ziehen - und NC4 kann man es ja, wie Du gesagt hast, beibringen...

Warum? Statt _einfach nur_ strike zu haben, hast Du jetzt del _und_ ins.

warum nicht strike und ins ?

Weil strike keine semantische Bedeutung hat.

(Bedenke: etwas durchgestrichenes hat in _unserem_ Kulturkreis die Bedeutung, dass es nicht mehr gültig ist,

ist doch Unfug, strike kann so wie gewünscht definiert werden, zumal
du gerade behauptet hast die Bedeutung der Worte wäre nahezu gleich.

Die Bedeutung der Worte, unter der Annahme, dass strike eine logishe Auszeichnung sei, ja. Aber wenn ich diese falsche Annahme weglasse, dann ist strike nichts anderes als eine physische Textauszeichnung.

Und du argumentierst über eine bildhafte Vorstellung der Teilbedeutung
eines Wortes, die gar nicht gegeben ist.

Doch, die ist gegeben, denn strike heißt hier nichts anderes als Durchstreichen - Du kannst da nicht Anschlag, Aufprall, Streik oder sonst noch was reininterpretieren...

Grüße,

Christian

[Kai Lahmann]

hi

Ob es z.B. irgendeine Blindensoftware gibt, die versucht Tags
irgendwie auszuwerten, und unterschiedliche Informationen ausgibt.

natürlich, das Ding wird bei <strike>, was ja nur ein layout-gimmik ist nichts sagen, bei <del> kommt irgendwas von "aufgehobener Abschnitt" oder so. Das versuchen wir dir ja jetzt schon den ganzen Tag einzutrichtern!

Warum? Statt _einfach nur_ strike zu haben, hast Du jetzt del _und_ ins.

warum nicht strike und ins ?

weil der Browser jetzt nicht wüsste, ob <strike> im HTML4.0-Sinne gemeint ist (als durchgestrichen, weil es schöner aussieht) oder in deinem (als "ungültig").

ist doch Unfug, strike kann so wie gewünscht definiert werden, zumal
du gerade behauptet hast die Bedeutung der Worte wäre nahezu gleich.

HIMMELDONNERWETTER!
ließ doch mal die HTML-Spec!

http://www.w3.org/TR/html4/present/graphics.html#h-15.2.1
"STRIKE and S: Deprecated. Render strike-through style text."

so, welche Bedeutung über den Grund des Durchstreichens steckt da jetzt drin?

Grüße aus Bleckede

Kai

[Sven Rautenberg]

Moin!

ist doch Unfug, strike kann so wie gewünscht definiert werden, zumal
du gerade behauptet hast die Bedeutung der Worte wäre nahezu gleich.

_Alle_ HTML-Elemente können bei Bedarf so formatiert werden, wie alle anderen HTML-Elemente. Du kannst aus <sup> eine <h1>-Überschrift machen, und du kannst mit <form> Bilder anzeigen lassen. Alles kein Problem.

Worum es geht, ist die derzeitige Definition der Bedeutung von <strike>. Und die ist nunmal ziemlich banal:
"STRIKE and S: Deprecated. Render strike-through style text."
(http://www.w3.org/TR/html401/present/graphics.html#edef-STRIKE)

Das bedeutet: Der damit ausgezeichnete Text hat keine _Bedeutung_, sondern er soll durchgestrichen gezeigt werden.

Was macht ein Browser, der dazu nicht in der Lage ist?

Die Sache sieht bei <del> nur scheinbar genauso aus. <del> kennzeichnet Text, der nicht mehr ins Dokument gehört. Das _kann_ man durch Durchstreichen kennzeichnen, oder durch eine "gelöscht"-Markierung, oder durch Nicht-Darstellung. Der Browserhersteller ist da grundsätzlich frei, wenngleich das W3C Default-Stylesheets veröffentlicht hat, die eine gewisse Vorgabe machen können.

Und du argumentierst über eine bildhafte Vorstellung der Teilbedeutung
eines Wortes, die gar nicht gegeben ist.

Im Sinne von HTML schon.

- Sven Rautenberg

[Cyx23]

Hallo,

Worum es geht, ist die derzeitige Definition der Bedeutung von <strike>. Und die ist nunmal ziemlich banal:

also da fand ich die Problematik diese Bedeutung zu ändern
(wie Kai es gepostet hat) als Argument für einen neuen Tag
recht plausibel, auch wenn ich meine dass es nicht so
zwingend ist.

Die Sache sieht bei <del> nur scheinbar genauso aus. <del> kennzeichnet Text, der nicht mehr ins Dokument gehört. Das _kann_ man durch Durchstreichen kennzeichnen, oder durch eine "gelöscht"-Markierung, oder durch Nicht-Darstellung. Der Browserhersteller ist da grundsätzlich frei, wenngleich das W3C Default-Stylesheets veröffentlicht hat, die eine gewisse Vorgabe machen können.

Eben, die mögliche "Nicht-Darstellung" war ja auch mein Kritikpunkt.
Und mein Text gehört absolut ins Dokument, zumindest auf der
letzten Instanz bzw. der Betrachterbene, so gesehen wäre also
del u.U. gar nicht richtig für mein Speisekartenbeispiel, ich
kann dann nur strike nehmen oder eine CSS-Klasse, und der
gewünschte Inhalt wäre ohne strike nicht barrierefrei darstellbar,
mit womöglich auch nicht. Strike wäre aber am ehesten in der Lage
darzustellen dass vielleicht doch eine Bedeutung hinter der
text-decoration steckt, auch wenn es so nicht in HTML-Specs steht.
Aus rechtlichen Gründen muss ich dann doch del nehmen, denn dann
kann ich über die Konformität zu Normen des W3C nachweisen dass
ich bei meinem Angebot auf der Speisekarte hinreichend auf den
Ausverkauf bestimmter Artikel hingewiesen habe. Womit ich auf
den Punkt komme dass aus juristischen Gründen womöglich die reale
Zugänglichkeit von Webseiten erstmal verschlechtert werden könnte...

Und du argumentierst über eine bildhafte Vorstellung der Teilbedeutung
eines Wortes, die gar nicht gegeben ist.

Im Sinne von HTML schon.

Dann hat diese bildhafte Vorstellung womöglich in Kulturen
die das nicht verstehen eine Verküpfung mit unserer Bedeutung
sowie ein Feld an Bedeutungen des Wortes strike.

Grüsse

Cyx23

[Kai Lahmann]

hi

Eben, die mögliche "Nicht-Darstellung" war ja auch mein Kritikpunkt.

auf die versteifst du dich auch ohne Ende...
Eine nicht-darstellung von <del> gibt's nur, wenn DU als Autor ein del{display:none;} (o.ä.) in den Stylesheet schreibst. Ohne dieses, wird der Text eben über druchstreichen oder eine geeignete andere Darstellungsform.

Grüße aus Bleckede

Kai

[Christian Seiler]

Hallo Cyx,

Der Browserhersteller ist da grundsätzlich frei,

Jain, es gibt ja noch Autorenstylesheets, denn Browser,
die das anders machen werden, unterstützen sicherlich
CSS.

Eben, die mögliche "Nicht-Darstellung" war ja auch mein Kritikpunkt.

Dafür hast Du die mögliche Ignoranz gegenüber <strike> von
anderen zukünftigen Tools, die IMHO gravierender ist. Die
meisten zukünftigen Tools wirst Du per CSS beeinflussen können,
CSS beinhaltet ja nicht nur Visualisierung sondern auch
"Aurealisierung". (sagt man das so?)

Und mein Text gehört absolut ins Dokument,

Ja, aber die Trüffel gehören ja auch nicht mehr
zu Deinem Dokument, oder? Sie gehören nicht zur
aktuellen Speisekarte.

so gesehen wäre also
del u.U. gar nicht richtig für mein Speisekartenbeispiel,

Warum? Es gehört nicht mehr ins _aktuelle_ Dokument,
wohl aber in eine vorige Version, und genau das
willst Du ja ausdrücken. Du fixierst Dich wieder auf die
Visualisierung und nicht auf die semantische Ebene.

und der gewünschte Inhalt wäre ohne strike nicht
barrierefrei darstellbar,

Warum nicht? Barrierefreiheit beinhaltet auch die Tatsache,
dass nicht jeder Browser alles interpretieren kann, wohl
aber, dass die Seite unter jedem Browser benutzbar ist. Und
wenn ein Browser halt das nicht darstellen kann, dann dringt
der Inhalt trotzdem durch. Wenn Du auch <ins> verwendest,
um zu erklären, dass eben die Trüffel heute nicht verfügbar
sind, dann wundert sich der Benutzer vielleicht wegen der
etwas seltsamen Darstellung, aber er versteht immerhin, was
Du meinst.

Außerdem: was spricht gegen

<del><span class="del">Trüffel</span></del>

und

del { text-decoration: line-through; }
.del { text-decoration: line-through; }

(getestet im NC4/Linux)

Einmal bedienst Du da die Semantik und  ein anderes mal die
Visualisierung. Die WCAG erlauben _ausdrücklich_, dass bis
die Browser alle Features unterstützen, Workarounds verwendet
werden dürfen.

mit womöglich auch nicht.

Eben.

Strike wäre aber am ehesten in der Lage darzustellen dass
vielleicht doch eine Bedeutung hinter der text-decoration
steckt, auch wenn es so nicht in HTML-Specs steht.

Warum? Strike hat gar keine Bedeutung außer der visuellen.

Aus rechtlichen Gründen muss ich dann doch del nehmen, denn dann
kann ich über die Konformität zu Normen des W3C nachweisen dass
ich bei meinem Angebot auf der Speisekarte hinreichend auf den
Ausverkauf bestimmter Artikel hingewiesen habe. Womit ich auf
den Punkt komme dass aus juristischen Gründen womöglich die reale
Zugänglichkeit von Webseiten erstmal verschlechtert werden könnte...

Siehe meinen Workaround.

Dann hat diese bildhafte Vorstellung womöglich in Kulturen
die das nicht verstehen eine Verküpfung mit unserer Bedeutung
sowie ein Feld an Bedeutungen des Wortes strike.

Das verstehe ich jetzt wieder nicht...

Grüße,

Christian

[Cyx23]

Hallo,

(getestet im NC4/Linux)

ist schon klar dass das funktioniert.

Ein Punkt war dass ich es für möglich gehalten hatte,
strike seitens des w3c umzudefinieren, ist ja auch
schon hinreichend durchgekaut worden.

Dann halte ich es für möglich dass ältere Software für
Sehbehinderte womöglich eher strike versteht, dazu fehlt
aber wohl ein Teilnehmer im Thread der sich mit solchen
Details auskennt.

Warum? Strike hat gar keine Bedeutung außer der visuellen.

s.o., z.B. eine Blindensoftware die del noch nicht kennt sollte
m.E. strike irgendwie darstellen, siehe auch Zitate weiter unten.

Aus rechtlichen Gründen muss ich dann doch del nehmen, denn dann
kann ich über die Konformität zu Normen des W3C nachweisen dass
ich bei meinem Angebot auf der Speisekarte hinreichend auf den
Ausverkauf bestimmter Artikel hingewiesen habe. Womit ich auf
den Punkt komme dass aus juristischen Gründen womöglich die reale
Zugänglichkeit von Webseiten erstmal verschlechtert werden könnte...

Siehe meinen Workaround.

Ich meinte nicht speziell meine oder Deine Seiten.

Dann hat diese bildhafte Vorstellung womöglich in Kulturen
die das nicht verstehen eine Verküpfung mit unserer Bedeutung
sowie ein Feld an Bedeutungen des Wortes strike.

Das verstehe ich jetzt wieder nicht...

Wer bei etwas durchgestrichenem aus kulturellen Gründen was anderes
assoziiert, lernt trotzdem Bedeutungen des Wortes strike wie auch
Anwendungsbeispiele bei Webseiten, also erfährt er die Bedeutung
sehr genau und eindeutig zumindest in dem Kontext HTML, um den
es vorher im Posting m.E. ging.

Z.B. Zitat aus Fachbuch "HTML" von 1996, tewi Verlag:
"<s> .. wie in Gestzestexten"

Also genau in dem Kontext der mir hier für del zitiert worden ist.

Oder O'Reilly 1997:
"<strike> ... Redigiermarke"

Also da gibts in der Praxis nichts von wegen Textauszeichnung ohne
Bedeutung oder so bei strike, strike wird schon sehr eindeutig
so verwendet wie es jetzt offenbar per del erfolgen soll!

Deshalb ist ja auch anzunehmen, dass verbreitete Blindensoftware
wenn überhaupt dann mit strike klarkommt, dehalb ist der Ersatz
durch del ja nochmals fragwürdig.

Grüsse

Cyx23

[Christian Seiler]

Hallo Cyx,

ist schon klar dass das funktioniert.

dann steht ja nichts mehr im Wege, es zu verwenden.

Dann halte ich es für möglich dass ältere Software für
Sehbehinderte womöglich eher strike versteht, dazu fehlt
aber wohl ein Teilnehmer im Thread der sich mit solchen
Details auskennt.

Eben. Von daher möchte ich auch darüber nicht weiter sepkulieren,
ich kann Dir nur sagen, wie es mit zukünftiger Software _vermutlich_
aussehen wird.

Siehe meinen Workaround.

Ich meinte nicht speziell meine oder Deine Seiten.

Was hat das denn mit den versch. Seiten zu tun?

Wer bei etwas durchgestrichenem aus kulturellen Gründen was anderes
assoziiert, lernt trotzdem Bedeutungen des Wortes strike wie auch
Anwendungsbeispiele bei Webseiten, also erfährt er die Bedeutung
sehr genau und eindeutig zumindest in dem Kontext HTML, um den
es vorher im Posting m.E. ging.

Nicht notwendigerweise. Denn

Z.B. Zitat aus Fachbuch "HTML" von 1996, tewi Verlag:
"<s> .. wie in Gestzestexten"
Oder O'Reilly 1997:
"<strike> ... Redigiermarke"

HTML 4 gab's erst 1998.

Also genau in dem Kontext der mir hier für del zitiert worden ist.

Ja, aber nur, weil damals es nichts anderes gab. Damals wurde auch
noch intensiv mit <big>, <font> und <small> gearbeitet.

Also da gibts in der Praxis nichts von wegen Textauszeichnung ohne
Bedeutung oder so bei strike, strike wird schon sehr eindeutig
so verwendet wie es jetzt offenbar per del erfolgen soll!

Es wurde so verwendet, weil es nichts anderes gab!

Aber schon in der HTML 3.2-Spec [1] heißt es:

| STRIKE strike-through text style

Da steht nur etwas über die Visualisierung.

Deshalb ist ja auch anzunehmen, dass verbreitete Blindensoftware
wenn überhaupt dann mit strike klarkommt,

Ich will wie gesagt nicht spekulieren. Solange mir das niemand
bestätigt, bleibe ich bei <del>, andernfalls könnte es sein, dass
ich mir das noch mal überlege. (je nach Verbreitungsgrad und
Upgradewarscheinlichkeit)

Grüße,

Christian

[1] http://www.w3.org/TR/REC-html32#font-style

[Kai Lahmann]

hi

ich hatte dass so verstanden dass die Sichtbarkeit nicht so
selbstverständlich ist, und "del" hat m.E. eine andere Bedeutung,
und bei "strike" gehe ich nach wie vor von einer semantischen
Bedeutung aus, die sich stimmiger aus dem Kontext erschliesst als
bei del. Bei del hätte ich bei o.g. Beispiel die Vermutung, dass es
ungewisser ist nochmals am nächsten Tag oder eine Woche später
Trüffel zu bekommen.

nochmal:
<strike> streicht durch, wenn ein Browser nicht durchstreichen kann, ist es zu ignorieren, es hat ABSOLUT GAR KEINE LOGISCHE BEDEUTUNG.
<del> besagt, dass dieser Abschnitt ungültig ist, sonst gar nichts. Das *sollte* (nach W3C) mittels durchstreichen visualisiert werden. Ein Audio-Browser wird das dann mit "irgendwas kommentieren, dass dieser Abschlitt nicht mehr gilt, ein farbiger lynx (der nicht durchstreichen kann), wird das dann wohl in blasserer Farbe anzeigen.

"Delete" kann neben ausradieren und löschen zwar auch als streichen
übersetzt werden, aber "strike" bedeutet wohl erst als "strike off"
etwas ähnlich endgültiges?

<strike> bedeutet eben NICHT irgendwas, sondern exakt "Text durchstreichen", sonst nichts, nicht "Text wird ungültig". Wenn jemand seine Überschrift durchstreicht, weil er das hübsch findet, ist das für die automatische Verarbeitung bedeutungslos (für einen Screenreader auch).

Ist die Frage was erfährt ein Surfer bei welchem Browser überhaupt
über die Tags. Wie zukunftsicher ist z.B. dass del sichtbar ist.

<del> wird wie oben gesagt bleiben, <strike> muss ein Browser, der das "Strict" ernst nimmt schon ignorieren.

Und natürlich der Unfug etablierte Tags zu ersetzen statt ältere
Browser kompatibel zu bedienen, hier seitens des w3c m.E. absolut
unnötig

wo ist denn vor <del> einn LOGISCHES Element für "ungültiger Abschnitt" gewesen?

Grüße aus Bleckede

Kai

[Sven Rautenberg]

Moin!

Zur Frage der Textauszeichnung meine ich dass es Vorteile hat
dicht am Text auszuzeichnen und diese Auszeichnungen ggf. auch
im Code zu erkennen, also ggf. höhere Notwendigkeit einen
aufwändigeren Editor zu verwenden (als Autor).

Was meinst du mit "dicht am Text auszeichnen"? Wenn du damit meinst, in HTML Strict erlaubte Elemente einzusetzen, wo immer sie Sinn machen, dann hast du vollkommen Recht.

Nur sollte man es nicht übertreiben - auch in Texten anderer Medien ist selten wahnsinnig viel besonders ausgezeichnet. Es beschränkt sich in der Regel darauf, dass es Überschriften, Textabsätze und unter Umständen die eine oder andere Hervorhebung durch Fettschrift oder Kursivschrift gibt. Außerdem gibts häufiger Zitate und Verweise.

All das kann HTML leisten. Ok, dass mit Fettschrift/Kursivschrift sollte besser CSS leisten, weil es ja bekanntlich Systeme gibt, die nur irgendwie "hervorheben" können, aber nicht fett oder kursiv schreiben. Aber die Tatsache der _Hervorhebung_ sollte man auszeichnen.

Fakt ist dabei aber, dass physikalische Auszeichnungen wie <b>, <i>, <s>, <u>, <big> und <small> eben gedanklich implizieren, wie der Text auszu_sehen_ hat. Da es Menschen gibt, die aus irgendwelchen Gründen nicht sehen können oder wollen (weil sie sich beispielsweise das Online-Rezept vom Kühlschrank vorlesen lassen), muß man dem Wiedergabemedium ohnehin begreiflich machen, wie es in solch einem Fall vorzugehen hat. Und damit die Webautoren das nicht vergessen, hat man ein paar Elemente schon mal auf die Abschußliste gesetzt.

Interessanterweise sind nur <u>, <s> und <strike> deprecated, kommen also in der Strict-Version nicht mehr vor. (Auch interessant ist, dass alle Elemente bis auf <iframe>, die nur in der Transitional-Variante vorkommen, deprecated sind - da wird also aufgeräumt.)

Wenn dann die Eindeutigkeit höher ist, beim Autor, beim Leser,
wenn der Code kompakter ist, macht es keinen Sinn viele tags
durch <span class=xy> zu ersetzen.

Nein, das macht auch keinen Sinn. Denn die Klasse hat keine Bedeutung, wie <strong> sie hat. <span>-Formatierungen sind im Prinzip rein optisch zu sehen, solange man Stylesheets nur für "screen" und "print" schreiben kann, weil Browser anderer Medien das noch nicht unterstützen.

Und strike hat zudem eine andere Bedeutung als del.

Welche Bedeutung hat den <strike>?

"Wieso widersprechen sich Barrierefreiheit und W3C?"
Ich unterstelle einfach dass eine Auflösung /Darstellung für
Hilfsmittel Behinderter mit Tags besser gelingt, dass dazu
sowieso eine Darstellung ganz ohne CSS möglich sein muss, und
auch ist ein Minimalbestand an Tags vorteilhaft.

Ich bin voll deiner Meinung. Eine Seite muß textlogisch ausgezeichnet sein, CSS kann dann optional dazukommen, um das Aussehen zu beeinflussen. Allerdings sind nach meiner Meinung dazu ausreichend Tags verfügbar - alle, die in Strict enthalten sind.

Gehen wir doch mal kurz durch, was von Transitional nach Strict verlorengeht:
<applet> - Nimm <object>
<basefont> - Nimm CSS
<center> - Nimm CSS
<dir> - Yet another List - braucht(e) die jemand?
<font> - Nimm CSS
<isindex> - Braucht(e) das jemand? Hat es jemals irgendwo funktioniert?
<menu> - Yet another List - braucht(e) die jemand?
<s> - Mal abgesehen davon, dass man durchgestrichenen Text ohnehin ultraselten benötigt, hat das Durchstreichen sicherlich einen textlogischen Grund - und damit ein anderes HTML-Element.
<strike> - dito
<u> - Unterstreichung ist schon deshalb böse, weil Links üblicherweise ebenfalls unterstrichen werden und es leicht zu Verwechslungen kommen kann. Ansonsten kann man mit den vorhandenen zwei Hervorhebungsstufen <em> und <strong> zusammen mit CSS ebenfalls Unterstreichungen herstellen

Es ist m.E. nötig eine Gegenstrategie zu CSS zu forcieren,
wenn HTML noch irgendwie universell funktionieren soll.

Ich finde HTML eigentlich universell genug für meine Zwecke. Ich denke, es ist der Sache nicht förderlich, wenn HTML plötzlich als Auszeichnungssprache für den Grund der Auszeichnung genutzt wird. Die _Tatsache_, dass gewisse Textstellen eine gewisse bzw. besondere Bedeutung haben, sollte ausreichend sein. Und HTML ist da wirklich reichlich gerüstet: Es gibt insgesamt 91 verschiedene Elemente. Davon sind 3 Stück für Framesets, 10 deprecated, und eines nur in Transitional enthalten. Bleiben 77 Elemente in Strict für die Textauszeichnung.

Ich will mal bezweifeln, dass in den meisten Texten mehr als 77 Textbedeutungen vorkommen. Üblicherweise ist die Nutzung der Elemente doch kaum aufregender als diese 14 Stück:
<html>, <head>, <title>, <meta>, <body>, <h1>, <p>, <a>, <b>, <i>, <table>, <tr>, <th>, <td>, <div> und <span>.

Wobei ich allerdings zuwenig Informationen über die reale Bedeutung
der Barrierefreiheit habe, da kann ich mich natürlich bei meinen
Vorstellungen oder Vermutungen wie eine Website von einer Software
vorgelesen oder anders dargestellt wird irren.

Mach, dass die Seite in Lynx funktioniert, und du hast einen großen Schritt getan in Richtung Barrierefreiheit. Würde ich mal sagen.

Und auch hier die Frage ob jeder Behinderte gleiche und aktuelle
Software hat.

Vermutlich nicht. Entsprechende Software dürfte, weil selten verlangt, entsprechend teuer sein. Die eventuell notwendige Hardwareausstattung ist es mit Sicherheit (Braille-Zeile z.B.).

- Sven Rautenberg

[molily]

Hallo, Sven,

Nur eine Anmerkung:

<dir> - Yet another List - braucht(e) die jemand?

[...]

<menu> - Yet another List - braucht(e) die jemand?

Wenn man sich http://www.w3.org/TR/xhtml2/mod-list.html#edef_list_nl anschaut, haben einige durchaus die Meinung, dass es ein Element speziell für Navigations(menü)-Listen geben sollte.

Ich persönlich halte es für sinnvoll, zwischen einer Liste und einer Navigationslinkliste zu unterscheiden, unabhängig davon, dass das XHTML 2 WD vorsieht, dass nl mit verschachtelten aufklappenden Boxen visualisiert werden soll. Zu einer nl könnte der Benutzer durch Eingabe direkt springen, dies ist bei einer <ul id="nav"> nicht möglich, da diese id-Konvention nicht besteht. IMHO sollten Navigationsleisten auf Markupebene eindeutig gekennzeichnet werden können, sodass der Browser sie gegebenenfalls genauso wie die hX-Struktur nachbilden und in der vom Benutzer gewünschten Weise darstellen kann. Ein Benutzerstylesheet, welches auf *jeder* Seite die Primärnavigation nach Benutzerwünschen anpassen könnte, das wäre ein Meilensprung...

Ansonsten: ACK. *smirk*

Grüße,
Mathias

[Kai Lahmann]

hi

Ich persönlich halte es für sinnvoll, zwischen einer Liste und einer Navigationslinkliste zu unterscheiden, unabhängig davon, dass das XHTML 2 WD vorsieht, dass nl mit verschachtelten aufklappenden Boxen visualisiert werden soll.

<nl> ist ja als NavigationsListe gedacht. Dabei entwickelt das ganze übrigens seine volle "Macht" erst zusammen mit dem globalen href="", dass es ja auch in XHTML2 geben soll.

Grüße aus Bleckede

Kai

[Sven Rautenberg]

Moin!

Nur eine Anmerkung:

<dir> - Yet another List - braucht(e) die jemand?
[...]
<menu> - Yet another List - braucht(e) die jemand?

Wenn man sich http://www.w3.org/TR/xhtml2/mod-list.html#edef_list_nl anschaut, haben einige durchaus die Meinung, dass es ein Element speziell für Navigations(menü)-Listen geben sollte.

Naja, die kommen etwas spät damit. Es sind zwar in der Spec zu HTML 4.01 keine Gründe für das Abschaffen von <dir> und <menu> genannt, aber immerhin steht drin:
"The DIR element was designed to be used for creating multicolumn directory lists. The MENU element was designed to be used for single column menu lists. Both elements have the same structure as UL, just different rendering. In practice, a user agent will render a DIR or MENU list exactly as a UL list.

We strongly recommend using UL instead of these elements."

Da HTML 4.01 morgen vor drei Jahren verabschiedet wurde, <dir> und <menu> aber mindestens seit HTML 2.0 im Standard enthalten sind, haben die Browserhersteller die Möglichkeiten nicht genutzt, <dir> und <menu> einzubauen.

Außerdem (und das dürfte der Hauptgrund sein) ist die Beschreibung, was<dir> und <menu> machen sollen, eine rein Layout-technische Beschreibung.

RFC1866 sagt:
"The <DIR> element is similar to the <UL> element. It represents a list of short items, typically up to 20 characters each. Items in a directory list may be arranged in columns, typically 24 characters wide."

" The <MENU> element is a list of items with typically one line per item. The menu list style is typically more compact than the style of an unordered list."

Bei beiden darf nicht verschachtelt werden, was vermutlich das Killer-Argument gegen diese beiden Elemente war. Menüs sind nun einmal immer verschachtelt, weil die Dokumentenstruktur verschachtelt ist: Eine Buch enthält mehrere Teile mit mehreren Kapitel mit mehrern Hauptüberschriften mit mehreren Unterüberschriften ... mit mehreren Absätzen. Da man in einem Menü zumindest theoretisch bis hinunter zu den Absätzen Selektionsmöglichkeiten haben können sollte, sind die beiden Elemente dafür ungeeignet.

Ich persönlich halte es für sinnvoll, zwischen einer Liste und einer Navigationslinkliste zu unterscheiden, unabhängig davon, dass das XHTML 2 WD vorsieht, dass nl mit verschachtelten aufklappenden Boxen visualisiert werden soll.

Das mit den aufklappenden Boxen klingt zwar auf den ersten Blick nett, dürfte sich aber schätzungsweise dadurch erübrigen, dass auch XHTML 2.0 nur mit Wasser... ähm, nur mit CSS kocht. Das, was <nl> verspricht, kriegt man heutzutage schon ganz prima mit <div> hin - das spricht grundsätzlich dafür, <nl> einzuführen (denn die Browserhersteller haben da nicht viel zu ändern). Dann kriegen bislang anonyme <div>-Blöcke auf einmal eine Bedeutung, und ordentliche Browser könnten daraus auch ganz ohne CSS und Javascript eine vernünftige Navigation machen. Grafische Browser sollten und werden sich mit CSS dann recht weitgehend beeinflussen lassen.

- Sven Rautenberg

[molily]

Hallo, Cyx23,

Zur Frage der Textauszeichnung meine ich dass es Vorteile hat dicht am Text auszuzeichnen

Du meinst nicht die Textauszeichnung, sondern Formatierungen. Das Vermixen von Formatierungen und Markup entspricht nicht dem konzept von HTML, und CSS würde auch überflüssig, wenn es nicht vom Markup getrennt wurde, beispielsweise wurde aus diesem Grund das style-Attribut aus XHTML 2 entfernt beziehungsweise es wird darüber diskutiert (man kann darüber unterschiedlicher Auffassung sein).

und diese Auszeichnungen ggf. auch im Code zu erkennen, also ggf. höhere Notwendigkeit einen aufwändigeren Editor zu verwenden (als Autor).

Das Argument ist konstruiert, denn CSS lässt sich mit jedem x-beliebigen Texteditor schreiben, es ist zudem ein offenener Standard und kostenlose Autorenwerkzeuge existieren in Hülle un Fülle.

Wenn dann die Eindeutigkeit höher ist, beim Autor,

Das Verständnis des Codes ist IMHO viel einfacher, wenn semantische Elemente und bedeutungsvolle Klassennamen verwendet werden, beispielsweise:

<p><small>murks</small></p>
versus
<p class="anmerkung">murks</p>

Genauso sind del und ins darauf ausgerichtet, dass im title-Attribut der Grund und und im datetime-Attribut das Datum der Änderung abgelegt werden können, somit kann der Autor im Code ungleich mehr Informationen über die Änderung ablegen, als er es je mit einem strike-Element ohne Kommentare oder Ähnliches könnte. Text kann aus dutzenden Gründen durchgestrichen sein, weshalb ich dir widerspreche, dass strike semantisch mit del gleichwertig oder sogar aussagereicher ist - es sagt explizit nichts darüber aus, warum der Text durchgestrichen ist.

Natürlich sagen alle anderen Präsentatioselemente wie b, i und u auch etwas implizit über die Bedeutung aus, aber dies sollte im Markup festgehalten sein - deshalb rede ich ständig von der *Abstraktion*.

beim Leser, wenn der Code kompakter ist, macht es keinen Sinn viele tags durch <span class=xy> zu ersetzen.

Kompakter Code ist nicht das Ziel von XML-Applikationen, das Markup soll die Dokumentstruktur auf einer abstrakten Ebene detailliert beschreiben.

Und strike hat zudem eine andere Bedeutung als del.

IMHO sagt es nicht mehr aus, als dass der Text durchgestrichen dargestellt ewrden soll.
Opera stellt beispielsweise bei einem bestimmten Benutzerstylesheet besuchte Links durchgestrichen an - hat das etwas mit s oder del zu tun?

Wieso widersprechen sich Barrierefreiheit und W3C?

Ich unterstelle einfach dass eine Auflösung /Darstellung für
Hilfsmittel Behinderter mit Tags besser gelingt

Nein, wieso denn? Wie in diesem Thread sagte, ist die Trennung von Inhalt und Darstellung eine der Grundlagen, auf denen ein anpassungsfähiges und damit zugängliches Web aufbaut, die WCAG schreiben *explizit* vor, dass HTML-Elemente für Formatierungen nichts im Markup zu suchen haben, zumindest bis Browser CSS-Layout unterstützen.

dass dazu sowieso eine Darstellung ganz ohne CSS möglich sein muss

Ja, ist sie auch - HTML garantiert das. Es wäre aber der falsche Schluss, die gewonnenen Erkenntnisse der CSS-Benutzung dafür zu benutzen, um wieder mit HTML Formatierungen vorzunehmen, weil man schließlich jedem die Formatierungen aufzwängen will, selbst wenn der Browser CSS nicht versteht.

und auch ist ein Minimalbestand an Tags vorteilhaft.

IMHO stehen für die meisten Anwendungen die nötigen Elemente zur Verfügung, darüber hinaus lassen sich viele Bedeutungen durch kreative Nutzung der vorhandenen erreichen; an der Darstellung hapert es nicht, alleinig is die Frage, ob ein passendes Markup dafür existiert.

Es ist m.E. nötig eine Gegenstrategie zu CSS zu forcieren, wenn HTML noch irgendwie universell funktionieren soll.

HTML funktioniert zweifelsohne universell, CSS ist eine Sylesprache, welche als *optionaler Zusatz* zu HTML dient (wie oft habe ich es schon in diesem Thread gesagt?). Im Bezug auf die Zugänglichkeit ist CSS schlichtweg nicht zwingend notwendig.

Wobei ich allerdings zuwenig Informationen über die reale Bedeutung der Barrierefreiheit habe, da kann ich mich natürlich bei meinen Vorstellungen oder Vermutungen wie eine Website von einer Software vorgelesen oder anders dargestellt wird irren.

Diese Zusatzsoftware wird ein strike-Element womöglich schlichtweg ignorieren. Ein del-Element würde entsprechend gekennzeichnet werden.

Und auch hier die Frage ob jeder Behinderte gleiche und aktuelle Software hat.

Die aktuellen Browser verstehen tatsächlich keinesfalls alle Zugänglichkeitsfeatures von HTML, aber dafür sieht die WCAG Übergangslösungen vor...
Es geht auch darum, dass man die größtmögliche Benutzbarkeit und Zugänglichkeit anstrebt, das heißt sich am Möglichen orientiert - wenn ein WCAG-Zugänglichkeitsfeature bei den meisten Browsern nur Unheil anrichtet oder andere wichtige Seitenaspekte dadurch unverhätnismäßig negativ beeinflusst werden, ist es logisch, dass auf diese spezielle Richtlinie verzichtet werden sollte.

Aber, W3C, der Widerspruch i.d. Praxis wenn W3C-Empfehlungen nicht umgesetzt werden können, weil eine Website für möglichst viele Browser zugänglich sein soll.

Naja, das Problem ist ausreichend bekannt, deshalb ist es momentan auch nicht möglich, ultrakorrektes XHTML zu schreiben und sich ausschließlich auf die neusten CSS-Layouttechniken zu verlassen.
Im Vergleich zur rudimentären Zugänglichkeit einer Seite ist jedoch eher wenig relevant, ob das Layout interoperabel zu einer exakt pixelgleichen Ausgabe führt.

Da kann man strike auch als W3C gut beibehalten, aber vielleicht verselbstständigt sich da bei denen irgendetwas, oder man bildet sich als Browserhersteller ein Umsatz bzw. Updates generieren zu müssen (ob die Browser was kosten ist in dem Zusammenhang gar nicht so wichtig).

Den Satz verstehe ich nicht ganz. :)
Momentan sind die meisten W3C-Standards abwärtskompatibel, das heißt, es geht nichts Wesentliches verloren, wenn ein Browser benutzt wird, welcher nur die Vorgängerversion unterstützt. Wohingegen man eine gewisses Gestaltung durchaus als wesentlich ansehen kann, aber völlig ungestylt muss eine Seite auch in alten Browsern nicht sein.

die Verwebung von Markup und Präsentationsanweisungen zum Selbstzweck,

Nein, sondern da wo eindeutiger einfacher sicherer geschrieben, korrigiert und gelesen werden kann, möglichst ohne speziellen Editor.

Siehe oben.

Da, wo es so unmittelbar in der Struktur naheliegt wie das auch bei Tabellen vorkommt.

Tabellen sind IMHO eine völlig andere Strukturebene, das wäre, als würdest du ol, ul oder h1 mit strike vergleichen...

Grüße,
Mathias

[molily]

Hallo, Cyx23,

gibt's eben CSS

da wir hier in diesem Thread über Barrierefreiheit oder gar Lynx als Maßstab posten, gibt es CSS womöglich nicht.

Das stellt darf keine Barriere darstellen, das Autorenstylesheet ist optional. Siehe WCAG 6.1: »Bauen Sie Dokumente so auf, dass sie ohne Stylesheets gelesen werden können. Z. B. wenn ein HTML- Dokument ohne ihm zugeordnete Stylesheets dargestellt wird, muss es immer noch möglich sein, das Dokument zu lesen. [Priorität 1]«.

Sowohl aus Sicht des effizienten Erstellens von Markierungen im Text

Eine Auszeichnung mit b, i und u ist sicher »schneller und dreckiger«, das schon, dennoch stehen diese Elemente allesamt auf der Abschussliste, meiner Meinung nach zurecht.

als auch aus Sicht der Barrierefreiheit ist CSS ab einem
bestimmten Punkt kontraproduktiv.

Wieso? Ich würde das Gegenteil behaupten.

Es gibt Auszeichnungen, z.B. strike, die so stark mit einem Text dicht am Inhalt verwoben sein können

Dann hat der Autor die Abstraktion von Dokumentstruktur und Wieder- bzw. Ausgabe des Dokuments mittels CSS unzureichend vorgenommen.

Wenn eine bestimmte Semantik zwischen der Formatierung (Unterstreichung) und der auszuzeichnenden Text besteht - und das ist meistens der Fall - lässt sich eine Klasse sehr einfach benutzen, beispielsweise:

<em class="kernbegriff">...</em>

dass die Darstellung per Span und Klassen eigentlich im Arbeitsablauf beim Erstellen des Dokumnents unpraktisch,

IMHO ist das Gegenteil der Fall, durch die Auslagerung der Styles lassen sich globale Änderungen vornehmen oder das Dokument mit anderen Styles komplett anders darstellen.

und später als Ergebnis auch weniger barrierefrei ist.

Das kann ich absolut nicht verstehen. Die Auszeichnung sollte im Idealfall natürlich nach der Bedeutung des Auszuzeichnenden verlaufen, das heißt eine Klasse, welche »unterstrichen« genannt wird, sollte nicht als <span class="unterstrichen">...</span> angewendet werden, weil dies dem Konzept von CSS widerspricht.

Oder erst durch andere Anforderungen an Software, ob nun Lesehilfen für Behinderte oder HTML-Editoren, komfortabel handhabbar.

Nein, wieso? Jedes Zusatzprogramm, ob es eine Bildschirmlupe, ein Screenreader oder eine Braillezeile ist, profitiert von semantischer Auszeichnung. Die einzige Möglichkeit wäre, dass der Browser die Styles nicht versteht; diesen Fall sollte der Autor jedoch einkalkulieren und oben genannte Richtlinie anwenden.

Den Hinweis auf HTML-Editoren verstehe ich nicht. Wie du argumentierst könnte man auch gegen Styles generell argumentieren. Sicher hat es ein Editor schwerer, wenn er die Formatierungen nicht zum Selbstzweck in das Dokument bringen darf sondern, wie Kai sagt, das Warum anstatt dem bloßen Wie berücksichtigt.

Damit entfernt sich HTML aber tendeziell von der freien, einfachen Anwendung.

Das stimmt tatsächlich, aber da das Stylesheet nur als optionaler Darstellungsvorschlag des Autors zu verstehen ist, macht es wenig Sinn, sich über die steigende Komplexität der Stylesprache Sorgen zu machen. Die Anwendung von CSS ist in jedem Fall mit Risiken und einem Mindestmaß an Komplexität und damit vielleicht einer möglichen indirekten Barriere verbunden - theoretisch, denn praktisch sehe ich meist nur Vorteile, für den Fall, dass die WCAG beachtet werden.
Im Übrigen wüsste ich nicht, wieso HTML *mit* den Präsentationselementen und -attributen einfacher wäre. Oder was meintest du mit »damit«?

Grüße,
Mathias

[Robert Bamler]

Hallo Sven,

Du weißt ja: Meine Seite ist angeblich häßlich - aber sie ist (wieder mal IMHO) ziemlich barrierefrei.

Vorab: Ich finde deine Seiten eigentlich gar nicht hässlich. Nur mein Opera (7 beta 2) zerschießt mir beim Scrollen irgendwie die linke Navigationsleiste, indem er zwei Linklisten "übereinanderschiebt", was ziemlich unübersichtlich wirkt.

Ich wollte aber eigentlich etwas ganz anderes sagen: Unter "Barrierefreiheit" verstehe ich, dass Webseiten für *alle* Besucher gut zugänglich sind (korrigiert mich bitte, wenn das nicht stimmt). Zu diesen *allen* Besuchern gehören IMHO auch die sog. "normalen" Besucher, also Besucher ohne körperliche Einschränkungen und mit modernen grafischen Textbrowern. Somit gehört für mich zu "Barrierefreiheit" unter anderem auch, dass Webseiten für "normale" Besucher gut zugänglich gemacht werden.

Mit "gut zugänglich" meine ich nun nicht nur, dass man irgendwie an die Inhalte herankommt, wenn man sich viel Mühe gibt. Unter "gut zugänglich" verstehe ich beispielsweise auch, dass man motiviert wird, die Inhalte aufzusuchen. Denn Besucher, die einfach keine Lust haben, die Inhalte zu suchen, werden diese auch nicht lesen (können). Der Inhalt ist also auf so einer Seite für "normale" Menschen nicht zu erreichen, weil die Menschen ihn nicht erreichen wollen. Eine hässliche Seite, wie du deine Seiten selbst genannt hast, also eine Seite mit schlechtem Design, kann also nach dieser Definition nicht barrierefrei sein, weil schlechtes Design nicht gerade motiviert und die Inhalte damit nicht gut zugänglich sind.

Deshalb finde ich, das "gutes Design" eigentlich gleichzusetzen ist mit "Barrierefreiheit", denn Design ist IMHO genau dann gut, wenn es den Zugang zu den Inhalten möglichst einfach macht. Und dieser einfache Zugang zu den Inhalten umfasst IMHO auch - aber nicht ausschließlich - die Ästhetik.

=> Also ist IMHO die Ästhetik einer Webseite auch ein Gesichtspunkt der Barrierefreiheit.

Damit ist der ständige Streit zwischen Design- und Usabilityfans eigentlich sinnlos, weil es sich um genau das gleiche handelt.

Jetzt hab' ich mal wieder viel philosophiert, aber hoffentlich versteht mich trotzdem jemand,
Robert

[Sven Rautenberg]

Moin!

Vorab: Ich finde deine Seiten eigentlich gar nicht hässlich. Nur mein Opera (7 beta 2) zerschießt mir beim Scrollen irgendwie die linke Navigationsleiste, indem er zwei Linklisten "übereinanderschiebt", was ziemlich unübersichtlich wirkt.

Das ist kein Browserfehler, sondern die unkonvetionelle Lösung zu einem Navigationsproblem: Erstens tritt das nur in der Abteilung "HTML-Editor Plugin" auf, und es war die einzige Lösung, die mir einfiel, um diverse Links zu externen Seiten links unterzubringen.

Die Navigation wird mit position:fixed festgehalten, nur wäre es unmöglich, diese Navigation zu hoch zu machen, weil dann auch mit scrollen niemand mehr an den Inhalt rankommen würde. Also hab' ich einen Extra-Block gemacht, der mitscrollt. Ist nicht unbedingt ideal, das weiß ich. Ich lege es unter "Experiment mit position:fixed" ab und werde es vielleicht wieder ändern.

Ich wollte aber eigentlich etwas ganz anderes sagen: Unter "Barrierefreiheit" verstehe ich, dass Webseiten für *alle* Besucher gut zugänglich sind (korrigiert mich bitte, wenn das nicht stimmt). Zu diesen *allen* Besuchern gehören IMHO auch die sog. "normalen" Besucher, also Besucher ohne körperliche Einschränkungen und mit modernen grafischen Textbrowern. Somit gehört für mich zu "Barrierefreiheit" unter anderem auch, dass Webseiten für "normale" Besucher gut zugänglich gemacht werden.

Ein guter Punkt. :)

Eine hässliche Seite, wie du deine Seiten selbst genannt hast, also eine Seite mit schlechtem Design, kann also nach dieser Definition nicht barrierefrei sein, weil schlechtes Design nicht gerade motiviert und die Inhalte damit nicht gut zugänglich sind.

Ich habe meine Seite selbst nicht häßlich genannt, das war nur ein Zitat aus einem anderen Thread über meine und andere Seiten. Ich finde meine Seite vollkommen in Ordnung. :)

Dann: Ob man eine Seite häßlich oder schön findet, sagt IMO noch nichts darüber aus, ob sie "schlecht designt" wurde. Als "Design" wird landläufig nur das Aussehen bezeichnet, und da gibt es in der Tat höchst unterschiedliche Seiten - welche, die wirklich toll aussehen (und dann leider ihre Navigation hinter einem einzelnen Pixel verstecken), welche mit ganz schrecklichem Aussehen (die es aber zumindest noch schaffen, vernünftige Beschriftungen auf die Menüpunkte zu packen), und natürlich alle Mischungen dazwischen und darüber hinaus.

Ich würde aber nicht sagen, dass schlechtes Design (vom Aussehen her) gleichbedeutend ist mit "nicht barrierefrei". Der Umkehrschluß (gutes Design == barrierefrei) gilt jedenfalls nicht.

Ok, wenn eine Seite _wirklich_ gut designt wurde, sieht sie gleichzeitig gut aus _und_ ist barrierefrei. Dann hat der Begriff "Design" aber eine größere Bedeutung - und nach diesem Begriff gibt es im Netz dann kaum gut designte Webseiten, weil entweder das Aussehen schlecht ist, oder die Barrierefreiheit, oder sogar beides.

Damit ist der ständige Streit zwischen Design- und Usabilityfans eigentlich sinnlos, weil es sich um genau das gleiche handelt.

So gesehen ja - es hängt eben davon ab, was man unter Design versteht.

- Sven Rautenberg

[Robert Bamler]

Hallo Sven,

So gesehen ja - es hängt eben davon ab, was man unter Design versteht.

Stimmt. Damit hast du den Hauptpunkt genannt, an den ich in meinem Posting gar nicht gedacht habe: Dass der Begriff "Design" gar keine klare Bedeutung hat, bzw. jeder etwas anderes darunter versteht.

Robert

[molily]

Hallo, Sven,

Ich würde aber nicht sagen, dass schlechtes Design (vom Aussehen her) gleichbedeutend ist mit "nicht barrierefrei". Der Umkehrschluß (gutes Design == barrierefrei) gilt jedenfalls nicht.

Mit Einschränkungen würde ich Robert zustimmen: ohne dass die Optik einer Seite durch eine klug gewählte Layoutkomposition die Struktur der Seite in adäquater Form visualisiert, ist eine Benutzbarkeit nicht möglich - selbst wenn die Seite selbst vom Stylesheet abgesehen den WCAG folgt und zugänglich ist.

Die visuelle Gestaltung des Interfaces ist, wie das Wort sagt, die Schnittstelle zwischen der Seite und dem Benutzer, deshalb trägt diese Gestaltung wesentlich dazu bei, ob sich der Besucher auf der Seite zurechtfindet, ob er die Struktur der Seite erkennt, beispielsweise indem die entscheidenden Layoutelemente durch ihre Position, durch Farbe etc. hervorgehoben sind, eine Hierarchie der Seite und des Dokuments deutlich wird, allgemein gesagt die Gestaltung die Semantik unterstützt beziehungsweise sogar ausmacht.

Diese Benutzbarkeitsaspekte stehen meiner Meinung nach in einem direkten Verhältnis zur äußeren Erscheinung der Seite, denn wenn die Bedienung der Seite nicht durch ein passendes intuitives und verständliches Interface ermöglicht wird, bringt der zugängliche weil semantikreiche Code mit viel Metainformation selbst nicht viel. Die Dokumentstruktur wird nur soweit sichtbar, wie es die visuelle Darstellung abzubilden vermag; Zusammenhänge, Nebenordnungen und die Semantik des Textes (Zitate, Anmerkungen, Fußnoten, Emphasen, Überschriften, Listen...) können nur über eine angemessene Darstellung kommuniziert werden. Der Benutzer fragt sich: wie bewege ich mich auf der Seite, was sind die Navigationselemente, wo befinde ich mich gerade, wo finde ich XYZ auf der Seite; dies kann nur verdeutlicht werden, indem die Seite den Benutzer anhand seines Aussehens beim Navigieren assistiert, das Aussehen ist dafür zwar nicht der einzige entscheidende Punkt, aber doch einer der wesentlichen.

Insofern würde ich Chräcker in dem Punkt zustimmen: »Denn nur wenn man eine Seite eben zweckentsprechend gestaltet (designt) wurde, kann sie nacher eben auch barrierefrei sein.« - »Zweckentsprechend« umschreibt genau den Punkt, den ich meine. (Ich unterstelle ich einfach einmal, dass er vor allem das Aussehen meinte.) Natürlich ist eine Seite mit ansprechender Optik nicht zwangsläufig zugänglich oder umgekehrt, darin stimme ich dir zu - wie Chräcker sagt, nur wenn sie passend gestaltet ist, kann sie dann (nachher) benutzbar/zugänglich sein. Oder konkret gesagt: Eine Hypertextseite ist ohne spezielle Styles nicht halb so benutzbar wie eine Seite mit ansprechender und passender Gestaltung.

(Irgendwer verbreitet ja ständig, »HTML-Puristen« u.ä. würden  dies verleugnen... das ist natürlich Blödsinn. Das Einzige, was man einsehen sollte, ist, dass Gestaltung ohne grundlegende Benutzbarkeit genauso töricht ist wie die Illusion von Benutzbarkeit ohne die dazu zwangsweise nötige darauf aufsetzende und diese wiedergebende Gestaltung.)

Insgesamt sind jegliche ästhetische Überlegungen meiner Auffassung nach zweifelsohne Teil der Barrierefreiheit beziehungweise die Barrierefreiheit umfasst diese.

Grüße,
Mathias

[Kai Lahmann]

hi

Mir stellt sich aber die Frage, ob die hohen Ansprüche des Artikels mit einem modernen (auch grafischen) Design vereinbar sind, oder ob die Erfüllung der Anforderungen nicht zwangsläufig zu einer optisch minimalistischen Seite führen muss.

nein. Man muss sich nur daran halten jedes ELement dafür zu nutzen, wozu es gedacht ist. So darf man eben nicht einen Text mittels Tabellen "zufällig" in einen Rahmen schieben, sondern der Rahmen muss direkt zu den Element gehören. Überhaupt sind Tabellen, die nicht dazu dienen tabellarische Informationen weiterzugeben das Grauen schlechthin und gerade für die Accessbility der Tod.

Mich würde einmal interessieren, ob es ein paar Beispielseiten gibt, die neben gutem optischen Design auch die Anforderungen an Barrierefreiheit erfüllen?

ich versuche bei allen linuxfaqs.de-Seiten diese Regeln zu erfüllen.

Grüße aus Bleckede

Kai

[Orlando]

Hi Axel,

http://aktuell.de.selfhtml.org/artikel/design/barrierefrei/index.htm#a1 Mir stellt sich aber die Frage, ob die hohen Ansprüche des Artikels mit einem modernen (auch grafischen) Design vereinbar sind, oder ob die Erfüllung der Anforderungen nicht zwangsläufig zu einer optisch minimalistischen Seite führen muss.

Nein, nicht unbedingt, warum sollte das der Fall sein? Auf diese pauschale Frage kann ich eigentlich nur mit 'kein Problem' antworten.

Mich würde einmal interessieren, ob es ein paar Beispielseiten gibt, die neben gutem optischen Design auch die Anforderungen an Barrierefreiheit erfüllen?

Ich weiß nicht, was du unter 'gutem optischen Design' verstehst, aber es könnte helfen, sich mal die 'potthässlichen Seiten von HTML-Gurus' anzusehen... ;)

LG Roland

[Chräcker Heller]

Hallo,

soll eine Seite (möglichst) Barrierefrei sein (vollkommen kann sie es nie sein, für viele stellt der Einsatz eines Computers schon eine Barriere dar, frag mal meine Herrschaften aus meiner Seniorenarbeit....), also: soll eine Seite Barrierefrei sein, dann gehört ein gutes Design dazu. Denn nur wenn man eine Seite eben zweckentsprechend gestaltet (designt) wurde, kann sie nacher eben auch barrierefrei sein. (Wenn das eine der gestellten Anforderungen war).

Design hat nichts mit (reduzierung auf ) "gefälligem Aussehen" oder "grafischen verkleisterungen" zu tun und Design ist kein Gegensatz zu "strukturiertem html" oder "funktionalität". Funktionalität ist ein Bestandteil von gutem Design.

Nun aber zu Deiner Frage: ich glaube ("glaube" in Abgrenzung zu "wissen"), daß barrierefreies Design sich nicht zwingend einem grafischen (html-css-technik-)Minimalismus unterwefen muß. Selber habe ich aber noch keine barrierefreie Seite (bewust) kennengelernt, die nicht gleichzeitig eine hypertext-css-Tristese verströmte. (Was an sich noch keine Wertung zur Qualität des diesbezüglichen Designs sein soll!!!!) - und, ich gebe es zu, ich selber habe mich bisher mit der Problematik noch nicht intensiv beschäftigt sondern rette mich in meine Nischenprodukte.  (Nicht jedes Angebot in unserem Kulturbereich muß barrierefrei sein.)

Es wäre aber sicherlich mal eine spannende Aufgabe, eine möglichst weitgehende Barrierefreiheit in einem optisch anspruchsvollerem Projekt umzusetzen..... (und sicherlich  wichtig, ich gebe es zu....) - wenn die Vorsatzliste zum nächsten Jahr nur nicht schon so voll wären ;-)))

Chräcker

[Sebastian Burkhart]

Moin,

Mich würde einmal interessieren, ob es ein paar Beispielseiten gibt, die neben gutem optischen Design auch die Anforderungen an Barrierefreiheit erfüllen?

Ich glaube, wired ist ein schoenes Beispiel dafuer. Ich weiss nicht, inwieweit die Seite nun Accessibility-Standards entspricht, aber meines Wissens arbeitet die inzwischen mit einer kompletten Trennung zwischen Dokument und Ansicht per validem XHTML/CSS und sollte von daher recht barrierefrei sein.

(Siehe auch: http://www.wired.com/news/culture/0,1284,55675,00.html)

Gruss
Sebastian

[Chräcker Heller]

Hallo,

mit einer kompletten Trennung zwischen Dokument und Ansicht per
validem XHTML/CSS und sollte von daher recht barrierefrei sein.

...für Maschinen vielleicht, für Menschen mit normalen Browsern und Augen und Sehvermögen empfinde ich sie als äuserst Barierenlastig. Ich hab kaum Ahnung, wo ich überhaubt klicken muß um "was?" zu bekommen.

Eine saubere Trennung von Struktur und Layout ist erst einmal nur für Maschinen nett. (und solche Surfer, die schon wie Maschinen denken und deren Ästetikempfinden, und damit die Aufnahmefähigkeit, darauf konditioniert ist...) und ergibt nicht zwangsläufig eine gute, geschweige denn eine Barierenfreie Seite...... (außer eben vielleicht für Maschinen und Menschen, die auf Maschinen angewiesen sind. Aber eine unbersichtliche Navigatios-Seitestruktur bleibt auch bei einer sauberen "Trennung von..etc etc" unsauber

Chräcker

[Sebastian Burkhart]

Moin,

mit einer kompletten Trennung zwischen Dokument und Ansicht per
validem XHTML/CSS und sollte von daher recht barrierefrei sein.

...für Maschinen vielleicht, für Menschen mit normalen Browsern und Augen und Sehvermögen empfinde ich sie als äuserst Barierenlastig. Ich hab kaum Ahnung, wo ich überhaubt klicken muß um "was?" zu bekommen.

Naja, der Mensch sitzt ja an einer Maschine, seinem Client, der das Dokument fuer ihn parst. Und der Standard-Look der Seite, der wohl eher auf eine technikorientierte Zielgruppe ausgerichtet ist, laesst sich dank der Dokument/Ansicht problemlos mit eigenen Stylesheets ausstatten etc, sodass selbst Blinde/Sehbehinderte etc. die Seite komplett betrachten koennen. Oder hab ich das Wort Barrierefreiheit jetzt falsch verstanden?

Gruss
Sebastian

[Chräcker Heller]

Hallo,

Naja, der Mensch sitzt ja an einer Maschine, seinem Client, der das
Dokument fuer ihn parst.

aber nur das, was auch "da" ist....

Und der Standard-Look der Seite, der wohl eher auf eine
technikorientierte Zielgruppe ausgerichtet ist, laesst sich dank
der Dokument/Ansicht problemlos mit eigenen Stylesheets ausstatten

Problemlos? Problemlos wirklich nur bei Leuten, die eben eh zu der technikorientierten Zielgruppe gehören. Alle anderen müssen das nehmen, was sie geliefert bekommen.

Oder hab ich das Wort Barrierefreiheit jetzt falsch verstanden?

Barrierefreiheit heist für den Menschen, egal wie weit behindert (also auch für mich), daß der Gehalt der Seiten möglichst barrierefrei (sprich: hindernisfrei) in sein Hirn kommt, und zwar in den Bereich, der versteht. Dazu braucht es mehr als eine Anpassung an eine Maschine. "Was vorher nicht drin ist in einer Seite, kann auch ein Stylesheet nicht retten" - oder anders ausgedrückt: eine schlecht aufnehmbare Seite bleibt auch eine schlecht aufnehmbare Seite, wenn man sie sich vorlesen lassen kann. (kommen nur mehr Blinde in den Genuß der schlecht aufnehmbaren Seite ;-))

Chräcker