Webkrauts Logo

Webkrauts Webkrauts Schriftzug

- für mehr Qualität im Web

Definiere: Barrierefreiheit

Wir haben noch nicht alle älteren Artikel nachbearbeitet. Das bezieht sich in der Regel nur auf die Codebeispiele, die noch nicht optimal dargestellt werden.

Definiere: Barrierefreiheit

Über den Begriff Barrierefreiheit lassen sich stundenlange Diskussionen führen. Diskussionen, die schnell auch die Bereiche Usability, Zugänglichkeit, Design und Content-Management-Systeme streifen. Und manchmal stellt man fest, dass man zunächst mal die Barrierefreiheit klar definieren sollte, bevor alles durcheinander geht. Ein Kommentar von Tomas Caspers.

In letzter Zeit gab es in Klein-Bloggersdorf wieder reichlich Diskussionen die zeigen, dass wir noch einen langen Weg vor uns haben. Nicht nur bis das Netz wirklich von allen Menschen genutzt werden kann, sondern auch bis Anbieter und insbesondere Web-Designer verstanden haben, worum es geht.

Wohlgemerkt: erstmal nur worum es geht, nicht wie es geht – so weit sind wir augenscheinlich noch nicht. Dass auch im Jahre 2008 immer noch um die Definition des Begriffs ›Barrierefrei‹ gestritten wird – das hat mich schon einigermaßen erstaunt.

Manchmal hilft da auch die Sicht von aussen: nach der EfA-Tagung in Gelsenkirchen saßen ein paar Webkrauts noch mit Teilnehmern aus der Schweiz, Österreich und England zusammen, die sich erstaunt über den Stand der Diskussion um Webstandards & Accessibility in Deutschland äusserten. In Großbritannien hätte man sich, so die Meinung aller, fünf oder zehn Minuten über die Notwendigkeit unterhalten und sich danach an die praktische Umsetzung gemacht.

Warum sind wir also in Deutschland immer noch auf einem Stand, wo auch in vielgelesenen Blogs derartige Mißverständnisse und Unwissen offenbart werden? Ich weiss es auch nicht.

Also versuche ich es nochmal mit einer Definition, vielleicht hilft das bei der Auflösung mancher Verwirrungen:

Websites sind dann barrierefrei, wenn sie von Menschen mit Behinderung genau so effektiv und effizient genutzt werden können wie von Menschen ohne Behinderung. Punkt.

  • Das heisst nicht, dass ein blinder Screenreader-Nutzer z.B. Dinge in einer Web-basierten Applikation in der exakt gleichen Zeit erledigt wie ein sehender Nutzer. Das Vorlesen und das Zurechtfinden in einer komplexen Seite dauert unter Umständen länger, selbst wenn die Sprachausgabe auf sehr schnell gestellt ist.
  • Das heisst auch nicht, dass sich ein sehbehinderter Nutzer bei 16-facher Vergrößerung genau so schnell auf einer Seite orientieren kann wie ein übersichtiger Nutzer, der die Schrift an seinem 30"-Monitor mit 160 ppi auf 10 pt gestellt hat. Aber es darf dem sehbehinderten Nutzer eben auch nicht unnötig schwer gemacht werden.
  • Das heisst auch nicht, das ein Nutzer mit Lese-/Rechtschreibschwäche oder ein Gehörloser Geschriebenes in der gleichen Zeit aufnimmt wie ein Germanistik-Professor.

Das heisst nur, dass den Nutzern keine unnötigen Steine in den Weg gelegt werden. Es darf eben nicht signifikant länger dauern oder gar unmöglich sein, sonst stimmt irgendwas nicht. Das heisst auch, dass seitens des Anbieters (wo nötig) unterstützend eingegriffen wird, sodaß das Ergebnis der Nutzung für alle Besucher vergleichbar ist. Nota bene: nicht der eigentliche Ablauf, sondern nur das Ergebnis.

Wie kann man nun mit dieser Definition einem Web-Entwickler erklären was zu tun ist, um z.B. die Forderungen der BITV zu erfüllen?

Garnicht.

Es kann keine pauschalen und einfachen Handlungsanweisungen auf die Frage geben (um einem der geäusserten Kritikpunkte zu begegnen), sondern es gilt wie so oft: es kommt darauf an.

So, können wir uns jetzt bitte endlich mal um die praktische Umsetzung kümmern? Danke für's Zuhören.

Ein Kommentar von Tomas Caspers

Kommentare

Dirk Ginader

Dirk Ginader (Webkraut)
am 30.06.2008 - 15:52

eine Wonne endlich mal wieder jemanden eine klar definierte einfache und verständliche Aussage über Barrierefreiheit machen zu sehen - Danke Tomas :-)

Permanenter Link

