Das Testen der Barrierefreiheit mit Bildschirmleseprogrammen: Fragen und Antworten

Übersetzung eines Artikels von: https://www.webaim.org/articles/screenreader_testing/

Titel des Originals: Testing with Screen Readers: Questions and Answers

Anmerkung des Übersetzers - translators note:

Soweit möglich, habe ich mich beim Übersetzen an den Wortlaut der Original-Version gehalten. Sollten hierbei Fehler entstanden sein oder der Inhalt nicht verständlich sein, bitte ich um eine Nachricht an Vianos Web Design per E-Mail an kontakt (at) vianos.de. Die englische Abkürzung für Alternativen Text mit "alt" -text, wurde übernommen, da diese Abkürzung auch im Deutschen Sprachgebrauch geläufig ist.

Welche Vorteile bietet das Testen von Web-Inhalten mit Bildschirmleseprogrammen?

Web-Inhalte hörend statt sehend wahrzunehmen kann in der Tat "die Augen öffnen" (entschuldigen Sie das Paradoxon) und sehenden Nutzern den normalerweise gewohnten Komfort deutlich machen. Sehende Nutzer erhalten hierdurch die Möglichkeit, Ihre Inhalte aus einer völlig anderen Perspektive wahrzunehmen: der eines blinden Menschen. Sie werden sehr häufig Fehler finden, die Ihnen bei einer rein optischen Wahrnehmung nicht aufgefallen wären. Rechtschreibfehler werden beispielsweise viel offensichtlicher, wenn Sie die Wörter vom Bildschirmleseprogramm falsch buchstabiert hören. Bildschirmleseprogramme sind außerdem sehr gut geeignet um die Genauigkeit und Qualität der alt Texte zu überprüfen. Neulich habe ich eine Webseite angehört und festgestellt dass alt Text komplett falsch verwendet wurde. Die graphische Darstellung zeigte "Suchen" wohingegen der alt Text "Optionen" auswies. Es hat einen Moment gedauert, bis ich dahinter gekommen bin warum das Bildschirmleseprogramm nicht den alt Text für das "Suchen" - Feld vorgelesen hat. Das Bildschirmleseprogramm hat nämlich einfach nur den alt Text vorgelesen - auch wenn dieser falsch war. Bildschirmleseprogramme können auch helfen, Probleme zu identifizieren bei der Lesereihenfolge, bei Tabellenbezeichnungen, bei Formularelementen und bei vielen weiteren Aspekten der Barrierefreiheit.

Sollte ich die Barrierefreiheit meiner Web-Inhalte grundsätzlich mit einem Bildschirmleseprogramm testen?

Das kommt ganz darauf an. Wenn Ihnen klar ist, wie ein Bildschirmleseprogramm funktioniert, kann so ein Test außerordentlich nützlich sein. Wenn Sie sich mit der Bedienung allerdings nicht auskennen, kann das Testen frustrierend und kontraproduktiv sein. Tatsächlich könnte man fälschlicherweise zu dem Schluss gelangen, das nahezu alle Inhalte die man erstellt hat, nicht barrierefrei zugänglich sind. Einfach weil das eigentliche Problem darin besteht, dass man sich mit der richtigen Benutzung eines Bildschirmleseprogramms nicht auskennt. WebAIM bietet Ihnen Artikel wie Barrierefreiheit mit JAWS testen und Barrierefreiheit mit NVDA testen die Ihnen die grundsätzliche Verwendung von gebräuchlichen Bildschirmleseprogrammen erklären.

Wenn ich mich mit einem Bildschirmleseprogramm nicht auskenne, brauche ich also gar nicht erst anzufangen?

Nun ja, das wäre wohl die bequemste Möglichkeit. Aber bevor Sie sich damit entschuldigen, lassen Sie uns einen Blick darauf werfen, was Sie dann verpassen würden. In erster Linie sind die Benutzer von Bildschirmleseprogrammen Nutznießer Ihrer Anstrengungen. Also macht es Sinn sich mit deren Bedürfnissen auseinander zu setzen. Natürlich dürfen Sie jetzt nicht den Fehler machen und glauben, dass Barrierefreiheit ausschließlich für Nutzer von Bildschirmleseprogrammen relevant ist. Zu häufig konzentriert man sich auf ausschließlich auf blinde Menschen und grenzt damit andere Behinderte ( Bewegungbehinderung, Gehörbehinderung, eingeschränkte Wahrnehmungsfähigkeit, eingeschränkte Sehkraft etc.), deren Bedürfnisse genauso relevant sind, aus. Da es hier aber um das Testen mittels Bildschirmleseprogrammen geht, schauen wir uns die speziellen Anforderungen hierfür näher an.

