Wie Barrierefrei ist TL wirklich?

**MacKP** · 02.10.2009, 09:32

Hallo Ihr alle.
Mir liegt das Thema Barrierefreiheit sehr am Herzen und daher beschäftige ich mich auch öfter damit.
Inzwischen sind mir ein paar Dinge aufgefallen, die leider nicht so ganz stimmig sind mit der Aussage, das TL barrierefrei ist...

Daher wollte ich hier mal eine kleine Diskusion anregen um mal zu höhren wie ihr das seht (Nina ist da ja zum Beispiel auch sehr bewandert in diesem Bereich und hat am Usertreffen 2009 auch schon ein paar Dinge angesprochen gehabt wie ich mitbekommen habe http://de.contaowiki.org/typolight/F...ibility-tuning).

1. Der 'weiterlesen' Link in TL ( http://https://contao.org/issues/show/198 ) muss per Template angepasst werden (warum nicht richtig gesetzt?)

2. Die skiplinks von den Navigationen werden ja relativ unnützlich benannt ( http://https://contao.org/issues/show/726 ) da fände ich eine andere Handhabe auch schöner.

3. Das Kommentar Formular ist so auch nicht barrierefrei, zu sehen ist das ja auch bei den anderen Formularen, diese werden aber bald geändert (was ich sehr gut finde) ( http://https://contao.org/issues/show/944 )

4. Man muss Bildern einen alt-Text geben... was ja nicht bei allen Bildern wirklich sinnvoll ist, da es auch schmückendes Beiwerk gibt, oder auch schon eine Bildunterschrift/-überschrift diese Angaben enthält... (diese Diskusion gab es glaube ich vor sehr langer Zeit im alten Forum)

Diese Punkte finde ich einfach nicht so schön gelöst. Vor allem mit dem Hintergrund das die meisten Leute möglichst nicht die fe_page.tpl anpassen sollen und TL sich auf die Fahne schreibt Barrierefrei zu sein -> https://contao.org/funktionen.html

Wie man sieht habe ich die meisten Punkte schon versucht mit leo zu klären. Leider ist mir da nicht wirklich gelungen auch nur irgend etwas zu erreichen.

Klar kann man auch nicht alles abfangen und wird immer Handarbeit haben um Barrierefreiheit zu erlangen. Aber ich bin der Meinung, das man da doch einige Punkte noch automatisiert bereinigen könnte.

Was meint Ihr dazu? Wie seht ihr das? Was kann man da machen/verbessern?

Viele Grüße

***leo*** · 02.10.2009, 10:08

zu 1.) Der Weiterlesen-Link ist keinesfalls nicht barrierefrei und die von Dir angedachte Bezeichnung ist es auch nicht mehr oder weniger als die jetzige.

zu 2.) Auch die Benennung der Links zum überspringen der Navigation schmälert nicht die Barrierefreiheit. Die Bezeichnung "Navigation überspringen" finde ich auch nicht "unnütz benannt", da sie genau sagt, was der Link macht.

zu 3.) Zu Formularen gibt es eine ganze Reihe an offenen Tickets für die 2.8. Es stimmt, dass hier bezüglich der Barrierefreiheit nachgerüstet werden muss.

zu 4.) Ja, man muss Bildern einen alternativen Text geben, weil das "alt"-Attribut für Bilder zwingend vorgeschrieben ist. Inwiefern sollte das nachteilig für die Barrierefreiheit sein?

Ich habe ein bisschen den Eindruck, als müsstest Du Dich noch mal mit dem ganzen Thema auseinandersetzen. Der überwiegende Teil Deiner Einwände hat nichts direkt mit der Barrierefreiheit zu tun oder ist wie die Forderung, das im XHTML-Standard erforderliche "alt"-Attribut wegzulassen, schlicht falsch.

