„Anfahrtsplan“ ist ein wichtiger Alternativtext, wenn nämlich der Sehbehinderte eben diesen beispielsweise jemandem schicken will, der da hin fährt. Da ist es wichtig, dass er weiß, dass es da einen Plan gibt …

Ja gut, das ist ein Argument.

Alternativtexte sind nicht semantisch, das IMG-Element ist es (und sollte nie abgeschafft werden, wo hast du das her?)

In irgendeinem der nächsten (und hoffentlich nie kommenden) XHTML-Standards sollten Bilder nur noch via OBJECT eingebunden werden. – Die "display: table-*"-Styles waren u.a. dafür gedacht, um mit XML Tabellen darstellen zu können (da dort TABLE/TR/TD-Tags keine spezielle Bedeutung oder Funktion haben). Unter HTML braucht man diese Styles eigentlich nur, um Tabellenlayouts ohne Tabellen zu bauen.

Wohlgemerkt: erstmal nur worum es geht, nicht wie es geht

Das sollte immer vorne an stehen.

Es schadet sicher nicht, sich mal intensiv mit BITV auseinanderzusetzten und konsequent validen und semantischen Code zu schreiben. Wichtiger ist jedoch, sich vorstellzustellen, wo die Schwierigkeiten liegen können. Keiner wird dabei auf jede Einschränkung eingehen oder geschweige denn nachvollziehen können. Und es wird immer Lösungen geben, die die eine oder andere Einschränkung nicht berücksichtigen können.

Schlimmstenfalls wird die Abkürzung markiert und im WYSIWYG-Editor die Beschreibung eingetippt, bestenfalls gibt es eben eine Ersetzungstabelle mit häufig vorkommenden Wörtern, die dann automatisch ersetzt werden.

Es heißt ja auch: What you see is what you get. Das was ich nicht sehe sind die Sprachauszeichnungen und was ich unter Zeitdruck oder Faulheit gerne übersehen wird, die Abkürzungen.

Da gibt es technisch noch Nachholbedarf. In Anbetracht des Umfangs, also der vielen Sprachen mit nochmehr Abkürzungen, ist da eine klientseitige Lösung gefragt, zum Beispiel als Browserplugin auf Basis der Betriebsysteme.

Das muss doch eine Herausvorderung für Linguisten sein, oder? Währe sogar eine rudimentäre Prüfung auf einfache Sprache möglich?

Stylesheets wie "display: table", "display: table-cell" usw. sind schon Vorerscheinungen, wohin die Reise noch gegangen wäre: zur Abschaffung von Tabellen. Ironischerweise steht/stand ja sogar das IMG-Tag auf der Abschussliste. Am Ende hätten wir semantisch toten Code geschrieben.

Ich finde display: table-cell gut, und eine Abschaffung vom IMG würde mich nicht stören, wenn OBJECT korrekt unterstützt wird. Dann kann ich auch endlich längere alternive Texte mit HTML schreiben. Doch ich sehe auch, dass es nicht alle so verstehen werden, wie es gedacht ist. Es beunruhigt mich aber nicht.

Beunruhigender finde ich den oft sorglosen Umgang mit Javascript und AJAX. Hier werden echte Barrieren aufgebaut. Vor dem
AJAX-Hype war Javascript schon etwas anrüchig geworden, was ich garnicht mal so schlecht fand. So wurde es von einer spürbaren Menge nicht eingeschränkter Nutzern abgeschaltet – die Entwickler mussten sich auf Fallbacklösungen verlassen.

Kleine Anmerkung zu den erlaubten Tags in dieser Eingabe: es fehlt mit SPAN für Sprachauszeichnungen und die Eingabe von zwei Attributen in ACRONYM produziert Fehler. Es gibt also noch viel zu programmieren. Wenn wir das fertig haben, können wir weiter diskutieren

Oka, dann halt nicht.

