Vorlage Diskussion:Infobox Gemeinde in Deutschland/Barrierefreiheit

Ich möchte den Interessenten am BIENE-Projekt ein konkretes Betätigungsfeld vorschlagen, an dem wir praktische Erfahrungen sammeln und dabei tatsächlich etwas bewirken können. Verbesserungen an der vergleichsweise komplexen Infobox „Ort in Deutschland“ würden dafür sorgen, dass auf einen Schlag 13.000 Artikel etwas barriereärmer wären. Die gewonnen Erfahrungen können danach auf viele weitere Vorlagen angewandt werden. Idealerweise sollte ein kleines Regelwerk mit ganz konkreten Richtlinien zum technischen und inhaltlichen Aufbau solcher Vorlagen entstehen.

Im Folgenden habe ich alle aus meiner Sicht bestehenden Probleme aufgezählt und bitte um eure Mithilfe, da ich selbst als Sehender sicherlich viele Details und Lösungsmöglichkeiten übersehen habe. Wie die Infobox momentan im Artikelnamensraum aussieht, kann man in den Gemeindeartikeln sehen, z. B. in Bautzen. Sehende müssten sich das mit einem Textbrowser ansehen (Lynx, Opera mit abgeschaltetem CSS), sonst wissen sie zum Teil nicht, was ich mit den einzelnen Punkten meine. --TM 19:54, 2. Aug. 2007 (CEST)

Vielen Dank für deine Initative! Ich werde versuchen, die angesprochenen Punkte aus der Sicht eines Screenreadernutzers zu kommentieren. Generell sollte man dazu folgendes wissen:
Der sehr verbreitete Screenreader Jaws zeigt Webseiten standardmäßig im sogenannten vereinfachten Layout an. Dabei wird der ganze Seiteninhalt wie in einem Dokument gezeigt, wobei jeder Link in einer eigenen Zeile dargestellt wird. Wie sich das auf die Ausgaben einer Sprachausgabe auswirkt, habe ich hier zu erklären versucht. Bei Jaws lässt sich auch das sogenannte Bildschirmlayout einstellen, wodurch die Seite für Blinde scheinbar fast genauso wie für Sehende ausgegeben wird und mehrere Links in einer Zeile stehen. Diese Funktion nutze ich allerdings fast nie, sondern lediglich um verstehen zu können, wie andere Menschen die Entsprechende Seite auf dem Bildschirm sehen. Moderne Versionen von Screenreadern geben dem Benutzer eine Menge Möglichkeiten an die Hand, gezielt in Tabellen navigieren zu können. Siehe dazu auch hier. Da viele blinde Menschen aber noch mit veralteter Hilfssoftware arbeiten, sollten wir die dadurch eingeschränkten Möglichkeiten dieser Nutzer berücksichtigen und Lösungen finden, die für möglichst viele eine Verbesserung bringen. -- Lalü 10:23, 3. Aug. 2007 (CEST)

Danke für deine Hilfe. Ich habe Jaws inzwischen ausprobiert und meine Beobachtungen notiert (siehe unten). Dabei habe ich bewusst die Standardeinstellungen benutzt. Was mich besonders interessiert ist, Darstellungsmöglichkeiten zu finden, die in möglichst vielen Fällen (Jaws mit typischen individuellen Einstellungen, andere Screenreader, Textbrowser etc.) ideale Ausgaben erzeugen. --TM 11:03, 3. Aug. 2007 (CEST)

Ja, das sehe ich genauso. Wenn wir sorgfältig sein wollen, sollten wir neben den Jawsversionen 4 bis aktuell 8 auch andere Screenreader-Software wie Window Eyes, Virgo+Webformator und die Open-Source-Projekte NVDA und Thunder in Bezug auf die Darstellung von Webinhalten, navigationsmöglichkeiten und anderen eventuell verbreitet eingesetzten Features für die Anforderungen von WikiMedia unter die Lupe nehmen. Das können wir natürlich nicht alleine schaffen, so daß wir versuchen sollten, einige blinde Nutzer dieser Programme für eine wenigstens kurzfristige Mitarbeit zu gewinnen. Vielleicht können wir einige für uns relevante Auskünfte auch von Sehenden bekommen, die sich beruflich mit der Thematik "WebAccessibility" beschäftigen und einen umfassenderen Überblick haben. Die könnten sich auf dieser und den anderen WP-Seiten leicht über unsere Fragestellungen informieren und dann eventuell freundliche Ratschläge geben.
Bei Browsern brauchen wir wohl nur IE6, IE7 und einige Varianten von Firefox berücksichtigen, da dies die scheinbar von meiner Personengruppe fast ausnahmslos genutzten Programme zum surfen sind. Zu Linux kann ich absolut nichts sagen, aber grade die blinden IT-Experten nutzen das viel. -- Lalü 19:45, 3. Aug. 2007 (CEST)