Es tut mir leid, wenn die Erläuterungen im Ticket-System manchmal kurz ausfallen. Du solltest einen Fehler aber auch nur dann melden, wenn es tatsächlich einer ist. Wenn das dafür erforderliche Basiswissen nicht vorhanden ist, solltest Du lieber zuerst im Forum fragen, wie Du es jetzt ja auch getan hast. Dort sind die Antworten auch meistens ausführlicher, weil die Beiträge von mehr Benutzern gefunden und gelesen werden als im Ticket-System.

***Nina*** · 02.10.2009, 10:43

Da barrierefreies Webdesign mein Fachgebiet ist und ich auch im Team diesem Ressort zugeteilt bin, gebe ich dazu gerne auch noch meinen Senf ab:

Es gibt aus meiner Sicht zur Barrierefreiheit von TYPOlight noch einiges zu verbessern, aber das System erfüllt auch schon sehr viele Anforderungen, so dass es aus meiner Sicht definitiv das Label "CMS das bewusst die Barrierefreiheit unterstützt" tragen darf.

Nicht umsonst habe ich mit TYPOlight als Basis bereits einen BIENE-Award gewonnen

Das ist natürlich auch mit anderen CMS möglich, aber wie ich aus Erfahrung weiß, bedeutet das bisher in jedem CMS sehr viel Aufwand. Mit TYPOlight fielen die notwendigen Anpassungen für die hohen BIENE-Kriterien wesentlich einfacher und besser machbar aus, als mit allen anderen CMS die ich kenne.

Jetzt zu den von dir genannten Punkten:
geht gleich weiter, muss nur kurz Zwischenspeichern wegen Telefonanruf

**MacKP** · 02.10.2009, 10:50

hallo leo,
danke für diese Ausfürhlichen Antworten.

Ich muss dir aber wiedersprechen. Ich beschäftige mich nicht erst seite heute mit dem Thema sondern bin da schon etwas länger dabei.

zu 1)
10 Links auf einer Seite die mit 'mehr' bezeichnet sind, sind für Menschen die Screenreader nutzen müssen unheimlich nutzlos. Wenn dort 'mehr zum Thema XY' stehen würde könnten diese Menschen damit auch was anfangen

zu 2)
Es ist genau in der BITV beschrieben das solche Links keinem nutzen, da sie nicht angeben wo man landet. Das hatte ich aber auch schon im Ticket geschrieben. Es ist immer schlecht, wenn man nicht weiß wo hin es geht. Ein Beispiel wäre da eine Navigation am Ende einer Seite... man überspringt die Navigation und landet.. Am Ende.. da ist nichts mehr...

zu 3)
Ja, ich weiß das diese Nachgerüstet werden. Warum aber nicht alle? Wenn da gerade aufgeräumt wird um alles richtig zu machen, warum dann ab der hälfte stoppen?
Auch oder gerade Menschen die eingeschränkt sind möchten etwas kommentieren ;-)

zu 4)
Es gibt immer mal wieder Schmückende Bilder, die einfach nur an einer Nachricht kleben, damit diese Optisch schicker wird. Da bringt ein alt Text nichts an Informationen.
Und wie ich geschrieben habe sind die Informationen zum Teil durchaus schon bei einer Überschrift vorhanden oder einer Bildunterschrift.
Was würdest du zu einer Internetseite sagen, wo dir 3 mal die Selbe Information gegeben wird an einer Stelle? Unnütz albern.. geh ich lieber wo anders hin... Das würde ich zumindest denken und viele Andere auch

Viele dieser Dinge kann man auf dieser Seite nachlesen -> http://www.einfach-fuer-alle.de/
oder auch in Literatur zu diesem Thema.

Ich finde es schade, das du mir immer wieder meine Kompetenzen aberkennst (wie seinerseites schon einmal im Bezug auf das Thema Impressum).
Ich beschäftige mich nicht nur aus Spaß mit diesen Themen und schreibe solche Beiträge nicht ohne Grund.

Bei deinen Antworten stellst sich mir allerdings die Frage ob du dich da nicht eventuell noch ein wenig fortbilden solltest oder vllt noch besser dich beraten lässt von zum Beispiel Nina, die ja für dich durchaus Fachlich kompetenter ist als ich es bin.