Und selbst darüber kann man streiten. Ich gehe mehr und mehr dazu über, in Bildern möglichst nur noch leere ALT-Attribute einzusetzen. Was nützt es einem Blinden, wenn sein Browser auf ein IMG-Tag stößt und ihm den Text "Unser Firmenlogo", "Foto von unserem Team", "Anfahrtsplan", "Unsere Produktionshalle", "Kursdiagramm unserer Aktien" oder "Mallorca bei Nacht" vorliest? Welchen Informationswert hat das?

„Unser Firmenlogo“ wäre natürlich der Text (Firmenname) auf dem Logo, sofern es nicht eh in der Nähe vorkommt und deshalb logisch erschließbar ist. „Anfahrtsplan“ ist ein wichtiger Alternativtext, wenn nämlich der Sehbehinderte eben diesen beispielsweise jemandem schicken will, der da hin fährt. Da ist es wichtig, dass er weiß, dass es da einen Plan gibt (das selbe gilt für das Kursdiagramm). Das „unsere“ ergibt sich meist daraus, dass es auf „unserer“ Seite ist.

Wenn ein Sehender durch Ansehen des Bildes „Mallorca bei Nacht“ erkennen kann, dann ist das der richtige Alternativtext. Ansonsten ist es viel mehr ein „Strand bei Nacht“.

Der Informationswert ist, dass sich der Sehbehinderte auch ein Bild vom Feeling der Seite machen kann. Bilder vermitteln Stimmung, nur weil jemand nicht sehen kann muss er sich nicht in einer sterilen Online-Welt bewegen.

Mehr noch: viele Grafiken setze ich noch nicht mal mehr mittels IMG-Tag, sondern nur noch als Hintergrundgrafik in einen leeren DIV-Container. Dann kann ich ganz sicher sein, dass kein Screenrader oder Textbrowser auch nur versucht, den Nutzer auf eine für ihn völlig nutzlose Information hinzuweisen – und damit seine Zeit verplempert. Mit dieser Klappe schlage ich auch gleich zwei weitere Fliegen: manche Handy-Browser laden Hintergrundbilder erst gar nicht und die Druckfunktion der meisten Browser druckt Hintergrundbilder nicht mit – das spart Ladezeit bzw. Tinte und wieder – Zeit

Das heißt, dass die Bilder keinerlei Relevanz für den Inhalt der Seite haben und ausschließlich zu Dekozwecken da sind? Dann ist das völlig korrekt.

Wenn in den Seiten merkwürdige Viertelkreise (=verwaiste runde Ecken irgendwelcher Container), falsch plazierte Avatare, Schatten, Verläufe und anderer Krimskrams herumfliegen – raus damit.

Richtig, solche rein dekorativen Grafiken haben im HTML nix zu suchen.

ALT-Attribute haben m.E. nur dort wirklich Sinn, wo ausgerechnet Blinde sich kaum aufhalten dürften: in Bildergalerien. Da sorgt ein das Bild treffend beschreibender Alternativtext dafür, dass das Bild in Googles Bildersuche gefunden wird – auch das bringt Besucher. (Ein weiteres Einsatzgebiet sind selbstredend grafische Links).

Es gibt sogar Blinde, die Bilder für sich oder andere im Internet kaufen. Klingt sicher total abwegig, aber es ist wahr.

Das liegt m.E. daran, dass sich die Standards verschiedener Bereiche z.T. widersprechen. Einerseits sollen ALT-Texte (also semantischer Code) gesetzt werden, andererseits schaffte HTML 4 schon vor Jahren z.B. das MENU-Tag ab, was für semantisch eindeutige Auszeichnung von Navigationsmenüs sehr schön gewesen wäre. Stylesheets wie "display: table", "display: table-cell" usw. sind schon Vorerscheinungen, wohin die Reise noch gegangen wäre: zur Abschaffung von Tabellen. Ironischerweise steht/stand ja sogar das IMG-Tag auf der Abschussliste. Am Ende hätten wir semantisch toten Code geschrieben.