Konkrete Probleme der Infobox

Diskussionen und Vorschläge bitte thematisch getrennt zu jedem Punkt einzeln führen. Neue Punkte bitte unten anfügen.

Skiplink zum Überspringen der Infobox

Es wäre denkbar, einen unsichtbaren Link einzubauen, der das Überspringen der Infobox erlaubt („Infobox überspringen“ oder „Zum Text“). Wie sollte ein solcher Link beschriftet sein? Wie kann man das gestalten, damit es zu den bereits vorhandenen „Wechseln zu“-Links passt? Mit welcher CSS-Anweisung sollte der Link versteckt werden (display: none; kann problematisch sein)?

Mein Vorschlag: <a href="#jump-to-text">Informationskasten überspringen</a> direkt vor der Infobox und direkt dahinter <span id="jump-to-text"></span>. Das Wort „Infobox“ würde ich vermeiden, da es Wikipedia-Jargon ist und dem Leser u. U. nichts sagt. --TM 19:54, 2. Aug. 2007 (CEST)

Mein Test mit Jaws in den Standardeinstellungen: Der Skiplink ist unbedingt notwendig. Er darf nicht mit display: none; ausgeblendet werden, da er dann nicht vorgelesen würde. --TM 11:03, 3. Aug. 2007 (CEST)

Ich habe den "wechseln zu"-Link sofort ausgeblendet, nachdem ich die Option dazu unter Einstellungen/Diverses fand. Die Entfernung dieser 3 unnötigen Zeilen sind an dieser fast am häufigst gelesenen Stelle sehr praktisch.
Um auf einer Seite an den gewünschten Ort zu kommen, benutze ich entweder das springen mit "h" von einer Überschrift zur anderen oder ich nutze die access keys wie Alt+. / Alt+l / Alt+t. Außerdem bietet mir Jaws die komfortable Möglichkeit zur Suche nach bestimmten Zeichen auf der jeweiligen Seite. Das nutze ich häufig, um bei umfangreichen Inhalten sehr schnell an die begehrte Stelle zu kommen, vorrausgesetzt man nimmt die richtigen Suchwörter. Eine weitere Schnellnavigationstaste von Jaws ist "f", nach deren Betätigung ich auf allen WP-Seiten außer den Spezialseiten sofort ins untenstehende Suchfeld springe. Diese hier beschriebenen Navigationsmöglichkeiten gab es auch bereits in wesentlich älteren Versionen von Jaws und wahrscheinlich auch bei anderen hochwertigen Screenreadern, weshalb sie eigentlich fast jedem blinden Anwender zur Verfügung stehen müssten.

Ich mag zwar auch passende deutsche Bezeichnungen von englischen Begriffen und finde "Infokasten" auch gut, allerdings empfinde ich es oft als sehr verwirrend, wenn man beim Einstieg in eine neue Thematik mit zwei unterschiedlichen Begriffen für die gleiche Sache konfrontiert wird. Da sich der Begriff "Infobox" auch bei De.WP bereits überall eingebürgert hat, befürchte ich deshalb, daß eine weitere Bezeichnung mehr Verwirrung als Vereinfachung mit sich bringen würde.

Noch eine Frage: Du hast obenstehend nach dem Begriff "wechseln zu" einen Anführungsstrich gesetzt, aber direkt davor, wo eigentlich auch einer sein sollte, steht ein für meine Sprachausgabe unbekanntes zeichen, weshalb sie dort stumm bleibt. Was ist das? -- Lalü 12:56, 3. Aug. 2007 (CEST)