Viele Grüße

----
Edit:

@Nina: klar geht schon viel mit TL, aber einiges finde ich da doch eher unglücklich weil automatisiert nicht richtig gehandhabt. Ob nun Barrierefrei drauf stehen darf oder nicht ist glaube ich ein Streitpunkt den andere Stellen besser beurteilen könnten. Denn nach deiner Argumentation könnte das jedes CMS haben, da im Grunde (auch mit mehr arbeit) jedes CMS soweit ist.... Daher will ich darüber auch nicht wirklich diskutieren. Sondern eher über die Punkte die ich genannt habe und deren Behandlung.

***Nina*** · 02.10.2009, 10:58

MacKP: Warte doch bitte einfach ab, bis ich meine Antwort gepostet habe. Darin findest du alle Erklärungen zu den einzelnen Punkten die klar machen WARUM bestimmte Entscheidungen getroffen wurden bzw. wie unsere Sicht darauf ist.

**MacKP** · 02.10.2009, 11:00

Hallo Nina,
ich warte da gerne.
Allerdings wußte ich zu diesem Zeitpunkt noch nicht das du gerade auch etwas schreibst ;-)

Viele Grüße

***Nina*** · 02.10.2009, 11:06

Vorneweg möchte ich mal grundsätzlich etwas zum Thema Barrierefreiheit sagen:
Es bringt nichts, wenn man die Regeln einer WCAG 2, BITV oder sogar die BIENE-Kriterien einfach liest und wortwörtlich umsetzt. Das Internet und die Anwendungsgebiete sind dafür schlicht und einfach viel zu unterschiedlich. Man muss jede Menge Faktoren beachten wie z. B. welche technischen Features müssen auf der Website abgebildet werden, wie komplex ist der Umfang und woher kommen die Inhalte, wer pflegt die Internetseite (fachlich ausgebildete Redakteure oder doch eher Laien), usw.

Deshalb kann ein CMS nicht einfach gegen alle Regeln gegen geprüft werden, sondern muss natürlich die Grundregeln erfüllen und dann dem Administrator die Möglichkeit geben, bei den weiteren Belangen möglichst einfach das System zu modifizieren ohne gleich jegliche Updatefähigkeit zu verlieren (bei manchen CMS läuft es im Endeffekt darauf hinaus).

Hier geht TYPOlight aus meiner Sicht grundsätzlich den richtigen Weg, da die Entscheidungen für/wider ein Feature im Core so getroffen werden, dass sie für die Masse der CMS-Nutzer die sinnvollste Variante darstellt. Gleichzeitig ermöglichen die Templates und z. B. die dcaconfig.php, dass man das System sehr einfach für projektspezifische Anforderungen tunen kann.

1. 'weiterlesen' Link
Grundsätzlich hast du absolut recht, dass eine Seite voller "weiterlesen"-Links einem blinden Nutzer nichts bringt. Wenn er sich via Screenreader alle Links der Seite ausgeben lässt, kennt er die tatsächlichen Ziele nicht. Das ist uns absolut bewusst, daher müssen wir darüber an sich nicht diskutieren, da wir gleicher Meinung sind.

ABER:
Hier wurde die Abwägung ganz klar so getroffen, dass die Core-Ausgabe den Anforderungen der Masse der Nutzer entspricht. Die meisten Nutzer wollen, dass es kurze und knappe "weiterlesen"-Links gibt. Gerade in meiner beruflichen Arbeit kommt diese Anforderung ständig von den Firmen und sie bestehen darauf.

Die gute Sache daran ist aber, dass es ein leichtes für jeden ist, der Wert auf Barrierefreiheit legt, das betroffene Template anzupassen. Ich bin z. B. jemand der bei den News oft nur die Überschrift verlinkt lässt und den weiterlesen-Link unter dem Teaser ganz aus dem Template löscht. Alternativ habe ich Kunden, die ich davon überzeugen kann, dass wir den weiterlesen-Link so umbauen, dass der jeweilige Linktitel darin versteckt nochmal für Screenreader-Nutzer ausgegeben wird. Oder eben der von dir erwähnte Vorschlag. Wie du alleine an diesem Beispiel siehst, gibt es unterschiedlichste Herangehensweisen und tausend Meinungen.