Lothar Baier
am 30.06.2008 - 19:00

Genau solche Definitionen wie oben sind es, die dazu führen, das viel diskutiert wird und wenig gemacht. Weil das, was oben in der Definition steht, schlichtweg nicht geht. Punkt.

Nicht geht, weil es jede Menge Behinderungen gibt, die diametral entgegengesetzte Anforderungen an eine Technik stellen. Einer, dem beide Beine amputiert wurden, wird vielleicht trotzdem ein entsprechend ausgerüstetes Auto fahren können, aber niemals das gleiche wie einer, dem beide Arme amputiert wurden.

Es gibt Sehbehinderte, die können nur bei extrem hohen Kontrasten überhaupt noch was lesen. Und es gibt andere, deren größte Barriere genau dieser hohe Kontrast ist. Und so fort, es gebe viele Beispiele.

Und deshalb sollten die Dogmatiker der Barrierefrei-Szene endlich mal aufhören, unerfüllbare Forderungen zu stellen, dann könnte man nämlich das tun, was machbar und sinnvoll ist.

Es ist nicht sinnvoll, dass der ganz überwiegende Teil der Menschheit, der nicht behindert ist, auf jede Menge nützliche und praktische Errungenschaften des Internets verzichtet, nur weil nicht alle Browser-Hersteller es schaffen, diese Technik in ihren Browsern behindertengerecht zu implementieren. Dann muss man halt einfach den Browser wechseln.

Und es ist auch nicht sinnvoll, dass jede Website einen Style-Switcher anbietet, damit man die Schriftgröße anpassen kann. Weil ich das dann nämlich auf jeder neuen Website wieder tun muss. Sinnvoller wäre es, die entsprechende Funktion des Browsers zu nutzen. Und wenn ich das nicht kann, dann muss ich als Behinderter was lernen, nicht der Webdesigner.

Ich jedenfalls möchte nicht auf gut gestaltete Websites verzichten, nur weil der Farbkontrast für einige Wenige nicht ausreicht. Dafür gibt es User-Stylesheets, da kann man das anpassen. Ich möchte keine flachen Texte mit drei-Wort-Sätzen lesen müssen, nur weil einige kognitiv Behinderte den Inhalt sonst nicht verstehen können. Vielleicht war der Inhalt ja auch gar nicht für sie gedacht.

Kein Mensch jedenfalls käme auf die Idee, von der Auto-Industrie zu verlangen, dass alle Fahrzeuge so gebaut sein müssen, dass auch ein Amputierter sie ohne Umbau fahren kann. Und niemand würde einem Buchverlag verbieten, Goethe oder Schiller zu publizieren, weil die Sprache für einige Behinderte nicht verständlich ist. Nur bei Websites kommen manche Menschen auf die Idee, dass sie so beschaffen sein müssen, dass sie ein Jeder benutzen kann.

Dogmatismus hilft niemandem, auch nicht Behinderten.

Permanenter Link
Nils Pooker

Nils Pooker (Webkraut)
am 30.06.2008 - 19:45

@ Lothar:

Und deshalb sollten die Dogmatiker der Barrierefrei-Szene endlich mal aufhören, unerfüllbare Forderungen zu stellen, dann könnte man nämlich das tun, was machbar und sinnvoll ist.

Sind die "Dogmatiker" schuld daran, dass es sowenig barrierefreie Webseiten gibt oder so viele Webdesigner, die nicht wissen, worum es geht?

Es ist nicht sinnvoll, dass der ganz überwiegende Teil der Menschheit, der nicht behindert ist, auf jede Menge nützliche und praktische Errungenschaften des Internets verzichtet, nur weil nicht alle Browser-Hersteller es schaffen, diese Technik in ihren Browsern behindertengerecht zu implementieren.

Wo steht, dass Nutzer barrierefreie Webseiten auf jede Menge nützliche und praktische Errungenschaften des Internets verzichten sollen oder müssen?

Dann muss man halt einfach den Browser wechseln.

Willkommen im Glücksbärchi-Land.

Und es ist auch nicht sinnvoll, dass jede Website einen Style-Switcher anbietet, damit man die Schriftgröße anpassen kann. Weil ich das dann nämlich auf jeder neuen Website wieder tun muss. Sinnvoller wäre es, die entsprechende Funktion des Browsers zu nutzen.

Style-Switcher sind kein Merkmal von barrierefreien Webseiten, eher ein visuelles Hilfsmittel für Nutzer, die garnicht wiessen, wie man die Schriftgröße über den Browser verändern kann – weil sie eben nicht behindert sind.

Und wenn ich das nicht kann, dann muss ich als Behinderter was lernen, nicht der Webdesigner.