Meinst du „diese“ beiden Zeichen? Das sind die typografisch korrekten Anführungszeichen unten und oben. Im Sinne der Einheitlichkeit hast du Recht, Infobox ist hier wirklich weit verbreitet. Zur Frage, ob der Skiplink benötigt wird: Wenn ich dich richtig verstehe, sagst du, dass er eher stören als helfen würde? --TM 14:38, 3. Aug. 2007 (CEST)

Ja, mich würde der Skiplink genauso wie der "wechseln zu"-Link stören. Wenn man ihn optional bei den Einstellungen ebenso ausblenden könnte, wäre das aber nicht schlimm. Hier sollten wir unbedingt noch andere Meinungen blinder Anwender oder von Barrierefachleuten einholen.

Da der einführende Text nach der Infobox nicht mit einer Überschrift formatiert ist, könnte ein direkt dorthin führender Skiplink zwar doch eventuell nützlich sein. Weil man bei Jaws aber beispielsweise mit Alt+Strg+Ende aus einer Tabelle sofort an ihr Ende springen kann, ist dieser Punkt auch anders erreichbar. Viel störender sind beim Beispiel Bautzen die Bilder, die weitere 19 Zeilen vor dem eigentlichen Einführungstext beanspruchen. Das sieht dan so aus, wobei die Sprachausgabe dabei noch jeden Link als solchen bennennt:

Stadtansicht
images/magnify-clip
Stadtansicht
Alte Wasserkunst und Michaeliskirche
images/magnify-clip
Alte Wasserkunst
und
Michaeliskirche
Wasserturm und Teil der Klosterruine
images/magnify-clip
Wasserturm und Teil der Klosterruine
Friedensbrücke über die Spree
images/magnify-clip
Friedensbrücke
über die
Spree
Nicolaiturm
images/magnify-clip
Nicolaiturm

Das hat zwar nichts mehr mit dem Skiplink zu tun, ist aber wesentlich störender als die Infobox, die ja wenigstens Informationen enthält und wegen ihres Tabellenformats wie oben beschrieben schnell verlassen werden kann.

Im Netz gab es noch vor einigen Jahren kaum Seiten mit Überschriftsformatierungen und damals war solch ein Skiplink Wahrscheinlich sehr nützlich, um schnell zum Inhalt oder Navigationsmenü zu kommen. Heutzutage ist das dank der zahlreichen gut strukturierten & programmierten Seiten glücklicherweise nicht mehr nötig, da die Screenreader gezielt bestimmte Elemente anspringen können. Deshalb sind aus meiner Sicht solche Skiplinks fast schon eher ein Usability-Problem für blinde Nutzer, da sie ständig unnötige Cursorbetätigungen erfordern, um an die teilweise direkt dahinter stehenden Inhalte kommen zu können. Ich fand bei Wikis von Anfang an toll, daß es dort bereits vor über 3 Jahren Überschriftsformatierungen gab, an denen ich mich prima entlang hangeln konnte und so phänomenal schnell einen Überblick über die Seite bekam. Google benutz bei den Suchergebnissen beispielsweise erst seit maximal ca. 2 Jahren eine Überschriftsformatierung pro angezeigtem Treffer, was ich heute nicht mehr missen möchte.

Das Problem mit dem für meine Sprachausgabe unbekannten vorderen Anführungszeichen werde ich gesondert verfolgen, da ich hier bei WP oft auf solche "stummen" Zeichen treffe. Ich erwarte eigentlich von meinem Screenreader, daß er möglichst alle Zeichen kennt und werde darum mal recherchieren, ob sich das nicht irgendwo einstellen oder "nachrüsten" ließe. -- Lalü 17:21, 3. Aug. 2007 (CEST)