Genau dafür gibt es das Template-System von TYPOlight, damit wirklich jeder das machen kann, was ihm lieb ist.

Man könnte als Zwischenlösung in TL eventuell dafür sorgen, dass die Variante mit den "unsichtbaren" weiteren Infos im weiterlesen-Link eingebaut sind. Dann wäre das barrierefreier und würde beim Standardprojekt trotzdem nicht auffallen. Sicher eine Möglichkeit über die man nachdenken und eventuell in einem Ticket sprechen kann. Das würde dann grob vereinfacht nach diesem Schema funktionieren:

HTML-Code:

<a href="...">Weiterlesen <span class="invisible">Beitrag: individueller Newstitel</span></a>

**MacKP** · 02.10.2009, 11:11

Hallo Nina,
da bin ich genau deiner Meinung. Auch mit den Templates, das ist klar. Nur der vorgegebene Weg ist nicht ganz passend zu der Aussage wie ich finde.
Deiner Zwischenlösung würde ich sehr begrüßen.
Mir geht es ja auch nicht um DIE eine Lösung, sondern um eine Möglichkeit das besser zu machen.

Mir ist bewußt das es auf jeder Seite anders ist. Ich mache das ja auch immer wieder unterschiedlich. Ich denke hier aber auch an Lischen Müller, die mal eben eine Internetseite mit TL macht. Ich bin da so jemand der sich freuen würde mehr Barrierefreie Seiten zu sehen ;-)

Und zusätzlich entscheiden sich ja viele für TL weil es eben Barrierefrei sein soll...

Viele Grüße

***Nina*** · 02.10.2009, 11:13

2. Skiplinks

Skiplinks sind bei der Barrierefreiheit immer ein etwas heikles Thema. Auf ein einziges Projekt bezogen, ist natürlich sehr einfach sie zu setzen da man genau die Umstände kennt.

Wenn wir aber in TYPOlight an den Anfang der Seite standardmäßig im Core Skiplinks setzen wollten, gäbe es diese klaren Projektumstände nicht. Der eine Nutzer setzt eine Hauptnavigation im Header ein, der andere Nutzer teilt Hauptnavigation und Subnavigation, der dritte Nutzer packt seinen Text in die linke/mittlere/rechte Spalte, der vierte Nutzer nur in die Hauptspalte, dann kommt die Individualnavigation dazu, außerdem eine Zusatzspalte mit Extralinks, usw.

Es ist also faktisch nicht möglich in TYPOlight eine generelle Lösung mit perfekten Skiplinks zu machen. Deshalb wurde hier auf den kleinsten möglichen Nenner gesetzt, damit überhaupt Skiplinks zur Verfügung stehen und somit bei der totalen Durchschnittsseite (deren Nutzer gar nicht über Barrierefreiheit nachdenkt), zumindest ein Mindestmaß an Hilfestellung für Screenreader und Co. verfügbar ist. Auch ihre Benennung ist nicht klarer möglich, da wir gar nicht wissen, an welcher Stelle der Nutzer seine Navigation einbauen wird. Daher ist hier die einzig generell nutzbare Bezeichnung gewählt worden, nämlich der Hinweis dass man eine Navigation überspringt.

Jeder Nutzer der sich wirklich Gedanken zur Barrierefreiheit macht, kann ganz leicht eigenständig Skiplinks hinzufügen. Dazu muss er die fe_template.tpl gar nicht anfassen, sondern kann z. B. ein Modul mit HTML-Code machen, darin die Skiplinks reinschreiben und dieses dann fix im Seitenlayout an erster Stelle (oder wo auch immer) platzieren.

Übrigens noch eine allgemeine Anmerkung: In meinen Gesprächen mit den Nutzern habe ich den Eindruck erhalten, dass die meisten Nutzer gar nicht so viel Wert auf die Skiplinks legen, sondern sehr viele Nutzer vor allem über die Überschriftenhierarchie navigieren. Entsprechend empfehle ich, dass man vor allem darauf viel Wert legt.

