Vorlage Diskussion:Infobox Gemeinde in Deutschland/Barrierefreiheit

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)

message: 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)
replies: text: Mein Test mit Jaws in den Standardeinstellungen: Es wird gar nicht zwischen Kopf- und Datenzellen unterschieden. --TM 11:03, 3. Aug. 2007 (CEST)
thread_title:  Zuordnung von Kopfzellen zu Datenzellen 

message: 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)
replies: text: 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)
replies: text:  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 InfoboxBesser 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)
replies: text: 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)
replies: text: 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)
thread_title:  Zusätzliche Beschriftungen für Screenreader 

message: 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)
replies: text: 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)
thread_title:  Zeichensetzung innerhalb der Box 

message: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
replies: text: 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)
thread_title:  Sinnvolle Linkmenge und sinnvolle Linkziele 

message: 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	Lage der Kreisstadt Bautzen im gleichnamigen Landkreis
50px|Karte                                            	50px|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)
replies: text: 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)
replies: text: 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)
thread_title:  Sinnvolle Bildbeschriftungen