Ich erinner mich dunkel, irgendwann einmal gelesen zu haben, daß man einen für Sehende unsichtbaren Link dadurch erzeugen kann, indem man seine Größe (?) auf 1 oder 0 setzt. Vielleicht würde mich so ein mit "Infobox überspringen" beschrifteter Link doch nicht allzu sehr stören, da ein weiterer Link bei all den zahlreichen anderen Links im Einführungsbereich auch egal wäre. Wenn du also einen Skiplink einbauen willst, dann sollte er am besten ohne weitere Leerzeile für Jaws direkt vor der Zusammenfassungszeile stehen. Dann würde sich der Anfang der Infobox idealerweise also so anhören:
Link Infobox überspringen
Zusammenfassung Infobox Ort in Deutschland
Auf die beiden Anführungszeichen beim Titel der Infobox kann verzichtet werden, das erspart der Sprachausgabe wieder 10 unnötige Silben in dieser Zeile. ;-) Spannend wäre jetzt die Frage, wohin der Skiplink führen könnte. Es wäre nämlich am schönsten, wenn man dadurch auch die Bilderlinks nach der Infobox überspringen könnte und so direkt beim eigentlichen Einführungstext landet. Ich denke aber, daß das wohl leider nicht gehen wird, weil die Bilder nichts mit der Formatvorlage "Ort in Deutschland" zu tun haben. -- Lalü 16:23, 4. Aug. 2007 (CEST)

Eine sehr interessante Frage bei FzW hat mich auf die Idee für die Ideallösung für die in diesem Abschnitt angesprochenen Probleme gebracht. Wenn der kurze einführende Text immer vor der Infobox und den Bildern ausgegeben würde, ließe er sich sehr leicht finden und nach dem lesen könnte man mit den SR-Schnellnavigationstasten sofort die nächste Überschrift anspringen und so Infobox & Bilder umgehen. Diese Lösung wäre natürlich nur machbar, wenn sich das programmiertechnisch erledigen ließe, da es wohl unrealistisch wäre, dafür alle Artikel von Hand nachzubearbeiten. Außerdem stellt sich die Frage, ob das nicht gegen bestehende feste Regeln verstößt oder eine zu große Umgewöhnung für alle anderen Leser wäre. -- Lalü 19:45, 5. Aug. 2007 (CEST)

Die Bilder sind ein ganz eigenes Problem. Ich fürchte, das werden wir hier kaum lösen können. Die Überlegungen hier sollten sich auf Infoboxen und andere Vorlagen beschränken.

Die Idee, die Einleitung vor die Infobox zu verschieben, ist sehr naheliegend und wurde tatsächlich schon oft diskutiert, hat aber einen entscheidenden Nachteil für Sehende: Die Infobox rutscht optisch genauso weit nach unten, wie der Einleitungstext lang ist. Da die Einleitung aber in jedem Artikel verschieden lang ist, hängt die Infobox jedesmal auf einer leicht anderen Höhe. Das ergibt ein sehr unruhiges Bild, wenn man sich von einem Artikel zum anderen bewegt.

Eine Lösung, diesen rein kosmetischen Mangel mit Stylesheets zu beheben, habe ich leider nicht gefunden. --TM 01:46, 9. Aug. 2007 (CEST)

Zuordnung von Kopfzellen zu Datenzellen

Momentan werden Kopfzellen (in der Tabellensyntax am Ausrufezeichen zu erkennen) in der Infobox eher aus optischen Erwägungen verwendet (die fett geschriebenen Texte auf grauem Grund). Ich vermute, dass das im Screenreader eher chaotisch vorgelesen wird. Wäre es sinnvoll, statt dessen die komplette linke Spalte als Kopfzellen auszuzeichnen (die Optik ließe sich per CSS anpassen, so dass sich für Sehende nichts ändern würde)? Versteht der Screenreader die Zuordnung zwischen der Überschrift „Wappen“ und dem Wappen, das darunter steht? Kann man diese Zuordnung besser machen?

Hier zum Vergleich zwei Beispieltabellen, die erste nur mit Datenzellen, die zweite mit Kopfzellen.

Bundesland:	Sachsen
Landkreis:	Bautzen

Bundesland:	Sachsen
Landkreis:	Bautzen

--TM 19:54, 2. Aug. 2007 (CEST)

Mein Test mit Jaws in den Standardeinstellungen: Es wird gar nicht zwischen Kopf- und Datenzellen unterschieden. --TM 11:03, 3. Aug. 2007 (CEST)

Zusätzliche Beschriftungen für Screenreader

Mit dem HTML-Attribut summary (Zusammenfassung) kann ein Text angegeben werden, der im Screenreader als erstes vorgelesen wird und idealerweise die Funktion der Tabelle erläutert. Was sollte dort stehen? Für Kopfzellen können mit dem HTML-Attribut abbr kürzere Alternativen angegeben werden, z. B. abbr="Karte" für die Kopfzelle „Deutschlandkarte“. Wo wäre das konkret sinnvoll?