Obwohl ein Bildschirmleseprogramm kein Internetzugangsprogramm wie Firefox, Opera, Safari und Internet-Explorer ist (tatsächlich basieren Bildschirmleseprogramme in den meisten Fällen allerdings auf solchen Internet Zugangsprogrammen), ermöglichen Bildschirmleseprogramme den Zugriff auf Web-Inhalte anders, als wenn sehende Menschen Internetzugangsprogramme verwenden. Wenn Sie diese Unterschiede nicht verstehen, können Sie die Herausforderungen für Benutzer eines Bildschirmleseprogramms nicht nachvollziehen und damit nicht effektiv für diese Nutzergruppe Inhalte entwickeln.

Was sind die Hauptunterschiede beim Zugriff auf Web-Inhalte zwischen sehenden Nutzern und Nutzern von Bildschirmleseprogrammen?

Blinde Nutzer greifen auf völlig andere Weise als sehende Nutzer auf Web-Inhalte zu. Zunächst bedingen Bildschirmleseprogramme die Benutzung von Tastenkürzeln, welche der Nutzer zum Großteil auswendig kennen muss. Sehende benutzen hingegen die Maus zur Navigation. Sie sind es außerdem gewöhnt, eine Seite visuell - in alle Richtungen nahezu gleichzeitig - zu untersuchen. Auf beide Gewohnheiten müssen sehende Menschen beim Testen mit einem Bildschirmleseprogramm verzichten.

Aber Gewohnheiten und die Art und Weise der Navigation durch Web-Inhalte sind nur ein Aspekt. Bildschirmleseprogramme fördern das "Anders-Denken" im eigentlichen Sinn. Ein sehender Mensch neigt dazu, Web-Seiten als visuell strukturierte Informationsblöcke wahrzunehmen. Die meisten Web-Seiten bieten Navigationsmöglichkeiten entweder oben oder seitlich des sichtbaren Bereichs. Häufig werden Grafiken eingesetzt, um die Aufmerksamkeit des Nutzers auf "wichtige" Inhalte wie z.B. neue Inhalte, Sonderangebote oder ähnliches zu lenken. Gutes Design lenkt die visuelle Aufmerksamkeit zum Inhalt und nutzt visuelle Anker um die Struktur eine Seite innerhalb von ein oder zwei Sekunden wahrzunehmen.

Benutzer von Bildschirmleseprogrammen können sich nicht in so kurzer Zeit einen Überblick über eine Web-Seite verschaffen. Web-Inhalte sind für sie linear und text-basiert aufgebaut. Sie denken nicht in Kategorien wie links oder rechts und Position auf der Seite. Es ist für sie irrelevant, ob der wichtigste Inhalt visuell in der Mitte der Seite mit der auffallendsten Farbe und mit dem küstlerischten Design dargestellt ist. Positionierung und künstlerische Optik sind vom Grundsatz her weder hilfreich, noch ein Hindernis für die Barrierefreiheit von Web-Inhalten für die Nutzer von Bildschirmleseprogrammen. Diese Art der Information ist für Sie schlicht und ergreifend nutzlos.

Wie nehmen Nutzer von Bildschirmleseprogrammen Webseiten denn dann wahr?

Benutzer von Bildschirmleseprogrammen hören zuerst den Titel einer Webseite (vorrausgesetzt es gibt ihn), und dann jedes Textelement in der Reihenfolge, in der es im Quellcode der Seite erscheint. Natürlich hören Sie nicht den Quellcode, aber wenn man sich den Quellcode anschaut und diesen um alle Formatierungen reduziert, bleibt lediglich der reine Textinhalt übrig. Um sich diesen Linearisierungs-Effekt annähernd vorzustellen, können Sie die gesamte Webseite kopieren (nicht den Quellcode, sondern die komplete Seite so wie Sie im Internet Broweser angezeigt wird) und dann in einem Texteditor ohne Formatierung einfügen. Man kann auch die Web Developer Firefox Toolbar oder WAVE benutzen, um eine reine Text-Version des Dokumentes zu generieren.