***Nina*** · 02.10.2009, 11:15

3. Formulare

An den Formularen arbeiten wir, wie an den Tickets ersichtlich ist. Hier kann ich nur sagen: Vertraue mir, ich sorge schon dafür, dass die Barrierefreiheit aller Formulare mit der 2.8 deutlich verbessert wird. Schon ganz aus Eigennutz, da ich das für alle meine Kundenprojekte benötige

Im Ernst: Hier sehe ich auch in mehreren Modulen dringenden Verbesserungsbedarf und habe etsprechend mit Leo diverse Möglichkeiten durchgesprochen, die den Spagat schaffen und für die Bestandsnutzer von TYPOlight nicht zu krasse Änderungen durch das Update erforderlich machen, aber gleichzeitig für die Zukunft die Barrierefreiheit an der Stelle massiv erhöhen.

Nicht alle Planungen werden via Ticketsystem erledigt, sondern wir sprechen als Team natürlich oft über direktere Kanäle

**MacKP** · 02.10.2009, 11:20

Das ist mir durchaus bewusst.
Und könnte mit sicherheit nur durch eine etwas kompliziertere Möglichkeit der Einstellung gelöst werden (wenn man vom Template absieht).

Aber gerade diese Bezeichnungen werden ja eher als negativ gewertet... warum dann den Leuten etwas vorgaukeln was nicht richtig geht? Dann doch lieber weg lassen und dazu ein kleines Tutorial schreiben oder?
So denken die Leute mit halbwissen: alles klar hab ich drinn macht TL von sich aus... brauch ich nix mehr machen.

Seh ich vllt auch falsch. Aber so finde ich es nicht sinnvoll.

Und wieder : Viele Grüße ^^

**MacKP** · 02.10.2009, 11:26

Zitat von Nina

3. Formulare

An den Formularen arbeiten wir, wie an den Tickets ersichtlich ist. Hier kann ich nur sagen: Vertraue mir, ich sorge schon dafür, dass die Barrierefreiheit aller Formulare mit der 2.8 deutlich verbessert wird. Schon ganz aus Eigennutz, da ich das für alle meine Kundenprojekte benötige

Im Ernst: Hier sehe ich auch in mehreren Modulen dringenden Verbesserungsbedarf und habe etsprechend mit Leo diverse Möglichkeiten durchgesprochen, die den Spagat schaffen und für die Bestandsnutzer von TYPOlight nicht zu krasse Änderungen durch das Update erforderlich machen, aber gleichzeitig für die Zukunft die Barrierefreiheit an der Stelle massiv erhöhen.

Nicht alle Planungen werden via Ticketsystem erledigt, sondern wir sprechen als Team natürlich oft über direktere Kanäle

Als ich das gesehen habe, habe ich auch erst mal einen Luftsprung gemacht ;-)
Wobei ich zugeben muss, das ich einige Dinge schon dadruch umgehe, das ich die yaml-tools nutze und dort das normale Formular schon um einiges verbessert wurde ;-)

Nur gerade bei den Kommentaren ist es noch ganz verdreht.. und wenn ihr da etwas intern besprecht. Ich als Rückmeldung nur bekomme, das der Core nicht geändert wird... dann ist das irgendwie für mich einfach nicht zu verstehen.

Viele Grüße weiterhin *g*

***Nina*** · 02.10.2009, 11:30

4. Alternativtext bei Bildern

Alternativtext soll nur dann bei Bildern erscheinen, wenn dieser inhaltlich Sinn macht. Es gibt hier unterschiedliche Denkansätze und keine ausschließliche Wahrheit, da die Endnutzer (die Besucher der Website) sich selbst untereinander nicht einig sind.

Ich habe blinde Nutzer gehört, die wollen, dass es so wenig Alternativtexte wie möglich gibt und sie nur dann eingesetzt werden, wenn das Bild inhaltliches Wissen transportiert, das zwingend notwendig ist um den Inhalt der Seite zu verstehen.