Hier ein kleines Beispiel mit einer Zusammenfassung und der Abkürzung „Karte“ für die zweite Spaltenüberschrift:

Wappen	Deutschlandkarte
Wappen von Musterstadt	Deutschlandkarte, Position von Musterstadt hervorgehoben

Mein Vorschlag: Die Zusammenfassung sollte entweder summary="Informationskasten" lauten oder ganz weg gelassen werden, da sie redundant zum Skiplink darüber wäre. Das Wort „Infobox“ würde ich hier ebenfalls vermeiden. --TM 19:54, 2. Aug. 2007 (CEST)

Mein Test mit Jaws in den Standardeinstellungen: Abkürzungen werden gar nicht vorgelesen. Die Zusammenfassung wird vorgelesen, ist durch den Skiplink darüber aber überflüssig. --TM 11:03, 3. Aug. 2007 (CEST)

Stimmt, Abkürzungen funktionieren standardmäßig nicht. Die Zusammenfassung könnte aber für jede Infobox auch den Titel enthalten: summary=Infobox "Ort in Deutschland" (falls wir keinen Skiplink benutzen.) Wenn es ginge, daß alle Infoboxen in ihrer Formatvorlage gleich den jeweils genauen Namen als Summary verpasst krigen würden, bräuchten sich die Benutzer solcher Formatvorlagen nicht alle selbst um den korrekten Zusammenfassungstitel kümmern. Jaws liest solch ein Summary direkt vor der Tabelle momentan wie folgt vor:
Zusammenfassung Infobox
Besser wäre: Zusammenfassung Infobox "Ort in Deutschland".
Wie bereits oben erwähnt, liest Jaws ein vorderes spezielles Anführungszeichen nicht vor, so daß ich dafür wäre, immer das Standardzeichen (Shift+2) bei einem so häufigen Zeichen zu verwenden. - Lalü 12:58, 4. Aug. 2007 (CEST)

Ich habe jetzt probehalber den vollen Namen der Vorlage als Zusammenfassung eingesetzt. Das ist vielleicht etwas einfallslos, hat aber einen großen Vorteil: Man versteht sofort den Zusammenhang, wenn man den Artikel bearbeiten möchte, da dort der selbe Name auftaucht. --TM 20:45, 6. Aug. 2007 (CEST)

Das gefällt mir gut. Das ist zwar eine Zweckentfremdung von "summary", aber dadurch kriegen diese für mich anfangs immer ominösen "Tabellen" endlich einen aussagekräftigen Titel. Das könnte man sicherlich ohne allzu viel Aufwand für andere Infoboxen oder vielleicht auch die Taxoboxen übernehmen. Vorrausgesetzt natürlich nur dann, wenn eine Formatvorlage die "Zusammenfassung" nicht schon bereits sinnvoll nutzt. -- Lalü 21:31, 6. Aug. 2007 (CEST)

Zeichensetzung innerhalb der Box

Ist die Zeichensetzung innerhalb der Infobox sinnvoll oder sollte man da etwas ändern, damit es sinnvoller vorgelesen wird? Sind die Doppelpunkte in jeder Zeile in Ordnung? Gibt es Probleme mit geschützten Leerzeichen? Probleme mit Auslassungspunkten, die erscheinen, wenn ein Pflichtfeld fehlt? --TM 19:54, 2. Aug. 2007 (CEST)

Mein Test mit Jaws in den Standardeinstellungen: Es fallen keine besonderen Probleme auf. Doppelpunkte werden vorgelesen, aber das ist gut so. --TM 11:03, 3. Aug. 2007 (CEST)

Sinnvolle Linkmenge und sinnvolle Linkziele

Eine vollständig ausgefüllte Infobox enthält extrem viele Links. Wie wird das im Screenreader vorgelesen? Sind die Links alle sinnvoll oder wäre es besser, den einen oder anderen wegzulassen? Zeigen die Links alle auf nutzbringende Artikel? Ich würde gern diejenigen Links entfernen, die so naheliegend sind, dass sie eher stören als helfen. Es ist allerdings schwer, da eine Grenze zu ziehen.