Wooohooo. Stop. Also: Alternativtexte sind nicht semantisch, das IMG-Element ist es (und sollte nie abgeschafft werden, wo hast du das her?), das MENU-Element, das die selbe Möglichkeiten hat wie Listen ist in HTML4.01/Trans noch enthalten und kann benutzt werden, allerdings hat es nie eine Browserunterstützung gegeben. HTML5 bekommt das neue NAV-Element, das viel vielseitiger ist, so kann man beispielsweise darin nicht nur Listen benutzen.

Zur Abschaffung von Tabellen wäre es nie gekommen, da das Inhaltsinformationen sind. Im Gegenteil. Moderne Browser benutzen diese CSS-Attribute um ihre Tabellen zu rendern und du kannst Tabellen auch ganz anders darstellen. Nicht Tabellen werden abgeschafft, man ist dank dieser Definitionen für die Darstellungen viel flexibler als vorher.

Ich halte das für eine fatale Fehlentwicklung.

Die es nie gab und nicht gibt.

Und dazu braucht es einen glasklaren HTML-Standard.

Richtig. Aber an dem fehlt es. Die HTML4-Spezifikation ist teilweise so schwammig, das macht echt keinen Spaß.

Letzteres wird nämlich oft vergessen – denn es scheitert auch die beste Vorarbeit, wenn die Anwender mit schlampig programmierten, UTF8-unfähigen Uraltbrowsern herumsurfen, sich mit ihrem Browser nicht beschäftigen (z.B. wie man Schrift vergrößert oder im Opera Überschriften anspringt usw.) und ihn nicht so konfigurieren, dass sie damit bestmöglich durchs Web kommen.

Auch schlampig programmierte Uraltbrowser können HTML4, UTF8 ist auch schon länger kein Problem mehr. Ein Benutzer, der noch mit NN4 oder IE4 herumsurft wird nur kaputte Seiten kennen. Natürlich hat das seine Grenzen. Es ist trotzdem nicht unsere Aufgabe alle möglichen Szenarien abzudecken. Das wird auch von niemandem gefordert. Es ist Nutzern zuzumuten, dass sie einen relativ modernen Browser benutzen.

Wer nicht standardmäßig Alternativtexte für Bilder einbaut (und das ist echt kein Hardcore-Aufwand), der handelt auch nicht Standardkonform.

Und selbst darüber kann man streiten. Ich gehe mehr und mehr dazu über, in Bildern möglichst nur noch leere ALT-Attribute einzusetzen. Was nützt es einem Blinden, wenn sein Browser auf ein IMG-Tag stößt und ihm den Text "Unser Firmenlogo", "Foto von unserem Team", "Anfahrtsplan", "Unsere Produktionshalle", "Kursdiagramm unserer Aktien" oder "Mallorca bei Nacht" vorliest? Welchen Informationswert hat das?

Mehr noch: viele Grafiken setze ich noch nicht mal mehr mittels IMG-Tag, sondern nur noch als Hintergrundgrafik in einen leeren DIV-Container. Dann kann ich ganz sicher sein, dass kein Screenrader oder Textbrowser auch nur versucht, den Nutzer auf eine für ihn völlig nutzlose Information hinzuweisen – und damit seine Zeit verplempert. Mit dieser Klappe schlage ich auch gleich zwei weitere Fliegen: manche Handy-Browser laden Hintergrundbilder erst gar nicht und die Druckfunktion der meisten Browser druckt Hintergrundbilder nicht mit – das spart Ladezeit bzw. Tinte und wieder – Zeit. (Ich weiß, dass das auch bzw. besser mit @media-Blöcken in den Stylesheets geht. Mir geht es aber darum, dass die Bedeutung eines HTML-Elementes bereits im HTML-Code deutlich wird und nicht erst in den Stylesheets – dies ist auch überhaupt nicht die Aufgabe von Stylesheets, und "display: none" sagt auch nichts über die Bedeutung des versteckten Elementes aus. Ein leeres DIV-Tag bzw. ein nicht vorhandenes IMG-Tag hingegen schon.)