Andere Nutzer haben mir erzählt, dass sie unbedingt wollen, dass man auch den Bildern Alternativtexte gibt, die eigentlich nur zur Verschönerung des Inhalts eingesetzt werden. Sie argumentieren, dass man diese Bilder einsetzt um beim Betrachter Emotion zu schaffen und sie nicht wollen, dass man ihnen diese Emotion vorenthält. Das setzt aber wiederum voraus, dass der Redakteur weiß, wie man Alternativtexte so befüllt, dass sie diesen Zweck erfüllen.

Der Haken liegt hierbei ganz klar da, dass es keine perfekte Lösung gibt. Aus meiner persönlichen Sicht ist es z. B. generell abzulehnen, dass man Bilder einsetzt, die zum Verstehen der Seite zwingend notwendig sind ohne gleichzeitig ein entsprechendes textliches Pendant im Haupttext (!) zu schaffen. Gleichzeitig habe ich schon oft sogenannte Alternativtexte gesehen, die sagenhaft schlecht befüllt waren, so dass sie den (blinden) Leser wohl eher stören als ihm helfen werden. Außerdem gibt es dann noch den Ansatz, dass man reine Layoutbilder möglichst gleich nur per CSS einbinden sollte, was für den normalen Redakteur aber zu schwer ist.
Und dann kommen da natürlich noch die Suchmaschinenoptimierer, die den Alternativtext für ihre Zwecke einsetzen wollen.

Wo zieht man also die Linie? Auch hier fiel die Entscheidung wieder zu Gunsten der Masse der Nutzer. Der durchschnittliche Redakteur hat keinen bis wenig Plan von Barrierefreiheit. Er schreibt also z. b. seine News und füllt denen ein Bild dazu, das durchaus für das inhaltliche Verständnis wichtig ist. Durch den Zwang für den Alternativtext kommt er nicht drum rum, zumindest eine Mindesterklärung zum Bild in den Alternativtext zu erfüllen und somit wenigstens ein bisschen Barrierefreiheit zu bringen.
Das ist mit Sicherheit keine Toplösung, aber die einzige, die beim wirklichen Durchschnittsredakteur schlussendlich wenigstens ein bisschen Barrierefreiheit mit sich bringt. Wenn es kein Pflichtfeld wäre, würden die Redakteure es meistens gar nicht ausfüllen und so sehr oft den (blinden) Lesern wichtige Infos vorenthalten.

Ich gehe da bei meinen Kunden so ran, dass ich mich je nach Situation entscheide. Wenn ich z. B. Redakteure umfassend zur Barrierefreiheit schulen konnte, setze ich in der dcaconfig.php diese Anweisung:

PHP-Code:


$GLOBALS['TL_DCA']['tl_content']['fields']['alt']['eval']['mandatory'] = false;

Dadurch wird der Alternativtext für den Inhaltstext nicht mehr verpflichtend (für andere Bereiche müsste man das auch noch in der dcaconfig.php dazu schreiben). Das geht aber in diesem Fall nur deshalb, weil ich durch meine Schulung weiß, dass diese Redakteure mit der neuen "Freiheit" korrekt umgehen.

***Nina*** · 02.10.2009, 11:39

So, erstmal Luft holen. Meine Finger glühen

Ich kann zu dem Thema erstmal abschließend nur sagen, dass wir das Thema Barrierefreiheit sehr ernst nehmen. Ich habe aber in meiner täglichen Arbeit gelernt, dass Barrierefreiheit auch bedeutet, dass man Kompromisse eingehen muss. Deshalb können wir im TYPOlight-Core zwar sehr viel machen, aber den Rest müssen bei Bedarf die jeweiligen Administratoren über die Mittel machen, die wir ihnen mit Templates, dcaconfig.php, usw. zur Verfügung stellen.