Das ist dann lediglich eine grobe Näherung, da Benutzer von Bildschirmleseprogrammen für gewöhnlich über noch mehr Informationen verfügen und auch verschiedenste Möglichkeiten haben, durch diese Informationen zu navigieren. Aktuelle Bildschirmleseprogramme informieren den Benutzer beispielsweise darüber, wo Listen beginnen oder enden und sogar darüber, wie viele Elemente sich in einer Liste befinden. Bildschirmleseprogramme erlauben Nutzern durch Datentabellen zu navigieren, von Zelle zu Zelle zu springen (vorausgesetzt die Tabelle wurde korrekt indexiert) und informieren den Nutzer darüber, welche Überschriften zu den jeweiligen Zelle gehören. Benutzer von Bildschirmleseprogrammen können unter anderem auch von Überschrift zu Überschrift springen, sich eine alphabetisch sortierte Linkliste ausgeben lassen, die Tabulator-Taste benutzen um von Link zu Link zu springen und innerhalb der Seite nach Schlagwörtern suchen. Obwohl der Inhalt also linear dargestellt wird, haben die Nutzer von Bildschirmleseprogrammen viele unterschiedliche Möglichkeiten um durch den Inhalt zu navigieren. Und jeder hat seine eigenen bevorzugten Methoden. Aufgrund der individuellen Unterschiede kann man also nie sagen, dass Benutzer von Bildschirmleseprogrammen "immer" die eine oder "immer" die andere Methode verwenden.

Es ist selten, dass sich Benutzer von Bildschirmleseprogrammen eine komplette Webseite von Anfang bis Ende anhören, ohne bestimmte Bereiche - wie Navigationlinks am Seitenanfang, die Copyright Informationen am Ende oder andere Bereiche dazwischen - zu überspringen. Die komplette Seite werden Nutzer wahrscheinlich nur anhören, wenn sie mit dem Inhalt noch nicht vertraut sind und dieser für sie sehr wichtig ist. Aber meist werden sie versuchen, das Gesuchte so schnell wie möglich zu finden. Überschriften, die Suche innerhalb der Seite und Linklisten (oder das Springen von Link zu Link) sind die gebräuchlichsten Methoden um Inhalte schnell zu finden.

Wie weiß ich nun, mit welchen Methoden Benutzer von Bildschirmleseprogrammen meine Web-Inhalte nutzen?

Gar nicht! Man kann lediglich annehmen, das alle diese Methoden an der einen oder anderen Stelle zum Einsatz kommen. Sie haben keinen Einfluss darauf, wie Nutzer mit Ihren Inhalten interagieren. Sie können lediglich soweit wie möglich sicherstellen, dass Ihr Design die Anwendung der verschiedenen Interaktionsmöglichkeiten nicht erschwert.

Was erschwert den Zugriff?

Hierzu einige Beispiele. Man kann nicht durch Überschriften einer Webseite navigieren wenn keine Überschriften vorhanden sind. Man kann die Bedeutung einer Grafik nicht hören - außer, wenn diese mit einem Alternativ-Text versehen ist. Unklare Link Texte wie "hier klicken" und "weiteres" bieten wenig bzw. gar keine Informationen darüber, wohin der Nutzer beim Anklicken gelangt. Das sind nur einige der Barrieren. Wenn Sie sich an die Prinzipien der Richtlinien zur Zugänglichkeit von Web-Inhalten (WCAG) oder Richtlinien aus Abschnitt 508 halten, wird dies deutlich helfen Barrieren abzubauen, auch wenn dies keine 100 prozentige Garantie ist. Aber natürlich gibt es keine 100 Prozent sichere Methode. Den größten Erfolg hat man, wenn man die Prinzipien und Richtlinien befolgt und den Inhalt testet.

Wo finde ich Informationen über die Tastaturkürzel von Bildschirmleseprogrammen?

WebAIM hat eine Liste von of Tastaturkürzel für JAWS und Tastaturkürzel für NVDA zusammen gestellt. Die Anleitung für Window Eyes - externer Link enthält Tastaturkürzel für "Windows Eyes". Andere Bildschirmleseprogramme stellen die Anweisungen für Tastaturkürzel meist in Ihren Hilfe-Dateien zur Verfügung.

