< CSS Voodoo - The dark art of CSS Hacks | jQuery Accessible Tabs - How to make tabs REALLY accessible >

2009-02-07 jQuery Accessible Tabs - Wie man Tabs WIRKLICH zugänglich macht

Während viele Tabs-Scripts behaupten zugänglich zu sein sind es die meisten leider weit davon entfernt. Während ich dieses jQuery Plugin zusammen mit meinem Kollegen Artur Ortega entwickelte, suchten wir nach existierenden Javascript Tabs die Artur mit seinem Screenreader tatsächlich bedienen kann. Wir gaben die Suche irgendwann auf.

Das Problem, dass selbst die besseren Scripts haben, ist die Fehlende Rückmeldung an den Nutzer, dass tatsächlich etwas Passiert. Die meisten Tabs Scripts ändern das Aussehen der Tabs und die Sichtbarkeit der zugehörigen Inhalte aber lassen den Nutzer da zurück wo er war - auf dem Tab auf den geklickt wurde - ohne Ahnung was gerade passiert ist (vergleichbar mit einem Klick auf die immer noch viel zu beliebten "Blinden Links" (a href="#")).

Das ist auch genau der große Unterschied den dieses Script macht. Während das Verhalten für Nutzer ohne Sehbehinderung exakt die gleiche ist passiert sehr viel unter der Haube. Aber erstmal zurück zum Anfang.

jQuery Accessible Tabs benutzt ein sehr einfaches und flexibles HTML Markup als Basis. Alles was es braucht ist ein Wrapper mit Headlines und Inhalts-Elementen nacheinander. Die einfachste und bestmöglichste Alternative ohne Javascript ohne Auszusehen als würde etwas fehlen oder etwas währe kaputt.


    <div class="tabs">
        <h2>eine Beispielüberschrift</h2>
        <div class="tabbody">
            <p>Lorem ipsum dolor sit amet, consectetuer adipiscing elit.</p>
            <h3>Lorem ipsum</h3>
            <p>Nullam malesuada suscipit pede. Nullam ipsum lacus, varius</p>
        </div>
        <h2>noch eine Beispielüberschrift</h2>
        <div class="tabbody">
            <p>Integer tincidunt. Cras dapibus. Vivamus elementum nisi.</p>
            <p>Quisque rutrum. Aenean imperdiet. Etiam ultricies nisi vel.</p>
        </div>
        <h2>alles andere</h2>
        <div class="tabbody">
            <p>Hier könnte Ihr Inhalt stehen</p>
        </div>
    </div>
 

Ein einfacher jQuery Aufruf transformiert das Markup in accessible Tabs:


    $(document).ready(function(){
        $('.tabs').accessibleTabs();
    });
 

Um nicht nur so zugänglich sondern auch so flexibel wie möglich zu sein, kann das Script mit verschiedensten Einstellmöglichkeiten konfiguriert werden.


$('.tabs').accessibleTabs({
    // Der Name der Klasse die dem Div zugewiesen
    // welche um das Markup herumgeschrieben wird
    wrapperClass: 'content',
    // Der Name der Klasse die das aktuelle Tab markiert
    currentClass: 'current',
    // Tag oder valider Query Selector der Elemente 
    // aus denen die Tabs Navigation erzeugt wird
    // (die Originale werden entfernt)
    tabhead: 'h4',
    // Tag oder valider Query Selector der Elemente die
    // als Inhalte der Tabs genutzt werden sollen
    tabbody: '.tabbody',
    // Anzeigeeffekte:  'fadeIn', 'slideDown' oder 'show'
    fx:'show',
    // Geschwindigkeit (String|Number): 'slow', 'normal', oder 'fast')
    // oder die Milisekunden die die Anzeigeeffekte dauern sollen
    fxspeed: 'normal',
    // Text um Screenreadern anzuzeigen welches der ausgewählte Tab ist
    currentInfoText: 'current tab: ',
    // Definition wo der Text eingefügt wird
    // Entwender 'prepend' oder 'append'
    currentInfoPosition: 'prepend',
    // Klasse des span mit dem Infotext
    currentInfoClass: 'current-info'
});
 

Also gut, warum ist dieses Script zugänglicher als andere?

Das, was dieses Script hauptsächlich besser macht als die anderen ist ein Feedback für Nutzer von Screenreadern nach dem Klick. Wenn der Nutzer auf einen der Tabs klickt wird tatsächlich auf der Seite navigiert.