Die folgenden Links würde ich mal zur Diskussion stellen, da sie recht naheliegend sind und auf eher weniger hilfreiche Artikel verweisen.

• Bevölkerungsdichte
• Bürgermeister
• Einwohner
• Höhe
• km²
• Koordinaten
• NN
• Webpräsenz

--TM 19:54, 2. Aug. 2007 (CEST)

Mein Test mit Jaws in den Standardeinstellungen: Jeder Link wird mit dem Wort „Link“ angesagt. Das geht fix und stört praktisch kaum. Ein oder zwei besonders überflüssige Links könnten wir trotzdem entfernen. --TM 11:03, 3. Aug. 2007 (CEST)

Ich denke auch, daß die Links bleiben könnten. Der Koordinatenlink ist allerdings doppelt vorhanden. Hat das eine tiefere Bewandnis? Die GeoHack-Seite gefällt mir übrigens sehr gut, nur schade, daß ich davon nicht wirklich was habe. ;-) Aber irgendwann möchte ich die WP-georeferenzierten Artikel auch gerne in Bezug auf meine per GPS aktuell ermittelte Position mit einem mobilen Endgerät mit Screenreader finden & lesen können. -- Lalü 14:23, 6. Aug. 2007 (CEST)

Der doppelte Koordinatenlink ist mir auch schon aufgefallen. Die Idee ist, die Koordinaten zusätzlich oben rechts in der Ecke des Artikels anzuzeigen, so dass Sehende schnell erkennen können, dass es sich um einen georeferenzierten Artikel handelt. Als einzige naheliegende Optimierung könnte ich mir vorstellen, die Reihenfolge von "Koordinate: Koordinate: 10° N, 14° O10° N, 14° O" in "Koordinate: 10° N, 14° O Koordinate: 10° N, 14° O" zu ändern. Dazu müssten wir uns an WP:GEO wenden. --TM 20:39, 6. Aug. 2007 (CEST)

Dann könnte der schnell erkennbare Link ja oben rechts in der Ecke bleiben aber stattdessen könnte man den gleichen Koordinatenlink mit der zusätzlichen Angabe "Koordinate:" ja in der Infobox weglassen. Das ist aber eigentlich nicht wirklich wichtig und wo ich doch so ein Freund von Geo-Koordinaten bin, können diese dort von mir aus auch ruhig doppelt auftauchen. :-) -- Lalü 21:01, 6. Aug. 2007 (CEST)

Sinnvolle Bildbeschriftungen

Eine vollständig ausgefüllte Infobox enthält vier Bilder: Ein Wappen und zwei Karten, wobei sich die Deutschlandkarte mit dem roten Punkt aus zwei Bildern zusammen setzt. Es wäre evtl. sinnvoll, einige der Alternativtexte leer zu lassen, damit Screenreader die zierenden Grafikelemente ignorieren. Wie sollten die vier Bildbeschriftungen lauten, damit möglichst nutzbringender Inhalt transportiert wird?

Hier ein kleines Beispiel für die Bildbeschriftungen in einer typischen Infobox:

Wappen	Deutschlandkarte
Lage der Kreisstadt Bautzen im gleichnamigen Landkreis
Karte

Mein Vorschlag: Die Beschriftung des roten Punkts und den Alternativtext des Lageplans ganz unten entfernen und lieber auf die Tabellenköpfe setzen. --TM 19:54, 2. Aug. 2007 (CEST)

Mein Test mit Jaws in den Standardeinstellungen: Leer lassen darf man die Beschriftung nie, da Bilder in der Wikipedia immer auch Links sind und Jaws dann sehr umständlich den Dateinamen vorliest (aufgrund der von der Software nach dem Muster "Dateiname.jpg/180px-Dateiname.jpg" erzeugten Dateinamen sogar doppelt). Statt dessen sollten sehr kurze, prägnante Beschriftungen verwendet werden, zum Beispiel "Markierung" und "Karte". --TM 08:52, 22. Aug. 2007 (CEST)

Hallo TM, wie ich hier damals schrieb, resultiert der Dateiname als Titel des Bildes nicht aus Jaws’ Interpretation sondern durch die Mediawiki-Software. Im Browser erhalte ich auch den Dateinamen als title-Tag. — Lecartia Δ 16:19, 7. Mär. 2008 (CET)