Moment mal, wie viele Programme für Bildschirmleseprogramme muss ich denn lernen?

Realistischer Weise wird man von niemanden erwarten alle Programme im Detail zu lernen. Viele Nutzer von Bildschirmleseprogrammen verwenden mehrere Programme je nach Situation oder Art des Inhalts. In der Tat ist es ein Problem, dass die verschiedenen Programme jeweils auf leicht unterschiedliche Arten Inhalte auslesen und auf Inhalte zugreifen.

Wie groß sind diese "kleinen Unterschiede" und müssen Designer dies beim Gestalten des Inhalts in Betracht ziehen?

Das ist eine gute Frage. Viele der Unterschiede sind mehr oberflächlicher Natur und spielen aus Sicht des Erstellers der Inhalte keine große Rolle. JAWS zum Beispiel sagt "Link" vor jedem Link. Die meisten der Unterschiede bei Bildschirmleseprogrammen fallen unter die Rubrik "interessant, aber nicht wichtig". Andererseits gibt es manchmal Unterschiede bei Bildschirmleseprogrammen im Hinblick darauf, welche Technologien Sie unterstützen, welche Fehler Sie haben oder andere wesentliche Unterschiede. Als Adobe zum Beispiel anfing, Elemente für die Barrierefreiheit in den Adobe Reader zu integrieren, wurde dies nur von einigen Bildschirmleseprogrammen unterstützt. Mittlerweile ist diese Fähigkeit bei Bildschirmleseprogrammen wesentlich weiter verbreitet.

Soll man von Entwicklern wirklich erwarten, über all diese Unterschiede den Überblick zu behalten?

In gewisser Hinsicht schon, aber nicht zwangsläufig. Beim Erscheinen neuer Web-Technologien ist es wichtig einen groben Überblick über die Entwicklungen zu behalten. Eine Möglichkeit sich auf dem Laufenden zu halten, ist regelmäßig Seiten wie WebAIM zu besuchen oder sich in Mailverteilern zum Thema einzuschreiben. Gute Entwickler bleiben bei neuen Browser-Versionen, neuen Web-Technologien und Web-Standards auf dem Laufenden. Bildschirmleseprogramme sollten auch dazu gehören. Entwickler sollten die verschiedenen Anbieter von Bildschirmleseprogrammen und deren verwendete Techniken kennen.

Andererseits ist es insgesamt besser, wenn Entwickler den Prinzipien und Richtlinien für Barrierefreiheit mehr Aufmerksamkeit schenken, als den Unterschieden zwischen den spezifischen Bildschirmleseprogrammen. Wir raten zum Beispiel davon ab, dass Entwickler nur für ein spezielles Bildschirmleseprogramm entwickeln, da dies den Zugriff auf die Inhalte für Nutzer anderer Bildschirmleseprogramme erschweren würde.

Sollte ich meine Inhalte mit allen Bildschirmleseprogrammen testen?

Natürlich könnte man das machen und man würde dabei vor allem bei Java Script, Flash oder PDF Inhalten einiges lernen. Es wäre vernünftig Inhalte in so vielen Techniken wie möglich zu testen, einschließlich einer breiten Palette von Bildschirmleseprogrammen. Bei weniger aufwendigem Inhalt allerdings, sollte der Test mit ein oder zwei Bildschirmleseprogrammen für gewöhnlich reichen.

Welche "ein oder zwei"?

JAWS ist momentan zwar das am weitesten verbreitete Bildschirmleseprogramm, aber VoiceOver, NVDA und System Acess werden aufgrund Ihrer Fähigkeiten und der niedrigen Kosten immer populärer. Testen Sie Ihre Inhalte mindestens in einem dieser Programme. Die meisten Bildschirmleseprogramme sind hinsichtlich Ihrer Fähigkeiten Inhalte zu lesen ungefähr gleichwertig, man kann also mit keinem etwas falsch machen. Es ist lediglich eine Frage, mit welchem von ihnen man sich persönlich am wohlsten fühlt.

Wäre es nicht einfacher, einen blinden Nutzer meine Web-Inhalte testen zu lassen damit ich diese ganzen Dinge nicht lernen muss?