Das weiß der Behinderte, sofern der Webdesigner darauf geachtet hat, dass z. B. das Layout mit der Schriftgröße sinnvoll skaliert.

Ich jedenfalls möchte nicht auf gut gestaltete Websites verzichten, nur weil der Farbkontrast für einige Wenige nicht ausreicht. Dafür gibt es User-Stylesheets, da kann man das anpassen.

Das ist im Einzelfall zu prüfen und kommt immer darauf an (auf das konkrete Projekt nämlich)

Ich möchte keine flachen Texte mit drei-Wort-Sätzen lesen müssen, nur weil einige kognitiv Behinderte den Inhalt sonst nicht verstehen können.

Wo hast Du Internetseiten mit drei-Wort-Sätzen gefunden?

Kein Mensch jedenfalls käme auf die Idee, von der Auto-Industrie zu verlangen, dass alle Fahrzeuge so gebaut sein müssen, dass auch ein Amputierter sie ohne Umbau fahren kann.

Ein Auto wird auch nur von ein bis zwei Menschen genutzt, nicht von allen.

Und niemand würde einem Buchverlag verbieten, Goethe oder Schiller zu publizieren, weil die Sprache für einige Behinderte nicht verständlich ist.

Korrekt. Niemand würde aber einem Verlag verbieten, Goethe und Schiller in einfacher Sprache zu publizieren. Gibt es auch schon.

Permanenter Link

Sebastian Verweyen
am 30.06.2008 - 21:26

Klasse Artikel. Vielleicht hilft der mir unseren Verkäufern die Argumentation vorm Kunden zu erleichtern. Wie oft ich schon endlose Diskussionen führen musste, dass man Barrierefreiheit nicht allgemein gültig definieren kann. Ein Chef gibt sich mit solchen Aussagen nur leider nie zufrieden.

Gruß,

Sebastian

Permanenter Link

Lothar Baier
am 30.06.2008 - 22:55

@Nils:
Ich fürchte, die Essenz meines Kommentars ist nicht angekommen, deshalb nochmals kürzer und deutlicher:

Es sind genau solche Definitionen wie die oben von Thomas, warum über die WCAG 2.0 seit nunmehr zehn Jahren diskutiert wird, ohne dass es einen endgültigen Standard gibt, geschweige denn eine Implementierung. Und sie sind auch der Grund dafür, das man inzwischen ein dickes Buch mit Erklärungen braucht (das die Workinggroup freundlicherweise mitliefert), um den Entwurf überhaupt noch zu verstehen.

Bei den ganzen Diskussionen um Barrierefreiheit geht es schon lange nicht mehr um die Behinderten. Es geht um Profit, Macht und Selbstbeweihräucherung.

Wenn die Standardistas und Accessibility-Gurus mal die Augen aufmachen würden, dann würden sie feststellen, das die Barrierefreiheit nicht an den ungebildeten Webdesignern scheitert, sondern an den inzwischen unerfüllbaren Forderungen und Standards. In der Szene wird viel diskutiert, in den USA noch mehr als hier. Und die ganz überwiegende Mehrheit der Webdesigner hat sich eindeutig geäußert: Gebt uns Standards und Richtlinien, die sich umsetzen lassen, und wir sind gerne dabei. Aber wenn ihr so weitermacht, dann haben wir einfach keinen Bock mehr darauf und machen unseren Job so, wie wir es für richtig halten.

Und das wird sich auch solange nicht ändern, wie man mit Browser-Kriegen und Barrierefrei-Etiketten viel Geld verdienen kann.

Oder, um es noch kürzer zu sagen: Gerade weil es solche Standards und Gremien für deren Schaffung gibt, gibt es so wenige barrierearme Webseiten. Und nochmals: Barrierefrei gibt es nicht, weil weder medizinisch noch technisch möglich. Punkt.

Permanenter Link
Tomas Caspers

Tomas Caspers (Autor)
am 30.06.2008 - 23:04

@LB: Ach, weisst du, letztendlich ist es doch wurscht was ich oder andere dir antworten. Du hast so ein astreines Pedigree im Rumtrollen dass jedes Anfüttern reine Zeitverschwendung wäre, deswegen lass ich es lieber gleich sein.

Permanenter Link

Lothar Baier
am 30.06.2008 - 23:19

@Thomas:

Ist ja spannend. Wenn man eine andere Meinung hier äußert, dann ist man ein Troll? Im Gegensatz zu Dir bringe ich hier Fakten und Tatsachen, Du dagegen nur eine Beleidigung.

Antworte doch auch mal mit Fakten. Ich bin für jedes belegte Argument offen. Aber nicht für Definitionen, die weder nützen, noch einer praktischen Überprüfung standhalten.

Permanenter Link
Nils Pooker

Nils Pooker (Webkraut)
am 01.07.2008 - 00:00

