nicht angemeldet
dynamisches CSS-Menü barrierefrei?
Hallo,
ich habe eine Hauptnavigation und eine Bereichsnavigation.
Die Hauptnavigation ist im Moment nur eine Liste aus Links zu
den "Hauptseiten" ohne deren Unterseiten (scheint mir gut zu
sein, da so blinden Besuchern nur diese "Hauptseiten" vom
Screenreader vorgelesen werden und nicht auch noch deren
zahlreiche Unterseiten). Habe mal gelesen, daß es für blinde
Besucher ziemlich nervig sein soll, sich alles mit Unterseiten
vorlesen zu lassen. Die Unterseiten werden dann halt in der
Bereichsnavigation eingeblendet.
Jetzt meine Frage:
Wenn ich die Hauptnavigation in ein dynamisches CSS-Menü
(mit allen Unterseiten) umgestalte - liest der Screenreader
auch alle Unterseiten (unerwünschterweise!) mit vor?
Oder allgemeiner:
Schaden dynamische CSS-Menüs der Barrierefreiheit oder schaden
sie nicht und sind einfach nur eine Bereicherung für den sehenden
Besucher?
Viele Grüße!
nickyname
-
Hallo,
Jetzt meine Frage:
Wenn ich die Hauptnavigation in ein dynamisches CSS-Menü
(mit allen Unterseiten) umgestalte - liest der Screenreader
auch alle Unterseiten (unerwünschterweise!) mit vor?Betrachte deine Seite _ohne_ CSS - dann siehst du, was ein Screenreader sieht und entsprechend in welcher Reihenfolge vorliest (in der Regel jedenfalls).
Oder allgemeiner:
Schaden dynamische CSS-Menüs der Barrierefreiheit oder schaden
sie nicht und sind einfach nur eine Bereicherung für den sehenden
Besucher?Meiner Meinung nach sollte man darauf (für die Mehrheit) nicht verzichten. Für diesen Zweck gibt es dann ja noch die sog. "Skip Links".
Gruß Gunther
-
Hallo Gunter,
danke für Deine Antwort.
Demnach sind dyn. CSS-Menüs nicht uneingeschränkt barrierefrei
(einen jederzeitiger Ausstieg per Skip Link ließe sich unangenehmer
Weise nur durch Skip Links hinter jedem Listenelement erreichen -
was beim Zuhören wohl ziemlich bald nerven würde).Ansonsten bin ich aber absolut Deiner Meinung. Da meine aktuelles
Projekt aber "extrem" barrierfrei sein soll, werde ich wohl für
dieses Projekt von dieser Menüart abrücken. Schade eigentlich.Viele Grüße!
nickyname
-
Für alle, die das Thema interessiert:
Die Seite
http://www.einfach-fuer-alle.de/artikel/menues/tag5/
welche sich ausschließlich mit dem Thema Barrierefreiheit
beschäftigt, sieht solche dyn. Menüs mitunter auch kritisch
(das Ganze wird in einem kurzen Absatz beleuchtet).nickyname
-
Hallo nickyname,
danke für Deine Antwort.
Demnach sind dyn. CSS-Menüs nicht uneingeschränkt barrierefrei
na ja, das ist wohl im Zweifelsfall eine Definitionsfrage. Sie verhindern ja nicht den Zugriff oder schränken die Zugänglichkeit ein. Von daher eigentlich schon "barrierefrei". Nur speziell für Nutzer auraler Ausgabemedien extrem "lästig".
(einen jederzeitiger Ausstieg per Skip Link ließe sich unangenehmer
Weise nur durch Skip Links hinter jedem Listenelement erreichen -
was beim Zuhören wohl ziemlich bald nerven würde).Nein, üblicherweise hat man auch nur einen Skip Link _vor_ dem Menü, um selbiges komplett zu überspringen.
Leider habe ich aber bis heute noch nirgendwo mal vernünftige Quellen gefunden, wo sich gerade mal solche User dazu äußern, wie eine Website aufgebaut sein sollte, damit sie für sie möglichst benutzerfreundlich ist.
EfA kenne ich natürlich auch, aber wenn du mal andere Quellen zum Thema findest, würde ich mich über einen entsprechenden Link (Email siehe oben) freuen - Danke!
Gruß Gunther
-
-
Hi,
Betrachte deine Seite _ohne_ CSS - dann siehst du, was ein Screenreader sieht
diese Generalisierung ist unzulässig!
Die meisten Screenreader unterstützen CSS bzw. setzen auf CSS-Fähigen Browsern auf. Demzufolge kann man alternative Inhalte für Sreenreader auch nicht einfach über display:none vor anderen Usern verstecken, sondern muss immer kompliziertere Methoden austüfteln.
Daher werden so ausgeblendete Untermenüs in den allermeisten Fällen auch nicht vorgelesen und stellen somit auch keine zusätzliche Barriere dar - vorausgesetzt natürlich, dass der Hauptmenüpunkt verlinkt ist und hierin dann die Untermenüpunkte zur Verfügung stehen.freundliche Grüße
Ingo-
Hi Ingo,
Betrachte deine Seite _ohne_ CSS - dann siehst du, was ein Screenreader sieht
diese Generalisierung ist unzulässig!
ist klar, wenn du den extra angebrachten Zusatz beim Zitieren weglässt ;-)!
Ich wollte es mir in diesem Zusammenhang ersparen, auch noch auf das Kapitel "Screenreader und display:none" einzugehen, da es m.E.n. in diesem Fall eher von geringerer Bedeutung ist, denn es sollte ja nicht das Menü ausgeblendet werden, sondern vielmehr ein Skip Link angeboten werden, zum Überspringen der Navigation/ des Menüs bspw. in einem Screenreader.Die meisten Screenreader unterstützen CSS bzw. setzen auf CSS-Fähigen Browsern auf.
Da geht es ja schon los: Welche sind denn "die meisten", bzw. welche kennen denn wohl überhaupt die meisten? Was ist mit "den anderen"? Und woher soll man dann noch wissen, welche CSS-Fähigkeiten und "Besonderheiten" dieser und jener dann hat? Das ist ja bei "normalen" Browsern schon kaum zu überblicken.
Demzufolge kann man alternative Inhalte für Sreenreader auch nicht einfach über display:none vor anderen Usern verstecken, sondern muss immer kompliziertere Methoden austüfteln.
Welche denn bspw.? Ist es nicht einfacher, diese alternativen Inhalte im Screen-Style per display:none zu verbergen?
Daher werden so ausgeblendete Untermenüs in den allermeisten Fällen auch nicht vorgelesen und stellen somit auch keine zusätzliche Barriere dar - vorausgesetzt natürlich, dass der Hauptmenüpunkt verlinkt ist und hierin dann die Untermenüpunkte zur Verfügung stehen.
Das habe ich jetzt nicht verstanden. Wie werden die Untermenüs denn jetzt ausgeblendet, damit sie von Screenreadern nicht vorgelesen werden? Und warum sollte man das tun? Und seit wann ist ein korrektes Menü eine Barriere?
Gruß Gunther
-
Hi,
Ich wollte es mir in diesem Zusammenhang ersparen, auch noch auf das Kapitel "Screenreader und display:none" einzugehen, da es m.E.n. in diesem Fall eher von geringerer Bedeutung ist, denn es sollte ja nicht das Menü ausgeblendet werden, sondern vielmehr ein Skip Link angeboten werden, zum Überspringen der Navigation/ des Menüs bspw. in einem Screenreader.
Nein. Es geht hier um die Frage, ob (üblicherweise per display:none ausgeblendete) Untermenüpunkte von Sreenreadern vorgelesen werden. Und dies ist i.d.R. nicht der Fall.
Die meisten Screenreader unterstützen CSS bzw. setzen auf CSS-Fähigen Browsern auf.
Da geht es ja schon los: Welche sind denn "die meisten", bzw. welche kennen denn wohl überhaupt die meisten?die meisten setzen auf den IE auf und selbst der kann display:none umsetzen.
Was ist mit "den anderen"?
Nur mal auf die Schnelle herausgesucht: http://forum.de.selfhtml.org/archiv/2007/6/t154240/#m1003964
Demzufolge kann man alternative Inhalte für Sreenreader auch nicht einfach über display:none vor anderen Usern verstecken, sondern muss immer kompliziertere Methoden austüfteln.
Welche denn bspw.? Ist es nicht einfacher, diese alternativen Inhalte im Screen-Style per display:none zu verbergen?wie bitte? Überlege doch selbst mal, was Du da schreibst.
Daher werden so ausgeblendete Untermenüs in den allermeisten Fällen auch nicht vorgelesen und stellen somit auch keine zusätzliche Barriere dar - vorausgesetzt natürlich, dass der Hauptmenüpunkt verlinkt ist und hierin dann die Untermenüpunkte zur Verfügung stehen.
Das habe ich jetzt nicht verstanden. Wie werden die Untermenüs denn jetzt ausgeblendet, damit sie von Screenreadern nicht vorgelesen werden? Und warum sollte man das tun? Und seit wann ist ein korrektes Menü eine Barriere?Hierbei geht es nicht um Untermenüs, sondern um alternative Inhalte für Screenreaderm z.B. für grafische Überschriften, siehe Fahrner Image Replacement.
freundliche Grüße
Ingo-
Hi,
Ich wollte es mir in diesem Zusammenhang ersparen, auch noch auf das Kapitel "Screenreader und display:none" einzugehen, da es m.E.n. in diesem Fall eher von geringerer Bedeutung ist, denn es sollte ja nicht das Menü ausgeblendet werden, sondern vielmehr ein Skip Link angeboten werden, zum Überspringen der Navigation/ des Menüs bspw. in einem Screenreader.
Nein. Es geht hier um die Frage, ob (üblicherweise per display:none ausgeblendete) Untermenüpunkte von Sreenreadern vorgelesen werden. Und dies ist i.d.R. nicht der Fall.Ah, ich glaube jetzt verstehe ich, worauf du hinaus willst. Du gehst davon aus, dass die Untermenüpunkte eines CSS-Menüs ja normalerweise per display:none ausgeblendet werden (und nur per hover wieder eingeblendet werden), und somit von einem Screenreader sowieso nicht vorgelesen werden. Richtig? Ich bin davon ausgegangen, dass das display:none an das Screen Stylesheet gebunden ist, und für Screenreader der Media Type "aural" zutrifft, ebenso wie:
[Zitat aus http://www.w3.org/TR/REC-CSS2/aural.html]
"The aural rendering of a document, already commonly used by the blind and print-impaired communities, combines speech synthesis and "auditory icons." Often such aural presentation occurs by converting the document to plain text and feeding this to a screen reader -- software or hardware that simply reads all the characters on the screen. This results in less effective presentation than would be the case if the document structure were retained. Style sheet properties for aural presentation may be used together with visual properties (mixed media) or as an aural alternative to visual presentation."Unter Berücksichtigung des letzten Satzes, muss man wohl auch die Einstellungen aus dem Scrren Style mit berücksichtigen. Wobei ich dann allerdings nach wie vor die Auffassung vertrete, dass auch für die Screenreader alle Menüpunkte verfügbar sein sollten. Denn warum sollte man diesen Usern die direkte Navigation vorenthalten und sie zwingen Zwischenschritte machen zu müssen, _ohne_ vorher überhaupt über die jeweiligen Unterpunkte informiert zu sein!?
Und da ich ferner davon ausgehe, dass Usern, die Screenreader verwenden, im zweifelsfall auch keine Maus für Hover-Effekte zur Verfügung steht, es aber dafür andererseits nicht auf das visuelle Layout ankommt, kann die Navi also folglich ruhig als komplette UL Liste erscheinen.Die meisten Screenreader unterstützen CSS bzw. setzen auf CSS-Fähigen Browsern auf.
Da geht es ja schon los: Welche sind denn "die meisten", bzw. welche kennen denn wohl überhaupt die meisten?
die meisten setzen auf den IE auf und selbst der kann display:none umsetzen.Was ist mit "den anderen"?
Nur mal auf die Schnelle herausgesucht: http://forum.de.selfhtml.org/archiv/2007/6/t154240/#m1003964Ich kann mich halt noch an die Zeiten erinnern, wo die Mehrheit der verwendeten Screenreader display:none sehr wohl vorgelesen haben. Außerdem erscheint mir, dass du dir selber widersprichst, wenn du schreibst: "Die meisten Screenreader unterstützen CSS bzw. setzen auf CSS-Fähigen Browsern auf. Demzufolge kann man alternative Inhalte für Sreenreader auch nicht einfach über display:none vor anderen Usern verstecken, sondern muss immer kompliziertere Methoden austüfteln.
Daher werden so ausgeblendete Untermenüs in den allermeisten Fällen auch nicht vorgelesen ...". Einerseits schreibst du, dass man Inhalte _nicht_ einfach per display:none verstecken kann, andererseits sagst du im nächsten Satz, dass per display:none ausgeblendete Inhalte _nicht_ vorgelesen werden.Demzufolge kann man alternative Inhalte für Sreenreader auch nicht einfach über display:none vor anderen Usern verstecken, sondern muss immer kompliziertere Methoden austüfteln.
Welche denn bspw.? Ist es nicht einfacher, diese alternativen Inhalte im Screen-Style per display:none zu verbergen?
wie bitte? Überlege doch selbst mal, was Du da schreibst.Ja, habe ich schon bevor ich es schrieb ;).
1.) Warum braucht es überhaupt "alternative Inhalte" für Screenreader?
2.) Ich gehe nach wie vor davon aus, dass Screenreader Styles für den Typ aural anwenden. Wenn ich also schon verschiedene Inhalte für Screen und Aural haben will, warum dann nicht im Screen-Style display:none und im Aural-Style vorlesen lassen? Wie du ja selbst geschrieben hast, kann selbst der IE display:none korrekt umsetzen.Daher werden so ausgeblendete Untermenüs in den allermeisten Fällen auch nicht vorgelesen und stellen somit auch keine zusätzliche Barriere dar - vorausgesetzt natürlich, dass der Hauptmenüpunkt verlinkt ist und hierin dann die Untermenüpunkte zur Verfügung stehen.
Das habe ich jetzt nicht verstanden. Wie werden die Untermenüs denn jetzt ausgeblendet, damit sie von Screenreadern nicht vorgelesen werden? Und warum sollte man das tun? Und seit wann ist ein korrektes Menü eine Barriere?
Hierbei geht es nicht um Untermenüs, sondern um alternative Inhalte für Screenreaderm z.B. für grafische Überschriften, siehe Fahrner Image Replacement.Aha, wie kommst du denn jetzt von CSS-Menüs zu grafischen Überschriften, die ein IRP erfordern?
Gruß Gunther
-
Hi,
Ah, ich glaube jetzt verstehe ich, worauf du hinaus willst. Du gehst davon aus, dass die Untermenüpunkte eines CSS-Menüs ja normalerweise per display:none ausgeblendet werden (und nur per hover wieder eingeblendet werden), und somit von einem Screenreader sowieso nicht vorgelesen werden. Richtig?
Ja, genau das meine ich.
Unter Berücksichtigung des letzten Satzes, muss man wohl auch die Einstellungen aus dem Scrren Style mit berücksichtigen. Wobei ich dann allerdings nach wie vor die Auffassung vertrete, dass auch für die Screenreader alle Menüpunkte verfügbar sein sollten. Denn warum sollte man diesen Usern die direkte Navigation vorenthalten und sie zwingen Zwischenschritte machen zu müssen, _ohne_ vorher überhaupt über die jeweiligen Unterpunkte informiert zu sein!?
Ganz einfach aus Gründen der Usability. Eine Seite sollte eine möglichst geringe und damit überschaubare Anzahl von Navigationspunkten haben, wenn möglich nicht mehr als 7. Diese 7 Hauptmenüpunkte mal angenommen mit jeweils 7 Unterpunkten ergäben schon 49 Links. Diese würde ich weder einem Sehenen komplett auf einer Seite präsenieren, noch von einem Screenreader vorlesen lassen. Die dynamische Einblendung kann zwar einerseits etwas verwirrend sein, andererseits aber auch die Nutzbarkeit verbessern.
Ich kann mich halt noch an die Zeiten erinnern, wo die Mehrheit der verwendeten Screenreader display:none sehr wohl vorgelesen haben. Außerdem erscheint mir, dass du dir selber widersprichst, wenn du schreibst: "Die meisten Screenreader unterstützen CSS bzw. setzen auf CSS-Fähigen Browsern auf. Demzufolge kann man alternative Inhalte für Sreenreader auch nicht einfach über display:none vor anderen Usern verstecken, sondern muss immer kompliziertere Methoden austüfteln.
Daher werden so ausgeblendete Untermenüs in den allermeisten Fällen auch nicht vorgelesen ...". Einerseits schreibst du, dass man Inhalte _nicht_ einfach per display:none verstecken kann, andererseits sagst du im nächsten Satz, dass per display:none ausgeblendete Inhalte _nicht_ vorgelesen werden.So ist es auch. Du hast mich missverstanden - ich meinte: alternative Inhalte für Screenreader vor den übrigen (sehenden) Usern so verstecken, dass sie von Screenreadern noch vorgelesen werden und eben nicht auch vor ihnen versteckt werden.
Früher ging das in der Tat einfach über display:none - heute aber nicht mehr, weil die Screenreader ihr Bestes tun um möglichst das auszugeben, was auch auf dem Bildschirm (und eben nicht nur im Quelltext) zu sehen ist.1.) Warum braucht es überhaupt "alternative Inhalte" für Screenreader?
u.U. ja, siehe z.B. Fahrner Image Replacement.
2.) Ich gehe nach wie vor davon aus, dass Screenreader Styles für den Typ aural anwenden.
das sollten sie, aber ich fürchte, dass zumindest die Screenreader, die auf dem IE aufsetzen, damit nichts anfangen können.
Daher werden so ausgeblendete Untermenüs in den allermeisten Fällen auch nicht vorgelesen und stellen somit auch keine zusätzliche Barriere dar - vorausgesetzt natürlich, dass der Hauptmenüpunkt verlinkt ist und hierin dann die Untermenüpunkte zur Verfügung stehen.
Das habe ich jetzt nicht verstanden. Wie werden die Untermenüs denn jetzt ausgeblendet, damit sie von Screenreadern nicht vorgelesen werden? Und warum sollte man das tun? Und seit wann ist ein korrektes Menü eine Barriere?Wie ich schon schrieb: über display:none werden sie auch für die allermeisten Screenreader ausgeblendet, so dass die Übersicht - wie für normale Nutzer auch - gewahrt bleibt. Lediglich das Gimmick der Direktauswahl entfällt.
Aha, wie kommst du denn jetzt von CSS-Menüs zu grafischen Überschriften, die ein IRP erfordern?
Als Beispiel dafür, dass display:none eben nicht mehr ausreicht zum Ausblenden aternativer Inhalte, die für Screenreader nutzbar sein sollen.
freundliche Grüße
Ingo
-
-
-
-
-
-
Hallo,
Schaden dynamische CSS-Menüs der Barrierefreiheit oder schaden
sie nicht und sind einfach nur eine Bereicherung für den sehenden
Besucher?Meiner Meinung nach ja. Die Menüs werden ja mit Javascript realisiert, oder meinst du was anderes? Wenn Javascript, dann hat dies folgende Nachteile:
- Links in den Menüs können von Suchmaschinen schlecht bzw. überhaupt nicht angesteuert werden.
- Mögliche Probleme bei PDA-Usern
- Und je nach dem wie das Menü realisiert wird (mouse over, etc.) schließt es auch User aus, die ohne Mouse unterwegs sind oder nur schlecht mit der Mouse umgehen können (bedingt durch Behinderung oder Ähnlichem).
Schöne Grüße
Rosanna-
Hallo Rosanna!
Schaden dynamische CSS-Menüs ...
Meiner Meinung nach ja. Die Menüs werden ja mit Javascript realisiert, oder meinst du was anderes?
Ja, CSS-Menüs.
Allerdings gelten einige der Punkte auch für CSS-Menüs.
- Mögliche Probleme bei PDA-Usern
- Und je nach dem wie das Menü realisiert wird (mouse over, etc.) schließt es auch User aus, die ohne Mouse unterwegs sind oder nur schlecht mit der Mouse umgehen können (bedingt durch Behinderung oder Ähnlichem).
Hover-Effekte bedingen eigentlich immer die Bedienung per Maus. Wo das nicht möglich ist, sollte man entsprechende Alternativen vorsehen.
Dies lässt sich bspw. durch ein extra Stylesheet für Handhelds realisieren. Und last but not least sollte man auf seiner Site immer einen Link zu einer Text-only Version anbieten, d.h. ohne alle Styles, wo dann ein CSS-Menü meist als UL Liste zur Verfügung steht (die entsprechenden Skip Links nicht vergessen), womit die o.g. "Nachteile" beseitigt sind.
Gruß Gunther
PS: Eigentlich wollte ich schon viel früher geantwortet haben, aber mein Provider (Netcologne) hatte eine technische Störung und ich somit bis gerade keinen Onlinezugang.
-
Hallo Gunter,
Hover-Effekte bedingen eigentlich immer die Bedienung per Maus. Wo das nicht möglich ist, sollte man entsprechende Alternativen vorsehen.
Die Knackpunkt ist für mich der Einsatz von Javascript. Habe ich ein einfache Hover über CSS definiert, so gehen - wenn das nicht funktioniert oder angewandt werden kann - keine wesentlichen Informationen verloren, z. B. Bildwechsel (Layoutbild) bei hover. Außerdem kann ich hier ganz locker ausweichen, indem ich die selben Informationen auch einem a:focus zuweise.
Bei einem Pop-Up-Menü allerdings kommt der User nur weiter, wenn er mit der Mouse über einen Menüpunkt fährt und wenn Javascript aktiviert ist. D. h. die weiteren Seiten sind nur dann zugänglich, was ja einen wesentlichen Informationsverlust bedeutet.
Bei den meisten PC-Nutzern ist Javascript aktiviert, am PDA-Sektor sieht es hier sicher anders aus.
Dies lässt sich bspw. durch ein extra Stylesheet für Handhelds realisieren. Und last but not least sollte man auf seiner Site immer einen Link zu einer Text-only Version anbieten, d.h. ohne alle Styles, wo dann ein CSS-Menü meist als UL Liste zur Verfügung steht (die entsprechenden Skip Links nicht vergessen), womit die o.g. "Nachteile" beseitigt sind.
Ja, aber du brauchst auch eine Alternative zum Javascript, d. h. das Menü müsste dann doppelt aufgebaut werden, sehe ich das richtig? Zum Text-Only: Jein, aus meiner Sicht eine bequeme und kostengünstige Alternative für PDAs, um nicht die ganze CSS komplett neu aufsetzen zu müssen. Das BITV sagt aber eindeutig - keine Textversionen. Kommt sicher darauf an, bis zu welchem Grad die Seite den Richtlinien entsprechen soll bzw. muss.
LG
Rosanna-
Hallo Rosanna,
Hover-Effekte bedingen eigentlich immer die Bedienung per Maus. Wo das nicht möglich ist, sollte man entsprechende Alternativen vorsehen.
Die Knackpunkt ist für mich der Einsatz von Javascript.
löse dich doch bitte mal von deinem Javascript ;-). Wir reden doch hier von reinen CSS-Lösungen. Javascript kann, und da sind wir uns ja einig, immer nur eine Ergänzung sein, niemals eine Grundvoraussetzung.
Habe ich ein einfache Hover über CSS definiert, so gehen - wenn das nicht funktioniert oder angewandt werden kann - keine wesentlichen Informationen verloren, z. B. Bildwechsel (Layoutbild) bei hover. Außerdem kann ich hier ganz locker ausweichen, indem ich die selben Informationen auch einem a:focus zuweise.
Ja, man muss nur halt dran denken, bzw. sich vergegenwärtigen, dass bspw. auf PDAs, die mit einem Stift bedient werden, keine Hover-Effekte möglich sind.
Bei einem Pop-Up-Menü allerdings kommt der User nur weiter, wenn er mit der Mouse über einen Menüpunkt fährt und wenn Javascript aktiviert ist. D. h. die weiteren Seiten sind nur dann zugänglich, was ja einen wesentlichen Informationsverlust bedeutet.
Nein! Es geht um Javascript freie reine CSS-Menüs (s.o.)!
Von daher ist der Rest deines Postings ebenfalls nicht zutreffend (in diesem Fall).Bei den meisten PC-Nutzern ist Javascript aktiviert, am PDA-Sektor sieht es hier sicher anders aus.
Ja, aber du brauchst auch eine Alternative zum Javascript, d. h. das Menü müsste dann doppelt aufgebaut werden, sehe ich das richtig? Zum Text-Only: Jein, aus meiner Sicht eine bequeme und kostengünstige Alternative für PDAs, um nicht die ganze CSS komplett neu aufsetzen zu müssen. Das BITV sagt aber eindeutig - keine Textversionen. Kommt sicher darauf an, bis zu welchem Grad die Seite den Richtlinien entsprechen soll bzw. muss.
Gruß Gunther
-