Das ist einerseits eine fabelhafte Idee, andererseits auch wieder nicht. Blinde Nutzer sind ein Teil Ihrer wirklichen Zielgruppe, Sie können also viel von Ihnen lernen. Viele von ihnen wären glücklich, ihre Sachkenntnis und Meinung mit Ihnen zu teilen. Große Organisationen sollten tatsächlich überlegen, blinde Fachleute dafür zu engagieren. Einige sind als Berater für Projekte verfügbar. Wenn man also auf blinde Nutzer zum direkten Test der eigenen Web-Inhalte zurück greifen kann, sollte man dies auf jeden Fall tun.

Doch es gibt auch ein ein paar negative Seiten bei diesem Szenario bzw. Vorsichtsmaßnahmen, die man berücksichtigen sollte.

Erstens, nicht alle blinde Menschen sind routiniert im Benutzen von Bildschirmleseprogrammen. Einige sind es zwar, andere jedoch nicht. Unerfahrene Benutzer können zwar auch eine wertvolle Perspektive geben (eben den Blickwinkel eines Anfängers), aber sie sind nicht in der Lage, Ihnen die breitere Perspektive der typischen Nutzer von Bildschirmleseprogrammen zu geben. Manchmal geben Ihnen unerfahrene blinde Nutzer - wegen ihrer fehlenden Erfahrung - einen schlechten Rat. Andererseits würden Ihnen routinierte Nutzer von Bildschirmleseprogrammen wiederum nicht die volle Perspektive von weniger erfahrenen Nutzern geben. Mit anderen Worten, man muss wie bei jedem Test durch die Auswahl der Benutzer sicherstellen, dass die Nutzer die gewünschte Zielgruppe repräsentieren. Man sollte nicht den Fehler machen und sagen: "Fred, unser blinder Benutzer von Bildschirmleseprogrammen hat vorgeschlagen, es auf diese Weise zu gestalten". Fred kann zwar, muss aber nicht, repräsentativ für die Mehrheit von Bildschirmleseprogramm-Nutzern sein. Er kann außerdem noch individuelle Einstellungen benutzen, die den Inhalt anders darstellen, als bei der überwiegenden Zahl der Nutzer. Ideal wäre eine Nutzer Gruppe aus verschiedenen Personen mit den unterschiedlichsten Erfahrungstufen. Es ist natürlich nicht immer machbar oder praktisch so eine Gruppe auf der Gehaltsliste zu haben. Trotzedem ist es keine schlechte Idee, gelegentlich in Benutzergruppen-Studien zu investieren. Insbesondere vor dem Start neuer Versionen komplexer Webseiten.

Zweitens, blinde Menschen können nicht immer erkennen ob Inhalte für Sie unzugänglich sind. Wenn der Hauptinhalt einer Webseite beispielsweise aus komplexen, nicht zugänglichem Java Script besteht, kann der blinde Nutzer möglicherweise gar nicht erkennen, dass dieser Inhalt überhaupt existiert. Wenn das Bildschirmleseprogramm Inhalte nicht vorliest, können diese für den Nutzer genausogut gar nicht existieren. Ein sehender Nutzer hingegen, kann den Inhalt sehen und anhören und dabei feststellen, dass der Hauptinhalt nicht vorgelesen wird. Natürlich kann das Sehen auch nachteilig für den Testprozess sein. Sehende Nutzer könnten sich zu sehr auf das verlassen, was sie sehen, und dabei übersehen, dass nicht alles was sie sehen, vom Bildschirmleseprogramm auch vorgelesen wird.

Man sollte daraus also lernen, die eigenen Inhalte von einer Vielzahl von Menschen mit verschiedensten Erfahrungs-Leveln, testen zu lassen. Am besten verlässt man sich nicht auf die Auswertung durch eine einzelne Person. Eine Möglichkeit blinde Nutzer mit einzubeziehen ist es, deren Ratschlag über die WebAIM Diskussuions Liste oder andere Online-Foren, zu erbitten. Gelegentlich bieten diese ihren Rat dort kostenlos an. Manchmal ist es jedoch besser, einen geeigneten Test- oder Beurteilungservice zu beauftragen.

Ist das nicht sehr aufwändig so viele Meinungen von verschiedensten Nutzern zu bekommen?