Gerade weil es solche Standards und Gremien für deren Schaffung gibt, gibt es so wenige barrierearme Webseiten. Und nochmals: Barrierefrei gibt es nicht, weil weder medizinisch noch technisch möglich. Punkt.

Ja nun, wenn das deine Meinung ist, gebe ich hier auf – und ich gebe Dir recht mit allem was du sagst, hier und jetzt und gestern und zukünftig bis zum Ende aller Tage, OK? Damit ist das hoffentlich erledigt und wir können alle wieder produktiv arbeiten.

Permanenter Link
Eric Eggert

Eric Eggert (Webkraut)
am 01.07.2008 - 00:42

Lothar: Es wäre wirklich einfacher, wenn du die WCAG2 mal gelesen hättest, dann wüsstest du, dass die Regeln auf 12(?) Din-A4-Seiten auszudrucken sind. Dass du dem W3C dann den Vorwurf machst weiterführende (nicht normative!) Materialien anzubieten, ist an sich ja schon ein Treppenwitz.

Die Forderungen nach Barrierefreiheit sind nicht erfüllbar, nenne die Punkte, die nicht erfüllbar sind. Und wenn sie nicht erfüllbar sind, wo sind dann deine E-Mails an das W3C, an die WCAG WG, diese Dinge zu korrigieren.

Wir haben hier in Wien mit Vertretern von Accessible Media, Agenturen, Freelancern und dem W3C zusammen gesessen und sind die Punkte Schritt für Schritt durch gegangen. Nicht umsetzbar ist ein Ausdruck, der nie gefallen ist.

Von 100%iger Barrierefreiheit spricht niemand, deshalb gibt es verschiedene Level (A, AA und AAA), die etwa Grundzugang, leichter Zugang und perfekter Zugang bedeuten. Uns ist wichtig Webseiten von A nach AA zu bekommen. Niemand wird Gebärdensprachvideos einbinden müssen.

Und nochmals: Barrierefrei gibt es nicht, weil weder medizinisch noch technisch möglich. Punkt.

Wie interpretiere ich das mit dem medizinisch? Dass es einer geburtsblinden Person wahrscheinlich nie möglich sein wird zu sehen? Am besten interpretiere ich das gar nicht und folgere, dass es DEINE Vorstellung von Barrierefreiheit nicht gibt, was nicht so schlecht ist, weil sich daran ja nur eine Person in diesem Universum misst. Du.

Antworte doch auch mal mit Fakten. Ich bin für jedes belegte Argument offen. Aber nicht für Definitionen, die weder nützen, noch einer praktischen Überprüfung standhalten.

Auf welche Fakten soll irgendjemand von uns mit Fakten antworten? Es ist ja schon in deinen Aussagen keine Substanz da. Auf Nils nachfragen bist du ja auch geschickt nicht eingegangen. Bravo.

Bei den ganzen Diskussionen um Barrierefreiheit geht es schon lange nicht mehr um die Behinderten. Es geht um Profit, Macht und Selbstbeweihräucherung.

Allerdings weit weniger überheblich als in deinen Kommentaren. Sollen sich Menschen, die barrierefreie Webseiten machen, die wirklich Menschen helfen denn verstecken? Dürfen sie nicht stolz auf ihre geleistete Arbeit sein? Ich arbeite regelmäßig mit behinderten Menschen zusammen, höre mir ihre Probleme an und versuche so gut es geht darauf einzugehen. Dabei helfen die Richtlinien des W3C, damit ich keine ernsthaften Dinge übersehe.

Permanenter Link

Martin Kliehm
am 01.07.2008 - 11:47

Gute Definition: Barrierefreiheit ist für Menschen mit Behinderungen. Die Dogmatiker enden an diesem Punkt leider. Wer Barrierefreiheit nicht erfüllt, diskriminiert. Auch das ist richtig. Aber negative Anreize motivieren niemanden.

Ebenfalls ist richtig, daß es große Schnittmengen gibt zwischen Barrierefreiheit, Usability oder Geräteunabhängigkeit.

Da ich nicht ein Internet für Behinderte und eines für iPhone-Nutzer und eines für meine Eltern und eines für den Rest der Welt baue, sondern insgesamt nur eines für alle, muß ich diese Punkte (und noch einige mehr) sowie ihre Schnittmengen berücksichtigen. Das ist professionelles Frontend-Engineering, und den gleichen holistischen Ansatz erwarte ich von Designern, Konzeptern und Textern.

Falsch ist hingegen, daß von Barrierefreiheit nur eine Randgruppe profitiert, daß Farbkontraste nicht auch für die 4,4% Farbenblinden nützlich sind, daß barrierefreie Websites grundsätzlich häßlich wären. In den letzten Monaten habe ich Websites für DAX 100-Unternehmen realisiert, und Barrierefreiheit ist für sie alle relevant. Ich frage mich also, warum erfolgreiche Unternehmen Barrierefreiheit als Grundlage erkannt haben, während die anderen das Thema ignorieren…