Ich arbeite seit ner kleinen Ewigkeit an der Neugestaltung der Website meiner Firma, da diese derzeit meinen Barrierefreiheitsansprüchen zum größten Teil nicht mehr entspricht (ist schon ziemlich alt). Im Rahmen dieser Neugestaltung habe ich es mir als Ziel gesetzt, dass ich die Barrierefreiheit auf möglichst hohem Niveau entsprechend den neuesten Anforderungen (WCAG2, WAI-ARIA, etc.) umsetze. Da ich logischerweise TYPOlight als Basis nutze, notiere ich mir etwaige Grenzen an die ich stoße und bringe diese dann in die TYPOlight-Entwicklung ein.
Mein Ziel für TYPOlight ist ganz klar, dass wir so viel wie möglich Barrierefreiheit auf höchstem Niveau reinbringen. An den Stellen, wo das im Core wegen den Abwägungen zwischen dem Durchschnittsnutzer und verschiedenen Projektansätzen nicht möglich ist, werde ich aber meine Erfahrungen nach und nach in Anleitunge/Guides umsetzen, damit interessierte Administratoren darauf zurück greifen können.

**MacKP** · 02.10.2009, 11:49

Mit den Bildern kann ich dir da zustimmen.
Wobei meine dcaconfig so langsam immer voller wird mit solchen Dingen und ich mir da eventuell eine andere Einstellungsmöglichkeit wünschen würde *g* aber so ist das nun mal.

Auch ich lege bei meinen Schullungen sehr viel Wert darauf den Leuten genau das zu vermitteln, was dann natürlich mal mehr mal weniger umgesetzt wird.

Mein Ziel für TYPOlight ist ganz klar, dass wir so viel wie möglich Barrierefreiheit auf höchstem Niveau reinbringen. An den Stellen, wo das im Core wegen den Abwägungen zwischen dem Durchschnittsnutzer und verschiedenen Projektansätzen nicht möglich ist, werde ich aber meine Erfahrungen nach und nach in Anleitunge/Guides umsetzen, damit interessierte Administratoren darauf zurück greifen können.

Genau das möchte ich ja auch und finde es wunderbar, das mit dir da auch im inneren Kreis jemand ist, der Ahnung davon hat. Hoffe so wird dem ganzen mehr gehör geschenkt und es wir doch eventuell noch das ein oder andere geändert was bisher abgelehnt wurde.
Ich freue mich auf jeden Fall auf die Neuerungen die da kommen mögen...

Viele Grüße udn vielen Dank für die Ausführlichen Antworten von dir Nina

**drefsa** · 05.11.2009, 13:43

Soeben gefunden:
WCAG 2.0 auf nun auch Deutsch.

Edit: Hatte lindesbs gestern schon gepostet. War mir entwischt....

**Jan S.** · 07.11.2009, 16:03

Zitat von MacKP

zu 4)
Es gibt immer mal wieder Schmückende Bilder, die einfach nur an einer Nachricht kleben, damit diese Optisch schicker wird. Da bringt ein alt Text nichts an Informationen.
Und wie ich geschrieben habe sind die Informationen zum Teil durchaus schon bei einer Überschrift vorhanden oder einer Bildunterschrift.
Was würdest du zu einer Internetseite sagen, wo dir 3 mal die Selbe Information gegeben wird an einer Stelle? Unnütz albern.. geh ich lieber wo anders hin... Das würde ich zumindest denken und viele Andere auch

Wenn schon, dann wenigstens alt=" ".

Leer sein darf das Alt-Attribut wie Leo schon schrieb nach Standard nicht. Wenn du keines brauchst, dann setz einfach ein Leerzeichen rein.

Wie sinnvoll das jetzt wirklich ist, ist natürlich eine andere Frage... aber das wäre der korrekte Weg.

Viele Grüße
Jan

**MacKP** · 08.11.2009, 10:12

Hallo Jan S.,
danke für die Anmerkung, aber laut WCAG 2.0 ist auch ein alt="" erlaubt und sollte bevorzugt werden -> http://www.w3.org/TR/2008/NOTE-WCAG2...S-20081211/H67

;-)

Viele Grüße