Ja, das kann manchmal in der Tat eine Menge Arbeit sein! Vielleicht haben Sie weder Zeit noch Mittel um dies für alle Ihre Web-Inhalte zu tun. Ich gebe zu, dass die meisten Leute Schwierigkeiten haben dürften regelmäßig überhaupt irgend eine Art von Nutzergruppe zusammen zu stellen. Außerdem kann es auch eine Herausforderung sein, Benutzer mit vielfältigen Behinderungen zu finden.

Trotzdem ist dies beim Durchführen von großen, seitenübergreifenden Änderungen, beim Entwurf einer neuen Schnittstelle oder bei einem umfassenden Test der Barrierefreiheit bereits vorhandener Inhalte, anzuraten. Selbst erfahrene Designer, die schon seit langem mit Blick auf Barrierefreiheit entwickeln, profitieren von solchen Nutzergruppen.

In der Praxis gibt es natürlich mehr als eine Möglichkeit, solche Bewertungen zu erhalten. Die teuerste und zeitintensive Möglichkeit ist es, formelle Studien durchzuführen. Solche Studien können sehr nützlich und gründlich sein. Man kann solche Studien nicht allzu häufig durchführen, außer man hat jede Menge Geld und Zeit zur Verfügung. Die billigere Methode ist es, von Zeit zu Zeit Kollegen, Mitarbeiter oder Menschen aus Diskussionsforen etc. zu bitten, Seiten zu testen und Ihnen dann formlose Rückmeldung darüber zu geben.

Wie teuer sind Bildschirmleseprogramme?

Teuer. JAWS ist normalerweise am teuersten mit Preisen zwischen 895 US Dollar und 1495 US Dollar, abhängig von der jeweiligen Version und von Rabatten. Windows Eyes Preise liegen in ähnlicher Größenordnung wenn auch etwas günstiger. JAWS und Windows Eyes können auch Textverarbeitungen, Finanzprogramme, Betriebssysteme und viele andere Anwendungen vorlesen. VoiceOver ist im vergleichsweise günstigen Apple-Mac Betriebssystem mit enthalten. NVDA ist zwar kostenlos, bietet aber keinen Zugriff auf das komplette System. NVDA liest für gewöhnlich nur Web-Inhalte und einfache Dokumente vor.

Ich muss also eine Menge Geld ausgeben oder?

Nicht unbedingt. Wenn Sie eine Menge Geld zur Verfügung haben, nur zu, kaufen Sie alle! Wenn Sie einen Apple-Mac mit OS X haben, haben Sie VoiceOver bereits zur Verfügung. Wenn Sie nicht soviel Geld haben, nehmen Sie NVDA. Wenn Sie gar kein Geld ausgeben wollen, gibt es eine Alternative: Sie können zeitlich befristete Testversionen von JAWS und Window Eyes verwenden. Diese zeitlich befristete Versionen sind jedesmal für 40 Minuten verwendbar. Nach 40 Minuten müssen Sie Ihren Rechner aber neu starten um die Bildschirmleseprogramme erneut verwenden zu können (ja, man muss den Rechner komplett neu starten, es reicht leider nicht, nur das Bildschirmleseprogramm neu zu starten). Diese zeitlich befristeten Versionen können für Web-Entwickler zum Testen Ihre Inhalte ideal sein. Sehr häufig kann man alle gewünschten Tests innerhalb des 40 minütigen Zeitlimits durchführen. Manchmal muss man um weiter testen zu können, den Computer wohl oder übel neu starten. Das ist insgesamt aber doch vertretbar, wenn man berücksichtigt, dass die Software "kostenlos" war. AKTUALISIERUNG: Wir wurden benachrichtigt, dass die Nutzungsbedinungen der JAWS Demo-Version die Benutzung zu Bewertungs- und Testzwecken ausdrücklich untersagen.

Zu guter Letzt, ist es das alles wert?

Wenn Sie auf den Aufwand abstellen, Inhalte für Benutzer von Bildschirmleseprogrammen verfügbar zu machen, antworte ich Ihnen mit folgender Frage: Wie wichtig ist Ihnen die Benutzung des Internets? Ich weiß nicht, wie es Ihnen geht, aber für mich ist das Internet ein wesentlicher Bestandteil meines Lebens geworden. Für mich wäre die wirkliche "Unannehmlichkeit" wenn ich die Vorteile des Angebotes im Internet nicht nutzen könnte. Für die Benutzer von Bildschirmleseprogrammen ist diese "Unannehmlichkeit" unglücklicherweise Realität.