Wir kommen dann weiter, wenn wir den ganzheitlichen, professionellen Ansatz akzeptieren und uns mit den Konsequenzen befassen, wie wir damit herausragende Websites erstellen können.

Permanenter Link
Gerrit van Aaken

Gerrit van Aaken (Webkraut)
am 01.07.2008 - 12:31

Da der Artikel sich ja direkt auf mein Essay von vorletzter Woche bezieht, will ich auch kurz Stellung nehmen.

Ein Problem, das ich sehe (und das ich eben auch im Essay beschrieben habe), ist die Tatsache, dass ich mich als Webdesigner eben nicht nur um die fest definierbare "Barrierefreiheit für Behinderte" kümmern muss, sondern stets auch technische Zugänglichkeit (kleine Screens usw) und Usability und gutes Grafikdesign im Hinterkopf haben muss. So verstehe ich jedenfalls meinen Job. Man kann Techniken der Barrierefreiheit nicht einfach so anwenden und befolgen, und dabei die anderen Aspekte der Frontend-Entwicklung ignorieren, weil diese - so Leid es mir tut - bei den meisten Projekten einfach wichtiger für den Kunden sind.

Deswegen tue ich mir so wahnsinnig schwer damit, wenn die BF-Experten hier immer behaupten, das wäre alles so einfach und klar und man müsste sich nur an die Regeln halten und wo es keine klaren Regeln gibt, dann "käme es eben drauf an".

Ich gewinne auch den Eindruck, dass es unter vielen BF-Experten nicht sonderlich viel Konsens gibt. Die einen sagen: 100% Barrierefreiheit kann es nie geben, es ist nur ein theoretisches Ziel. Die anderen mögen den Begriff Barrierefreiheit nicht, weil er negativ formuliert ist und nicht positiv. Für die einen ist die BITV das, worauf es ankommt. Die anderen gehen nur nach dem gesunden Menschenverstand und Usertests. In Erlangen 2006, gab es einen Vortrag, wo sinngemäß gesagt wurde: "Barrierefreiheit ist eben nicht »Webdesign für Behinderte«, sondern alles, was Websites zugänglich für alle Nutzer macht". Gemeint waren eben auch ältere Browser, Senioren, langsame Netzverbindungen usw ... Das fand ich gut.

Ich beobachte diesen ganzen Zirkus wirklich seit geraumer Zeit, und obwohl ich motiviert bin, weiß ich wirklich nicht, was ich anstellen soll, um Websites zu bauen, die gut aussehen, moderne Funktionen besitzen, auf allen Geräten funktionieren und auch noch barrierefrei sind. Aber wahrscheinlich muss ich noch ein bisschen nachsitzen und ein zweites Mal "BITV reloaded" auf EfA lesen – das ist wenigstens verständlich geschrieben.

(Und ich verstehe nicht, warum das immer alles so wahnsinnig emotional ablaufen muss. Geht doch auch netter: siehe Nils’ Attitüde!)

Permanenter Link
Sylvia Egger

Sylvia Egger
am 01.07.2008 - 13:59

@Tomas:
Es ist halt schon schade, dass wir immer noch auf diesen Grundfragen rumkauen müssen. Natürlich strebe ich an, dass alle alles gleich schnell erfassen. ;) Nein, Scherz beiseite.

Was Gerrit ja durchaus richtig einfordert ist, wie mache ich das dann richtig und ganz konkret. Und der Großteil der barrierefreien Optimierung kann durchaus in den Standard miteinfliessen. In der konkreten Quellcode-Bearbeitung unterscheide ich nicht mehr zwischen standardkonform oder barrierefrei. Auch wenn ich von oben immer den Hinweis erhalte, Du das muss nicht barrierefrei optimiert werden, fliessen bei mir da ohnehin - weil im Tempalte bereits mit integriert - vieles mit ein (vielleicht ein wenig wie das bei Joomlas Beez-Theme der Fall ist).

Ich kann in diesen Grundsatzdiskussionen kaum noch was beitragen, weil mich andere Fragen interessieren. Wie macht ihr das: trennt ihr das noch, wenn etwas barrierefrei optimiert wird oder greift ihr auch schon auf Templates zurück, die darauf schon vorbereitet sind. Diese Fragen der konkreten Umsetzung und Weiterentwicklung sind für mich spannender. Aber das mag dann daran liegen, dass man einfach schon etwas mehr barrierfreie Arbeit auf dem Buckel hat. :)

