nicht angemeldet
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