Jeder Link in den Tabs führt tatsächlich zu einem fokusierbaren Inhalt. Um dies zu ermöglichen, erzeugen wir einen benannten Anker in dem zugehörigen Inhalt des Tabs. Dieser Anker, da er keine href-Egenschaft hat, kann von Haus aus aber keinen Fokus erhalten. Um dies zu ermöglichen wird ihm die Eigenschaft tabindex="0" zugewiesen. Warum 0? Weil ein Tabindex von 0 nicht die natürliche Tabordnung des Dokumentes verändert aber dem zugewiesenen Element trotzdem ermöglicht Tab-Fokus zu bekommen.


<h4>
    <a id="accessibletabscontent" name="accessibletabscontent" class="accessibletabsanchor" tabindex="0">
        Eine Beispielüberschrift
    </a>
</h4>
 

In dem benannten Anker wird der selbe Text wie im Tab eingefügt welches gerade geklickt wurde und das ganze mit einer Headline umklammert. Dies stellt eine sehr angenehme Erfahrung für die Nutzer von Screenreadern dar, da es auf nette Art und Weise bestätigt, dass man gerade zu einem anderen Inhalt auf der Seite gesprungen ist.

Ein weiteres Zusatzfeature für Screenreader Nutzer ist ein kleiner Text der auf den aktuell ausgewählten Tab kennzeichnet. Standardmäßig lautet dieser Text "current tab: " gefolgt von dem Standardtext des Tabs. Dieser Text, ebenso wie seine Position (entweder davor oder danach) ist aber sehr leicht internationalisierbar.

Problem: Das Fokussieren von versteckten oder eben noch versteckt gewesenen Elementen

Während dem Testen der Tabs stießen wir auf ein sehr interessantes und ebenso störendes Verhalten des Screenreaders Jaws (und sehr wahrscheinlich auch von anderen). Wir wollten auf die Headline in dem Inhaltselement eines Tabs fokussieren nachdem es eingeblendet wurde. Bei jedem Test war der Screenreader nicht in der Lage das entsprechende Element zu finden und sprach statt dessen um Ende des Dokumentes oder einer anderen zufälligen Position. Dieses Phänomen wird durch den virtuellen Buffer des Screenreaders verursacht, einer internen Kopie des DOMs in dem der Screenreader navigiert. Der virtuelle Buffer gleicht seinen Inhalt regelmäßig mit dem DOM des Browsers ab aber dies ist stets erst nach einer Verzögerung.

Um um dieses Problem herum zu arbeiten nutzen wir einen anderen Lösungsansatz. Der benannte Anker auf den wir verlinken ist tatsächlich nicht in dem versteckten Inhaltselement sondern im DOM davor und "offscreen" (position:absolute;left:-999em) versteckt. Tatsächlich zeigt jeder Tab auf den exakt selben Anker. Wir schreiben den Inhalt des Headline-Elementes einfach jedes mal neu und blenden das zugehörige Inhaltselement entsprechend ein oder aus. Das empfundene Verhalten ist genau das gleiche. Der Screenreader Nutzer klickt auf den Tab, folgt dem Link und findet den verlinkten Inhalt mit der entsprechenden Headline.

Man kann sich das Script hier in in vielen verschiedenen Beispielen in Aktion ansehen. Das jQuery Plugin ist ebenfalls seit der Version 3.1.1 Teil des CSS Framework Yaml.

Man kann das script zusammen mit den demos hier herunterladen. Der gesamte Code ist ebenfalls auf github.

Trackbacks
Wirklich zugängliche Tabs mit jQuery
Vor ca. 1,5 Jahren, im Sommer 2007 sprach ich Dirk Ginader per Skype auf ein kleines Problem an. Damals machte ich gerade meine ersten Schritte mit jQuery und wollte für das Redesign von YAML.de ein Tabscript verwenden, um mehrfache hintereinander aufgelstete Quelltextabschnitte aufgeräumter präsentieren zu können. Zu diesem Zweck sah ich mir verschiedene Tab-Lösungen (mit und ohne jQuery) an, die jedoch alle am gleichen Problem krankten. Die Tabs funktionieren generell nur in Verbindung...
Weblog: High Resolution Weblog
Tracked: Mar 02, 21:11
jQuery Accessible Tabs
Dirk Ginder hat vor einiger Zeit mit einen Kollegen zusammen ein “wirklich” zugängliches “jQuery UI Tab Plugin” geschrieben. Da ich mich in den letzten Wochen stark mit dem xHTML & CSS Framework “YAML” und auch ...
Weblog: fk:Blog - Fabians Weblog
Tracked: Oct 07, 15:34