Und ähnliche Fragen kann man sich in der Farbgebung und Layout-Fixiertheit stellen, wie läßt sich das ganz konkret in der täglichen Arbeit in den Workflow packen. Was kann man schon im Ansatz bei der Farbgebung mit der Grafik durchsprechen, dass es standardmässig immer mitläuft.

Aber vielleicht bin ich da zu optimistisch. :)

Permanenter Link

GE
am 01.07.2008 - 14:00

Barrieren werden in der Zukunft (und auch jetzt schon) durch immer bessere Ausgabegeräte und immer bessere Software abgebaut.

Ansonsten bevorzuge ich den universellen Ansatz:

Barrierefreiheit (-armut) beginnt bei verständlich geschriebenen Inhalten und einer sinnvollen Strukturierung derselben sowie der Einhaltung der anerkannten Webstandards. Ein ordentliches Design und Layout für die 90% Normalnutzer gehört ebenso dazu wie ein möglichst einfacher Quellcode.

Mit diesen Voraussetzungen müssen die verschiedenen Ausgabemedien dann zurechtkommen, auch die speziellen für die verschiedensten Behinderungen. Dazu sind die Standards da.

Erst dann denke ich darüber nach, was ich zusätzlich tun kann, um besonderen Ausgabegeräten Unterstützung anzubieten.

Und das ist nun der hardcore-Ansatz, der Barrierefreiheit als eine spezielle Disziplin betrachtet, losgelöst von Benutzbarkeit und gutem Stil, ausschliesslich für Behinderte und deren Bedürfnisse und Ausgabegeräte.

Beispiel: Ein Browser mit Sprachausgabe sollte wissen, ob ein "Browser" als Brofser oder als Brauser auszugeben ist, ob "CSS" ein Zischlaut ist oder eine Abkürzung.

Also: Auszeichnung von Fremdwörtern und Abkürzungen, Angabe von alternativen Inhalten z. B. für Multimedia-Inhalte. Ein zum Inhalt gehörendes Bild mit einem leeren alt-tag (vom WYSIWYG erzeugt) ist zwar standardkonform, aber erst eine kurze und prägnante Beschreibung im alt-tag baut eine Barriere ab.

Das (und dergleichen, kein Anspruch auf Vollständigkeit) allerdings IST zusätzlicher Aufwand, der vom Kunden bezahlt werden muss, egal ob ich das für ihn mache, oder ob ich die Autoren, die sein CMS mit Inhalten füttern, ausbilde und regelmässig schule.

Wenn also jemand eine von mir erstellte Seite findet, die diesem hardcore-Ansatz nicht genügt, dann unterstelle er mir nicht, dass ich das nicht kann, keine Ahnung habe und unprofessionell arbeite. Die Tendenz zu solchen Unterstellungen ist ja hier durchaus erkennbar.

@ Martin: Wenn Du Kunden hast, die bereit sind, das notwendige Budget bereitzustellen, kann ich Dich nur dazu beglückwünschen ;-)

Permanenter Link
Eric Eggert

Eric Eggert (Webkraut)
am 01.07.2008 - 16:09

Das (und dergleichen, kein Anspruch auf Vollständigkeit) allerdings IST zusätzlicher Aufwand, der vom Kunden bezahlt werden muss, egal ob ich das für ihn mache, oder ob ich die Autoren, die sein CMS mit Inhalten füttern, ausbilde und regelmässig schule.

Das (und dergleichen, kein Anspruch auf Vollständigkeit) ist, was zu qualitativ hochwertigem, Webdesign gehört. Wer nicht standardmäßig Alternativtexte für Bilder einbaut (und das ist echt kein Hardcore-Aufwand), der handelt auch nicht Standardkonform. Ob der Kunde das dann umsetzt (er sollte das tun und es liegt an uns ihm zu vermitteln, dass es die richtige Sache ist 5 Wörter zum Bild einzutippen), steht natürlich auf einem anderen Blatt Papier.

Das selbe gilt für die Auszeichnung von Abkürzungen. 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.

Wenn Du Kunden hast, die bereit sind, das notwendige Budget bereitzustellen, kann ich Dich nur dazu beglückwünschen

Das ist ein Teufelskreis, nur wer qualitativ hochwertige Arbeit herstellt kommt auch für qualitativ hochwertige (und dann besser bezahlte) Arbeit in Frage. Ich geh auch zum Bäcker, der die besseren Brötchen hat, wenn sie 5ct mehr kosten als beim Supermarkt.

Permanenter Link
Gerrit van Aaken

Gerrit van Aaken (Webkraut)
am 01.07.2008 - 17:26

@sprungmarker: Das ist doch mal ein Kommentar, der mir entgegenkommt, mit dem ich wirklich was anfangen kann, danke.

Permanenter Link