Auf diese "Schiene" bin ich gekommen, seit ich meine Seiten auch immer mit abgeschalteten Stylesheets anschaue. Wenn in den Seiten merkwürdige Viertelkreise (=verwaiste runde Ecken irgendwelcher Container), falsch plazierte Avatare, Schatten, Verläufe und anderer Krimskrams herumfliegen – raus damit. Es bleibt nur ein einziges IMG-Tag drin: das mit dem Firmenlogo – wenigstens das soll immer angezeigt und auch mitgedruckt werden.

ALT-Attribute haben m.E. nur dort wirklich Sinn, wo ausgerechnet Blinde sich kaum aufhalten dürften: in Bildergalerien. Da sorgt ein das Bild treffend beschreibender Alternativtext dafür, dass das Bild in Googles Bildersuche gefunden wird – auch das bringt Besucher. (Ein weiteres Einsatzgebiet sind selbstredend grafische Links).

Fazit: Das Ansinnen, allen alles zugänglich zu machen, macht es am Ende allen nur ein bisschen schwerer.

Und im übrigen meine ich, dass Lothar nicht ganz unrecht hat, wenn er sagt, dass die Standards – so vorhanden – nicht immer praktisch umsetzbar sind. Das liegt m.E. daran, dass sich die Standards verschiedener Bereiche z.T. widersprechen. Einerseits sollen ALT-Texte (also semantischer Code) gesetzt werden, andererseits schaffte HTML 4 schon vor Jahren z.B. das MENU-Tag ab, was für semantisch eindeutige Auszeichnung von Navigationsmenüs sehr schön gewesen wäre. Stylesheets wie "display: table", "display: table-cell" usw. sind schon Vorerscheinungen, wohin die Reise noch gegangen wäre: zur Abschaffung von Tabellen. Ironischerweise steht/stand ja sogar das IMG-Tag auf der Abschussliste. Am Ende hätten wir semantisch toten Code geschrieben.

Ich halte das für eine fatale Fehlentwicklung. Webseiten-Code muss – ohne Missbrauch von CSS zur Bedeutungsvermittlung – semantisch glasklar sein – genauer gesagt: eindeutig maschinenlesbar. Denn es sollte die Maschine sein, die den Seitencode interpretiert und die dabei gewonnenen Informationen dem Anwender so präsentiert, wie es seinen Bedürfnissen entspricht. Dazu müssen die Browser in der Lage sein, glasklaren Code auch in glasklare Informationen umzusetzen. Und dazu braucht es einen glasklaren HTML-Standard. Und daran müssen nicht nur wir uns halten, und auch nicht nur die Browserhersteller, sondern auch die Anwender. Letzteres wird nämlich oft vergessen – denn es scheitert auch die beste Vorarbeit, wenn die Anwender mit schlampig programmierten, UTF8-unfähigen Uraltbrowsern herumsurfen, sich mit ihrem Browser nicht beschäftigen (z.B. wie man Schrift vergrößert oder im Opera Überschriften anspringt usw.) und ihn nicht so konfigurieren, dass sie damit bestmöglich durchs Web kommen. Das ganze Spiel kann nur funktionieren, wenn alle Beteiligten sich am Riemen reißen.

André

den Tidy würde ich grundsätzlich immer so an der Kunde nur das notwendigste an Möglichkeiten hat. Kunden sind ja in der Not erfinderisch, aber oft ist es reine Gedankenlosigkeit. Oder der Kunde weiß es einfach nicht besser.
Ich würde dem Kunden einen kleinen Styleguide mitgeben. Wann setzt er wo welche Überschrift, wie zeichnet er eine Abkürzung aus. (Vorrausgesetzt das CMS macht das nicht automatisch, mittels Plugin oder Modul)

Der Kunde wird dir dankbar sein, wenn Du ihm mit dem WYSIWYG-Editor nicht alleine lässt.

Den Styleguide erstellst Du einmal. Macht zwar am Anfang ein wenig mehr Arbeit, aber dafür kannst du den Stylguide immer wieder verwenden. Höchstens hin und wieder ein paar Anpassungen musst die vielleicht vornehmen.