Comments

Alexander FarkasHallo Dirk,

Gibt es einen Grund warum du einen tabindex von 0 und nicht einen von -1 nimmst? In der Regel will man doch nur selber fokusieren können, aber dem User diese Möglichkeit vorenthalten.

Ich glaube, ich bin auch auf das selbe - von dir oben angesprochene - Problem gestoßen (Leider konnte ich es gerade nicht mehr genau nachstellen.)

Bei mir wurde beim Fokusieren der fokusierte Bereich immer übersprungen und der Inhalt danach vorgelesen.

Meine Lösung war aber eine andere. Ein Delay zwischen sichtbar machen und fokusieren von 180 ms reichte aus. Wenn ich dagegen "Aria-Tab-Semantik" hinzugeügt habe, benötigte ich gar keinen timeout mehr. (Ich habe mich allerdings bei Tabs gegen Aria-Semantik und für einen timeout entschieden).

Grüsse
Alex

P.S.: Du hast noch einen Teil deines englischen Beitrags hier in den deutschen eingefügt. :-)
#1 Alexander Farkas on 2009-02-07 16:09 (Reply)
Dirk GinaderHallo Alexander, danke für die hervorragende Frage.
Mein Kollege Benjamin-Hawkes Lewis, ein wandelndes Lexikon in Sachen Web Development, Browsern und Screenreadern, hat mich auf ein Problem mit tabindex -1 hingewiesen. Opera hat wohl Probleme Elemente mit diesem Tabindex zu fokussieren. Grundsätzlich hast Du aber recht. Ein Tabindex von -1 wäre genau der richtige Ansatz. Aus Kompatibilitätsgründen habe ich aber bewusst darauf verzichtet.

WAI-ARIA ist eine tolle Sache. Leider ist die Unterstützung bei tatsächlich benutzten Browsern und Screenreadern aber noch recht gering. Es spricht zwar absolut nichts dagegen, Webseiten oder Applikationen die bereits zugänglich aufgebaut sind, mit WAI-ARIA noch weiter anzureichern. Sich vollständig darauf zu verlassen ist aber genauso kurzsichtig wie von einer hunderprozentigen Verbreitung von Javascript auszugehen.
Mit dem Delay währe ich sehr vorsichtig. Dieses Timing ist doch sehr systemabhängig und kann je nach Prozessor, Arbeitsspeicher etc. stark variieren.
(Und danke für den Hinweis mit dem englischen Textschnipsel - unfassbar wie ich den immer wieder übersehen habe... ;-) )
#1.1 Dirk Ginader (Homepage) on 2009-02-07 17:03 (Reply)
Alexander FarkasDanke nochmal für die Infos. Ich hoffe Du schreibst weiterhin über sowas und hoffentlich auch weiterhin auf deutsch :-).
#2 Alexander Farkas on 2009-02-08 10:41 (Reply)
Gerhard GroebeHallo, bitte seht die YAML-Version mal im IE6 an: sieht nicht gut aus, Tab-Inhalt rutscht rechts hinter das dritte Tab usw.
Leider ist das Surfen mit dem IE6 immer noch nicht verboten ;-)
Grüße
Gerhard
#3 Gerhard Groebe (Homepage) on 2009-03-06 19:14 (Reply)
Michael FingerSehr Interessanter Artikel, da ich so was auf meiner Seite nutze, zwar als JavaScript Lösung, aber man schau ja immer ob man noch was besseres findet, was für den Benutzer einfacher ist.

Wobei ich mich Frage, ob es immer richtig ist, das man eine Überschrift hat, bei einigen Sachen so wie das unter
http://www.holzwurm-page.de/holzarten/abisza.htm macht es keinen Sinn, das alles mit Überschriften zu versehen oder habe ich da jetzt einen Denkfehler ???
#4 Michael Finger (Homepage) on 2009-04-22 09:12 (Reply)
Dirk GinaderEine gute Überschriftenstruktur ist das A und O einer zugänglichen Webseite. Screenreader nutzen die Headlines einer Seite als primäre Navigationshilfe. Ich bin der Meinung dass Du tatsächlich jedem der Blöcke auf deiner Seite eine Headline geben solltest. Auch die Tabs in den Blöcken wären sinnvolle Headlines. Allerdings nur, wenn sie sinnvoll unter den Block-Headlines unterstrukturiert werden. z.B.:

h1 Holzwurm-Page.de
--h2 Service
--h2 Benutzeranmeldung
--h2 Holzatlas
----h3 A-Z
----h3 Abachi
------h4 Namen
------h4 Verbreitung
------h4 Bearbeitung
----h3 Abarco
------h4 Namen
------h4 Verbreitung
------h4 Bearbeitung
----h3 und so weiter...
--h2 Holz Sprüche
--h2 Ihre Unterstützung

Hope it helps :-)
#4.1 Dirk Ginader (Homepage) on 2009-04-22 10:33 (Reply)
kwurzelSchade finde ich, dass alle Anker die gleiche ID bekommen. Ich weiß nicht. ob das der Zugänglichkeit schadet, aber es wirkt auf jeden Fall "falsch" auf mich. Desweiteren wäre es wunderbar, wenn ich gleich einen Reiter "vorbelegen" könnte, d.h. die ID mit der URL übergeben und sofort den entsprechenden Reiter öffnen könnte.
Soll heißen: Ich setze einen Link auf tabs.html#ueberschrift1 und die Seite wird mit aktivem Tab 1 geöffnet, bei einem Verweis auf tabs.html#ueberschrift4 wird die Seite mit aktivem Tab 4 geöffnet.
Wäre soetwas möglich?

P.S.: Schon einen Plan für die Veröffentlichung von YAML 3.1.1? ;-)
#5 kwurzel on 2009-07-02 14:08 (Reply)
Dirk Ginadersehr gut Idee! Ich habe das direktmal als neuen task im zugehörgen github project angelegt: https://github.com/ginader/Accessible-Tabs/issues/9/find

Danke :-)
#5.1 Dirk Ginader (Homepage) on 2009-07-02 14:44 (Reply)
Christian HallerHallo,
ich kenne die Richtlinien der WAI nicht, aber was mir an eurem Beispiel negativ auffällt, ist die fehlende Unterstützung des Zurückbuttons sowie die Möglichkeit, ein Bookmark auf einen Tab zu setzen. Gibt es einen Grund, weshalb das bei eurer Plugin-Entwicklung nicht beachtet wurde?

http://www.asual.com/jquery/address/samples/tabs/#/extras.html
Beispiel Tabs mit Anchors.
#6 Christian Haller (Homepage) on 2009-07-11 19:05 (Reply)
Dirk GinaderWie ich während des Testens mit Artur feststellen musste verwirrt das umschreiben der URL den Screenreader Jaws gewaltig was leider dazu führt, dass dieser immer wieder zum Anfang der Seite springt.
Wir suche immer noch nach einer Möglichkeit den Backbutton nutzen zu können ohne auf dierse Probleme zu stossen. Für Vorschläge bin ich sehr offen.
#6.1 Dirk Ginader (Homepage) on 2009-07-13 10:03 (Reply)
nikosch» Wir suche immer noch nach einer Möglichkeit den Backbutton nutzen zu können

Ich bin da zwiegespalten. IMHO ist ein Tabreiter eben keine eigene Seite. Weshalb ich es durchaus logischer finde, bspw. von Eurem Beispiellink auch nach ein paar Tab-Drücken via Back-Button wieder auf diese Seite zu kommen. Für Screenreader-Nutzer mag die Erfahrung anders sein (auch wegen der erzeugten Überschriftensystematik), aber das wäre dann ein genereller Punkt, über den man nachdenken sollte. Im Zweifel wäre dann ein regulärer Request einem dynamischen Tabreiterinhalt vorzuziehen.
#6.1.1 nikosch on 2010-02-14 20:00 (Reply)
web development services DubaiDas Ausblenden des Textes wird per CSS gelöst, damit der Text für Screenreader & Co. noch zugänglich ist. Die Styles dafür hast du übernommen, aber sie greifen nur, wenn JS aktiviert ist und ein Element über den Tabs die Klasse »js« verpasst bekommt.
code;
.js .jquery_tabs .current-info,
.js .jquery_tabs .accessibletabsanchor{
position:absolute;
left:-999em;
}
Dazu wird beim Start die Klasse »js« dem html-Element hinzugefügt:

document.documentElement.className += " js";
#7 web development services Dubai (Homepage) on 2009-07-17 12:03 (Reply)
kwurzelLeider tritt bei eurer Tab-Implementation das Problem auf, das auch die originalen jQuery-Tabs haben: http://docs.jquery.com/UI/Tabs#...my_slider.2C_Google_Map.2C_sIFR_etc._not_work_when_placed_in_a_hidden_.28inactive.29_tab.3F

Dort gibt es allerdings einen Work-Around, den man bei eurer Version nicht anwenden kann. Gibt es eine Möglichkeit, auch bei den zugänglichen Tabs problemlos dynamischen JS-Inhalt einzubinden? Ein Bespiel gibt es in der angegebenen URL...
#8 kwurzel (Homepage) on 2009-08-18 10:04 (Reply)
MichaHallo Dirk.

Ich mußte wegen einer Googlemap im Tab dein Script umbauen und habe statt hide() und show() addClass('print') und removeClass('print') verwendet. Der Vorteil der Klasse .print aus dem YAML Core, die Tabs sind nun druckbar, dafür geht Fx nicht mehr. Vielleicht als Idee in den Options konfigrierbar machen: Entweder druckbare Tabs oder EffeKte.

Hier der Hintergrundartikel in meinem Blog.
#9 Micha (Homepage) on 2010-02-14 20:57 (Reply)
Option ITTolle tiefgründige Informationen. Bei der Recherche zur WAI Konformitäten bin ich auf der Suche nach entsprechenden Javascript Möglichkeiten auf dies Thema hier gestoßen, und brauche nicht mehr weitersuchen. Alles auf den Punkt gebracht, was den Übergang von HTML zu JS Passagen mit dem Screenreader flüssig erscheinen (erhören) lässt.
#10 Option IT (Homepage) on 2010-03-23 01:31 (Reply)
Jan Philipp PietrzykHallo Dirk,

Ich bin im Moment im Begriff dein Script in Mootools umzusetzten, da ich leider dieses Framework einsetzten muss und es für eine gute Fingerübung im Bereich Accessibility halte.

Leider habe ich ein paar Fragen, zu der Funktionsweise, die ich hier einfach mal stelle:

1. Warum ist es gewünschtes Verhalten, dass man einmalig ein Tab mit der Tastatur ändern kann und dann nicht weiter?

2. Wie kann man testen ob die document-KeyUp-Listener funktionieren und was ist deren Funktion? (Die sind doch nur aktive, wenn der div-Container Fikus hat?)

Ich hoffe ich nerv nicht zu sehr rum, aber irgendwie muss man sowas ja lernen...

MFG Jan
#11 Jan Philipp Pietrzyk (Homepage) on 2010-03-23 12:11 (Reply)
Dirk GinaderIch freue mich sehr über deine Initiative eine Mootools Version zu erstellen. Bitte lass mich wissen wenn sie fertig ist und wo sie zu finden sein wird! Zu deinen Fragen:

1. Das Verhalten dass du beschreibst ist der focus wechsel nach einem click auf einen tab. Der focus wandert nach einem click in den aktiven tabinhalt anstatt auf dem tab zu verbleiben. Dies ist notwendig um Screenreader nutzern den ausgewählten Inhalt zu zeigen.In die Tabnavigation zurückzukehren kann man mit shift+tab. Dort funktioniert dann auch die cursor key navigation wieder

2. um key events zu testen lässt du dir am besten einen debug meldung in die konsole schreiben. Die events sollten and die root node der tab liste angebracht werden damit sie nur dort funktionieren.
#11.1 Dirk Ginader (Homepage) on 2010-03-23 16:15 (Reply)
FlorianHallo,

Super Infos die du geschrieben hast. Danke und weiter so!

Bye
#12 Florian (Homepage) on 2010-09-16 14:56 (Reply)
Carolin MOllIch finde diese Lösung fantastisch – vielen Dank dafür!

Mit relativ wenig Erfahrung mit Javascript versuche ich gerade verzweifelt, die Position der "Tabs" –" ok, dann sind es keine mehr, nach unten zu schieben, was mir leider nicht gelingt. Ich möchte also keine Tabs, sonderne eine Linkliste unterhalb des wechselnden Contents. Ich wäre mega dankbar für eine kurze Antwort, falls die Position ohne großen Aufwand änderbar ist!

Viele Grüße
Carolin
#13 Carolin MOll on 2010-09-21 19:03 (Reply)
MichaelHallo,