Gerhard
am 02.07.2008 - 15:34

Ich habe mir angewöhnt bei üblicherweise sehr emotional diskutierten Themen immer zuerst die Kommentare zu lesen. Über den Artikel von Tomas Caspers war ich dann doch etwas erstaunt. Seine Definition „Websites sind dann barrierefrei, wenn sie von Menschen mit Behinderung genau so effektiv und effizient genutzt werden können wie von Menschen ohne Behinderung. Punkt.“ halte ich zwar für äußerst missverständlich, aber spätestens mit „Das heisst nur, dass den Nutzern keine unnötigen Steine in den Weg gelegt werden. Es darf eben nicht signifikant länger dauern oder gar unmöglich sein, sonst stimmt irgendwas nicht. Das heisst auch, dass seitens des Anbieters (wo nötig) unterstützend eingegriffen wird, sodaß das Ergebnis der Nutzung für alle Besucher vergleichbar ist. Nota bene: nicht der eigentliche Ablauf, sondern nur das Ergebnis.“ sollte jedem klar sein welche Meinung er vertritt.

Permanenter Link

Monika
am 02.07.2008 - 15:34

accessibility bedeutet doch Zugänglichkeit,
ich finde bei der Übersetzung des Wortes absolut keinen Hinweis, dass diese Zugänglichkeit Menschen mit Behinderungen ein-oder ausschließt.

Meine Mutter ist im Inernet und bekommt regelmäßig die Krise, wenn sie von sogenannten barrierefreien Webseits als Idiotin hingestellt wird, die zu blöd ist "Button" zu verstehen oder "download". Da steht dann "Schalter"- was technisch schlicht was anders als "Drücken" bedeutet.

Solange aber solche Webseiten sogar die Biene bekommen, darf sich niemand wundern, dass da viele Firmen auf ihren Webseiten nicht mitmachen: ich höre sehr oft, ich kann doch meine Kunden nicht als "doof" erklären...

Technisch gebe ich obiger Definition recht, wiewohl es furchtbar ist, dies nur auf Menschen mit Behinderungen einzugrenzen.

Zugänglichkeit für Alle - aus!

Da brauchts keinen moralischen Hammer für den Menschen mit Behinderungen immer herhalten müssen.

Diese Moralisierei der Lobby der "Barrierefrei Gurus" bringt mich immer weiter weg von diesem Weg. Ich mag bei keiner Moralisierei mit dabei mehr sein.

In meiner täglichen Arbeit stehe ich oft vor dem Konflikt, dass der Kunde nicht das Geld hat oder nicht bereit ist es für die Arbeitszeit, die eine voll zugängliche Seite nun mal braucht, auszugeben.

Ich kann es mir finanziell nicht immer leisten, dennoch eine -so weit ich es kann - zugängliche Seite zu machen.

Unabhängig davon, dass ich zu 90% CMS ausliefere, wenn der Schreiber dann keine Auszeichnungen etc macht, war meine Arbeit vorher umsonst.

Die Umprogrammierung eines Tiny zahlt eben kaum wer - oft ist auch einfach wirklich das Geld nicht da.

Mit diesen Einschränkungen lebt sichs im Alltag eines WebDesigners, der "OttoNormalVerbraucher" als Kunden hat. Qualität unter der Haube sieht kaum wer. Daher finde ich dieses Argument ein wenig "überheblich" (Eric Eggert letzter Absatz des Kommentars oben)

Anektote am Rande:

letztens bekam ich eine Email,dass meine Fotos in der Fotogalerie zu wenig Kontrast hätten und somit hätte sie der Emailschreiber nicht gut genug sehen können. Als Zitat brachte er mir den Absatz über den Kontrast auf Webseiten....

Ich habe drüber gelacht, bekommt das aber eine Firma, ist der ganze *barrierefrei Kram* sofort weg bei denen-jede Wette drauf.

lg
Monika

Permanenter Link
Peter Rozek

Peter Rozek
am 02.07.2008 - 16:13

@Lothar:

Und deshalb sollten die Dogmatiker der Barrierefrei-Szene endlich mal aufhören, unerfüllbare Forderungen zu stellen, dann könnte man nämlich das tun, was machbar und sinnvoll ist.

Ist doch immer wieder schön zu lesen das es Personen gibt, die eigentlich gar nicht Wissen worüber Sie reden, bzw schreiben.
Wenn ich kein Bock auf Barrierefreiheit habe oder mir das Thema einfach zu kompliziert und zu anstrengend ist dann soll mans doch einfach sein lassen. Aber Bitte nicht immer etwas von Dogmatiker, unerfüllbar, verzicht, ach Gott was ist das alles kompliziert schreiben.

Die gültigen Standards sind weder unerfüllbar noch Spaßbremsen. Klar gibt es immer wieder mal offene Fragen, wo man als Webentwickler oder Webdesigner denkt, wie mach ich das jetzt. Aber auf fast alle Fragen gibt es immer eine oder mehrere gute Antworten.

Mein Tipp: Tante Google fragen, lesen und kompetente Kollegen fragen.

@Lothar:

Antworte doch auch mal mit Fakten. Ich bin für jedes belegte Argument offen. Aber nicht für Definitionen, die weder nützen, noch einer praktischen Überprüfung standhalten.

Hallo, Fakten gibt es zu genüge! Schom mal mit mehr als einem Menschen mit Behinderungen gesprochen.

Ich komme zu dem Schluss das der "Liebe Lothar" kein Bock hat sich mit dem Thema ernsthaft auseinanderzusetzen. Punkt

An diesem Punkt schließe ich mich dem Thomas an und sage nur: "Lierum larum Löffelstiel, wer nicht lernt der weiß nicht viel."

Permanenter Link
Eric Eggert

Eric Eggert (Webkraut)
am 02.07.2008 - 18:33

Monika: Warum zäumt man das Pferd denn so von hinten auf? Barrierefreie Webseiten (und das ist in diesem Kontext die Übersetzung von accessibility) helfen jeden und machen das Web zugänglich für alle. Genauso wie Rampen auch Müttern (oder Vätern) mit Kinderwagen das Leben erleichtern.

Aber primär werden Rampen gebaut, damit Menschen mit Behinderungen am sozialen Leben teilhaben können.

Niemand schwingt hier eine Moralkeule, für manche ist es eben selbstverständlich und für andere nicht.

Es gilt den Kunden in dieser Beziehung aufzuklären, und ja, wenn er dann im CMS Dinge falsch macht ist das sehr schade. Aber: Wenn die grundsätzliche Überschriftenstruktur stimmt, wenn Sprunglinks vorhanden sind, dann ist das schon eine große Erleichterung und wirklich kaum ein Aufwand.

Und das umprogrammierte Tidy (was ich nicht machen würde, auch WYSIWYG-Editoren kann man so anpassen, dass sie als „größte Überschrift“ nur eine H2 ausgeben) machst du einmal und stellst es dann als Fixpreis in Rechnung. Wiederverwendbarkeit ist einfach eine tolle Sache.

Und Kunden, die auf der Suche nach Qualität sind (und bereit dafür zu zahlen) können dich nur finden, wenn du deine Projekte entsprechend angehst.

Zur Anekdote: Es gibt überall weltfremde Menschen, manchmal schreiben die auch E-Mails.

Permanenter Link
Peter Rozek

Peter Rozek
am 02.07.2008 - 19:53

@Monika

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.

Permanenter Link

André
am 03.07.2008 - 00:09

@Eric

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é

Permanenter Link
Eric Eggert

Eric Eggert (Webkraut)
am 03.07.2008 - 01:39

Puh, und ich dachte ich könnte noch irgendeine produktive Arbeit machen.

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.

Permanenter Link

Maria
am 03.07.2008 - 20:09

ah sommerloch! und die webkrauts haben zeit zum diskutieren, seitenlange grundsatzdiskussionen allenthalben. bewundernswert!! mir ist mein hirn etwas geschmolzen, ich versteh das grad alles gar nicht gut...
es wird nichts so heiß gegessen, wie es gekocht wird, denken wir hier in österreich pragmatisch, können also auch mit manchmal kraus formulierten guidelines ganz gut umgehen. dieser barrierefreibrei ist aber nun schon so kaltgerührt und durchgekaut, irgendwie schimmlig und leicht verwest. ich kann da gar nicht mehr lesen, was womöglich kluges drinsteckt in dieser diskussion. geschmolzenes hirn...ich mach einfach meine arbeit, websites mit einigermaßen qualitätsanspruch. barrierefreiheit ist tatsächlich nur ein kleiner und soweit möglich selbstverständlicher teil des jobs. die behinderten community wird mich nicht verklagen, wenn einmal der kontrast nicht 100% ausreicht. tun wir unser bestes und reden wir endlich nicht mehr über alternativtexte und schriftvergrößerungsbuttons, wenns ums thema barrierefreiheit geht.

Permanenter Link

Harald
am 06.07.2008 - 20:56

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 ;-)

Permanenter Link

Moritz Gießmann
am 06.07.2008 - 23:50

Noch mal zu den Kommentaren ganz oben:
Ich finde es schade, dass hier jetzt der Kindergarten von Praegnanz.de weitergemacht wird. Das hilft keinem weiter. Skyped doch mal und diskutiert richtig!

Permanenter Link

André
am 08.07.2008 - 00:13

„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.

Permanenter Link

Die Kommentare sind geschlossen.