habe ich mit diesem Skript auch die Möglichkeit die Tabs ein 2 oder mehr Zeilen anzuordnen, wenn ja wie?
Werden die Tabs durch die definierte Breit umgebrochen habe ich zwar mehr Zeilen, jedoch springt das ganze unschön bei einer aktuellen tabauswahl, dann kann es passieren das die vorher zweizeiligen Tabs plötzlich 3 haben und in der 2. Zeile nicht mehr ganz links beginnen.

Über Hilfe wäre ich dankbar.
Grüße
Michael
#14 Michael on 2010-10-26 10:56 (Reply)
Dirk GinaderKannst Du mir irgendwo ein Codebeispiel zeigen?
#14.1 Dirk Ginader (Homepage) on 2010-10-26 17:51 (Reply)
Till GrohmannDas passiert durch das CSS in der Zeile .tabs ul.tabs-list .current a
wo ein paddig-bottom kommt. Wenn man das weglässt, gibt es dieses Problem nicht. Dafür wäre eine Lösung interessant bei der mehrzeiligen Tabreitern der aktive Tabreiter in der letzten Zeile steht falls das möglich ist.
#14.1.1 Till Grohmann on 2011-03-23 11:27 (Reply)
JörgHallo im Rund, Hallo Dirk,
Danke für die Tabs, gute Sache! Ich habe hier ein interessantes Problem: Ein (Google Web-) Font wird nur innerhalb der Tabs nicht richtig gerendert und zwar auch nur dann, wenn man mit Citrix oder XEN Server auf die betreffende Website zugreift. Ich weiß, far out, aber immerhin. Hat da schon mal jemand von gehört? Gibt es einen Lösungsansatz?

Viele Grüße
Jörg
#15 Jörg on 2013-01-30 18:52 (Reply)
Dirk GinaderWow das ist mal extrem long tail. Hast du ein beispiel online?
#15.1 Dirk Ginader (Homepage) on 2013-01-30 23:57 (Reply)
JörgJa, unter www.joergo.de/tabs/references.html steht eine Variante. Nicht wundern, ist leicht abgestrippt die Seite. Über Teamviewer sieht das alles normal aus, CITRIX oder XEN kann ich leider nicht simulieren.
#15.1.1 Jörg on 2013-01-31 10:10 (Reply)
Dirk Ginaderhmpf. sorry. da kann ich leider gar nicht helfen. Habe weder CITRIX noch XEN zum testen.
#15.1.1.1 Dirk Ginader (Homepage) on 2013-01-31 18:00 (Reply)
PVCHallo Zusammen.

Wo kann ich den die Reiter-Buttons bearbeiten?
Ich möchte gerne die Reiter mit der Öffnung nach oben haben, damit ich Sie an den oberen Rand ansetzen kann. Schön wäre es auch wenn der aktive Tab ein wenig weiter nach unten ausfahren würde.

Danke
Thomas
#16 PVC on 2013-03-23 14:34 (Reply)
Dirk GinaderDas ist einfach nur CSS. Das Aussehen der Reiter in den Demos hat nichts mit der Funktionalität zu tun.
#16.1 Dirk Ginader on 2013-03-26 15:39 (Reply)
Carolin MollIch nutze die super Lösung für wirklich zugängliche Tabs schon lange. Ich habe mit der aktuellsten Version nur gerade folgendes Problem: die synchheight-Methode funktioniert nicht, wenn ich sie über syncheights:true setze.
Es wird zwar eine min-height berechnet, aber sie stimmt wohl nicht (ist zu klein, so dass der Container beim nächsten, größeren Tab nach unten springt)

Nur wenn ich das separat über einen eigenen Aufruf $('.tabbody').unSyncHeight();

starte, klappt die Berechnung.
Ist es ein nicht entdeckter Bug der neueren Version?

Viele Grüße
Carolin
#17 Carolin Moll on 2013-04-01 17:16 (Reply)
Dirk GinaderHm. Hast du ein Beispiel dass ich mit anschauen kann?
#17.1 Dirk Ginader (Homepage) on 2013-04-08 18:05 (Reply)
Add Comment

Standard emoticons like :-) and ;-) are converted to images.
E-Mail addresses will not be displayed and will only be used for E-Mail notifications

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA

Gravatar/Favatar/Pavatar/MyBlogLog author images supported.
You can use [geshi lang=javascript/css/html4strict/php]your code[/geshi] tags to embed source code snippets