Wikipedia Diskussion:BIENE/Archiv/1

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Wikipedia Diskussion:BIENE/Archiv/1#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Wikipedia_Diskussion:BIENE/Archiv/1#Thema_1

Legastheniker

Wie sieht es mit der besonderen Benutzergruppe der Legastheniker aus, die sind durch unsere doch recht Rechtschreibungsfetischiste Suchfunktion, sowie unserer Falschschreibungsredir-Politik als Leser teils recht überfordert. Dennoch sind sie selbst unter den Hardcorewikipedianern eher überproportional vertreten. --sугсго.PEDIA^-/+ 20:04, 26. Jun. 2007 (CEST)

Bisher habe ich keine Informationen, daß legastheniker benachteiligt wären - aber gerne können wir eine solche Arbeistgruppe einrichten. --RalfR 20:25, 26. Jun. 2007 (CEST)

Vorschlag machen Google zu benutzen die ne Rechtschreibkorrektur drin hat beim Suchen? Und das wird ja schon gemacht, ein Klick weiter über den Suchergebnissen. --Mot2 21:33, 17. Sep. 2007 (CEST)

Das kann ja durch die neue AJAX-Funktion (Vorschlagsliste im Suchfeld bei aktiviertem Javascript) als abgehakt gelten - oder? -- Hunding 13:12, 4. Mai 2008 (CEST)

Der Arbeitsgruppe "junge Benutzer" ...

... wünsche ich gutes Gelingen, empfehle aber zum Einstieg die Lektüre der traurigen Vorgänge rund um das Portal "Wikipedia für Kinder", das es nun seit geraumer Zeit nicht mehr gibt. --Wolli 20:10, 26. Jun. 2007 (CEST)

Um all diese Probleme zu lösen (und die von der Erwachsenenwikipedia), müsste dann wohl auch eher eine Wikipedia von Kindern sein, die sich selber verwalten und ältere keinen Zutritt bekommen. --Mot2 19:57, 17. Sep. 2007 (CEST)

Sehbehinderte/Sehschwache/Senioren

Der Begriff "Sehbehinderte" ist eigentlich die in Deutschland gebräuchliche Bezeichnung für Menschen, die zwar nicht blind sind, deren Sehrest oder Seheinschränkungen ihnen jedoch die normale optische Rezeption erschweren. "Sehschwache" dagegen gibt es meines Wissens offiziell nicht als Bezeichnung. Der Googletest ergab dafür ca. 37000 Treffer, während "Sehbehinderte" auf über eine Million Treffer kommt. Die Senioren stellen bei den blinden und sehbehinderten Menschen die größte Gruppe dar, wobei sie das Internet prozentual wohl nur geringfügig nutzen. Das wird im Laufe der Jahre bestimmt aber mehr werden. -- Lalü 09:56, 28. Jun. 2007 (CEST)

Ich glaube, daß wir keine 2 verschiedenen Arbeitsgruppen für Sehbehinderungen und Sehschwächen brauchen, weil die dadurch bedingten Probleme von Nutzern beim arbeiten am PC sich sehr ähneln. Es gibt allerdings trotzdem riesige Unterschiede bei den verschiedenen Auswirkungen von Sehbehinderungen und den damit verbundenen Problemen. Farbenfehlsichtigkeit ist dagegen klarer definiert und sollte weiterhin extra behandelt werden, zumal es mir so scheint, als daß wir für die Probleme dieser Nutzergruppe mit relativ wenig Aufwand eine gute Lösung für Wikipedia finden könnten. Gegenargumente sind erwünscht! -- Lalü 11:32, 4. Aug. 2007 (CEST)

Beispiele für barrierefreie Artikel

Der durchschnittliche Artikelautor hat sicher Probleme damit zu erkennen, was er tun muss, um seinen Artikel barrierefrei zu machen. Jemand der Erfahrung auf diesem Gebiet hat, sollte einen oder mehrere Artikel, die besonders schlechte Beispiele für Barrierefreiheit darstellen, optimieren und die Änderungen auf der Diskussionsseite ausführlich kommentieren. ArtMechanic 18:54, 1. Jul. 2007 (CEST)

(Noch) haben wir keine Chance, einen barrierefreien Artikel im WP-Namensraum zu erstellen, weil vieles irgendwelchen Konventionen entgegenläuft und einfach revertiert werden würde. Wir müssen damit im Benutzernamensraum bleiben. --RalfR → BIENE braucht Hilfe 12:35, 3. Jul. 2007 (CEST)

Ist vielleicht ne blöde Frage...

...aber warum ist die Seite nicht im WP-Namensraum? --Thogo (Disk.) -- Sorgen? 12:28, 3. Jul. 2007 (CEST)

Ich wußte nicht, ob und wie das aufgenommen wird --> hab mich nicht getraut...--RalfR → BIENE braucht Hilfe 12:35, 3. Jul. 2007 (CEST)

Sei mutig. ;) Wichtig isses allemal, denk ich. Auch wenn ich weder als Versuchsperson, noch als JS/CSS-Programmierer in Frage komme und daher wohl nicht helfen kann. --Thogo (Disk.) -- Sorgen? 12:49, 3. Jul. 2007 (CEST)

es gibt doch schon ein solches Portal oder WikiProhekt, oder? *such* Ireas ^?!?_+/-VvQSuP 16:10, 3. Jul. 2007 (CEST)

Wikipedia:Wikiprojekt_Barrierefreiheit Ireas ^?!?_+/-VvQSuP 21:00, 3. Jul. 2007 (CEST)

Könnte man das nicht „entern“? — Lecartia Δ 21:12, 3. Jul. 2007 (CEST)

Aber immer doch :) --RalfR → BIENE braucht Hilfe 21:17, 3. Jul. 2007 (CEST)

Zielsetzung

Da ich heute (erstmals wieder aktiv) über die Diskussion in den Kandidaten für exzellente Artikel stolperte, möchte ich nur darauf hinweisen, dass es viel bedeutender ist, zunöchst das ganze Drumherum und die Steuerung in der Wikipedia zu optimieren. Die Barrierefreiheit der Artikel ist ein Schritt, der danach kommen sollte. — Lecartia Δ 20:49, 3. Jul. 2007 (CEST)

Ja, das ist wahrscheinlich der beste Weg. Lalü als blinder Benutzer hat sich auch erstmal an derartige Dinge rangemacht. --RalfR → BIENE braucht Hilfe 20:56, 3. Jul. 2007 (CEST)

Meine Fragen, die man in über Gespräch/Chat/Diskussion klären kann:

• Was soll konkret erreicht werden?
• In welchen Teilschritten?
• Bis wann?

— Lecartia Δ 16:48, 4. Jul. 2007 (CEST)

Unser Vorschlag: Jcornelius Party könnte für eine erste kleine Diskussionsrunde herhalten. Dort können wir auch mal allen Interessierten unsere Ideen offenbaren.

• Ein kleiner, definierter Bereich der Wikipedia soll weitgehend barrierefrei gestaltet werden. Dies kann und wird nicht im Artikelnamensraum sein.
• Die Teilschritte sollten in den Arbeitsgruppen definiert werden, die Anforderungen sind zu verschieden.
• Termin für faßbare Ergebnisse ist wahrscheinlich Anfang Dezember, nähere Aussagen sind erst möglich, wenn wir Kontakt mit der Stiftung Mensch haben.

Der erste Schritt wäre für mich auf alle Fälle eine Bestandsaufnahme, um konkret die Probleme der verschiedenen Nutzergruppen zu identifizieren - der zweite Schritt wäre dann, nach möglichen Konfliktsituationen zwischen den Bedürfnissen der verschiedenen Gruppen zu suchen und diese so weit möglich auszuräumen. Erst dann kann man mit der Aufstellung von Zielen und den Teilschritten/Meilensteinen auf dem Weg dahin beginnen. Solange die genauen Probleme nicht bekannt sind, wäre alles andere nur eine ABM-Maßnahme ohne wirklichen Mehrwert. -- srb ^♋ 18:49, 4. Jul. 2007 (CEST)

Du hast völlig Recht - und so haben wir im Bereich der Blinden begonnen: http://de.mini.wikia.com/wiki/Blinden-Wiki/behebbare_Probleme --RalfR → BIENE braucht Hilfe 19:40, 4. Jul. 2007 (CEST)

Wieviel Barrierefreiheit wäre möglich ohne artikelspezifische Änderungen?

Mal laut gedacht: Wieviel Barrierefreiheit liesse sich realisieren durch Maßnahmen, die nicht auf Änderungen an einzelnen Artikeln beruhen? Ich denke dabei z.B. an ein Portal, das den Zugang zu bestimmten Bereichen der Wikipedia vereinfacht. Ich denke an eine Skin, die auf die Linkleiste an der linken Seite, das Logo etc. verzichtet und die auf die Nutzung durch Screenreader und Braillezeilen optiminiert ist. Ich denke an einen Filter, der die Anzeige von Artikeln für diese technischen Hilfen optimiert. Schon die Druckansicht eines Artikels dürfte doch beispielsweise deutlich barrierefreier sein als die normale Ansicht, und liesse sich eventuell noch weiter in Richtung Barrierefreiheit optimieren. Eine solche Ansicht liesse sich dann an günstiger Stelle (z.B. am Anfang eines Artikels) als Link "Für Screenreader und Braillezeilen optimierte Ansicht" oder ähnlich platzieren, oder sie wäre die Standardansicht in einer für barrierefreiheit optimierten Skin.

Mir ist klar, dass das mit solchen Maßnahmen Erreichbare weit vom Optimum entfernt wäre und auch nicht für alle Barrieren und Formen von Behinderungen relevant wäre. Aber das Verhältnis zwischen Aufwand und Nutzen erscheint mir doch brauchbar für eine Zwischenlösung, bis optimalere Lösungen zur Verfügung stehen, die dann eher durch artikelspezifische Änderungen erreichbar wären. --Uwe 21:44, 4. Jul. 2007 (CEST)

Ich habe weiter unten gerade etwas geschrieben, das auch dieses Thema anreißt. Kurz: Das Standardskin der Wikipedia ist bereits jetzt ein Musterbeispiel an Barrierefreiheit. Schau dir die Wikipedia einmal mit Lynx an (oder schalte im Opera das CSS ab), dann wirst du sehen, was ich meine.

Dem würde ich mal etwas widersprechen wollen. Das Standardskin hat mehrere Probleme, die allerdings nicht in der schon auch ordnetlichen Trennung von Markup und Layout liegen, sondern vielmehr in der Abfolge des Markups und der mangelhaften Sprungmarken.

Bei den Sprungmarken gibt es derzeit nur die auf Navigation und Suche. Ist man dann aber mal da, kommt man nicht wieder zurück. ZUdem ist Navigation nicht klar definiert, denn es gibt hier gleich mehrere Navigationen: EIne Inhaltsnavigation die Artikel betreffen, eine für die persönblichen Werkzeuge, dann eine die sich selbst nochmal Navigation nennt (aber nicht dieselbe ist zu der man bei Klick auf Navigation gesprungen ist!) und dann noch Mitmachen, Werkzeuge und Zusatzinfos (Datenschutz, Über, Impressum).

Dies müsste man besser Strukturieren und die Reihenfolge klarer machen. Wobei man natürlich nicht den Fehler machen sollte jetzt für jeden dieser Menüpunkte eine Sprungmarke zu machen und hinter jedem Absatz ein "Nach oben" einzubauen.

Das für den Inhalt wichtigste Menü wird derzeit auch nicht via Sprunkmarke angezeigert (Inhaltsverzeichnis).

IMHO wäre es daher sinnvoll ein neues Skin anzubieten, bei dem die Reihenfolge verschiedener Bereiche im Markup verändert werden. (Dies ist technische ohne weiteres Möglich, für eigene Wiki-Installationen hab ich es bereits getan.) Eine etablierte Reihenfolge der Bereiche ist z.B. diese: Titel, Sprungmarken, Suche, Inhaltsnavigation, Inhalt, technische Navigationen, Zusatztexte --Xwolf 23:34, 24. Jul. 2007 (CEST)

Die Idee eines Portals für Blinde gefällt mir, allerdings muss so etwas von den Benutzern kommen, die sich damit auskennen. --TM 21:00, 17. Jul. 2007 (CEST)

„Barrierefreiheit ohne artikelspezifische Änderungen“ lässt sich auch erreichen, indem wir dafür sorgen, das häufig benutzte Vorlagen barriereärmer werden. Ich habe zu diesem Thema eine eigene Seite begonnen: Vorlage Diskussion:Infobox Ort in Deutschland/Barrierefreiheit. --TM 09:17, 3. Aug. 2007 (CEST)

Grundgesetz-Paragraph?

Müsste das ganz oben in der Einleitung nicht Artikel statt § sein? Ich glaube nicht, dass das austauschbar ist. --Gruß, Con^structor 01:40, 8. Jul. 2007 (CEST)

• Ja, das GG hat Artikel, keine Paragraphen. --88.77.9.213 01:45, 10. Jul. 2007 (CEST)

Ja, mein Fehler. --RalfR → BIENE braucht Hilfe 07:56, 10. Jul. 2007 (CEST)

Bildbeschreibungen

Ein Teil der Pflichten für barrierefreie Webseiten ist es, zu Bildern unter allen Umständen neben html-alt-Tags auch eine verbale Bildbeschreibung auf einer eigenen, zu verlinkenden Seite, bereitzustellen, die Blinde und schwer Sehbehinderte nutzen können, um den Bildinhalt erfassen zu können. In aller Regel sind diese Beschreibungen mindestens einige, eher viele Sätze lang. Sie müssen ausreichen, daß ein begabter Leser das Bild danach nachskizzieren kann, ohne es zuvor gesehen zu haben.

Solche Seiten haben eine gewisse technische Infrastruktur zur Voraussetzung, die Wikipedia und Mediawiki zur Zeit nicht bieten. Bilder können und werden in mehreren Seiten eingebunden, also müssen die Beschreibungsseiten mit dem Bild assoziiert sein, nicht mit dem jeweiligen Artikel oder der Seite, in die das Bild eingebunden ist.

Manche Bilder werden als Erkennungszeichen enigesetzt - etwa im Baustein „Begriffsklärung“ - solche erfordern zusätzlich für diesen Einsatzfall eine Erklärung oder müssen per Sehbehinderten-CSS ausgeblendet bleiben.

Eine weitere Schwierigkeit ergibt sich daraus, daß viele Bilder von Wikimedia Commons Repository zur Verfügung gestellt werden, wo Bildbeschreibungen zur Zeit schon in wenigstens etwa 250 Sprachen benötigt werden.

Wer traut sich denn zu, die entsprechenden Spezifikationen in Aufträge für die Weiterentwiklung der Wiki-Programmierung umzusetzen und auf MediaZilla einzutragen? Vielleicht kann man für die Umsetzung sogar Fördergelder bekommen?

--88.77.9.213 01:45, 10. Jul. 2007 (CEST)

Zu den verlinkten Beschreibungsseiten: Die Bilder sind doch bereits zu ihren Beschreibunsseiten verlinkt, oder braucht es eine Extralink unter dem Bild? Würde es nicht reichen die jetzigen Beschreibungsseiten entsprechend auszubauen? --Revvar (D Tools) 08:29, 10. Jul. 2007 (CEST)

Was die IP schreibt, ist nicht von der Hand zu weisen. Ob unsere jetzige Bildbeschreibungsseite dafür genutzt werden kann und nur ausgebaut werden muß, werden wir testen. Vielleicht müssen wir auch einfach nur die Struktur des Links im Artikel etwas ändern. --RalfR → BIENE braucht Hilfe 08:42, 10. Jul. 2007 (CEST)

Grundsätzlich stimme ich zu, würde die Prioritäten aber ewas anders setzen. Zuerst einmal ist das Beispiel mit dem Baustein „Begriffsklärung“ ein schlechtes, denn dort handelt es sich um ein rein zierendes Bild, das einen leeren alt-Text bekommen muss (ist bereits möglich) und dementsprechend auch nicht verlinkt sein dürfte (nicht möglich).

Was mich (wie auch schon richtig gesagt) sehr viel mehr stört, ist die Tatsache, dass keinerlei Unterscheidung zwischen Bildunterschrift (sichtbar für jeden, beschreibt die Funktion des Bildes im Kontext des Artikels), Alternativtext (alt-Attribut, beschreibt den Inhalt des Bildes für den Fall, dass das Bild nicht sichtbar ist) und Tooltipp (title-Attribut, zusätzliche Informationen) gemacht wird. Es gibt nur einen einzigen Text, der an allen drei genannten Stellen angezeigt wird, meist aber natürlich so formuliert ist, dass er als Bildunterschrift funktioniert.

Für viele der anderen genannten Forderungen (Stichwort longdesc) ist die Bildbeschreibungsseite meiner Ansicht nach ausreichend. Es besteht sogar jetzt schon die Möglichkeit, für Commons-Bilder zusätzliche Beschreibungsseiten in den einzelnen Wikipedias in der jeweiligen Sprache anzulegen. Diese Möglichkeit wird nur so gut wie gar nicht genutzt. --TM 00:39, 12. Jul. 2007 (CEST)

Eine Barriere für alle: Suche und Navigation

So sehr ich dieses Projekt hier begrüße (ich sehe mich als langjährigen Kämpfer an der Front der Barrierefreiheit), so sehr muss ich mich doch über den Denkansatz wundern. Es wurden ausschließlich Arbeitsgruppen für Menschen mit Einschränkungen definiert. Aber was ist mit – zum Beispiel – mir? Ich bin weder jung noch alt noch behindert. Ich bin ein ganz normaler Benutzer und stolpere hier in der Wikipedia trotzdem jeden Tag über jede Menge Barrieren. Beispiele:

• Die Suchfunktion ist seit Jahren eine Katastrophe. Ähnliche Begriffe werden nicht gefunden. Oft werden keine Textausschnitte angezeigt und wenn doch, dann völlig falsche. Beim Blättern bricht die Anzeige plötzlich ab. Die Sortierung der Suchergebnisse ist nicht nachvollziehbar. Auf der Suchergebnisseite gibt es drei (!) Eingabefelder, deren Unterschied sich nicht erschließt, eins davon mit einem hingeworfenen Haufen Kontrollfelder. Oft funktioniert die Suche auch gar nicht. Meist ist es schlicht sinnvoller, Google zur Suche nach Wikipedia-Artikeln zu benutzen. Barrierefrei ist das für niemanden.
• Wenn ein Leser beim Stöbern in der Wikipedia auf einen roten Link klickt (hier ein Beispiel), wird ihm eine Seite präsentiert, von der aus er keinerlei Möglichkeit hat, den Artikelbestand nach anderen Vorkommen dieses Wortes zu durchsuchen. Er muss statt dessen das Wort entweder über die Zwischenablage in das Suchfeld am linken Seitenrand kopieren oder es dort neu eingeben. Anders formuliert: Aus irgend einem Grund wird davon ausgegangen, dass jeder weiß, was „roter Link“ bedeutet. Dementsprechend erscheint nach dem Anklicken eine Seite, die ausschließlich Autoren dient, passive Leser (die in der Mehrzahl sind) aber völlig ignoriert. Warum diese Barriere?

Diese Liste ließe sich mit zahlreichen weiteren Beispielen fortsetzen. An welche Arbeitsgruppe soll ich mich mit solchen Problemen wenden? --TM 00:17, 12. Jul. 2007 (CEST)

Du hast vollkommen Recht! Es gibt auch noch ein anderes Problem: Das Beseitigen von Barrieren für einen Nutzerkreis schafft welche für andere. Stell dir nur mal vor, jemand würde Artikel in leichter Sprache schreiben ;) Als "Kämpfer an der Front der Barrierefreiheit" bist du herzlich eingeladen - die Barrieren für jedermann können wir uns auch gleich mit ins Pflichtenheft schreiben. Wir könnten beispielsweise die Google-Suche integrieren (lassen), wie das jeder kleine Homepage-Bastler tut. Die Suchergebnisse zeigen allerdings bezahlte Werbung. Also müßte eine Lösung her, die nur "ganz oben" von der Foundation mit Google besprochen werden kann. Unsere Entwickler sind offenbar nicht in der Lage, die Suche "ordentlich" zu programmieren. Das wundert mich auch nicht, unsere paar Leute können ja schlecht nebenbei eine Lösung schaffen, für die Google Jahre gebraucht hat. --RalfR → BIENE braucht Hilfe 00:42, 12. Jul. 2007 (CEST)

Weil ihr gerade das Stichwort "Suche" fiel: Dass sich daran in nächster Zeit auch wohl nichts dran ändern wird, liegt IMHO daran, dass das Problem mit geringer Priorität eingestuft ist. --STBR – !? 00:49, 12. Jul. 2007 (CEST)

Ich sehe eine vage Chance, daß uns Google eine werbefreie Suche sponsort. Dies wäre aber eine Frage, die alle Projekte betrifft. @Jimbo: frag doch mal...--RalfR → BIENE braucht Hilfe 00:55, 12. Jul. 2007 (CEST)

@RalfR: Das ist nicht das Problem. Die Google-Suche wird jetzt schon als Alternative präsentiert, wenn die Wikipedia-interne Suche mal wieder nicht funktioniert. Man kann sie recht elegant auf die Wikipedia-Seiten einschränken und Werbung erscheint da so gut wie nie (Beispiel). Die Google-Suche weiß allerdings nichts von Namensräumen, Kategorien, Personendaten etc., so dass sie in vielen Fällen nicht als Alternative taugt. --TM 01:05, 12. Jul. 2007 (CEST)

Punkt zwei hab ich jetzt grade mal behoben, im Erstellungsdialog fuer neue Artikel bekommt man jetzt Links zur Suche. --Elian Φ 20:54, 24. Jul. 2007 (CEST)

Super, danke, daß sowas mit so wenig Aufwand geht :) --RalfR → BIENE braucht Hilfe 21:58, 24. Jul. 2007 (CEST)

Identifikation konkreter Barrieren

Das Standard-Skin der Wikipedia ist – wenn man es sich einmal ohne Stylesheets, Bilder usw. ansieht (mit Opera oder Lynx auch für Sehende gut nachvollziehbar) – alles in allem ein Musterbeispiel an Barrierearmheit. Vorn geht es zügig mit dem Artikeltext los, darunter folgen mit Zwischenüberschriften sauber gegliedert die verschiedenen Werkzeuge. Alles ist sauber linearisiert, wie man sagt.

Konkrete Barrieren entstehen eigentlich nur dann, wenn in einem Artikel Elemente verwendet werden, die komplizierter sind als normaler Text mit Zwischenüberschriften. Im Folgenden möchte ich ein paar konkrete Beispiele zur Diskussion stellen.

Barrieren durch Tabellen

Problematisch sind Tabellen deshalb, weil sie – anders als Listen – zweidimensional sind. Jede Tabellenzelle ist einer Spalte und einer Zeile zugeordnet. Bei der Notation im Quelltext muss daher berücksichtigt werden, welche dieser beiden Zuordnungen primär und welche sekundär ist.

Das folgende Beispiel würde im Screenreader beispielsweise als „CDU, Die Grünen, 9 Sitze, 2 Sitze“ vorgelesen werden, was offensichtlich nicht besonders viel Sinn ergibt.

CDU	Die Grünen
9 Sitze	2 Sitze

Die Lösung ist in diesem Fall einfach:

CDU	9 Sitze
Die Grünen	2 Sitze

Möglich wäre auch eine schlichte Liste. Da es sich nur um zwei Spalten handelt, leidet die Übersichtlichkeit kaum:

• CDU: 9 Sitze
• Die Grünen: 2 Sitze

Barrieren durch Bilder

Beschreibung

Bilder wie das nebenstehende sind in der Wikipedia völlig normal. Das Problem hierbei ist, dass der Beschreibungstext im Quelltext insgesamt dreimal auftaucht (hier zur Veranschaulichung stark gekürzt):

<a title="Beschreibung">
  <img alt="Beschreibung" />
</a>
Beschreibung

Der Text ganz unten ist der auch für Sehende lesbare Beschreibungstext und insofern völlig in Ordnung.

Das Attribut title ist dagegen schon deutlich fragwürdiger. Es sorgt dafür, dass der Text als kleiner gelber Tooltipp erscheint. Screenreader wie Jaws lesen das nicht vor, so weit ich weiß. Dennoch frage ich mich, welchen Nutzen diese Wiederholung haben soll?

Das Attribut alt ist wortwörtlich ein Alternativtext, der erscheint, wenn das Bild nicht darstellbar ist. Bei Bildern ohne thumb ist das wichtig, bei Bildern mit Bildunterschrift dagegen eine weitere fragwürdige Wiederholung.

Eine Lösung für dieses spezielle Problem ist schwierig, wenn nicht gar unmöglich. Und selbst wenn, wie sollen die (sehenden) Benutzer dazu gebracht werden, zwei Texte einzugeben? Ideen? --TM 20:52, 17. Jul. 2007 (CEST)

Seltsam, bei mir im FF2 sieht der Quelltext (genauso gekürzt) so aus:

<a title="">
  <img alt="">
</a>
Beschreibung

Welchen Browser verwendest Du? Möglicherweise kommt Dein obiger Quelltext durch Browserfixes zustande? -- srb ^♋ 22:20, 17. Jul. 2007 (CEST)

Sorry, hab's gerade mal abgemeldet probiert und da hab ich genau den von Dir beschriebenen Quelltext - die Änderungen werden vermutlich von dem von mir eingebundenen popups.js hervorgerufen. Das bedeutet allerdings, dass es in einem spezellen Screenreader-Skin genauso leicht geändert werden könnte. -- srb ^♋ 22:28, 17. Jul. 2007 (CEST)

Du verkennst den Kern meines Problems: Der alt-Text soll den Inhalt des Bildes beschreiben, so dass man sich vorstellen kann, was da zu sehen ist (ein guter alt-Text für das obige Beispiel wäre etwa: "Dialogfenster, das vor dem Ende des Supports für Windows 98 warnt"). Der Text unter dem Bild soll den Zusammenhang zwischen Bild und Text erklären (hier: „Barrieren existieren nicht nur für behinderte Menschen“). Im Idealfall müssen das zwei völlig verschiedene Texte sein. --TM 10:09, 18. Jul. 2007 (CEST)

Da hab ich Dich tatsächlich falsch verstanden - in diesem Fall geht das bei thumb-Bildern (und vermutlich auch in Galleries) nur durch Softwareänderungen (d.h. über einen Bugreport und vermutlich warten bis zum St.-Nimmerleinstag), um die Angabe von zwei Texten zu ermöglichen. -- srb ^♋ 10:40, 18. Jul. 2007 (CEST)

Eben, und dazu sollten wir uns überlegen, wie das praxistauglich umgesetzt werden könnte. Zum Beispiel mit einem Abschnitt <alternative>…</alternative> in der Bildbeschreibungsseite, der automatisch überall als alt-Attribut für das Bild eingesetzt wird. Oder indem Teile aus den vorhandenen Bildbeschreibungs-Vorlagen als alt-Attribut angezeigt werden. Die Belastung für die Server wäre enorm, aber das ist die beste Lösung, die mir einfällt. --TM 11:28, 18. Jul. 2007 (CEST)

Die Belastung würde noch steigen, wenn die Alternativtexte sprachabhängig sein sollen (was unbedingt wünschenswert ist). Alternativ müsste für jedes Bild eine deutschsprachige Bildbeschreibung angelegt werden. --Gnu1742 12:20, 20. Jul. 2007 (CEST)

Ich bemerke beim Experimentieren mit Jaws gerade, dass leere Bildbeschreibungen gar nicht so sinnvoll sind. Weil Bilder in der Wikipedia immer auch Links sind, muss Jaws zwangsläufig irgend etwas vorlesen. Er entscheidet sich dann für den Dateinamen. Das heißt, es ist oft besser, lieber eine kurze und prägnante Beschreibung einzugeben als gar keine. --TM 09:22, 3. Aug. 2007 (CEST)

Hallo TM, das ist abhängig davon, wie deine Einstellungen in Jaws sind und wie ausführlich es vorgelesen werden soll. Unter HMTL-Optionen gab es, glaube ich, drei Arten der Anzeige. — Lecartia Δ 09:59, 3. Aug. 2007 (CEST)

Das ist schon klar. Ich denke, für solche Betrachtungen muss man von den Standardeinstellungen ausgehen. Jaws erlaubt sehr viele Einstellungen und man hätte keine Diskussionsgrundlage, wenn man die alle berücksichtigen wollte. --TM 10:03, 3. Aug. 2007 (CEST)

Ja, das stimmt. Ich habe mich in den letzten 3 Jahren bislang niemals mit diesen Optionen beschäftigt und viele andere blinde Anwender ebenfalls nicht. Diese Funktionen sind eher etwas für Experten oder werden für Anpassungen gebraucht, die für die verschiedenen beruflichen Anforderungen im Arbeitsleben benötigt werden, um beispielsweise mit dem Webangebot des eigenen Unternehmens besser klarkommen zu können. Die Devise sollte also immer sein, möglichst alle Verbesserungen in Bezug auf die Standardeinstellungen zu entwickeln. Die sogenannten Ausführlichkeitsoptionen (Einsteiger/Fortgeschritten/Experte) von Jaws werden aber meist von vielen Usern individuell eingestellt aber ich weiß nicht, ob sie auch auf oben stehende Problematik Einfluß haben. Ich habe immer "fortgeschritten" eingestellt. -- Lalü 10:59, 3. Aug. 2007 (CEST)

Ihr habt beide natürlich Recht, ich habe mich nur gewundert, weil JAWS bei leerer Beschreibung eigentlich nur „Bild“ vorliest. Aber nun habe ich gesehen, woran es liegt: Bilder ohne Beschreibung in Wiki-Syntax werden in HTML zu:

<img alt="" longdesc="relative Bild-URL" src="aboslute Bild-URL" … />

Es wäre also wünschenswert, wenn Bilder ohne Beschreibung auch mit in einer leeren longdesc-Beschreibung resultieren, nicht wahr? — Lecartia Δ 11:04, 3. Aug. 2007 (CEST)

Vorschlag für ein praxisnahes Experimentierfeld

Ich schlage vor, die hier diskutierten Barrieren nicht im Stillen irgendwo im Wikipedia-Namensraum auszuprobieren sondern an einem konkreten Beispiel. Häufig benutzte Vorlagen wie die Vorlage:Infobox Ort in Deutschland sind ein dankenswertes Betätigungsfeld, da jede Verbesserung dort sogleich 13.000 Artikel etwas barriereärmer macht. Ich habe dazu eine eigene Seite Vorlage Diskussion:Infobox Ort in Deutschland/Barrierefreiheit angelegt und würde mich über jede Hilfe freuen. --TM 20:09, 2. Aug. 2007 (CEST)

Öffentlichkeitsarbeit

Ich stelle zur Zeit fest, wie schwierig es ist, Leute für dieses Thema zu sensibilisieren. Beispielsweise bei der Verwendung von Tabellen aus reinen Layout-Gründen möchten die sich ungern von liebgewonnenen, aber schlechten Gewohnheiten trennen. Ein paar Leute alleine können nicht die ganze WP umkrempeln, daher sind noch Mitstreiter zu gewinnen. Just heute flattert mir die aktuelle iX in die Hand, die in einem kurzen Artikel etliche Websites beschreibt, die sich mit dem Thema befassen. Ein schneller Überflug meinerseits fand da schon einige sehr brauchbare Seiten. --Gnu1742 12:20, 20. Jul. 2007 (CEST)

Blindtabellen bzw. Tabellen zu Layoutzwecken sind tatsächlich ein großes Problem - aber es gibt viele sinnvolle Anwendungen dafür (z.B. Portale oder Listenartikel mit vielen schmalen Einzeltabellen) und praktikable Alternativen gibt es leider nicht, außer wir wollen eine Vielzahl von Lesern (und auch Autoren) vor den Kopf stoßen: Es gibt zwar css-Alternativen für Blindtabellen, allerdings werden die im IE (zumindest bis einschließlich Version 6 - die Version 7 habe ich noch nie verwendet) schlichtweg ignoriert - die Folgen für das dann dargestellte Layout kann man sich leicht vorstellen ... -- srb ^♋ 12:31, 20. Jul. 2007 (CEST)

Meine CSS-Version tabellenlosen Designs hat schon 2003 im IE funktioniert - es geht also. Man muß aber sehrwohl unterscheiden, wann man Tabellen nimmt und wann nicht. Taxoboxen bei den Biologen sind ein Beispiel dafür, daß Tabellen auch sinnvoll sein können. Zum Thema Öffentlichkeitsarbeit: ich werde morgen bei JC im Garten mit Lecartia etwas Werbung für die Sache machen, viele der aktiven Mitstreiter sind ja anwesend. --RalfR → BIENE braucht Hilfe 12:40, 20. Jul. 2007 (CEST)

Das interessiert mich jetzt: welche css-Auszeichnungen verwendest Du, wenn Du drei (oder mehr) Texte oder Tabellen nebeneinander unterbringen willst (mit zwei Elementen kann ich es auch - die Darstellung reagiert dann allerdings sehr sensibel auf kleinste Änderungen und erfordert viel Tüftelarbeit, vor allem wenn z.B. auch noch ein Hintergrundfarben vorhanden sind)? -- srb ^♋ 12:46, 20. Jul. 2007 (CEST)

http://www.petra-doehler.de und http://www.fahrradmonteur.de (letzteres ist von 2005) - bei meinen Tests hat beides in allen Browsern, sogar in Amaya funktioniert. --RalfR → BIENE braucht Hilfe 13:11, 20. Jul. 2007 (CEST)

Eieieiei... Merksatz: Gebe nie ein Beispiel an, es wird nur darauf rumgeritten werden ;-) Mir gehts gar nicht vorrangig um die Tabellen, die waren mir just heute ins Auge gesprungen. Mir gehts wirklich nur darum, dass man bei Entdeckung einer schlechten Lösung einige gute Argumente für die gute Lösung an der Hand hat. --Gnu1742 13:25, 20. Jul. 2007 (CEST)

Biene-Projekt im accessBlog

Im accessBlog von "Einfach für Alle" der Aktion Mensch gabs heute einen kurzen Eintrag zu unserem Projekt. [1] Dort lesen viele "Barriereexperten" mit, so daß dadurch sicherlich der eine oder die andere auf uns aufmerksam geworden ist. -- Lalü 20:20, 24. Jul. 2007 (CEST)

Vorgestern hat Stefan Münz im Webkompetenz-Blog einen interessanten & motivierenden Beitrag mit dem Titel "An Wikipedia schrauben im Dienste der Barrierefreiheit" veröffentlicht. Ich finde solche externen Meinungen von Fachleuten sehr hilfreich und hoffe auf noch mehr. :-) -- Lalü 18:33, 2. Aug. 2007 (CEST)

Ich habe mich auch gleich bei Stefan bedankt. Ja, sowas ist aus berufenem Munde sehr wichtig. --RalfR → BIENE braucht Hilfe 19:02, 2. Aug. 2007 (CEST)

Statische Schriftgrößen

In Wikipedia-Tabellen habe ich auf 95 Prozent gesetzte Schriftgrößen gefunden. Vermute ich richtig, dass das nicht das Anliegen der Barrierefreiheit unterstützt und zumindest nicht im Interesse von Sehschwachen ist? -- Hunding 23:39, 27. Jul. 2007 (CEST)

naja, wer wirklich sehschwach ist, wird sich eine hinreichend große schrift einstellen, und dann sind 95% auch groß. -- ∂ 23:56, 27. Jul. 2007 (CEST)

Sehe ich genauso, relative Schriftgrößen sind m.E. in Ordnung, da sie bei einer Vergrößerung der Browseranzeige (z.B. im FF mit <CTRL>+<+>) mit vergrößert werden - hier könnte jedoch jemand mit einer Sehschwäche wohl besser Auskunft geben. Weitaus problematischer sind hingegen absolute Schriftgrößen, die auch hin und wieder anzutreffen sind - die sollten auf alle Fälle auf Relativ-Werte umgestellt werden. -- 12:02, 28. Jul. 2007 (CEST)

Hehe, hab ich vor einiger Zeit mal versucht... Wurde revertiert mit der Begründung, dass das Layout auch schon vorher standardkonform war... --Gnu1742 09:23, 30. Jul. 2007 (CEST)

Kann ich nachvollziehen: ich kann mich düster erinnern, dass ich bei meinen ersten Portallayouts vor auch einige feste Schriftgrößen eingesetzt habe - und wenn da jemand drin „rumgepfuscht“ hätte, wäre ich wohl auch nicht sehr glücklich gewesen. Damals hat mir einfach das Bewusstsein (und auch die Erfahrung) gefehlt, um entsprechende Änderungen zu verstehen und zu akzeptieren - hier ist wohl noch viel Überzeugungsarbeit zu leisten. -- srb ^♋ 09:35, 30. Jul. 2007 (CEST)

Schwesterprojekt bei En.Wikipedia

Ich habe in der englischsprachigen WP das Projekt Accessibility/Usability gefunden, daß sich mit der gleichen Thematik wie das Biene-Projekt beschäftigt. Da mein Englisch leider nicht ausreicht, um dort alles komplett zu verstehen, wäre es sehr nützlich, wenn irgendjemand zumindestens die wichtigen und dort eher unumstrittenen Aussagen ins Deutsche übersetzen könnte. Ich habe mich sehr über diese Seiten gefreut und würde die dort zu findenen Infos nun auch gerne soweit wie möglich verstehen und nachvollziehen können. . Einige "Bugs", die mir als Laie bereits hier bei De.WP aufgefallen sind, habe ich dort gut beschrieben wiedergefunden. Links findet ihr auf der Rechercheseite. -- Lalü 08:13, 30. Jul. 2007 (CEST)

Wenn mir niemand zuvorkommt, werde ich die Seite heute abend mal in die de-wp lizenzkonform importieren und dann schrittweise übersetzen. --Gnu1742 08:19, 30. Jul. 2007 (CEST)

Und wenn ich dann schon dabei bin: en:Wikipedia:WikiProject Usability/Infobox accessibility erscheint mir auch sehr nützlich. --Gnu1742 08:31, 30. Jul. 2007 (CEST)

Super! Meinst du, daß auch Teile der Diskussionsseite übersetzt werden dürfen? Ich fürchte, daß sowas leider nicht Lizenz-konform wäre aber auf den Disk-Seiten stehen dort nun mal sehr spannende Infos. -- Lalü 08:53, 30. Jul. 2007 (CEST)

Sodele, hier sind sie schonmal: Wikipedia Diskussion:BIENE/import-en/Wikipedia:Accessibility und Wikipedia:BIENE/import-en/Wikipedia:WikiProject Usability/Infobox accessibility --Gnu1742 10:40, 30. Jul. 2007 (CEST)

Biene-Studie, Wikimedia: Vorschlag

Hallo, gestern ist meinem Azubi ein Brief ins Haus geflattert, der uns darüber informierte, dass es statt eines Awards dieses Jahr eine Studie zum Thema Barrierefreiheit in Web-2.0-Anwendungen von BIENE und Aktion Mensch geben wird (was Ihr sicher schon gelesen habt). Wikipedia wird explizit genannt. Ich möchte anregen, daß wir uns (auch mit den Biene-Connections aus der Vereinsarbeit, immerhin saß letztes Jahr ein Vorstandsmitglied von uns in der Jury) mit den Verantwortlichen für die Studie in Verbindung setzen, um a) herauszufinden, ob Wikipedia explizit in der Studie analysiert wird oder b) was wir tun können, um WP in die Studie zu kriegen bzw. c) unsere Unterstützung anzubieten. Gerne kümmere ich mich darum (für irgendwas muß mein Vorstandsjob ja gut sein ;-)), wenn Ihr das für eine brauchbare Idee haltet. In Folge hätten wir nämlich - statt einzelner Anhaltspunkte, wo es „hakt“ - im besten Fall eine perfekte Analyse, auf deren Grundlage wir konkrete Maßnahmen gut priorisieren und in Angriff nehmen könnten.

Was haltet Ihr davon? Freue mich auf Feedback. Grüße, --elya 22:01, 31. Jul. 2007 (CEST)

Ich finde das eine ausgezeichnete Idee! „[…] Deshalb möchten wir herausfinden, ob und wenn ja welche Barrieren diese Angebote für Menschen mit Behinderungen aufbauen. Die wollen wir im Rahmen der Studie identifizieren und erste Lösungsansätze skizzieren, damit Menschen mit Behinderung diese neuen Anwendungen ebenso selbstverständlich nutzen können, wie andere barrierefreie Webseiten. […]“ schreiben sie selbst. Wenn sie schon einen „Schlachtplan“ augsearbeitet haben, sollte es unsere Aufgabe sein, sie so gut wie irgend möglich zu unterstützen. Auf keinen Fall sollten wir uns doppelte Arbeit machen oder vor uns hin elaborieren. (Was alles bisher genannt wurde, kann den Biene-Leute mitgeteilt werden.)

Also: Unbedingtes Pro für Kontaktaufnahme mit Biene und Zusammenarbeit. — Lecartia Δ 22:11, 31. Jul. 2007 (CEST)

Volle Zustimmung auch von mir! Und danke für deine Hilfe. --RalfR → BIENE braucht Hilfe 22:23, 31. Jul. 2007 (CEST)

Was immer auch geschehen ist ...

Ich gehe davon aus, daß sich für Sehende nichts verändert hat, aber ich habe seit heute zwischen 19 und 21 Uhr das Problem, daß der Bearbeiten-Link hier auf einmal genau so dargestellt wird wie in En.WP und vielen anderen Wikis. Mein Screenreader liest nach dem anspringen der nächsten Überschrift, was ich einfach mit der Taste "h"machen kann, auf einmal immer zuerst den Bearbeiten-Link vor, so daß ich danach noch 2 Zeilen mit den Cursortasten nach unten wandern muß, bis ich den Titel lesen kann. Grade dieser kleine Unterschied machte mir das navigieren auf deutschen WP-Seiten bislang sehr komfortabel, während ich mich in anderen Wikis wie En.WP wesentlich langsamer (als eh schon) innerhalb des Seiteninhalts zurecht finden kann. Hier beschreibt ein User von En.WP unter der Überschrift " Editing a section" diese Problematik, die es glücklicherweise hier bislang nicht gab.

Ich wäre sehr interessiert daran, wer was wie geändert hat, denn daß würde eventuell die Erkenntnisse bringen, mit denen man bei En.WP und in vielen anderen Wikis ganz einfach eine große Navigationshürde für Screenreadernutzer beseitigen könnte.
Ach ja, und falls das geht, würde ich eine Rückgängigmachung dieser Veränderung natürlich sehr begrüßen, da mir das Lesen auf den deutschen WP-Seiten sonst etwas zu anstrengend wird. ;-) -- Lalü 22:02, 2. Aug. 2007 (CEST)

Unglaublich, aber während meines Editierens des vorstehenden Beitrags hat sich das Problem verflüchtigt. Merkwürdig ist, daß solch ein Phänomen bislang nie auftrat. Wenn also jemand weiß, ob oder ob nicht an irgendwas gebastelt wurde, würde ich mich über eine Mitteilung dazu freuen. -- Lalü 22:10, 2. Aug. 2007 (CEST)

Hallo Lalü, wollte grade schreiben: das ist vermutlich ein vorübergehendes Problem aufgrund von Serverüberlastung - da wird die falsche Javascript-Datei geladen (oder so ähnlich). Man kann nichts machen, meist erledigt sich das von selbst, wie jetzt bei Dir: evtl. hast du auch jetzt einen anderen, weniger überlasteten Server erwischt. Grüße, --elya 22:20, 2. Aug. 2007 (CEST)

@Lalü: Wahrscheinlich findest du die Lösung hier - du hast einfach einen ungünstigen Moment erwischt. --RalfR → BIENE braucht Hilfe 22:44, 2. Aug. 2007 (CEST)

Danke für den erklärenden Hinweis. Ob es wohl möglich wäre, der En.WP bzw. MediaWiki den Code für die bessere Darstellung der Section-Editlinks zur Verfügung zu stellen oder geht das aus technischen oder anderen Gründen vielleicht nicht? Dadurch könnte eventuell weltweit vielen Screenreadernutzern mit überschaubarem Aufwand eine wesentlich verbesserte Seitennavigation in Wikis ermöglicht werden. -- Lalü 08:58, 3. Aug. 2007 (CEST)

Es handelt sich hier um ein grundsätzliches Problem in der Mediawiki-Software, da die Bearbeiten-Links im Quelltext immer vor den Überschriften stehen, auch in der deutschsprachigen Wikipedia. Die Umsortierung wird erst durch einen JavaScript-„Hack“ erreicht. Das heißt, Webbrowser und Screenreader, die JavaScript nicht ausführen, haben immer das Nachsehen. --TM 09:12, 3. Aug. 2007 (CEST)

Warum nutzt die en.WP denn nicht auch den Codeteil des JavaScript-"Hacks", den wir hier dafür auch verwenden? Die Antwort darauf wird vielleicht keiner der Mitlesenden wissen, aber diese Frage scheint mir sehr wichtig. -- Lalü 14:47, 5. Aug. 2007 (CEST)

Hallo Lalü. Wenn du einen Account auf der englischen Wikipedia hast, kannst du den Hack in deine monobook.js schreiben. Du müsstest nur das reinkopieren:

// ============================================================
 // BEGIN Moving of the editsection links
 
 /*
 * moveEditsection
 * Dieses Script verschiebt die [Bearbeiten]-Buttons vom rechten Fensterrand
 * direkt rechts neben die jeweiligen Überschriften.
 * This script moves the [edit]-buttons from the right border of the window
 * directly right next to the corresponding headings.
 *
 * Zum Abschalten die folgende Zeile (ohne führendes Sternchen) in die eigene
 * monobook.js (zu finden unter [[Special:Mypage/monobook.js|Benutzer:Name/monobook.js]]) kopieren:
 * var oldEditsectionLinks = true;
 *
 * dbenzhuser (de:Benutzer:Dbenzhuser)
 */
 function moveEditsection() {
     if (typeof oldEditsectionLinks == 'undefined' || oldEditsectionLinks == false) {
         var spans = document.getElementsByTagName("span");
         for(var i = 0; i < spans.length; i++) {
             if(spans[i].className == "editsection") {
                 spans[i].style.fontSize = "x-small";
                 spans[i].style.fontWeight = "normal";
                 spans[i].style.cssFloat = "none";
                 spans[i].style.marginLeft = "0px";
                 spans[i].parentNode.appendChild(document.createTextNode(" "));
                 spans[i].parentNode.appendChild(spans[i]);
             }
         }
     }
 }
 // onload
 addOnloadHook(moveEditsection);
 
 // END Moving of the editsection links
 // ============================================================

Entnommen ist das aus diesem Skript. --Revolus Δ 13:13, 7. Aug. 2007 (CEST)

Hallo Revolus. Vielen Dank für deinen Tip, der mir sehr vielversprechend scheint. Leider stelle ich mich wohl zu dumm an, da ich noch nicht einmal die entsprechende Seite aufrufen konnte, vom Verständnis des dann einzugebenden Codes ganz zu schweigen. ;-) Bei en.WP heiße ich Lalue, vielleicht könntest du oder ein Mitleser mir das kurz einrichten? Wenn das nur der eingeloggte User selbst machen kann, könnte ich dir dazu kurz mein PW zumailen. Was meinst du? -- Lalü 16:08, 7. Aug. 2007 (CEST)

Ich helf doch gern :-) Bevor du mir dein Passwort zuschickst, probiere mal diesen Link hier aus: Eintragen. Dann müsstest du nur noch die Seite speichern. Das Skript sucht alle Abschnitt-Bearbeiten-Links und holt sie aus ihrem übergeordneten Element herraus und hängt es an dessen letzten Element an. Also aus A-B-C-D werde B-C-D-A. --Revolus Δ 17:11, 7. Aug. 2007 (CEST)

Juhu, ich bin begeistert! Hat alles geklappt und die Navigation dort ist nun wesentlich besser möglich. Herzlichen Dank! Nun sollte ich mir überlegen, wie ich dieses Feature dem Jaws-Nutzer Graham87 mit meinem schlechten Englisch erklären könnte. Er kennt diese Möglichkeit wahrscheinlich garnicht und ich wäre gespannt, ob es auch bei ihm funktioniert und wie er sowas finden würde. Aber das Hat Zeit. -- Lalü 18:28, 7. Aug. 2007 (CEST)

Gib ihm dann mal den Link: en:User talk:Revolus/de-editsection.js. Da müsste er dann nur <Your Name> gegen seinen Namen austauschen. So könnte es auch noch anderen helfen. Ich habe gesehen, dass Graham87 gerade zum Admin nominiert wird. Falls er es wird, dann kann er ja auch die Systemtexte der englischen Wikipedia anpassen. Auch für Sehende ist es wesentlich besser zu Arbeiten mit dem Skript. Wie das geht, weiß ich aber nicht. Hm, dafür lesen hier ja auch Admins mit, die wüssten das dann bestimmt. --Revolus Δ 18:52, 7. Aug. 2007 (CEST)

Bevor sich hier alles in scheinbares Wohlgefallen auflöst, möchte ich noch mal auf diese Frage von Lalü eingehen: Weshalb wird das Javascript zum Verschieben der "Bearbeiten"-Links nicht übernommen, nach enWP oder wohin auch immer? Offenbar bereitet dir, Lalü, stellvertretend für viele Andere, die standardmäßige Reihenfolge zwischen "Bearbeiten"-Link und Überschrift unnötig Probleme. Eine Lösung zu verwenden, die diese seltsame Reihenfolge nachträglich umkehrt, halte ich lediglich für eine Bekämpfung der Symptome, nicht aber der Ursachen. Javascript sollte für die Allgemeinheit das letzte Mittel der Wahl sein. Jeder soll sich nach Belieben das Leben mit eigenen JS- oder CSS-Dateien komfortabler gestalten dürfen, und in den zentralen Dateien können auch gern einige wenige Funktionen von allgemeinem Interesse untergebracht sein, aber die Software sollte von Haus aus schon alles mitbringen, um einen Artikel auch ohne Zusatzskripte lesen und bearbeiten zu können.

Dazu zählt für mich auch die Position der Bearbeiten-Links im Quelltext. Ich selbst musste mir nochmal kurz die Augen reiben und verdeutlichen, dass die Links unlogischerweise vor den Überschriften stehen, wenn man Javascript ausschaltet. Möglicherweise wurde diese Reihenfolge ehemals gewählt, weil das Layout sonst nicht passte. Dreht man Link und Überschrift testweise um, so steht nämlich der Link nun nicht mehr auf einer Höhe mit der Überschrift, sondern ein Stückchen weiter unterhalb. Das Javascript beweist jedoch, dass sich das Problem mit Hilfe einiger CSS-Einstellung zur allseitigen Zufriedenheit lösen lässt.

Wenn wir also

• alle nötigen Änderungen zusammentragen,
• zeigen, dass es gar nicht so schwierig ist, das umzusetzen und schließlich
• noch erfolgreich auf eine tatsächliche Umsetzung auf Seiten der Software und den projektweiten CSS-Dateien drängen,

ist es möglich, eine von Javascript-Unterstützung unabhängige Lösung zu haben, die nicht nur punktuell sondern im gesamten Einflussbereich von MediaWiki hilft. *smells like emperor spirit* ;-) Grüße, --CyRoXX ^(? ±) 20:33, 7. Aug. 2007 (CEST)

Die schuldigen Zeilen im Code zu finden könnte ganz schön schwer werden. Ich werde Morgen oder Übermorgen mal die Sourcen runterladen und schauen, ob ich ein Patch zusammenbekomme, was man an bugzilla: senden könnte. Aber um das Englisch und die Beschreibung müsste sich dann ein Anderer kümmern. Das ist nicht so meine Stärke. Ich weiß, dass einige Admins auch Entwickler sind, welche aber nicht. Wahrscheinlich wäre es das Beste sie anzuschreiben. --Revolus Δ 20:39, 7. Aug. 2007 (CEST)

Sehe ich das richtig, dass der unerwünschte Status Quo:

<p><a name="Was_immer_auch_geschehen_ist_..." id="Was_immer_auch_geschehen_ist_..."></a></p>
<h2> 
<span class="mw-headline">Was immer auch geschehen ist ...</span>  
<span style="font-size: x-small; font-weight: normal; float: none; margin-left: 0px;" class="editsection">
[<a href="/w/index.php?title=Wikipedia_Diskussion:BIENE&amp;action=edit&amp;section=23" 
 title="Abschnitt bearbeiten: Was immer auch geschehen ist ...">Bearbeiten</a>]
</span>
</h2>

ist, aber besser wäre es wie folgt:

<p><a name="Was_immer_auch_geschehen_ist_..." id="Was_immer_auch_geschehen_ist_..."></a></p>
<h2>
<span class="editsection">
[<a href="/w/index.php?title=Wikipedia_Diskussion:BIENE&amp;action=edit&amp;section=23" 
 title="Abschnitt bearbeiten: Was immer auch geschehen ist ...">Bearbeiten</a>]
</span> 
<span class="mw-headline">Was immer auch geschehen ist ...</span>
</h2>

--Raymond ^{Disk. Bew.} 21:08, 7. Aug. 2007 (CEST)

Hehe, genau andersrum. Du scheinst dir den produzierten Code angeschaut zu haben. Das Skript setzt erst die Style-Attribute. Aus

<p><a name="abc" id="abc"></a></p>
<h2><span class="editsection">[<a href="..." title="...">Bearbeiten</a>]</span> <span class="mw-headline">1 abc</span></h2>
<p>Text 123</p>

soll

<p><a name="abc" id="abc"></a></p>
<h2><span class="mw-headline">1 abc</span> <span class="editsection">[<a href="..." title="...">Bearbeiten</a>]</span></h2>
<p>Text 123</p>

werden. Das macht das Skript bis jetzt, es findet alle span#editsection und fügt ihnen das zu spans[i].parentNode.appendChild(spans[i]). --Revolus Δ 21:24, 7. Aug. 2007 (CEST)

Kurze Notiz: elya und Raymond haben sich die Sache mal angeschaut und wohl auch einen Lösungsansatz gefunden. Ein Problem dabei ist zum Beispiel noch, dass manche Browser noch ne Extrawurst brauchen (diesmal IE und FF).Sobald sich was neues ergibt, werden sie es uns bestimmt wissen lassen. ;-) Grüße, --CyRoXX ^(? ±) 23:12, 7. Aug. 2007 (CEST)

Ich durfte schon mal einen Blick auf die Bemühungen von Elya und Raymond werfen und das hat mir gut gefallen. Jetzt bin ich gespannt, ob der Einbau solch einer Veränderung bei MediaWiki überhaupt möglich ist. Die Macht der Gewohnheit und mögliche Probleme für User, deren eigene JS und CSS dadurch durcheinandergeraten könnten, sprechen ja vielleicht dagegen. Danke, CiroXX, daß du diesen Vorschlag gemacht hast. Meine Sprachausgabe liest deinen Namen übrigens immer "Cyro20" vor, ich habe eben erst gesehen, wie du eigentlich richtig geschrieben wirst. ;-) Außerdem hab ich mich endlich getraut, Graham87 anzusprechen und kommuniziere mit ihm nun auf "accessibility talk". Er scheint den JS-Hack von Revolus auch zu mögen, obwohl er wohl irgendwas verändern musste. -- Lalü 18:55, 10. Aug. 2007 (CEST)

Jetzt zu finden unter: Bug #11555 --85.178.161.233 23:59, 3. Okt. 2007 (CEST)

Sprachausgabe

Heise Online verwendet eine Sprachausgabe von http://www.readspeaker.com (Beispiel: [2]) vielleicht könnte man so etwas ähnliches auch bei Wikipedia ergänzen? Möglicherweise gibt es auch ein GPL Projekt? --Liberaler Freimaurer (Diskussion) 15:50, 4. Aug. 2007 (CEST)

Das Pediaphon kennst Du? (Nein, ich finde die Sprachqualität nicht toll, aber ist halt GPL-Ware.) --jha 15:58, 5. Aug. 2007 (CEST)

Nein, kannte ich noch nicht. Der franz. Akzent gefällt mir. :-))

Spricht etwas dagegen, eine Sprachausgabe-Vorlage für Artikel aus dem Dienst zu basteln?

Man müsste es dann allerdings in jeden Artikel als Baustein hinzufügen. Alternative wäre eine Änderung im Skin, dann wäre jeder Artikel erfasst. --Liberaler Freimaurer (Diskussion) 16:46, 5. Aug. 2007 (CEST)

Ich habe da mal eine Vorlage:Pediaphon gebastelt:

{{Pediaphon}}.

--Liberaler Freimaurer (Diskussion) 19:21, 7. Aug. 2007 (CEST)

Ich bin absolut gegen eine solche Vorlage, da man sie in wirklich alle Artikel stellen könnte. Den Dienst bei WP:GW zu erwähnen hielte ich für wesentlich sinnvoller. Und länger als zwei Minuten am Stück kann man der Sprachausgabe eh nicht zuhören, weil man sonst mit Sicherheit die Boxen vernichten wird^^ --Revolus Δ 19:34, 7. Aug. 2007 (CEST)

Erstens ist der Dienst dort längst erwähnt, zweitens geht es darum, das Ganze zu vereinfachen. Auf den Witz gehe ich nicht ein. --Liberaler Freimaurer (Diskussion) 19:50, 7. Aug. 2007 (CEST)

@Revolus: Möglichst natürliche Sprachsynthese? Mein Gott, wer schafft das schon! Lieber ein akzeptabler Service als gar kein Service.

Zur Vorlage: Das Problem ist tatsächlich: Wo soll sie hin? Standard-Benutzeroberfläche ist sowieso schon voll geballert mit Links und Funktionen; Bausteine stehen in manchen Artikeln in viel größerer Zahl, als man es im Vergleich zum eigentlichen Textumfang gutheißen kann. Da heißt es gut zielen und mit Augenmaß entscheiden, ob und wo eine Vorlage tatsächlich eingesetzt werden sollte. Ein Kriterium dafür wäre beispielsweise: Wem wäre damit gedient, welche Zielgruppe soll mit Hilfe der Vorlage erreicht werden? Für Blinde mit Screenreadern beispielweise ergibt sich kein Mehrwert, spontan fällt mir auch keine sinnvolle Verwendung durch eine andere auf Wikipedia:BIENE gelistete Zielgruppe ein. Eher noch wird die Artikelstruktur wie bereits erwähnt noch weiter zerrissen und dem "Otto-Normalo"-Benutzer, wie es auf der Seite so schön heißt, das Lesen und Bearbeiten erschwert.

Nur um es zu verdeutlichen: @Liberal Freemason: Ich finde deinen Vorstoß zum Bekanntmachen von Pediaphon löblich, aber vielleicht lässt sich ein anderer Weg in diese Richtung finden, mit dem genau denen das Leben erleichtert wird, die auf Dienste wie Pediaphon angewiesen sind. Grüße, --CyRoXX ^(? ±) 21:01, 7. Aug. 2007 (CEST)

Eigentlich dient der Potcast diesem Zweck. Dann muss das nur der Browser unterstützen. --Liberaler Freimaurer (Diskussion) 21:54, 7. Aug. 2007 (CEST)

Diplomarbeit "Methoden zur Verbesserung der Zugänglichkeit von Wikis"

Durch einen freundlichen Menschen wurde ich auf eine grade an der Uni Stuttgart fertiggestellte Diplomarbeit aufmerksam gemacht. Diese wird nach der noch ausstehenden, hoffentlich sehr guten Benotung auch öffentlich zugänglich sein. Der Verfasser hat seine Erkenntnisse in einem MoinMoinWiki umgesetzt, daß von jedem Interessierten heruntergeladen und installiert werden kann. . Bislang ist es aber leider noch nicht Online. Ich durfte die Arbeit trotzdem schon mal lesen und sie hat mir gut gefallen, da es darin um die gleichen Themen geht, die sich auch unser Projekt auf die Fahnen geschrieben hat. Dadurch bekommen wir bestimmt sehr interessante Infos & Lösungsideen. Eine Kurzbeschreibung findet sich hier: [3] -- Lalü 14:04, 14. Aug. 2007 (CEST)

Da bin ich gespannt und hoffe, dass wir möglichst viel rausziehen können. Lalü, welche wichtigen Erkenntnisse sind bei dir beim Lesen hängen geblieben? — Lecartia Δ 17:34, 14. Aug. 2007 (CEST)

Ich hoffe es findet sich jemand, der (ob nun anhand dieser Diplomarbeit oder nicht) die Seite WP:BF mit Richtlinien und Empfehlungen für Wiki-Autoren füllt. Denn aktuell weiß sicherlich ein sehr großer Teil der Wikipedia-Autoren nicht, wie man barrierefreie Artikel verfasst. ––Bender235 16:08, 25. Aug. 2007 (CEST)

Ist die Diplomarbeit mittlerweile öffentlich verfügbar? Grüße, --CyRoXX ^(? ±) 14:51, 26. Apr. 2008 (CEST)

Ob die Arbeit inzwischen öffentlich ist, weiß ich nicht. Aus meiner heutigen Sicht finde ich die Ergebnisse auch nicht mehr ganz so spannend, zumindestens was die Probleme blinder Menschen betrifft. Vielleicht mag Lecartia dazu auch etwas schreiben, ich hatte ihr die Dateien damals zugeschickt. Wenn es dich interessiert, könnte einer von uns dir das Ganze per Mail schicken oder ich gebe dir die Mail-Adresse des Verfassers. -- Lalü 07:32, 27. Apr. 2008 (CEST)

MB zu Einbindung von Flaggenicons in Ortsartikeln

Hallo, anscheinend gibt es zu der Einbindung von Flaggenicons in Ortsartikeln demnächst ein MB [4]. Gibt es hierzu aus Sicht des BIENE-Projektes zwingende Pro- oder Contra-Argumente, die bei diesem Meinungsbild berücksichtigt werden müssten? Gruß --Times 22:46, 19. Aug. 2007 (CEST)

Ich habe zwei Aspekte ergänzt bzw. ausformuliert. Ich hoffe, meine Erläuterungen sind nachvollziehbar. --TM 11:55, 20. Aug. 2007 (CEST)

Es gibt einen interessanten aktuellen Beitrag zu den Alt-Attributen, [5] der dort sehr kontrovers (aber leider auf Englisch) diskutiert wird. In einem halben Satz wird dabei auch auf Wikipedia eingegangen. -- Lalü 12:35, 28. Aug. 2007 (CEST)

Habs gelesen allerdings denke ich anders: Wenn sich die Leute schon die Mühe machen die Flagge zu verwenden statt nur dem Text, dann kann der Text ins ALT-Attrbute wandern. Dann kann man auch linken. Dann kann man auch lesen. Dann ist das Icon einfach zusätzlich und gut ist. Dürfte doch gehen, oder? --Mot2 19:48, 17. Sep. 2007 (CEST)

Sucht...

...ihr noch einen jüngeren „Otto-Normalo“-Halbexperten?--Τ ι λ λ α 2501 ^± 19:38, 9. Sep. 2007 (CEST)

derzeit ist eine Schüler-Umfrage in Arbeit, um dem Nutzerverhalten des "jungen Otto-Normalos" auf die Spur zu kommen. Wenn der Probelauf funktioniert, können wir das ausweiten, falls Interesse bei jungen „Multiplikatoren“ hier besteht. --elya 21:47, 9. Sep. 2007 (CEST)

Also derzeit nicht?--ΛΛΛΛΛΛΛ 21:54, 9. Sep. 2007 (CEST)

Rot/Grün-Sehschwächen-Verbesserungsvorschlag auf Mediazilla

Nach einer kleinen Diskussion auf /Farbenfehlsichtigkeit habe ich eine Bugmeldung phab:T13374 (Bugzilla:11374) auf MediaZilla eingestellt, damit bei Diff die Änderungen in Zukunft blau statt rot hervorgehoben werden. Ihr könntet mir dabei helfen, indem ihr euch da anmeldet und für die Umsetzung des Bugs votet. Damit bekäme das Projekt BIENE auch ausserhalb der de:Wikipedia Bedeutung :-) --Revolus Δ 23:15, 17. Sep. 2007 (CEST)

Gute Idee. Das Blasse Rot mit dem blassen Grün könnte eh mehr kontrast vertragen ;) --Mot2 06:13, 18. Sep. 2007 (CEST)

In diesem Zusammenhang ist noch Bug 7006: Colours in the mediawiki Allmessages page von Interesse. Otto Normalbenutzer kommt zwar in der Regel nicht mit Spezial:MediaWiki-Systemnachrichten in Berührung, aber es soll ja auch farbfehlsichtige Admins geben ;-) — Raymond ^{Disk. Bew.} 07:51, 18. Sep. 2007 (CEST)

Es wäre jedenfalls sehr unwahrscheinlich, dass es keine gibt ;-) Vielleicht kann man ja eine allgemeine Auflistung auf BIENE-bezogene Bugs an geeigneter Stelle erstellen? --Revolus Δ 05:26, 19. Sep. 2007 (CEST)

Artikel der gesprochenen Wikipedia

In meinen Augen stellen die von Menschen gesprochenen Artikel einen Mehrwert dar. Es wäre sinnvoll, wenn man sich als Benutzer einstellen könnte, daß der entsprechende Hinweis nicht wie jetzt am Ende der Seite sondern ganz oben erscheint. Das sit sicher über CSS kein großes Ding oder? --RalfR → BIENE braucht Hilfe 17:52, 19. Sep. 2007 (CEST)

Ich denke nicht, dass so etwas ein Problem wäre, weiß es aber nicht. Aber reicht nicht der Icon oben rechts? --BuecHerwuermLeIn DISK+/- 19:34, 19. Sep. 2007 (CEST)

Das habe ich übersehen - das sollte eigentlich ausreichen. --RalfR → BIENE braucht Hilfe 23:16, 19. Sep. 2007 (CEST)

Screenreader lesen (glaube ich) den Text in der Reihenfolge vor, wie die Daten im HTML-Quelltext erscheinen. CSS wird da wohl ignoriert, weil absolute Positionierungen für einen Nicht-Menschen schwer zu verstehen sind/wären. Es wäre deshalb wohl schon ganz praktisch, wenn der Hinweis dann am Anfang kommt. Der Hinweis wäre ja auch nicht störender als "Dieser Artikel", wenn man die Information nicht braucht überliest man es einfach. --Revolus Δ 01:13, 20. Sep. 2007 (CEST)

Ich meine eine CSS-Klasse, die nur der Braille gezeigt wird, die Sehende nicht angezeigt bekommen... also sowas wie <link rel="stylesheet" type="text/css" href="css/braille.css" media="braille, embossed"> in Verbindung mit #oben {display: none;} und <div class="oben"><a href="...">hier gehts zum gesprochenen Artikel</a> --RalfR → BIENE braucht Hilfe 09:58, 20. Sep. 2007 (CEST)

Ich glaube, es würde niemanden stören, wenn der Hinweis generell oben stehen würde. Aber auch wenn nicht, würde ich sagen, dass die Information nicht nur bei der Braillezeile interessant wäre, sondern auch für Screenreader (aural) und Textbrowser (tty).

#oben { display:hidden; }
@media aural, braille, embossed, tty { #oben { display:block; } }

wäre eine Möglichkeit für die common.css. Eine Einbindung über <link/> würde gleich eine Software-Änderung benötigen. --Revolus Δ 10:16, 20. Sep. 2007 (CEST)

Ich denke auch, daß es oben für alle sinnvoll wäre, aber wer weiß? Warum ist link problematisch? --RalfR → BIENE braucht Hilfe 10:23, 20. Sep. 2007 (CEST)

Naja, Änderungen an der common.css kann jeder "einfache" Admin durchführen, aber du kannst kein <link/> in den Quelltext packen. Mir fiele nur Javascript ein, aber das wäre unnötig in dem Fall. --Revolus Δ 10:29, 20. Sep. 2007 (CEST)

Entweder tricksen (link) oder Raymond fragen? --RalfR → BIENE braucht Hilfe 11:04, 20. Sep. 2007 (CEST)

PS: nicht mal nowiki reicht, guck mal in den Quelltext ;) --RalfR → BIENE braucht Hilfe 11:06, 20. Sep. 2007 (CEST)

Hehe, würde mir auch nicht wirklich gefallen, wenn man so html-Tag einbinden könnte. Gesprochene Wikipedia ist ja ein de:Projekt, ich glaube nicht, dass man dafür Raymond fragene muss (wobei ich schätze, dass er die Seite eh auf seiner Beobachtungsliste hat). --Revolus Δ 11:12, 20. Sep. 2007 (CEST)

Ja, habe ich ;-) Wobei es nicht möglich ist, über <link rel="stylesheet" type="text/css" … ein neues Stylesheet einzubinden. Das müsste im MediaWiki-Core geschehen. Eine Ergänzung des Commons.css kann, wie bereits gesagt, wurde, jeder lokale Admin vornehmen. — Raymond ^{Disk. Bew.} 12:11, 20. Sep. 2007 (CEST)

Ich würde sagen, man könnte eine Vorlage à la Vorlage:Gesprochene Version (Hinweis) mit dem Inhalt erstellen:

{| border="0" cellspacing="3" cellpadding="3" style="margin-left:auto; margin-right:auto; border:solid 1px #CCCC99; margin:0.5em; padding:0.2em; color:inherit; background-color:#F8F8F8;" class="tty-metadata"
 | Dieser Artikel kann als [[#Gesprochene Version|gesprochene Version]] angehört werden.
|}

Die CSS-Informationen müssen nicht, schaden aber auch nicht. Es sind die gleichen wie bei Vorlage:Gesprochene Version. Ich halte class="tty-metadata" für einen ganz guten Namen. tty ist wohl der kleinste gemeinsame Nenner zwischen aural, Braille-Zeile, Embossed-Drucker und eben Textmodus. Bei metadata wissen die meisten dann, dass es für sie unwichtig ist und mit einem allgemeinen Namen kann die Klasse für mehrere solcher Zwecke verwendet werden. MediaWiki:Common.css müsste dann um die Zeilen:

.tty-metadata {
	display:none;
	}
@media aural, braille, embossed, tty {
	.tty-metadata {
		display:block;
		}
	}

display:hidden, was ich oben schrieb, ist natürlich Unsinn. Für das Einfügen der Vorlage würde sich sicher auch ein Bot finden lassen. Gruß, --Revolus Echo der Stille 15:23, 24. Sep. 2007 (CEST)

Bild am Anfang eines Artikels

Gerade stelle ich fest, dass ein Benutzer hier ein Bild vom Anfang des Artikels etwas nach hinten verschoben hat und den Kommentar "Benutzer von Bildschirmlesegeräten bedanken sich, wenn ein Artikel mit Text beginnt und nicht mit einem Bild" eingefügt hat. Sämtliche Artikel zu ändern, bei denen entweder ein Bild oder eine Tabelle am Anfang steht, dürfte das Problem zwar lösen, ist aber kaum umsetzbar. Kann man Nutzern von Bildschirmlesegeräten Tipps geben, wie sie Artikel gut lesen können, auch wenn ein Bild am Anfang ist? Grüße, --Birger 02:25, 1. Okt. 2007 (CEST)

TM hat ein Skript geschrieben, dass das Verschieben von Bildern, Taxoboxen, etc. hinter den ersten Absatz übernimmt. MediaWiki:Gadget-Screenreader-Optimierung-TOC.js Ich habe es nicht getestet. --Revolus Echo der Stille 06:47, 1. Okt. 2007 (CEST)

Einstieg für behinderte Benutzer

Als nicht betroffener Benutzer fiel mir nach meinem vorhergehenden Beitrag oben auf: Wie würde ein behinderter Benutzer eigentlich Tipps für eine bessere Nutzbarkeit der Wikipedia auffinden? Von der Startseite bis Wikipedia:BIENE ist es recht weit. Wäre ein Link von der Hauptseite, beispielsweise mit der Bezeichnung "Barrierefreiheit", zu einer geeigneten Hilfeseite wünschenswert? (Doch welche Hilfeseite wäre das?) Grüße, --Birger 02:34, 1. Okt. 2007 (CEST)

Eine sehr vernünftige Idee. Nur ist es dafür viel zu früh, das sollte das Ziel am Ende sein. Darauf sollten wir hinarbeiten. Wie die Seite dann heißen mag, ist egal. --RalfR → BIENE braucht Hilfe 10:55, 1. Okt. 2007 (CEST)

Unsichtbare Null

Ich greife in Tabellen hin und wieder auf die {{0}} als Formathilfe zurück. Wie ist die Vorlage aus BIENE-Sicht zu bewerten? Wird sie beispielsweise vorgelesen oder wird sie ignoriert? --32X 23:32, 18. Okt. 2007 (CEST)

Oh nein, nicht doch. Ich halte so etwas für groben Unfug. Zur tabellarischen Darstellung von Zahlen gibt es Tabellen und dort zur Ausrichtung die Angabe style="text-align: right;" oder wer es kürzer mag align="right". Tabellen sind für Screenreader-Benutzer ähnlich gut zu erfassen wie für Sehende und ich sehe keinen Grund, warum man eine Tabelle nicht als Tabelle schreiben sollte. Die Vorlage sorgt im schlimmsten Fall dafür, dass die „unsichtbaren Nullen“ mit vorgelesen werden. Das ist zwar keine Katastrophe, aber doch irritierend. Außerdem ist der Artikelquelltext schwerer zu bearbeiten. --TM 22:29, 29. Nov. 2007 (CET)

Projekt noch aktiv?

Nur mal so eine generelle Frage: Ist das Projekt jetzt schon vor dem richtigen Aufkeimen gestorben? --Revolus Echo der Stille 16:41, 2. Nov. 2007 (CET)

Huhu, ich bin noch hier, wenn auch nicht der Initiator. --BuecHerwuermLeIn DISK+/- 16:47, 2. Nov. 2007 (CET)

Dochdoch, ich bin auch noch da ;) Ein Problem besteht darin, daß (zumindest ich) noch keinerlei Reaktion von der Stiftung Mensch habe. --RalfR → BIENE braucht Hilfe 19:22, 2. Nov. 2007 (CET)

Ein weiteres könnte sein, dass kein konkreter "Schlachtplan" vorliegt. --BuecHerwuermLeIn DISK+/- 19:26, 2. Nov. 2007 (CET)

Da hast du wahrscheinlich vollkommen Recht. Ich denk mir mal was aus. --RalfR → BIENE braucht Hilfe 20:50, 2. Nov. 2007 (CET)

Hallo Revolus, das ist wie mit Silvester und den guten Vorsätzen ... :-(
Da das Thema der barrierearmen Zugänglichkeit von Wikipedia bzw. Wikis aber immer aktuell bleiben wird, hat dieses Projekt zumindestens eine Startplattform für erneute Versuche geschaffen. Ich möchte mich daher noch einmal bei dir und TM für eure vorbildlichen Aktivitäten bedanken, die gut aufzeigen, wie man eventuell vorgehen könnte.

Hallo Ralf. Meinst du die Stiftung Digitale Chancen oder die Aktion Mensch? Was erwartest du dir von dort? Ich hatte zwar auch gehofft, daß man dort auf die Idee kommen könnte, das Wikipedia BIENE-Projekt bei der Umsetzung der für Wikis sinnvollen Kriterien von Biene/BITV/WCAG zu unterstützen, um so einmal öffentlich & transparent vorzumachen, wie man das Thema "Barriereabbau" konkret angehen könnte. Eventuell fehlen dort aber einfach nur die Ressourcen dafür. Auch wäre die aktive Projekt-Teilnahme von selbst zur Zielgruppe gehörigen Betroffenen bzw. von deren Fürsprechern wünschenswert. Vielleicht finden sich ja auch irgendwann Studenten, die sich eine Mitarbeit als Teil ihres Studiums anrechnen lassen können und von ihren Professoren/Dozenten darin bestärkt und unterstützt werden. Was ist übrigens aus der angedachten Zusammenarbeit mit dem Verein Wikimedia geworden?

Da ich anscheinend der einzige blinde Benutzer bei de.WP bin, der sich für eine bessere Usability interessiert und andere ebenfalls blinde Menschen trotz mehrerer öffentlicher Aufrufe von mir in den entsprechenden Foren nichts dazu beitragen wollen oder können, bin ich inzwischen auch etwas demotiviert und beschäftige mich daher lieber mit anderen Dingen. Irgendwann in nicht allzu ferner Zukunft wird es sicherlich einen erneuten Anlauf geben.
Braucht dieses Projekt eigentlich offizielle Koordinatoren? Wer ein wenig querliest, wird bestimmt auch herausfinden, wer sich hier für was zuständig fühlen könnte ... Außerdem sollte vielleicht vorsichtiger mit der Keule der Barrierefreiheit gewunken werden, da dies bestimmt einige von einer unvoreingenommenen & konstruktiven Beschäftigung mit dem Themenkomplex abhält. Dazu gibt es auch eine schöne Glosse in einem Blog von jemanden aus der "hauptberuflichen Expertenszene". -- Lalü 11:17, 3. Nov. 2007 (CET) Einrückung geändert --Revolus Echo der Stille 00:23, 4. Nov. 2007 (CET)

Bürcherwürmlein hat schon Recht, uns fehlt ein konkreter "Schlachplan". Bloß wie der aussehen sollte, weiß ich leider auch nicht. Hin und wieder mal eine Infobox, einen Artikel oder dergleichen anzugehen und den WP:BIENE in die Summary zu schreiben kann jedenfalls nicht alles sein. Schade finde ich auch, dass das inernationale Engagement zu dem Thema so gering zu sein scheint, wobei ich aber nicht weiß, ob es denn Projekte auf meta: gibt. Leider finden die beiden Bugreports, die ich eingebracht habe, auch keine Beachtung (phab:T13374 (Bugzilla:11374) Diff für Leute mit Rot/Grün-Schwäche, phab:T13555 (Bugzilla:11555) Bearbeitenlinks hinter den Überschriften), wobei ich von dem generellen Prozess Bugreport/Feature-Request bis Änderung auch keine Ahnung habe. Nach meinen subjektiven Beobachtungen gehen die Auswirkungen des Web 2.0 wieder zurück und die Errungenschaften (Mikroformate, XHTML, u.ä.) treten immer weiter in den Hintergrund, eine schnelle "Homepage" (wenn man es denn so nennen will) à la Myspace ist wichtiger, als dass man sie mit einem anderen Browser denn dem IE 7 anschauen kann. Die Wikipedia hat die Macht die gasamte Netzstruktur zu verändern, aber dafür müssten alle Sprachwikis zusammenarbeiten. Viva la revolution ;-) --Revolus Echo der Stille 00:23, 4. Nov. 2007 (CET)

Ich muß mal wieder Asche auf mein Haupt schütten, an mir ist auch einiges hängengeblieben in letzter Zeit. Sorry dafür, Job und so weiter. Ich hatte mit den Biene-Leuten freundlichen Kontakt, wie einige von Euch wissen, allerdings nützt uns das eher mittel- bis langfristig etwas, jedenfalls gibt es von dort keine konkrete Analyse, wie man Wikipedia barriereärmer machen könnte (schade ,-)). Den Gedanken, eine eigene Skin für z.B. blinde Benutzer zu schaffen (den ich mal hatte), zweifele ich aus verschiedenen Gründen inzwischen wieder an: 1) widerspricht es eigentlich der Barrierefreiheit, "Extraumgebungen" zu schaffen, die Hauptumgebung sollte eigentlich schon nutzbar sein. 2) bin ich inzwischen auch selbst einmal in die Mediawiki-Software eingestiegen, insbesondere in die monobook-Skin. Das hat mir den Gedanken auch ziemlich... naja, sagen wir mal verleidet.

Andere Punkte, die ich für vielversprechender halte: die Idee, die „BIENE-betreffenden" Bugs aus Bugzilla hier aufzulisten und zu bewerten (priorisieren, Ansprechpartner zu nennen, ggf. gesammelt dafür abzustimmen um etwas voranzutreiben usw.), und den Kontakt zu den anderssprachigen Projekten sowie zu den Entwicklern zu halten. Von der Chapter-Koordinatorin der Foundation kam - als ich das Thema bei unserer letzten Vorstandstagung ansprach - auch der Hinweis, daß Brion, der Hauptentwickler, Ideen zur Barrierefreiheit sehr offen gegenübersteht, es muß halt nur was konkretes kommen. Eine kommentierte Bugliste hier bei uns (ggf. abgeglichen mit anderen Projekten) fände ich eine sinnvolle Maßnahme, sie ist realistisch umsetzbar und gut von allen Projektteilnehmern zu bearbeiten. Ich habe selbst wieder einmal gemerkt, daß man sich viel großes vornehmen kann, es aber immer besser ist, kleine Schritte zu machen, um sich nicht zu verzetteln. Und ich kenne auch jemanden, der mit diesem komischen Bugzilla besser klarkommt als ich ;-)

Soviel heute von mir dazu – Grüße, --elya 11:11, 4. Nov. 2007 (CET)

kognitive Behinderungen

Hallo,

was soll man gegen kognitive Behinderungen tun? Ich sehe da eigentlich nur die einzige Möglichkeit, ein eigenes Wiki – ähnlich dem simple-english-Wiki – zu eröffnen. Oder soll man Artikel mit Unterseiten wie Fahrrad/simpel (oder wie auch immer) anlegen? Hat sich da schon jemand Gedanken drüber gemacht, ob in der Wikipedia überhaupt eine Barrierefreiheit für Menschen mit kognitiver Behinderung geben kann? Gruß -- Yellowcard 18:37, 12. Nov. 2007 (CET)

Für Texte in einfacher Sprache gibt es leider keine einfache Lösung, denn irgend jemand muss sie ja schreiben. Für ein eigenes Wikipedia-Projekt in einfachem Deutsch gäbe es vermutlich nicht genügend Mitarbeiter. Aber was es hier in der „normalen“ Wikipedia gibt ist der soganannte „Oma-Test“. Das bedeutet vereinfacht, dass der erste Absatz jedes Artikels für jeden Laien verständlich sein muss. Ich denke, mit diesem Anspruch ist deutlich mehr gewonnen als mit dem Verdoppeln der Artikelanzahl. --TM 22:45, 29. Nov. 2007 (CET)

Auf einer Homepage habe ich es so gelöst, daß eine Einleitung ganz bewußt OMA-tauglich gehalten wurde. Wenn es dann ams Eingemachte geht, kann man das nicht mehr durchhalten. --RalfR → BIENE braucht Hilfe 03:50, 10. Jan. 2008 (CET)

Braucht ihr Benutzer mit ADS?

Ich habe diese Seite nur zufällig gefunden, weil RalfR in seiner Signatur Werbung für Biene machte. Bei mir wurde ADS diagnostiziert. Ich bin zwar nicht wirklich behindert. Ich studiere... aber: es fällt mir manchmal schwer sehr lange Sätze mit sehr viele Nebensätzen zu lesen und ich habe Probleme damit, wenn es in einem Artikel kaum Absätze gibt, wenn er sehr theoretisch ist, wenn es keine Beispiele gibt. Keine Ahnung, ob ich euch behilflich sein kann... aber wenn ihr es wollt würde ich gerne Artikel für euch auf ADS-Tauglichkeit prüfen. Beste Grüße--Cumtempore 21:34, 8. Dez. 2007 (CET)

Ja, das brauchen wir auf jeden Fall! Insbesondere würde mich interessieren, wie du mit langen Artikeln klarkommst. Fast alle exzellenten Artikel sind sehr lang. Sind für dich Listen, Tabellen usw. besser als Fließtext? Helfen dir z.B. die kleinen Flaggenbildchen in Sportartikeln? Helfen Bebilderungen oder lenken sie eher ab, weil die Bilder ja auch beschriftet sind? Kannst du dir mal was aus Wikipedia:Exzellente_Artikel herauspicken, was dich interessiert und uns das Ergebnis mitteilen? --RalfR → BIENE braucht Hilfe 03:48, 10. Jan. 2008 (CET)

Lange Artikel finde ich okay, wenn sie viele einzelne Überschriften und Unterüberschriften haben, weil das für mich mehr Struktur gibt. Ich persönlich mache es auch so, dass ich wenn ich schreibe immer Gedankenpausen im Text mache.

So:

Text text text text. Text text text text. Text text text text. Text text text text. Text text text text. Text text text text. Text text text text. Text text text text. Text text text text. Text text text text. Text text text text. Text text text text.

Text text text text. Text text text text. Text text text text. Text text text text. Text text text text. Text text text text.

Text text text text. Text text text text. Text text text text. Text text text text. Text text text text. Text text text text. Text text text text. Text text text text. Text text text text. Text text text text. Text text text text. Text text text text.Text text text text. Text text text text. Text text text text. Text text text text. Text text text text. Text text text text.

Das heisst: Ich mache häufig nach ein bis zwei Sätzen eine gedanklichen Abschnitt und lasse ein paar Zeilen frei. Das wird dann meisten von anderen Benujtzern wieder geän dert. Deswegen habe ich es mir abgewöhnt.

Für mich sind Listen und Tabellen besser als Fliesstext und ich mag Abbildungen. Persönlich ist es für mich kompliziert, wenn ein Satz sehr lang mikt vielen Nebensätzen ist. Ich schreibe zwar zum Teil selbst so, aber fremderleuts Sätze verstehe ich oft direkt, wenn sie zu kompliziert sind. Ich muss sie dann mehrmals lesen.

Für mich persönlich sind viele Beispiele wichtig.

Ich kann mir gerne mal einen excellenten Artikel ansehen. Nur habe ich heute nicht so viel Zeit, aber demnächst. :)--Cumtempore 15:20, 10. Jan. 2008 (CET)

2 Jahre spaeter... was solls :) Ich glaube, lange Saetze mit vielen Nebensaetzen sind fuer _alle_ schwerer zu lesen. Das ist zu vermeiden ist einfach eine Sache des Stils. 'Exzellente' Artikel sollen "stilistisch ueberdurchschnittlich" sein - und das heisst fuer mich auch mit moeglichst kurzen und wenig verschachteten Saetzen zu arbeiten. Insofern denke ich, dass die momentanen Regeln das bereits vorschreiben Iridos 20:37, 19. Mai 2010 (CEST)

Wikilkint ist ein Tool, das automatisiert lange Sätze findet. Weiterhin sollte man grundsätzlich überlegen, ob man Sätze mit Klammern, indirekter Rede und mehreren Kommata nicht einfacher formulieren kann. Vereinfachter Satzbau hilft sehr verschiedenen eingeschränkten Benutzern: sowohl Visuell eingeschränkten, wie auch Benutzern mit verminderten kognitiven Fähigkeiten, Älteren, Kindern, Personen, die Deutsch nicht als Muttersprache kennen und Personen mit geringem Bildungsstand oder niedrigem IQ. In manchen Fällen sind kompliziertze Sätze auch ein Zeichen davon, dass der Autor sein Thema nicht richtig im Griff hat und deswegen langatmig herumschwafelt. Ähnliches gilt für Artikel mit vielen Hierarchieebenen. Eine komplizierte Gliederung erschwert das Verständnis.--Giftzwerg 88 (Diskussion) 22:26, 23. Jul. 2014 (CEST)

Zur Kenntnisnahme

[6]

und danke für die weitere sperrdrohung. -- schwarze feder 01:38, 10. Jan. 2008 (CET)

Inhaltlich gebe ich dir vollkommen Recht, das ist auch der Grund, warum du nicht gesperrt bist. Ein Edit-War geht aber nicht - auch wenn man "Recht" hat. Noch Linktips für die Disk: http://www.biene-award.de und http://www.aktion-mensch.de --RalfR → BIENE braucht Hilfe 01:42, 10. Jan. 2008 (CET)

Umfrage von Aktion Mensch

Die Aktion Mensch sucht Internet-Nutzer für eine Umfrage. Dort geht es auch um die Nutzung von Wikipedia bzw. von Wikis. Es wäre gut, wenn sich möglichst viele von euch daran beteiligen könnten. Wie sonst leider auch üblich, gibt es keinen Zurück-Knopf, guckt euch die Fragen also genau an, bevor ihr auf Weiter klickt. -- Lalü 12:24, 22. Jan. 2008 (CET)

Hinweis: Ich habe diese Meldung auf die Biene-Hauptseite unter Aktuelles gestellt. — Lecartia Δ 12:41, 22. Jan. 2008 (CET)

Aber es gibt den Zurück-Knopf im Browser. Wenigstens funktioniert der bei mir im Firefox. --Sebastian Mehlmacher 15:46, 23. Jan. 2008 (CET)

Nicht-Behinderte sind von der Umfrage leider völlig ausgeschlossen. --TM 17:14, 23. Jan. 2008 (CET)

Warum sind sie ausgeschlossen, TMg? Es wird doch extra gefragt, ob man selbst „Betroffener“ ist. Sogar in Gebärdensprache wird die Umfrage unterstützt. Wie sinnvoll das ist – Können Gehörlose nicht lesen? –, sei einmal dahingestellt. Ach, du schriebst, Nicht-Behinderte sind ausgeschlossen. Ich muss lesen lernen. — Lecartia Δ 17:30, 23. Jan. 2008 (CET)

Ich bin davon ausgegangen, daß der jeweilige Abschnitt der Umfrage nach dem weiterklicken bereits abgespeichert wurde und nicht erneut übermittelt werden kann. Ich habs also garnicht erst ausprobiert, da es keine ausdrückliche Möglichkeit zu geben schien. Das nächste Mal bin ich mutiger. ;-) -- Lalü 18:09, 23. Jan. 2008 (CET)

Die Umfrage ist übrigens beendet --Marcel1984 ^{(?! | ±)} 23:29, 9. Feb. 2008 (CET)

Stand, Ziel und Chancen

Bezug nehmend auf die Fragen – Wo stehen wir bisher in der Wikipedia was Barrierefreiheit und Nutzerfreundlichkeit angeht? Was sind unsere ambitionierten Ziele und warum konnten wir viele davon noch nicht erreichen? Was können wir realistisch gesehen tun? – meine etwas ernüchterten Überlegungen dazu.

Barrierefreiheit in kollaborativen Umgebungen, wie es Wikipedia ist, stellt technische und inhaltliche Herausforderungen. Auf der technischen Seite stehen Entwickler, die den Lesern möglichst komfortable und barrierefreie Varianten der Benutzeroberfläche (Skins) zur Verfügung stellen müssen. Dabei wird es keine Variante geben, die den Ansprüchen aller genügt, daher müssen mehrere Skins erstellt werden. Wird der Leser zum Autor, so müssen die Bearbeitungswerkzeuge ebenso barrierefrei sein. Die vorgegebene Syntax zum Erstellen von Artikeln kann dabei möglicherweise mit den Hilfsmittel interferieren. Auf der inhaltlichen Seite sind die Autoren gefragt. Sie müssen sich beim Schreiben an eine Reihe von formalen Vorgaben halten (bspw. Auszeichnung von fremdsprachigen Wörtern) und den inhaltlichen Ansprüchen eines Textes wie seiner Verständlichkeit (Stichwort Oma-Test) genügen.

Diese Anforderungen sind in einer abgesteckten Zielgruppe klar erreichbar: Entwickler und Autoren werden auf die Erfordernisse geschult, sie bringen danach ihr Wissen idealerweise wie gewünscht ein. Ein kollaboratives Projekt, das rein auf Freiwilligkeit beruht, kann diese Ziele nicht derart einfach erreichen. Lassen sich die wenigen Entwickler noch mit Aufwand koordinieren und für Barrierefreiheit sensibilisieren, können die unzähligen Autoren schwer erfasst werden. Automatismen sind lange noch nicht so weit, dass bspw. Auszeichnungen von fremdsprachigen Wörtern automatisch gesetzt werden können. Für die Verständlichkeit eines Textes werden immer Menschen als Kritiker benötigt. Wie kann also diese fluktuierende Masse an Mitgestaltern angesprochen und diese breite Masse geschult werden? Wie viel muss von den Autoren kommen, wie viel lässt sich automatisieren? Wie können Mentoren gewonnen werden, die sich um Neulinge, mit oder ohne Behinderung, kümmern?

Einige dieser Probleme versucht die deutsche Wikipedia in Ansätzen zu lösen. Was jedoch fehlt, ist meiner Meinung nach ein übergreifendes stringentes Konzept. Es ist fraglich, ob ein solches in einer offenen und kollaborativen Umgebung erreicht und die Langzeitmotivation für ein solches Unternehmen gehalten werden kann. — Lecartia Δ 15:21, 26. Mär. 2008 (CET)

Das spricht mir aus dem Herzen. Lecartia hat das formuliert, was mir seit Monaten im Kopf herumgeistert, was ich nicht formulieren konnte. Ich habe noch viele Ideen, man kämpft aber teilweise gegen Windmühlenflügel. Sollten wir das Projektziel anders definieren? Das erreichen, was uns paar Hanseln möglich ist? Selbst wenn nur eine einzige Barriere abgebaut wird, war das Ganze ein Erfolg. --RalfR → BIENE braucht Hilfe 15:47, 26. Mär. 2008 (CET)

Der Fokus auf ein konkretes Teilziel ist wahrscheinlich unsere einzige Chance, denn die vielen guten Ansätze einzelner kommen kaum zu einem Abschluss. Woran liegt das? Abgesehen von den üblichen Faktoren wie mangelnder Zeit und irgendwann auch mangelnder Lust der Initiatoren. :-) Fehlende Unterstützung? Ablehnung durch viele? Erschlagendes Themengebiet? Der Fokus auf ein Thema erfordert jedoch die Frage: Was muss am dringendsten behoben werden?

Ralf, ich möchte deine Vorschläge gerne hören, vielleicht schreibst du sie hier auf und wir diskutieren einiges davon auf der Biene-Fachtagung. Kommst du dort als Gast mit hin? — Lecartia Δ 16:12, 26. Mär. 2008 (CET)

Die eckigen Klammern um "bearbeiten" sind absolut unnötig und sollten ersatzlos gestrichen werden. Für Benutzer mit Screenreader ist das eine Zumutung. Bilder unter 50px sollten irgendwie abschaltbar gemacht werden, dann ist die ewige Klickibunti-Disk. vom Tisch. Ich halte Piktogramme für Lerngeschädigte durchaus für einen großen Gewinn. So könnten auf Wunsch des Benutzers immer wiederkehrende Punkte wie Weblinks, Quellen usw. durchaus ein Piktogramm vertragen. Diese beiden Sachen sollten softwaretechnisch sehr einfach realisierbar sein. In der Art könnten wir eine Art Pflichtenheft aufstellen, wo sich dann auch jemand einträgt, der das umsetzt. Gelsenkirchen kann ich mir nicht leisten...--RalfR → BIENE braucht Hilfe 16:29, 26. Mär. 2008 (CET)

Ich denke, daß Softwareweiterentwicklungen besser auf einer Metaebene bzw. mit Koordination aller Projekte voranzutreiben wären. Bei Brion würden wir wohl "offene Türen" einrennen, habe ich mir sagen lassen. Meine Idee (eine von vielen, die mal wieder an mangelnder Zeit scheitern) war es, alle betroffenen Bugs aus dem Bugtracker einmal zusammenzustellen und zu bewerten.

Was lecartias Stichwort "mehrere Skins" angeht, war das ja zunächst auch mein Gedankenansatz, aber das wäre wirklich ein sehr dickes Brett: Entwicklung, Wartung, Weiterentwicklung etc. MIt kleinen Schritten bewegen wir möglicherweise mehr.

Ich verspreche mir im übrigen von dem 2. Experten in der Workshop-Runde auf der Tagung, M. Jendryschik, einige Anregungen. Grüße, --elya 22:35, 26. Mär. 2008 (CET)

Wikipedia ist nicht nur eine kollaborative Umgebung, sondern auch ein Freiwilligenprojekt mit geringen finanziellen Ressourcen. Die Erfahrung zeigt, daß es nahezu unmöglich ist, komplexere technische Entwicklungsarbeiten für ein Nischenthema wie Barrierefreiheit zu realisieren. Potentielle Mitarbeiter sind auf der rein freiwilligen Ebene schwer zu motivieren und sehen ihre Mitwirkung logischerweise eher als unverbindlich an. Mein Vorschlag ist daher die weltweite Suche nach Sponsoren, um die Arbeit an Skins/Erweiterungen/Anpassungen durch bezahlte Profis erledigen zu lassen. Beispiele für eine Unterstützung bekannter Open Source Projekte, die der Allgemeinheit kostenlos zur Verfügung stehen, gibt es glücklicherweise bereits. Organisationen wie die Mozilla Foundation, die Gnome Foundation aber auch Firmen wie Sun Microsystems, IBM und Google engagieren sich bereits durch finanzielle Zuwendungen oder die Bereitstellung anderer Ressourcen für die Accessibility und Entwicklung von freien Softwareprojekten. Warum sollte es nicht möglich sein, für eine non-profit Software wie MediaWiki und damit auch für die weltweit bekannte und hoch angesehene Wikipedia Hilfe zum Barriereabbau und zur Verbesserung der Usability für eingeschränkte Nutzer zu bekommen?

Ich sehe hier nicht die vielen freiwilligen Wikipedianer aus der ganzen Welt in der Pflicht, sondern eher politische und gesellschaftliche Organisationen und deren Entscheidungsträger. Stiftungen, Philanthropen, Sponsoren aus der Wirtschaft und vor allem reiche Behindertenhilfe-Organisationen wie beispielsweise die Aktion Mensch oder die spanische Blindenselbsthilfeorganisation ONCE könnten ihren selbst gesteckten Zielen mit einer Unterstützung des vorgeschlagenen Projekts gerecht werden. Bei meinen Streifzügen im Netz bin ich auf viele finanziell & personell gut versorgte Projekte gestoßen, die sich anscheinend für benachteiligte Nutzergruppen des Internets engagieren wollen. Ein einziger bezahlter professioneller MediaWiki-Programmierer könnte in einigen Monaten wahre Wunder bei der Verbesserung der Zugänglichkeit und Benutzerfreundlichkeit von Wiki-Plattformen bewirken.

Seit kurzem gibt es bei Wikia übrigens auch ein Blind Wiki, dessen Benutzeroberfläche sich individuell konfigurieren lässt. Meine Kenntnisse reichen dazu aber nicht aus, so daß ich nun versuchen muß, geeignete Hilfe und Unterstützung zu bekommen. Sollte es gelingen, ausreichend starke Partner zu gewinnen, könnten die Ergebnisse & Erkenntnisse auch für blindengerechte MediaWiki-Erweiterungen oder einen eigenen Skin für Screenreader-Nutzer genutzt werden. Eine Unterstützung durch die WikiMedia Foundation oder den deutschen Verein WikiMedia wäre wünschenswert, da man als Einzelperson von potentiellen Förderern leider nicht Ernst genommen werden kann.

Ich wäre auch gerne auf die EFA-Fachtagung gekommen, aber als Privatperson fehlen mir die finanziellen Mittel dafür. Außerdem scheinen die Veranstalter sowieso nicht an meinen Aktivitäten interessiert zu sein. Sollte ich mich für die Online-Beteiligungsmöglichkeiten registrieren können, werde ich mich aber wahrscheinlich über das Veranstaltungsblog einbringen. -- Lalü 12:05, 3. Apr. 2008 (CEST)

Wettbewerb "Wege ins Netz"

Ich möchte mich gerne mit diesem Projektvorschlag bei "Wege ins Netz" bewerben. Wie wäre es, wenn ich das nicht als Einzelperson machen muß, sondern Wikimedia e.V. Deutschland sich dort offiziell bewirbt? Die in Frage kommenden Kategorien sind Bildung und Gesellschaft. Der erste Preis wären 5000 Euro. Es wäre aber schön, wenn der Verein sich nicht einfach im Alleingang anmeldet, sondern mich ebenfalls mit einbezieht. Sollte allerdings kein Interesse bestehen, würde ich es auch alleine versuchen. Eventuell möchte ich auch noch einen anderen meiner Träume dort einreichen, auch wenn ich als Privatperson, die lediglich Vorschläge und Lösungsideen anzubieten hat, wohl kaum eine Chance hätte. -- Lalü 17:18, 25. Apr. 2008 (CEST)

Lieber Lalü, da Elya unsere „Schnittstelle“ zwischen privater Initiative und dem Verein ist, ich werde sie daher auf deinen hervorragenden Vorschlag hinweisen. — Lecartia Δ 15:03, 27. Apr. 2008 (CEST)

Bei Netzpolitik.org gefunden und vielleicht auch interessant, eventuell sogar für die gesamte Wikipedia: EU-Parlament will Community-Medien fördern. -- Lalü 19:30, 6. Mai 2008 (CEST)

Vorlage:Nachbargemeinden

Hallo liebe Bienianer, was ist von der Vorlage:Nachbargemeinden unter dem Aspekt der Barrierefreiheit zu halten? Diese Vorlage wird in einer ganzen Reihe von Gemeindeartikeln verwendet, siehe beispielsweise Rosenheim. Gehe ich richtig in der Annahme, dass diese Vorlage für Benutzer mit Screenreader oder Braillezeile nicht sinnvoll nutzbar ist? Da die damit präsentierten Informationen ohne Nachteil auch im Fließtext dargestellt werden können, wäre fehlende Barrierefreiheit aus meiner Sicht ein starkes Argument gegen die Verwendung dieser Vorlage. -- Uwe 21:55, 30. Apr. 2008 (CEST)

Nunja, für Screanreader nicht optimal, aber lesbar, für Lerngeschädigte sehr hilfreich. Wie immer beim Thema Barrierefreiheit gibt es keine eindeutige Antwort. Ich sehe das Problem eher darin, daß eine Nachbargemeinde niemals genau Nord oder Ost ist. Von daher ist also die Darstellung immer falsch, allerdings auch im Fließtext. Für Benutzer von Screenreadern ist der Inhalt schneller erfaßbar als Fließtext, wenn auch etwas ungewöhnlich. Beim 2.-3. Mal wird klar, was gemeint ist. Taubstumme verstehen die Seerose besser als Fließtext, Sehschwache ebenfalls. Menschen mit kognitiven Behinderungen haben allerdings so ihre Schwierigkeiten. --RalfR → BIENE braucht Hilfe 22:05, 30. Apr. 2008 (CEST)

Ich hatte vermutet, dass ein Screenreader die Grafik nicht korrekt erfasst und deshalb nur die Textinformationen zeilenweise vorliest, was ja auf die reine Aufzählung von Ortsnamen hinauslaufen würde. Und dies möglicherweise in der Reihefolge Norden, Westen, Osten, Süden (Zeilen von oben nach unten, in den Zeilen von links nach rechts), was eher verwirrend sein dürfte. Und für Braille-Zeilen hatte ich ebenfalls vermutet, dass diese Vorlage zu massiven Lese- bzw. Verständnisproblemen führt. Wie würde es da aussehen? -- Uwe 22:13, 30. Apr. 2008 (CEST)

Wenn es ohne Grafik entscheidend besser wäre helfen vielleicht die hier Vorlage_Diskussion:Nachbargemeinden#Nachbarorte_-_Alternative.21.3F.21 vorgeschlagenen Kompromisslösungen. --Ilion 22:32, 30. Apr. 2008 (CEST)

Frage an Ralf oder die anderen Bienianer: Angenommen, die Vorlage wird für den Ort Seerosendorf verwendet, der folgende Nachbargemeinden hat: Nordstadt, Osthausen, Südwald und Westburg. Die Fliesstextformulierung wäre also:

Die Nachbargemeinden von Seerosendorf sind Nordstadt im Norden, Osthausen im Osten, Südwald im Süden und Westburg im Westen.

Was genau würde ein Screenreader im Vergleich dazu aus der derzeitigen Fassung der Vorlage sowie die beiden Alternativvorschläge machen, also was würde er konkret vorlesen bzw. an eine Braillezeile liefern? Und eine zweite Frage zu der von Ralf in seiner obigen Antwort angedeuteten Komplexität des Problems Barrierefreiheit: Ich verstehe das jetzt so, dass es für viele Probleme keine allgemeingültige Lösung gibt, die für alle Menschen das Optimum darstellt. Gibt es diesbezüglich, basierend auf welchen Kriterien auch immer (z.B. Zahl der Betroffenen, technische Realisierbarkeit etc.), Aspekte der Barrierefreheit, die eher umgesetzt werden sollten als andere? -- Uwe 22:49, 30. Apr. 2008 (CEST) @Lalü: Könntest du das mal bitte beantworten? Ich als Sehender kann das nur bedingt...--RalfR → BIENE braucht Hilfe 22:59, 30. Apr. 2008 (CEST)

In der Standardansicht mit einem Screenreader sieht das folgendermaßen aus. Die Lage der Nachbargemeinden wird dabei nicht klar:

Tabelle mit 3 Spalten und 3 Reihen
Großkarolinenfeld
mit 7.200 Einwohnern
Schechen
mit 4.600 Einwohnern

Kolbermoor
mit 19.000 Einwohnern
Compass_card_%28de%29.svg/80px-Compass_card_%28de%29.svg
Stephanskirchen
mit 10.000 Einwohnern

Raubling
mit 11.500 Einwohner
Rohrdorf
mit 5.500 Einwohner
tabellen ende

Wenn man den Screenreader auf Bildschirmlayout umstellt, was ich aber fast nie mache, da dies bestimmte Nachteile mit sich bringt, sieht das folgendermaßen aus:
Tabelle mit 3 Spalten und 3 Reihen
Großkarolinenfeld mit 7.200 Einwohnern | Schechen mit 4.600 Einwohnern |
Kolbermoor mit 19.000 Einwohnern | Compass_card_%28de%29.svg/80px-Compass_card_%28de%29.svg | Stephanskirchen mit 10.000 Einwohnern
Raubling mit 11.500 Einwohner | Rohrdorf mit 5.500 Einwohner
tabellen ende

Ich denke, daß die Tabelle mit der Seerose für fast alle Leser die Lage sehr anschaulich vermitteln kann. Für einen Screenreader-Nutzer wird die Lage nicht klar. Das ließe sich mit einer Fließtextbeschreibung verständlicher machen, gibt sehenden Lesern dann allerdings redundante Infos. Ich persönlich mag die Angabe von Himmelsrichtungen (und eventuell auch noch Entfernungen) im Fließtext sehr. Fazit: Macht euch nicht zuviele Gedanken darum, blinde Menschen stoßen überall mal auf Details, die sie nicht einordnen können und es bleiben glücklicherweise immer genug Infos übrig, auf die sie sich konzentrieren können. . Wenn eine nicht zugängliche Information wirklich für einen einzelnen blinden Leser sehr wichtig ist, kann er/sie beispielsweise alle Artikel der Nachbargemeinden durchlesen und findet dort ja auch wieder Infos zur Lage. Toll wäre es, wenn "Compass_card_%28de%29.svg/80px-Compass_card_%28de%29.svg" einen weniger komplizierten Titel hätte, da das vorlesen dieser Bezeichnung relativ lange dauert. -- Lalü 08:41, 1. Mai 2008 (CEST)

• Wenn ich das jetzt so lese, Screenreader-Nutzer haben von der Seerosentabelle nicht viel, für ihn sind Fließtexte verständlicher. Lesern mit anderer Behinderung können jedoch von der Seerosentabelle profitieren, da die Lage bildlich dargestellt wird. Wie sieht es in dem Zusammenhang mit einer Karte aus? Für mich ist die Seerosentabelle eigentlich nicht mehr als ein sehr schlechter Kartenersatz. -- SteveK ?! 12:06, 1. Mai 2008 (CEST)

Ja, ich habe mich auch schon gefragt, warum es nicht einfach eine grobe Kartendarstellung gibt. Ich finde die Idee mit der Seerose in einer Tabelle eigentlich sehr pfiffig, ist halt für Screenreader-Nutzer nicht zugänglich. Eine Karte ist natürlich für blinde Nutzer genauso wenig verständlich, es sei denn, man packt eine knapp gehaltene Fließtextbeschreibung als Alt-Attribut dazu. Dann sieht jeder Sehende eine Karte, bei der man ja vielleicht auch eine Seerose einbauen könnte, und andere wie ich hören noch eine textliche Beschreibung. -- Lalü 18:17, 1. Mai 2008 (CEST)

Ich fand die Seerose als Kartenersatz auch ganz pfiffig, aber nur dann. Eine Karte ist aber alle mal besser. Außerdem sollte eine Abbildung ja nie den Fließtext ersetzen, genauso sollte ja die Information der Infobox auch im Fließtext auftauchen. Beides zusammen, Karte und Fließtext ist dann wohl auch die anzustrebende Lösung. -- SteveK ?! 21:02, 1. Mai 2008 (CEST)

Kann man denn die Vorlage so anpassen, dass der Screenreader die Information mitbekommt, welche Himmelsrichtung welchem Feld in der Tabelle enspricht? Wenn aus „Kolbermoor mit 19.000 Einwohnern“ aus Lalüs Beispiel ein „im Westen Kolbermoor mit 19.000 Einwohnern“ wird, dann wäre es evtl. tatsächlich ein Gewinn, sonst sehe ich es wie SteveK, ohne Entsprechung im Fließtext ist es nichts. -- Achates You’re not at home ... 09:55, 2. Mai 2008 (CEST)

Die Aufzählung der Nachbargemeinden ist eher ein zu vernachlässigender Nebenaspekt in der Anlage der Gemeindeartikel und eigentlich nur eine Art Naviservice des unmittelbaren Umkreises. Umso erstaunlicher ist es, dass Windrosen in Vorlagen- oder Tabellenform unterschiedlichster Größe viele Artikel sehr stark dominieren (um nicht zu sagen: erschlagen). Dabei ist seit 2004 in über 1000 deutschen Städteartikeln der Passus der Uhrzeigerrichtung eingebunden (Trier, Schwerin...). Man umgeht hierbei Ungenauigkeiten in der Nennung der Himmelsrichtung, die dadurch entstehen, dass eine Gemeindegrenze im Süden liegen kann, die eigentliche Nachbarstadt aber genau westlich liegt (kuckstu Karte Groß Pankow (Prignitz)). Zugrunde gelegt sind dabei die objektiv gegebenen Gemeindegrenzen (anders als bei Ortsteilen, hier kann jeder die Nachbarorte beliebig aussuchen / erweitern). Schwierig wird es bei Enklaven bzw. Exklaven wie Langenwolschendorf oder Garding, Kirchspiel, bei Küstenorten oder Inselgemeinden (die Windrose der Gemeinde Helgoland ist sehr interessant). Bei allen Landkreisartikeln nennen wir seit 2003 die Nachbarlandkreise in Textform, bei Bergen und Seen habe ich (bis jetzt) noch keine Windrose der Nachbarberge oder -seen entdeckt :-) Ein Beispiel aus enwiki darf man hier bestaunen, die Kombination mit den Miniwappen ist auch für Null-Dioptrien-Leser eine Augenweide. Ich habe schon lange den Verdacht, dass die Windrosen bei Artikeln mit wenig Text als Füllstoff dienen, langen gut geschriebenen bis exzellenten Artikeln ist dagegen mit Text kaum noch beizukommen und so werden halt Windrosen, Wappenbatterien der Partnerorte usw. zur Verzierung genutzt. Vor fast drei Jahren gab es den Vorschlag von Arnomane, die Navigationsleisten am Ende der Gemeindeartikel, die landkreisweise zusammenfassen, durch Navileisten der Nachbargemeinden zu ersetzen. Das stieß (auch meinerseits) damals auf erbitterten Widerstand und erzeugte viel Frust auf beiden Seiten. Hätte man damals gewusst, dass mal massenhaft Windrosenbilder in die Artikel gedrückt werden (in österreichischen Gemeindeartikeln praktisch schon flächendeckend - die Schweizer sind dagegen noch völlig unbetroffen - sie würden es sich wahrscheinlich auch verbitten), hätte man sich wohl auf den Kompromiss von zwei Navileisten geeinigt. Eine zweite Leiste wäre durch das Boxenverschmelzen standardmäßig eingeklappt und man könnte sich von Flensburg bis Oberstdorf durchzappen. Inselgemeinden hätten natürlich auch weiterhin keine Nachbargemeinden und Navileisten mit einer Nachbargemeinde als Inhalt (ein Beispiel wäre Peenemünde) wären auch nicht der Bringer. Wie der Leser Windrosennavigation beurteilt, kann hier niemand sagen, denn die Beteiligten sind ja aus dem Kreis der Leser herausgetreten und dürften alle als befangen gelten. Deshalb hat die Aussage, dass ich als Leser die Windrosen scheiße finde und sie als ausgemachten Unfug bezeichne, keinen Wert. gruss Rauenstein 17:40, 2. Mai 2008 (CEST)

Interaktive Beteiligungsmöglichkeit an der Fachtagung

Seit Samstag kann man auf den Seiten der einzelnen Workshops seine Fragen und Kommentare hinterlassen. Für dieses Wikipedia-Projekt ist der Workshop 05 interessant. Am Dienstag wird es live-Streams von der Veranstaltung geben. Da mein Wunsch nach Kommunikation mit dem Verein Wikimedia mir bislang nur Schweigen eingebracht hat und Experten wie Herr Jendryschik vom Thema laut eigener Aussage selber nicht viel verstehen, bin ich gespannt, was dort überhaupt so diskutiert werden soll.

Vielleicht mögen sich andere Wikipedia-Nutzer dort ebenfalls zu Wort melden? Eigene Beiträge kann ich mir wahrscheinlich sparen, da sie anscheinend sowieso niemanden interessieren. Ich werde aber eventuell einige Argumente zusammenstellen, warum verschiedene Skins für verschiedene Bedürfnisse nicht dem Gedanken der Barrierefreiheit wiedersprechen. Warum gibt es sonst überhaupt die Möglichkeit, zwischen verschiedenen Skins bei Mediawiki/Wikipedia wählen zu können? Warum sollte man nicht mit einem Skin für Screenreader-Nutzer eine Möglichkeit schaffen, die Mediawiki-Benutzeroberflächen auch als Blinder optimal nutzen zu können? Ich werde manchmal richtig neidisch, wenn ich all die tollen Gadgets, Erweiterungen und all den Spielkram sehe, mit dem Nicht-Blinde sich die Wikipedia-Bedienung erleichtern und perfekt an ihre Bedürfnisse anpassen können.

Klar, solch ein Screenreader-Skin muß erstmal entwickelt werden und nur von Freiwilligen ist das natürlich nicht leistbar, aber wie ich bereits oben schrieb, könnte sowas doch eigentlich auch gesponsort werden. Aus dem Ausland habe ich bereits einige freundliche und motivierende, wenn auch leider unverbindliche Rückmeldungen bekommen. T.V. Raman hatte beispielsweise Chris DiBona auf meinen Vorschlag hingewiesen und beide fanden ihn gut. Da ich mein Feedback bislang lediglich via PM bekam, kann ich hier nicht die Personen aufführen, die wenigstens mal geantwortet haben. -- Lalü 08:40, 4. Mai 2008 (CEST)

ach Lalü... *seufz* – irgendwie habe ich bei Deiner Enttäuschung in letzter Zeit oft den Eindruck, daß ich mich angesprochen fühlen sollte. Den Knackpunkt unserer Kommunikationsschwierigkeiten sehe ich vor allem, das haben wir auch in unserem Telefonat schon beide gemerkt, in dem massiv unterschiedlichen Zeiteinsatz, den wir für dieses Thema aufbringen können. „Der Verein“ besteht auch nur in einem Haufen ehrenamtlicher und mit zig Ideen und Projekten beschäftigter, z.T. überarbeiteter Personen, von denen genau eine – nämlich ich – beim Thema Barrierefreiheit als mögliche Aktivität mal mutig die Hand gehoben hat. Und ich bin eher ein Mensch kleiner Schritte („wie krieg ich die verdammten eckigen Klammern aus dem Bearbeiten-Link weg, ohne daß alle weinen?“) als einer, der große Projekte mit Politik usw. aufzieht. Ich verspreche mir von der Tagung vor allem Anregungen dahingehend, wie man das Thema besser strukturiert, was Technik und was Community leisten können, sollen, müssen. Die Thesen von Michael J. dazu fand ich schon ganz spannend. Insgesamt haben sich immerhin auch rund 45 Personen im Workshop als Live-Publikum angemeldet, da gibt es sicher eine anregende Diskussion. Nur: Diskussion allein bringt uns nicht weiter, da können wir hier noch zig Seiten vollschreiben, ohne daß was passiert. Deshalb plädiere ich für Wikipedia weiterhin für kleine, aber konkrete Schritte, auch wenn das Dich, den ich eher als Aktivisten im positiven Sinne sehe, im Tempo frustriert. Das Thema „Ist eine eigene Skin sinnvoll im Sinne von Barrierefreiheit“ habe ich mir auf alle Fälle für die Moderation des Workshops notiert (und zwar schon bevor Du es hier angesprochen hast). Beste Grüße aus Köln, --elya 10:52, 4. Mai 2008 (CEST)

Ich denke, daß es kein allzu großes Problem sein sollte, ein BIENE-Skin (oder wie immer man das nennt) auf die Beine zu stellen. Wenn ein klar definierter Aufgabenkatalog vorliegt, können uns die Monobook-Bastler sagen, was geht und was nicht. Das muß nur irgendwo übersichtlich aufgelistet werden. Es hat keinen Sinn, wenn Ideen und Forderungen auf -zig Diskussionen verteilt herumliegen. --RalfR → BIENE braucht Hilfe 11:03, 4. Mai 2008 (CEST)

Ach Elya, mir ist die reine Freiwilligkeit eures Handelns sehr bewußt und ich möchte auf keinen Fall irgendwelche freiwillig arbeitenden Wikipedianer an den Pranger stellen. Darum versuche ich in der Regel auch, alles persönliche zu vermeiden. Auf den Gedanken der politischen bzw. gesellschaftlichen Ebene bin ich auch nur gekommen, da alle anderen Vorgehensweisen scheiterten. Wikipedia ist so wichtig für die Bildung und aufgrund der Freiwilligenstruktur ein völlig einzigartiges Projekt. Ich würde zu gerne einmal mit technisch versierten Mediawikianern telefonieren, um so herrausfinden zu können, welche meiner Ideen realistisch sind und welche eben nicht.

Die eckigen Klammern für die Bearbeitungslinks stören in der deutschen Wikipedia übrigens garnicht, sind aber aufgrund der anderen Reihenfolge von Abschnittsüberschrift und Editlink in allen anderen Mediawiki basierten Wikis sehr nervig. Mit einem globalen Gadget für eine Vertauschung dieser Elemente (siehe oben) wären diese Klammern aber auch kein Problem mehr.

@Ralf: Ein "BIENE"-Skin, der alle unterschiedlichen Bedürfnisse irgendwie eingeschränkter Nutzer auf einmal befriedigen will, erscheint mir unmöglich. Diversifikation ist unabdingbar, von mir aus auch ohne spezielle Skins aber dann eben mit Gadgets, die sich gezielt in den Einstellungen wählen lassen. -- Lalü 11:42, 4. Mai 2008 (CEST)

Ich glaube, wir sind uns einig, daß es eine befriedigende Komplettlösung nicht geben kann. Das meine ich auch nicht mit dem Skin. Sondern vielmehr ein Skin, bei dem sich der Benutzer einstellen kann, ob er beispielsweise eckige Klammern möchte oder nicht - nur, weil das gerade Thema ist, die eckigen Klammern sind ja auch nur ein ganz kleines Bausteinchen. Ich könnte mir noch einiges spontan vorstellen, Einstellmöglichkeiten für:

• Inhaltsverzeichnisse per Standard / erzwingen / immer einblenden
• Illustrationsbildchen unter 30px einblenden / ausblenden
• alle Bilder automatisch auf (z.B.) 130% skalieren
• wahlweise farbliche Hervorhebung von kursiv, fett usw.

Wie gesagt, die Beispiele sind völlig aus der Luft gegriffen und nicht repräsentativ. Ich stelle mir vor, daß jeder Benutzer sich derartige Dinge selbst einstellen kann. Nicht angemeldete Leser haben davon keinen Nutzen, ist schon klar. Wie wäre es, wenn wir irgendwo eine "Wunschliste" aufstellen? Völlig unabhängig davon, ob wir selbst das für durchführbar halten oder nicht. Oft sind scheinbar kleine Wünsche schwer umsetzbar und scheinbar Unmögliches geht ganz einfach. Wenn wir diese Wunschliste haben, finde ich garantiert auch Leute, die sich daranmachen, die Machbarkeit zu prüfen bzw. solch einen Skin / Gadget, was auch immer zu basteln. Übrigens finde ich BIENE nicht als gescheitert. Wir reden über Probleme, was noch vor 2 Jahren nicht der Fall war bzw. nur mal irgendwo krümelweise. --RalfR → BIENE braucht Hilfe 15:43, 4. Mai 2008 (CEST)

Spezielle Benutzeroberfläche für Screenreader

Ausgehend von Lalüs Mail an wikide-l hab ich mir Gedanken gemacht, was die technische Umsetzung angeht. Wer sich angesprochen fühlt, darf sich gerne beteiligen, auch wenn das Projekt in seiner Gänze vermutlich nicht nur über Skinprogrammierung ermöglicht werden kann. Die Diskussion und Koordination findet bisher unter Benutzer:Viciarg/Screenreader und der dazugehörigen Disku statt. – viciarg ᚨ 22:30, 7. Mai 2008 (CEST)

Lieber Viciarg, magst du deine Seite nicht auf eine Unterseite von WP:BIENE/Screenreader verschieben? Dann ist das Ganze hier zentral und hat nicht so den Anschein einer Privatveranstaltung. Liebe Grüße — Lecartia Δ Barrierefreiheit als Qualitätsmerkmal 22:59, 7. Mai 2008 (CEST)

Ich habe die Seite von Viciarg nun im Projekt "Blinde" verlinkt. Da alle unsere Arbeiten eine Art von Privatveranstaltung sind, dürfte die URL doch egal sein. Es ist wichtiger, kompetente Personen zu motivieren, sich an der Aufstellung und Klärung relevanter Fragen zu beteiligen. -- Lalü 08:21, 8. Mai 2008 (CEST)

Moin Moin Lalü, natürlich ist alles irgendwie eine Privatveranstaltung, aber es ist schade, wenn Interessierte diese Veranstaltung nicht finden. So wie du es jetzt gelöst hast, einen Link auf die Unterseite der Blinden-Arbeitsgruppe, ist es zufriedenstellend. Der Link ist dort schnell auffindbar, im Gegensatz zu dieser Diskussionsseite die langsam überquillt – wir müssen bald archivieren. Herzlichst — Lecartia Δ 10:27, 8. Mai 2008 (CEST)

Huhu Lecartia! Ich habe die Seite jetzt nach Wikipedia:BIENE/Screenreader/Skin verschoben, dort wird sie vielleicht schneller gefunden. Dass das Projekt nicht zu einer Privatveranstaltung wird, lässt sich am besten verhindern, wenn viele Leute mithelfen ;) – viciarg ᚨ 15:37, 8. Mai 2008 (CEST)

Ach, super. Danke, Viciarg. Ich finde es toll, dass du dich mit engagierst. Ich überlege noch, wie wir weiter dafür werben können. Ralf hat ja diese Signatur „BIENE braucht Hilfe“ – ob wir uns die alle aneignen? — Lecartia Δ 16:58, 8. Mai 2008 (CEST)

Ich möchte meine Signatur ungern so aufblähen, aber das BIENE-Projekt sollte wirklich etwas mehr beworben werden. Vielleicht könnten wir einen Kurier-Eintrag schreiben, wenn das Screenreader-Projekt erste greifbare Ergebnisse bringt. Ansonsten mal die Tutorial- und Einstiegsseiten durchgehen und schauen, ob wir uns da noch irgendwo eintragen können. Aber das überlasse ich lieber Leuten, die eher den Draht zur Community haben. – viciarg ᚨ 17:46, 8. Mai 2008 (CEST)

Wen du deine Benutzerseite verschönern willst: Jcornelius hat uns einen Banner gebastelt!

Biene-Banner

— Lecartia Δ 23:50, 9. Mai 2008 (CEST)

Verschiebung der Hilfe für blinde Benutzer und Umbenennung der AG Blinde

Ich habe die Hilfe für blinde Benutzer in den Hilfe-Namensraum verschoben. Könnte sich das vielleicht jemand angucken und die Kategorie nachtragen und Redirects und Links berichtigen? Ich habe das bislang nicht gemacht. Es wäre schön, wenn diese neue Hilfe nun irgendwie bekannt gemacht werden könnte, also von anderen hilfeseiten darauf verwiesen wird. Vielleicht könnte man die Seite auch für eine kurze Zeit auf der Hauptseite verlinken? Außerdem möchte ich die AG Blinde gerne in Screenreader umbenennen. Der Grund dafür findet sich hier. Leider traue ich mir das nicht zu, so dass das jemand anderes machen müsste. -- Lalü 11:31, 20. Mai 2008 (CEST)

Es reicht nicht nur den Text zu Verschieben, er muß auch eingebunden werden. So könnte er z.B. auf der Seite Hilfe:Bearbeiten sowohl unter dem Kapitel Grundlegendes eingefügt werden, als auch in der rechten Navigationsleiste. --Goldzahn 00:28, 24. Mai 2008 (CEST)

Ich bin gerade dabei, die gesamte Arbeitsgruppe inklusive aller Unterseiten von "Blinde" nach "Screenreader" zu verschieben. --TM 23:38, 28. Mai 2008 (CEST)

TMg, herzlichen Dank für deine Arbeit! -- Lalü 10:46, 29. Mai 2008 (CEST)

WAI ARIA (Accessible Rich Internet Applications)

Könnte man WAI ARIA für Mediawiki und deren Erweiterungen auf Basis von JavaScript und Ajax nutzen? Das wäre zumindestens schön. Die Mediawiki-Entwickler hätten später so eventuell mehr Spielraum bei Weiterentwicklungen, ohne Angst davor haben zu müssen, dass ihre Arbeit nicht den Accessibility-Standards genügen könnte. Was meint ihr? -- Lalü 09:27, 27. Aug. 2008 (CEST)

Ich hab gerade erstmalig davon gelesen. Ad hoc sag ich mal: Klingt interessant. Ich fürchte, ich sehe gerade noch 2 Probleme: Zum einen der noch unklare Zustand der Spezifikation (ARIA validiert im Moment nicht mit Standard-XHTML-1.0-Validatoren. Das W3C weiß darum und sucht zur Zeit nach einer für alle Seiten vertretbaren Lösung.), zum anderen: Soweit ich das sehe wäre eine Verwendung von ARIA erst im Rahmen einer grundlegenden Überarbeitung der MediaWiki-Oberfläche möglich. --Gnu1742 09:52, 27. Aug. 2008 (CEST)

Aria ist inzwischen weit genug fortgeschritten und wird ausreichend in den (Beta-)Versionen der Screenreader unterstützt. Eine grundlegende Überarbeitung steht auch gerade an: die Usability-Initiative ist dabei. Ich habe genau daher, dort eine Anfrage zur Nutzung von Aria platziert. Fazit: Wir müssen uns selbst kümmern, dass es eingepflegt bin. Ich hoffe, genügend Zeit aufzubringen, das voranzubringen – gern in Kooperation mit Organisationen oder Privatpersonen. — Lecartia Δ 09:54, 10. Sep. 2009 (CEST)

Schwerhörigkeit

Hallo ich würde gerne die BIENE erweitert sehen zum Thema Schwerhörigkeit, Ertaubung, Spätertaubung etc...

Rehabilitationszentrum für Hörgeschädigte

Deutsche Hörbehinderten-Selbsthilfe

sind meine bisherigen Artikel, doch da die Betroffenen meist nur Minderheiten sind werden die Artikel automatisch als Löschantrag eingestellt. Ich würde Euch bitten die Schwerhörigen dort zu unterstützen - und auch in die Barrierefreiheitsliste einzutragen, da Schwerhörige ganz andere Bedürfnisse als Gehörlose besitzen, wie zB Fernsehen mit unterstützenden Untertiteln - visualisierte Webseiten, welche Ton und Film nur fuer normalhörende Abspielen etc. - danke --Frank Sonnenkind 22:18, 30. Aug. 2008 (CEST)

Ich fürchte, das ist ein Missverständniss. Das BIENE-Projekt beschäftigt sich nicht mit konkreten Artikeln und erst recht nicht mit Löschanträgen sondern damit, die Wikipedia-Website ganz allgemein zugänglicher zu machen. Nun wird in der Wikipedia aber nur an ganz wenigen Stellen mit Ton und Film gearbeitet. Insofern sehe ich da keinen gesonderten Handlungsbedarf. Untertitel für Videos können gut in der Arbeitsgruppe Gehörlosigkeit diskutiert werden. --TM 18:09, 31. Aug. 2008 (CEST)

Danke für den Hinweis - ich wurde aufgrund meiner Artikel angesprochen ob ich am BIENE Projekt mitwirken mag. --Frank Sonnenkind 12:12, 3. Sep. 2008 (CEST)

Mitarbeit!?

HAllo!

Ich habe gerade des erstemal von Eurem Projekt erfahren. Ich würde gerne mitarbeiten. Ich bin selbst durch eine spastische Behinderung betroffen. Vielleicht könnt ihr ja meine Hilfe gebrauchen --Kleines214 15:00, 2. Sep. 2008 (CEST)

Hallo, herzlich willkommen. Es ist schön, dass du dich einbringen möchtest. Im BIENE-Projekt gibt es momentan aber leider kaum Aktivitäten. Das liegt vor allem daran, dass es fast keine Informationen von behinderten Menschen über ihre Probleme bei der Bedienung von Wikipedia gibt. Wenn du helfen möchtest, dies zu ändern, wäre das fein. Mir fallen spontan folgende erste Fragen ein:

Nutzt du eine normale PC-Tastatur und eine Maus oder hast du ein besonderes Eingabegerät? Eine spastische Behinderung kann ja sehr unterschiedliche Auswirkungen haben. Mit welchen speziellen Problemen hast du bei der Bedienung deines Computers oder beim surfen im Internet am meistn zu kämpfen? Vielleicht ein feinmotorisches Problem bei der Plazierung des Mauszeigers auf den richtigen Links?

Es wäre hilfreich, wenn du schreiben könntest, womit du speziell bei Wikipedia die meisten Schwierigkeiten hast. Damit meine ich aber nicht die Verständlichkeit von komplizierten Wikipedia-Artikeln, da sich daran leider kaum etwas ändern lässt. Dieses Problem haben alle nicht-behinderten Leser auch. Über Infos von dir würde ich mich freuen. Ich selbst bin übrigens blind. -- Lalü 10:09, 3. Sep. 2008 (CEST)

Nutzt du die Textskalierung? Ist Wikipedia mit Skalierung noch ordentlich zu lesen bzw. zu bearbeiten? Wie Lalü schon sagte, uns fehlen Nachrichten, wo konkret Probleme auftreten. --RalfR → DOG 2008 11:01, 3. Sep. 2008 (CEST)

Hat ein wenig gedauert, aber ich war gestern nur eingeschränkt bei WIki unaterwegs. Erst einmal zu deinen Fragen Lalü: Ich arbeitet mit einem LAptop und Maus. Auf der Arbeit habe ich auch eine spezielle Tastatur, die noch etwas kleiner ist als die normale Laptop-Tastatur, damit auch im Fünf-Finger-System schreiben kann. Meine Spastik nennt man auch Hemiplegie. Ich kann nur mir einer Hand schreiben, da meine andere HAnd nicht die notwendige Feinmotorik hat. Deshalb nutze ich auch keine Tastenkompinationen. Ich mache alles mit der MAus. Schwierigkeiten habe ich besonders beim Schreiben von ARtikel, ich meine hier nicht das Formulieren, sondern ehr das eingeben und bearbeiten. Man kann bei Wiki kaum Texthilfen finden. Dir ist wahrscheinlich aufgefallen, das einige WOrte mit zwei Großbuchstaben geschrieben worden sind. Dies hängt damit zusammen, das ich die UMschaltetaste micht meiner behinderten HAnd drücke und manchmal eben schneller schreibe wie loslassen kann. In den normalen Textverarbeitungsprogrammen kann ich dieses mit HIlfe der Autokorrektur unterbinden. Bei Wiki geht das leider nicht. Und jetzt zu deiner FRage RalfR: War ist eine Textskalierung? Wenn du sie mir erklärst kann ich dir auch sagen ob sie mir einen NUtzen bringt. --Kleines214 05:56, 4. Sep. 2008 (CEST)

Ich hatte vermutet, daß du Probleme hast, mit der Maus konkrete Textstellen zu finden bzw. zu treffen, das geht besser, wenn man sich den Text mit <Strg>+<+> vergrößert. Aber das ist ja nicht dein Problem, danke für die Beschreibung! Eine Autokorrektur müßte sich eigentlich realisieren lassen, ich frage mal. --RalfR → DOG 2008 06:53, 4. Sep. 2008 (CEST)

Vielleicht ist eines der Tools von Wikipedia:Textverarbeitung in diesem Fall interessant. Ich weiss aber nicht, ob man mit so einem Werkzeug eine ähnliche Fehlerkorrekturmöglichkeit wie auf deinem PC zur Verfügung stellen könnte. Danke für die Beschreibung der Problematik. Freundlichen Gruß -- Lalü 10:43, 4. Sep. 2008 (CEST)

Falls du den Browser Firefox benutzt, da gibt es ein Add-on für die deutsche Rechtschreibung. HAL 9000 14:38, 4. Sep. 2008 (CEST)

Ist Google Chrome für Behinderte geeignet?

Google hat einen Browser herausgegeben: Google Chrome. Der Browser ist sehr übersichtlich und einfach zu bedienen. Er basiert auf dem Firefox, übernimmt auch dessen Lesezeichen und Passwörter. Ich könnte mir vorstellen, daß einige Menschen mit Behinderungen damit besser klarkommen als mit den überladenen Standard-Browsern. Wäre schön, da mal Erfahrungsberichte zu haben. --RalfR → DOG 2008 10:57, 3. Sep. 2008 (CEST)

„Überladene Standard-Browser“. Soso. Was immer du mit „Standard“ und mit „überladen“ meinst. Den Internet Explorer? Der Microsoft-Browser hat übrigens bis heute mit die beste Unterstützung für Screenreader und andere assistive Software. Dass die Googlegläubigkeit sogar bis hier schwappt – erstaunlich. Der iPhone-Hype war ein Witz gegen den Tsunami, der gerade durchs Web rollt. Das Ding basiert übrigens auf WebKit, nicht auf Firefox. --TM 21:27, 3. Sep. 2008 (CEST)

Okok, hast schon Recht. Die Überschrift ist natürlich so besser. WebKit? Da war ich wohl falsch informiert. Googlegläubigkeit ist so ne Sache. Ich habe noch nie ein Mailprogramm besessen, habe immer Online-Lösungen benutzt. Und da kenne ich nichts Besseres als gmail. Bei Affiliate-Angeboten hat sich Google ganz klar als Marktführer durchgesetzt, Maps/Earth habe zwar Konkurrenz, sind aber auch am weitetsten verbreitet, zu Text und Tabellen kenne ich keine Alternative. Wenn die was machen, dann ordentlich. Daß da der zweite Gigant heranwächst, der M$ herausfordert, kann eigentlich nur gut sein. Es ist doch gut, wenn man in Zukunft mit Linux+Internet+Google auf Windows und Office verzichten kann? --RalfR → DOG 2008 22:10, 3. Sep. 2008 (CEST)

Es gibt bereits einen ersten Accessibility-Check für diese Software. Ich tippe darauf, dass Google die Entwicklung dieses Browsers im Hinblick auf das eigene Betriebssystem Android betreibt. -- Lalü 10:21, 4. Sep. 2008 (CEST)

@Ralf: Dass du keine Alternative zu Google Text & Tabellen kennst, bedeutet nicht, dass es keine gibt. Siehe Online-Textverarbeitung und Online-Tabellenkalkulation. Die Barrierefreiheit dieser Online-Lösungen ist so weit ich weiß katastrophal. Ehe eines dieser JavaScript-Monster einen BIENE-Award gewinnt, werden meiner Einschätzung nach noch fünf bis zehn Jahre vergehen. --TM 19:21, 4. Sep. 2008 (CEST)

Vorlage:Farblegende

Ist die geplante Änderung BIENE-konform, oder gibt es Verbesserungswünsche? --Fomafix 21:26, 8. Sep. 2009 (CEST)

Hallo Fomafix, ich finde die Ergänzung sehr gut, einen verständlichen Farbnamen in der Vorlage nutzen zu können – {{Farblegende|red|Beispiel|Rot}}. Das ist sehr hilfreich, wenn Sehende und Nichtsehende über etwas reden wollen. Es wäre toll, wenn ihr in der Dokumentation darauf hinweist, dass diese Version bei kryptischen Farbangaben immense Vorteile für die Barrierefreiheit bringt. Vielen Dank für eure Arbeit und dass ihr dabei stets die Barrierefreiheit im Blick habt! — Lecartia Δ 10:05, 10. Sep. 2009 (CEST)

Barrierefreiheit von LiquidThreads

Die MediaWiki-Erweiterung LiquidThreads soll bald als Diskussionsplattform genutzt werden. Da es sich hier um eine neue Erweiterung handelt, wäre es auch hilfreich, wenn sie auf Barrierefreiheit geprüft werden könnte und falls nötig, können jetzt schon Verbesserungen genannt werden, so dass bei einer (plötzlichen) Einführung die (meisten) Benutzer ohne technische Einschränkungen mit der Diskussionsplatform arbeiten können. Es wurde daher ein Abschnitt im WikiProjekt LiquidThreads eröffnet: Wikipedia Diskussion:WikiProjekt LiquidThreads#Barrierefreiheit, Beteiligung willkommen --Der Umherirrende 12:13, 6. Apr. 2010 (CEST)

Lieber Umherirrender, ich habe deine Anfrage gelesen, kann dir leider aber nicht schnell weiterhelfen. Ich habe leider derzeit keine Zeit, die Erweiterung selbst ausführlich zu testen, außerdem bin ich kein alltäglicher Anwender von Hilfsmitteln. Ich habe deine Anfrage aber auf meiner Erinnerungsliste und werde versuchen, entweder Tester dafür zu finden oder es mir selbst anzuschauen. Herzliche Grüße — Lecartia Δ 19:54, 11. Apr. 2010 (CEST)

90-%-Schrift in Tabellen

Manche Benutzer sind der Meinung, Tabellen (v. a. im Motorsport-Bereich) mit 90-%-Schrift zu versehen. Könnte bitte mal hier jemand von euch meinen Mitdiskutanten erklären, warum Barrierefreiheit wichtiger ist, als ein tolles Tabellendesign? -- Chaddy · D – DÜP – 21:20, 6. Sep. 2010 (CEST)

Das dort diskutierte Tabellenmonster ist für Menschen mit Behinderung sowieso praktisch unbenutzbar (9 Spalten, teilweise Rowspans, Dummy-Zeilen, Flaggenchaos). Da spielt die verkleinerte Schriftgröße keine Rolle mehr. Warum macht ihr nicht einfach für jedes Jahr eine Zwischenüberschrift und mehrere kleinere Tabellen mit den Platzierungen? Dann löst sich auch die Diskussion um die Schriftgröße von selbst. --TMg 23:57, 6. Sep. 2010 (CEST)

Ich hab mir die Tabelle nicht ausgedacht. Aber wenn schon der Widerstand gegen die Änderung der Schriftgröße so gewaltig ist...

Im Artikel Großer Preis von Deutschland (Motorrad) ufert das mit den Monstertabellen übrigens sogar soweit aus, dass der Artikel nicht mehr aufrufbar ist, da er die Hamster überfordert (siehe auf derselben Diskseite einen Abschnitt tiefer)... -- Chaddy · D – DÜP – 00:15, 7. Sep. 2010 (CEST)

Die Diskussion um die Barrierenfreiheit bei prozentual verkleinerter Schriftgrösse macht für mich nur Sinn, wenn sie gesamthaft diskutiert wird, anstatt nur bei den GP-Tabellen. Aktuell ist sowas, wenn ich keiner optischen Täuschung unterliege, in jedem Artikel bei Inhaltsverzeichnis und Bildunterschrift Standard. Zusätzlich verwenden tausendfach eingebundene Vorlagen, die Daten tabellenartig aufbereiten, eine verkleinerte Schriftgrösse. Ich nenne als Beispiel nur mal die Filmboxen und die Länderboxen. Ich halte nochmals fest: Es geht dabei nicht um einen festen Schriftgrad, sondern um eine Verringerung von 10%. Die Behauptung, dass dies die Barrierenfreiheit unterlaufe, ist also auf der Annahme begründet, dass auf dem Computer und Browser jedes, der meisten oder auch nur einiger Sehbehinderten, die technisch maximal machbare Zoom- und Textgröße gleichzeitig die einzig annehmbare Lesbarkeit für Wikipedia-Artikel darstellt, die mit 90% unterlaufen werde. Da würd mich jetzt schon interessieren, worauf diese Annahme fusst.

Ich weiss nicht, wie Du auf die Idee kommst, dass der "Widerstand gegen die Änderung der Schriftgröße so gewaltig ist". Wir diskutieren auf dem Portal und sind offen für jedes Argument. Für mich ist es bisher nichts mehr als eine Geschmacksfrage. Aber dass du ohne vorherige Diskussion einfach in zwei Artikeln, und nur in zweien, den Standard abänderst, und dies wiederholt und auch noch während der laufenden Diskussion, dagegen gibt es natürlich Widerstand. --Milwaukee 08 00:27, 7. Sep. 2010 (CEST)

Das Ändern der Schriftgröße individuell je Artikel ist (Zitat von dir) Geschmacksfrage und genau deshalb ist es grundsätzlich unerwünscht, erst recht im Haupttext (!) von Artikeln. In Infoboxen wird es gelegentlich praktiziert, weil die dortigen Informationen untergeordnet sind und in normaler Schriftgröße im Haupttext wiederholt werden. Das Design für Elemente wie das Inhaltsverzeichniss ist schließlich sogar zentral per CSS vorgegeben und nicht individuell von Artikelautoren. Deine Vergleiche sind insofern alle unzutreffend. --TMg 00:37, 7. Sep. 2010 (CEST)

Ich kann das Problem der 90-%-Schrift für Sehschwache nicht nachvollziehen. Wenn ich was nicht sehe, drücke ich + (strg +) und dann kann es sogar mein Blindenhund lesen. Ich nehme an, dass diesen Trick wohl jeder kennt, der einen weißen Stock zum Lesen braucht. Was hab ich übersehen? Liebe Grüße --Volker Paix^... 00:56, 7. Sep. 2010 (CEST)

Seh ich eben auch so, drum nochmals die Frage: Worauf fusst die Annahme, dass die maximale technisch machbare Zoom- und Textgröße, für Sehbehinderte gleichzeitig die einzig annehmbare Lesbarkeit von Wikipedia-Artikeln darstellt, die durch 90% unterlaufen wird? Und warum sollen meine Beispiele nicht zutreffen? Was zum Beispiel in Filmboxen steht, steht in den allerwenigsten Fällen auch zu 100% im Artikel - könnte aber. Umgekehrt könnte man zu jeder GP-Austragung einen eigenen Abschnitt mit Fliesstext schreiben. Und auch was vom CSS vorgegeben wird, könnte man ja abändern, wenn es der Barrierenfreiheit im Wege stünde, oder irre ich mich da? --Milwaukee 08 01:14, 7. Sep. 2010 (CEST)

Schlafen gehen; morgen nochmal lesen, was ich geschrieben habe. --TMg 01:20, 7. Sep. 2010 (CEST)

Gibts auch Barrierenfreiheit für Benutzer, die mit schnippischen Antworten nichts anfangen können? --Milwaukee 08 01:32, 7. Sep. 2010 (CEST)

Ich finde es ziemlich ignorant, Leuten mit Sehschwäche die Tastenkombination zu empfehlen. Das ist auch keine Außenseitergruppe sondern so gut wie alle Menschen ab Mitte 40. Es besteht keinerlei Notwendigkeit, mit den Schriftgrößen im Text hin- und herzuspringen. Ich habe keine Lust, mir die Schriftgröße ständig zu verändern. Tabellenmonster sind nicht nur schwer lesbar, sie sind für Ungeübte auch nicht mehr editierbar. --Marcela 08:38, 7. Sep. 2010 (CEST)

Da das Argument „wenns dir zu klein ist, drück halt Strg++ und machs größer“ immer wieder genannt wird, möchte ich fürs Archiv doch noch einmal darauf eingehen, denn es beweist gar nichts.

1. Mit genau der selben Argumentation kann auch für das Gegenteil gestritten werden. „Wenn die Tabelle bei 100% nicht auf deinen Bildschirm passt, drück halt Strg+− und mach sie kleiner.“ Keine dieser Sichtweisen ist richtiger als die andere, keine ist falsch und keine beweist etwas.
2. Mit genau der selben Argumentation kann auch für 80% gestritten werden. Oder für 70%. Oder für 10%. Man kann ja jederzeit Strg++ drücken, wenn man es als zu klein empfindet.
3. „So ein Quatsch, es gibt natürlich eine Grenze“, höre ich da. Gut. Aber wo ist diese Grenze? Darauf hat jeder eine andere Antwort und jede mögliche Antwort ist willkürlich. Wenn der eine 90% sagt, sagt der andere 95% und der nächste 87,5%. Nur eine Antwort ist über allen erhaben: 100%. Punkt. Keine Diskussion.

--TMg 22:39, 7. Sep. 2010 (CEST)

„Ich finde es ziemlich ignorant, Leuten mit Sehschwäche die Tastenkombination zu empfehlen.“ Was reitest denn Du für eine Welle, Ralf 'Marcela' Roletschek? Ich gehöre altersmäßig zu dieser doch nicht "Außenseitergruppe" und mit 8,25 Dioptrien auch nicht gerade zu den Adleraugen. Und ich finde es gar nicht ignorant, sondern sehr hilfreich, wenn ich in einer halben Sekunde die Schriftgröße so anpassen kann, dass ich sie gut sehe. Also das ist kein Argument! Sehr gut dagegen finde ich die Sichtweise von TMg. Ich hab mich nie für 90% Schriften eingesetzt, sie auch nie bekämpft, sondern nur gefragt, wo das Problem liegt. Grundsätzlich nirgends aber auch, wozu dann überhaupt? Genau, dann eben nicht - OK! Weil eines ist klar: wenn es einheitlich genauso gut geht, ist das immer besser.

Ich bin noch nie über was Schriftliches darüber gestolpert und trotzden hab ich den Eindruck, die Wikiseiten schauen bei einer bestimmten Breite (Breitenbereich) am besten aus - funktioniert die Darstellung genehm. Da Bildschirme und Auflösung differieren, sind Pixel oder Zentimeter verschieden. Die Breite liegt etwa bei einer gallery mit den üblichen vier Vorschaubildern plus ein wenig mehr. Da passen die meisten Seiten und was nicht passt, wird passend gemacht - manchmal von mir. Einige Darstellungen, wie z.B. die Klade in Sauropsida wurden dazu etwas eingeschrumpft. So auch die Tabellen im Motorradsport. Aber die Beeinträchtigung durch die kleinere Schrift ist minimal, weil die Schriftgröße für den Fliesstext optimiert ist, wo viel Text auf wenig Raum steht. Aber in Tabellen und Kladen ist das Schriftbild luftiger und das Auge ermüdet nicht so schnell. Zudem ist der Unterschied zwischen einer 10pt und einer 11pt Schrift kaum merkbar. Darum sah ich auch keinen Grund, dass das Portal Motorsport jetzt alle Tabellen ändern muss, um „behindertengerecht“ zu sein. (die o.a. Gründe für 100 % stelle ich nicht in Frage).

Weil ich auch in Hagenberg bei der Behindertengruppe „Computer“ gearbeitet habe, möchte ich im Rahmen des BIENE-Projekts noch einiges anmerken. Die ±10% Debatte ist für diese Gruppe nicht relevant, da gehts um 100 % aufwärts. @ Ralf 'Marcela' Roletschek: Tabellenmonster sind nicht nur schwer lesbar, sie sind für Ungeübte auch nicht mehr editierbar. Tabellen dienen der Darstellung großer Datenmengen in kompakter und gefälliger Form wie Fußball-Weltmeisterschaft 2010/Finalrunde. Bei so einer Datendichte richtet ein IT-Spasti natur- und erfahrungsgemäß ein Chaos an. Du würdest doch auch keine Gehirnoperation von einem liebenswerten Morbus Parkinson machen lassen? Erst wenn du so einer OP zustimmst, solltest du verlangen, dass die Sporttabellen auch für Ungeübte leicht zu editieren sein sollten. Aber ob dich dann noch jemand ernst nimmt? Solange Wiki keinen Tabelleneditor auf Excel-2.86-Niveau hat, was sehr begrüssenswert wäre, muss man schon einiges Interesse und auch etwas Zeit zu üben investieren. Liebe Grüße + Volker Paix^... 05:44, 8. Sep. 2010 (CEST)

@ TMg: Öhm, genau so steht das aber seit 2007 in eurem BIENE-Projekt, Abteilung "Arbeitsgruppe Sehschwache": Sehschwache, insbesondere ältere Menschen, benötigen Skalierbarkeit der Schriften im Browser, um die Schriftgröße an ihre Sehleistung anpassen zu können. Übersetzt: Es muss die Möglichkeit bestehen, dass die Schrift per Strg++ vergrössert werden kann, wenn man sie nicht erkennt. Das gilt für 100% genau so. Es ist nirgends die Rede davon, dass sich die einzelnen Schriften in ihrer Grösse nicht prozentual voneinander unterscheiden dürfen - warum denn auch nicht? --Milwaukee 08 06:04, 8. Sep. 2010 (CEST)

Weil einzelne Artikelautoren ihren Geschmack allen Lesern aufzwingen. Aber ich wiederhole mich. Wer es nicht verstehen will, dem kann ich auch nicht helfen. --TMg 20:04, 10. Sep. 2010 (CEST)

Sag ich doch - es ist eine Geschmacksfrage und hat nichts mit Barrierenfreiheit zu tun. --Milwaukee 08 09:46, 12. Sep. 2010 (CEST)

Reaktionsgrafiken

Hallo zusammen, in der Redaktion Chemie wird inzwischen zum wiederholten Male diskutiert, wie die Grafiken von Reaktionsgleichungen sinnvoll in den Text einzubinden sind. Lange Zeit üblich war eine Einbindung in der Syntax

[[Datei:Beispiel.svg|400px|Synthese von...]]

Nach einer ausführlichen Diskussion mit Beteiligung der Redaktion Bilder wurde als neuer Standard festgelegt:

[[Datei:Beispiel.svg|rahmenlos|hochkant=2.5|Synthese von...]]

Eine Erklärung, warum die eine Variante sinnvoller als die andere sein soll, erschließt sich uns jedoch nicht, daher möchte ich hier um Hilfe und Erläuterungen dort bitten. Vielen Dank -- Mabschaaf 11:58, 14. Dez. 2010 (CET)

Wie ist es zu interpretieren, dass sich zu diesem Punkt niemand äußert? Sind hier (gerade) keine aktiven Mitarbeiter mehr, ist das Problem unverständlich beschrieben oder ist es in der Tat für die Barrierefreiheit egal, wie die Grafiken eingebunden werden? -- Mabschaaf 12:33, 22. Dez. 2010 (CET)

Nein, es ist nicht egal, nur sind hier in der Tat nicht sehr viele Mitarbeiter aktiv. Zur Sache: Mann kann für beides argumentieren, mit den jeweils selben Argumenten und sich dabei herrlich im Kreis drehen. Der Unterschied ist doch der: Mit 400px ist das Bild für jeden Benutzer immer 400 Pixel breit. Das kann eine Barriere sein, etwa wenn ein Benutzer einen sehr hoch aufgelösten Bildschirm hat, auf dem diese 400 Pixel gemessen in Zentimetern sehr klein dargestellt werden. Allerdings kann man andererseits argumentieren, dass alle modernen Webbrowser das Vergrößern von ganzen Webseiten inklusive Bilder beherrschen. Damit kann jeder Benutzer die vermeintliche Barriere der „starren Breite“ problemlos durchbrechen.

Mit rahmenlos|hochkant=2.5 wird das Bild für nicht eingeloggte und auch die meisten eingeloggten Benutzer 220px × 2,5 = 550 Pixel breit dargestellt. Also etwas größer, aber sonst ändert das im Vergleich zur festen Pixelangabe funktional erst einmal nichts. Der Zoom im Webbrowser beispielsweise verhält sich ganz genauso. Angemeldete Benutzer haben jedoch die Möglichkeit, die Standardbreite in ihren Einstellungen zu verändern. Alle Bilder in der Wikipedia, die sich an dieser Standardbreite orientieren, werden für diesen Benutzer dann entsprechend proportional größer oder kleiner dargestellt.

So. Das klingt erst einmal gut und ich persönlich würde mich immer bemühen, auf starre px-Angaben zu verzichten. Es gibt allerdings auch Benutzer, die für sich die Standardgröße auf das Maximum von 300 Pixeln erhöht haben, obwohl sie einen sehr kleinen Bildschirm haben. Sie möchten, dass alle miniatur-Bilder (thumb) schön groß dargestellt werden und nehmen den Nachteil in Kauf, dass der Text daneben kaum noch Platz hat. Bei diesen Benutzern wird ein Bild mit hochkant=2.5 nun volle 750 Pixel breit und sprengt damit möglicherweise schon den verfügbaren Platz auf dem Bildschirm. Das wäre dann eine Barriere.

Ich empfehle wie gesagt trotzdem relative Größen, weil die Vorteile diesen einen Nachteil meiner Meinung nach überwiegen. Eine Lösung, die „frei“ von Barrieren ist, gibt es nicht. --TMg 16:29, 22. Dez. 2010 (CET)

Vielen Dank für die ausführliche Antwort. Die weitere Diskussion sollte dann in der WP:RC stattfinden. -- Mabschaaf 16:54, 22. Dez. 2010 (CET)

Römische Zahlen

Wikipedia:Fragen zur Wikipedia#Römische Zahlen. Was sagt die Biene zu römischen Zahlen? Erkennen Screenreader römische Zahlen und geben diese sinnvoll aus? Kann/muss diese Erkennung unterstützt werden? Ist der Unicode-Block Zahlzeichen dazu hilfreich? Die Darstellung dieser Unicodezeichen hat auf normalen Anzeigen eher Nachteile, weil sie in der Regel dicktengleich dargestellt werden. Könnte mit einer Vorlage und CSS ein sinnvoller Kompromiss erreicht werden? --Fomafix 13:37, 24. Dez. 2010 (CET)

Folgende angaben beziehen sich auf Tests mit dem Screen´reader JAWS 8.0:

Bei der Unicode-Darstellung bekomme ich auf der Braillezeile nichts angezeigt, und die Sprachausgabe schweigt mich an. Die im Artikel Römische Zahlen verwendeten Zeichen für 5.000 und 10.000 werden ebenfalls weder angezeigt noch angesagt.

Bei der Darstellung mit "normalen" Buchstaben werden einige römische Zahlen als solche erkannt und wie normale Zahlen vorgelesen: II, III, IV, VI, VII, VIII, IX, XI bis XVIII, XX, XXX, XL, LX, LXX, LXXX und XC. "XL" lasse ich mir allerdings als X L vorlesen, da es sich um eine Kleidergröße handelt, die öfter anzutreffen ist als die römische Zahl für 40.

Einstellige römische Zahlen werden sinnvollerweise als einzelne Buchstaben vorgelesen.

Ich hoffe, Du kannst damit etwas anfangen. --Wikinger08 Diskurs? 15:33, 24. Dez. 2010 (CET)

Danke für die Tests. Da die Unicodezeichen nicht ausgegeben werden können, ist es nicht sinnvoll diese zu verwenden. Vielleicht wird sich bei den Screenreader in Zukunft irgendwann mal ändern.

Kann man die Screenreader mit zusätzlichen HTML- oder CSS-Definitionen unterstützen? Vielleicht so <abbr title="40">XL</abbr> ergibt XL. --Fomafix 16:12, 24. Dez. 2010 (CET)

<abbr>...</abbr> und <acronym>...</acronym> mit title-Attribut erzeugen zwar einen Tooltip, den man allerdings nur mit dem sogenannten JAWS-Cursor (Mauszeigersimulation) erreichen kann – leider unzuverlässig, mal geht's, mal nicht. Wenn man sich also einen WP-Artikel vorlesen lässt, merkt man nicht, dass ein Tooltip vorhanden ist. --Wikinger08 Diskurs? 14:14, 26. Dez. 2010 (CET)

Wie wäre es mit HTML und CSS nach http://hyperkontext.at/weblog/artikel/roemische-zahlen-im-web-mit-html-und-css/? :before und :after würden allerdings Änderungen an zentralen CSS-Definitionen bedingen. --Fomafix 01:16, 28. Dez. 2010 (CET)

Die dort vorgeschlagene Lösung ist ziemlich grässlich. Wozu solche wirren Verrenkungen? Man kann auch ganz pragmatisch schreiben „der Stein nennt das Jahr 1782 (als römische Zahl MDCCLXXXII)“, dann ist sogar egal, ob der Screenreader das vorlesen kann. --TMg 02:03, 28. Dez. 2010 (CET)

Ich sehe gerade, dass es längst eine Vorlage:Römische Zahl gibt. Ist diese Vorlage screenreadertauglich, oder kann sie noch verbessert werden? --Fomafix 20:10, 9. Jan. 2011 (CET)

Die Vorlage gibt <span style="display:none;">1984</span>MCMLXXXIV aus. Das ist sicher nicht Screenreader-tauglich. Es hat nur einen Vorteil: Es funktioniert in sortierbaren Tabellen. Wobei ich ehrlich gesagt nicht verstehe, warum um alles in der Welt man in einer Tabelle römische Zahlen verwenden sollte. Wir geben die Höchstgeschwindigkeit von amerikanischen Pkw ja auch nicht in Meilen an. --TMg 09:34, 10. Jan. 2011 (CET)

Die Umrechnung mittels dieser Vorlage funktioniert; es wird die römische Zahl auf der Braillezeile angezeigt und in den weiter oben genannten Fällen von der Sprachausgabe auch angesagt. --Wikinger08 Diskurs? 14:57, 10. Jan. 2011 (CET)

Klasse zum Ausblenden überflüssiger Elemente

Hallo,

ich habe mich gerade erfolglos durch die Seite gekämpft. Gibt es bereits eine CSS-Klasse, mit der man für Screenreader überflüssige und verwirrende Elemente ausblenden kann? Beispiel: Es gibt noprint für „vom Druck ausschließen“. Wenn es keine gibt, mögt ihr eine definieren? Gruß --PerfektesChaos 01:10, 14. Jul. 2011 (CEST)

Wie stellst du dir das konkret vor? Was genau sind „überflüssige und verwirrende Elemente“? Müsste man nicht eine Möglichkeit haben, zu unterscheiden, was ausgeblendet wird? Vielleicht ist es ja wichtig für manche Screenreader-Nutzer, für andere aber nicht. Was man aktuell tun kann, ist, viele Infoboxen und andere Vorlagen per CSS auszublenden, indem man ihre ID oder ihren Klassennamen in seiner Common.css verwendet. Mit vielen Elementen in den Menüs geht das auch. --TMg 01:43, 14. Jul. 2011 (CEST)

Konkret geht es um eine Aufforderung, sich eine Kamera zu nehmen und Fotos zu knipsen.

Ich kenne aber andere Projekte, in denen man etwa duplizierte Portal-Elemente durch eine Klasse per CSS ausblendet, um eine möglichst verständliche Wiedergabe durch den Screenreader zu ermöglichen. Gleichermaßen werden ausgeblendet: Bilder im Sinne von Icons oder Logos, die nur als zusätzliche optische Verstärkung einer ohnehin vorhandenen Textbotschaft dienen und keinen eigenen Informationswert haben.

VG --PerfektesChaos 02:23, 14. Jul. 2011 (CEST)

Obwohl die Anfrage schon sehr alt ist, weise ich mal auf den CSS-Klassennamen wp_boppel hin, der sich aus irgend einem Grund (Namen sind letztlich sowieso Schall und Rauch) in zahlreichen Vorlagen für nicht bedeutungstragende Icons etabliert hat. --TMg 17:30, 16. Aug. 2013 (CEST)

Inaktivität...

Hallo.

Ich habe bemerkt, dass dieses Projekt (fast) inaktiv ist. BIENE ist jedoch ein sehr nützliches Projekt und es wäre sehr schade dabei mitzusehen, wie es scheitert, weil die Entwickler entweder das Interesse daran verloren haben oder an anderen Projekten arbeiten.

Ich möchte sicherstellen, dass dieses Projekt, für Leute wie mich (mit einer rot / grün Sehschwäche) oder meine Brüder (beide haben Lernschwierigkeiten) in Zukunft immer noch verwendbar sein wird. Deshalb bitte ich jeden, der daran interessiert ist, dass das Projekt weiterhin funktioniert, mich hier oder auf en.wikipedia zu kontaktieren.

Vielen Dank für Ihre Aufmerksamkeit. Cat in the Hat (Diskussion) 23:17, 16. Mai 2012 (CEST)

Was genau hast du denn vor? --TMg 23:30, 16. Mai 2012 (CEST)

Anmelden und barrierefreiheit

Hallo. Sorry for not speaking german. I'm notifying you that I requested an accessibility improvement at Wikipedia:Administratoren/Anfragen#MediaWiki:Loginend_und_MediaWiki:Loginend-https. Grüße Dodoïste (Diskussion) 13:44, 21. Jul. 2012 (CEST)

Erledigt. --TMg 03:45, 24. Jul. 2012 (CEST)

"ReferenceTooltips" und Barrierefreiheit

Hallo, es wird gerade bei Wikipedia:Verbesserungsvorschläge#MouseOver bei Einzelnachweisen diskutiert ein tool "ReferenceTooltips" einzuführen, das Fussnoten schneller sichtbar macht. Man kann das als gadget auch in den Einstellungen deaktivieren. Wie sieht das da mit der Barrierefreiheit konkret aus? Meinungen? --Atlasowa (Diskussion) 11:19, 16. Aug. 2012 (CEST)

Wie weit darf ich ausholen? ;-) Da lassen sich unfassbar viele Nachteile aufzählen. --TMg 01:05, 13. Sep. 2012 (CEST)

Bitte versuch es mir so einfach wie möglich zu erklären ;-) Ich habe von dem Thema furchtbar wenig Ahnung. Mal so als Einstiegsfragen:

• 1) Wie hört sich ein Satz mit EN bisher an in einem Leseprogramm, wie hört er sich mit dem gadget an? (Hörbeispiel, Transkription?)
• 2) Das gadget lässt sich in den Benutzereinstellungen (Spezial:Einstellungen#mw-prefsection-gadgets) unter "Lesehilfen" deaktivieren. Ich gehe davon aus, dass die Nutzer von anderen Lesehilfen-gadgets wie "Screenreader-Optimierung" (verändert Seitenelemente, um Blinden die Wikipedia besser zugänglich zu machen) und "Rot-Grün-Sehschwäche-Helferlein" dieses nutzen können.
• 3) Wo könnte man Betroffene selbst zu ihren Erfahrungen mit Wikipedia befragen? Nicht nur zu ReferenceTooltips sondern auch allgemein oder zu anderen Sachen ("citation needed", Gestorben-Kreuz-Symbol etc.). Oder benutzt man inzwischen sowieso eher die mobile Wikipedia? Gibt es ein hochfrequentiertes Forum und/oder kompetente Stellen, wo man allgemein Erfahrungen mit Wikipedia nachfragen könnte? (Das wäre doch auch ein sehr schöner Beitrag für Wikimedium oder Kurier)

Also, schiess los :). Wenn Du mir gezielte Links (überschaubaren Umfangs) zum Thema gibst, lese ich die auch. Grüsse --Atlasowa (Diskussion) 10:21, 13. Sep. 2012 (CEST)

Ich fang mal ganz von vorn an: Barrierefreiheit geht alle an, nicht nur blinde Benutzer mit Screenreadern und Braille-Zeilen. Es gibt beispielsweise Menschen mit motorischen Behinderungen, denen es nicht möglich ist, den Mauszeiger sekundenlang still zu halten. Wie reagiert das Gadget darauf? Was passiert bei der Verwendung von Bildschirmlupen? In diesem Sinne lassen sich unzählige Situationen finden, in denen die Popups problematisch sind. Besonders offensichtliche Beispiele findet man natürlich bei Screenreader-Nutzern. Die Braille-Zeile kann nur sehr wenige Zeichen darstellen. Und vorgelesen wird immer entweder zu viel, was dann nervt, oder zu wenig, was dann fehlt. Da ein gutes Mittelmaß zu finden, sowohl durch Einstellung des Screenreaders auf Seite des Benutzers als auch durch HTML- und Skript-Optimierungen auf unserer Seite, ist ein ewiger Prozess. "Verkrüppelte" Seiten wie die Mobilversion helfen einem Blinden nichts, wahrscheinlich ist sogar das Gegenteil der Fall, weil man sich dort nicht einloggen, keine Helferlein nutzen und nichts bearbeiten kann.

Konkret zu den Popups: Screenreader-Nutzer werden davon gar nichts mitbekommen, so weit ich das überblicke. Das geht nur mit der Maus. Das ist aber nicht die einzige Benutzergruppe, die da ein Mitspracherecht haben sollte. Mich nervt z.B. das Gewackel, das entsteht, wenn man die Maus versehentlich über eine Fußnote bewegt. Das sich unabsichtlich öffnende Popup verdeckt im schlimmsten Fall genau das, was ich gerade lesen will. Und selbst, wenn nicht, lenkt es furchtbar ab. Man guckt automatisch hin, was sich da bewegt, und verliert die Zeile, die man gerade lesen wollte. Google macht so was seit kurzem auch in der rechten Fensterhälfte und es geht mir tierisch auf den Geist. Diese Kritik war offenbar massiv genug, um Google ein paar Wochen zu einer deutlichen Reduzierung dieser Spielerei zu bewegen. Die aktive Fläche wurde deutlich verkleinert und die Zeit deutlich erhöht, nach der sich da "von selbst" etwas tut. Ähnliche Bedenken habe ich auch hier. Die standardmäßigen 200ms sind deutlich zu kurz.

Ach ja, und die Schrift in den Popups ist absurd klein. --TMg 03:39, 14. Sep. 2012 (CEST)

Arbeitsgruppen

Da heißt es in der Einleitung "Verschiedene Behinderungen verlangen völlig unterschiedliche Herangehensweisen" - aufgeführt werden dann auch "Junge Benutzer" und "Senioren". Bitte Formulierung in der Einleitung dringend überarbeiten! Danke! --149.172.233.72 08:01, 16. Feb. 2013 (CET)

Bitte unterbreite konkrete Vorschläge, sonst weiß keiner, was dir an der Einleitung nicht gefällt!--Wikinger08 (Diskussion) 08:45, 19. Feb. 2013 (CET)

Das Sachthema "Behinderung" in der Wikipedia hat noch kein Portal

Ich habe erst einmal als kleine Hilfe folgende Seite angelegt: Benutzer:Wartungsstube/Behinderung. Hier tragen Bots Veränderungen automatisch ein, zum Beispiel "Neue Artikel" oder Änderungen auf den Diskussionsseiten von Artikeln in dieser Kategorie. Monatlich gibt es Zugriffsstatisten, so dass man sehen kann, wie viele Leser die häufiger gelesenen Artikel haben.

Langfristig wäre es schön, wenn es ein Portal:Behinderung gäbe, denn jeder kann mit einer Behinderung geboren werden oder später eine Behinderung erfahren. Menschen mit Behinderungen sind eine sehr große Gruppe in Deutschland. – Simplicius Hi… ho… Diderot! 14:26, 16. Aug. 2013 (CEST)

Etwas derartiges habe ich auch schon vermisst. Insbesondere sollte es eine Art von Redaktion geben, die Artikel auf Barrierefreiheit abklopft, wenn es Probleme gibt diese benennt und an die Gemeinschaft weitergibt. Beispielsweise gibt es nur sehr selten Alternativtext für Bebilderung, was Barriere für Blinde und stark sehbehinderte bedeutet. Ich glaube auch nicht, dass es viele Autoren gibt, die ihre Artikelversionen von einem Screenreaderprogramm vorlesen lassen. Für Blinde ist es schwierig, Änderungen am Layout zu machen, die nötig wären, um die Lesbarkeit mit Screenreadern zu verbessern. Die Situation für Rot-grün-Blindheit ist da besser, da dieser Personenkreis notwendige Änderungen am Artikel, etwa Änderung der Farben in Tabellen meist selber vornehmen kann. Außerdem gibt es Tools, die für nicht betroffene durch Austausch von Farben die Darstellung für Betroffene simuliert. Ein weiteres Problem ist die Benutzergruppe die "leichtes Deutsch" benötigt. Die englische Wikipedia hat ja einen Ableger "simple English", die deutsche nicht. Zu den Nutzern, die auf solche Artikel angewiesen sind oder wären, gehören Grundschüler, Personen mit eingeschränkten kognitiven Fähigkeiten, Betagte, Personen, die Medikamente nehmen müssen, Ausländer, die wenig Sprachkenntnisse haben, Unfallopfer, Schlaganfallpatienten, Demenzkranke etc. etc. Aber auch Blinde mit Screenreadern profitieren von leichter Sprache weil der Text leichter verständlich wird. Artikel der Wikipedia sollten eine Wartungskategorie haben, die von diesem Personenkreis selber vergeben wird, diese könnte auf der einen Seite beinhalten Artikel, die nicht barrierefrei sind, samt Link zu einer Bastelanleitung zur Verbesserung, zum anderen Artikel die bestimmten Kriterien der Barrierefreiheit genügen, sowas wie ein Label "approved for screenreader" oder "Artikel in leichter Sprache". Falls es sowas mal geben sollte, kann man mal den Kurier nutzen, um auf die Problematik aufmerksam zu machen und im weiteren Autorenkreis ein Problembewußtsein zu schaffen. Der Autor sollte langfristig sich daran gewöhnen ebenso wie auf neutrale Darstellung, Bequellung und Verlinkung auch auf die Barrierefreiheit zu achten, bzw. immer wieder gelegentlich dezent darauf hingewiesen werden.--Giftzwerg 88 (Diskussion) 19:33, 16. Aug. 2013 (CEST)

Alternativtext für Bilder

Ausgewachsenes Lama

Hallo allerseits,

ich beabsichtige, ab sofort (und für alle von mir begonnenen Artikel nachträglich) Bilder in Artikeln mit Alternativtexten (Alt-Text) auszustatten. Daher wüsste ich gern Folgendes:

1. Gibt es irgendwo Hinweise, wie (Art, Umfang) man Alternativtexte sinnvollerweise gestaltet?
2. Gibt es eine Möglichkeit, bereits mit Alternativtexten versehene Bilder in der Wikipedia zu finden (als Orientierungshilfe)?

Danke und schöne Grüße, --Mosmas (Diskussion) 19:28, 25. Sep. 2014 (CEST)

Da hast du dir etwas sehr löbliches vorgenommen, die wenigsten Bilder sind mit Alternativtext versehen. Grundsätzlich sollte der Alternativtext beschreiben, was auf dem Bild zu sehen ist und nicht einfach eine Überschrift sein. Ein paar Sachen dazu stehen bei https://de.wikipedia.org/wiki/Wikipedia:Barrierefreiheit#Alternativtexte_f.C3.BCr_Bilder. Leider ist das Wissen um die Bedeutung von Alternativtexten nicht sehr weit verbreitet und es fehlt auch sowas wie eine organisierte Gruppe, die z. B. regelmäßig fehlende Alternativtexte auf Artikelkandidaturen für lesenswerte oder exzellente Artikel einfordert. Man sollte eigentlich so eine Art Siegel vergeben, für Artikel, die für Screenreader optimiert sind bzw. die bestimmte Normen zur Barrierfreiheit einhalten. Diese könnte man dann in einer Wartungskategorie sammeln und könnten über die Kategorie alphabetisch abgerufen werden wie z. B. Kategorie:Wikipedia:Gesprochener Artikel. Weiterhin wäre dann zu überlegen, ob solche Texte nicht irgendwie auch direkt bei der Bilddatei bzw. auf Commons verfügbar gemacht werden können z. B. mit Hilfe von Wikidata. --Giftzwerg 88 (Diskussion) 22:11, 25. Sep. 2014 (CEST)

Danke für das ausführliche Feedback. Das Lama-Beispiel beantwortet bereits einige Fragen. Ich habe gestern mal aus "meinen" Artikeln einige Übungsbeispiele mit unterschiedlichsten Anforderungen ausgewählt und Alternativtexte ergänzt:

• Chakalaka (ein Eintopf, was ganz Profanes)
• 65537-Eck (Grafik als Illustration zu einem geometrischen Sachverhalt)
• Madura (Sprache) (ein Text-Faksimile)
• FrauenRat NRW (ein Logo)
• die daktiker (Bühnenauftritt einer Kabarettgruppe)

Ist das so OK? Schöne Grüße, --Mosmas (Diskussion) 09:34, 26. Sep. 2014 (CEST)

Und noch ein paar: Sehbehinderung, Bildschirmlesegerät, Langstock, DAISY-Hörbuch, Heilung eines Blindgeborenen. Nun etwas konkretere Fragen:

1. Ist das zu ausführlich?
2. Gibt es sprachliche Regeln, die man beachten sollte?
3. Wohin gehört das |alt= in der Wikisyntax? (Ich habe es vor den schließenden ]] eingefügt.)

Schöne Grüße, --Mosmas (Diskussion) 13:58, 26. Sep. 2014 (CEST) Grüß

Antwort zu 3: Die Reihenfolge der Parameter spielt technisch keine Rolle. Vom Gefühl her gehört für mich die sichtbare Bildunterschrift an letzter Stelle. — Raymond ^Disk. 14:14, 26. Sep. 2014 (CEST)

Ich findes es so OK, das sollten aber besser die Leser dieser Zielgruppe beurteilen. Angaben zu Farben sollte man immer machen, denn es gibt viele, die erst im Lauf des Lebens Probleme mit dem Gesichtsinn bekommen, diese profitieren besonders stark davon und das fehlt z. B. bei der Beschreibung der die daktiker. Wichtig sind Beschreibungen von taktilen Oberflächen, die mit den Füßen betreten oder ertastet werden können, Größenangaben, Relationsangaben. Beschreibungen von Gerüchen können hingegen in den allgemeinen Artikeltext, denn solche Informationen sollten für alle Menschen leicht sichtbar sein. Gut sind auch lautmalerische Beschreibungen, die gewisse Geräusche imaginieren lassen z. B. köchelnder Eintopf oder Beschreibungen, die Bewegungen oder Gesichtsausdrücke erklären. Bilder entstehen in unserem Gehirn, nicht durch die Augen, wir brauchen dazu vor allem unsere Vorstellungskraft und ein paar Detailangaben. Ich glaube für diese Zielgruppe kann ein Bild kaum zu ausführlich beschrieben werden. Es sollte allerdings im Umfang noch in Relation zum übrigen Artikeltext stehen. Bitte auch keine Links in Alternativtexten, jeder Link unterbricht im Screenreader das Satzgefüge und erschwert das Verständnis, überhaupt sollten Links in Artikeln, die für für diese Zielgruppe besonders relevant sind, möglichst auf das Minimum reduziert werden und falls möglich aus dem Fließtext rausgehalten werden und besser im Abschnitt "siehe auch" untergebracht werden.--Giftzwerg 88 (Diskussion) 19:56, 26. Sep. 2014 (CEST)

Danke für die ausführliche Antwort. Kennst du Betroffene, die man um ein Review bitten könnte? Bevor ich damit weitermache, hätte ich gern die Gewissheit, dass es in die richtige Richtung geht und die, um die es geht, auch tatsächlich davon profitieren. --Mosmas (Diskussion) 20:27, 26. Sep. 2014 (CEST)

Leider nein, die Zielgruppe ist anscheinend auch nicht irgendwie organisiert oder vernetzt, die entsprechenden Portale nicht besonders aktiv.--Giftzwerg 88 (Diskussion) 03:34, 27. Sep. 2014 (CEST)

Bei Interesse: Die Liste der bisher von mir bearbeiteten Artikel ist HIER. Momentan konzentiere ich mich auf die Artikel der Kategorien Sehbehinderung/Blindheit, in der Annahme, dass dies von besonderem Interesse ist. Und natürlich werde ich das nach und nach für alle eigenen Artikel machen. --Mosmas (Diskussion) 19:21, 27. Sep. 2014 (CEST)

Hallo Mosmas,
zunächst vielen Dank für dein lobenswertes Engagement! Deine ausführlichen Bildbeschreibungen finde ich sehr hilfreich und dienen hoffentlich auf längere Sicht als Vorbild für andere Wikipedianer, die Bilder in Artikel einbauen.

Im Artikel FrauenRat NRW musste ich allerdings die " austauschen, weil an deren Stelle " ausgegeben wird. Mit den typografischen Anführungszeichen („“) passiert das nicht. --Wikinger08 (Diskussion) 08:54, 29. Sep. 2014 (CEST)

Danke für dein positives Feedback; ich schließe mal daraus, dass es Sinn macht, so weiterzumachen.

Ich gehe davon aus, dass die Alternativtexte ausschließlich von Screenreader-Benutzern wahrgenommen werden. Das hieße, dass man diese (im Gegensatz zum übrigen Artikeltext) konsequent screenreader-optimiert gestalten kann, den u. U. damit einhergehenden Verstoß gegen gültige Wiki-Regeln fänd ich vertretbar. Ich mache mir Gedanken über folgende Aspekte (immer vor dem Hintergrund, dass die Leser nicht dümmer, sondern auf einen Screenreader angewiesen sind):

1. Satzbau: Ich verzichte bereits auf ganze Sätze, wo das den Text nur unnötig aufbläht ("Ein Schuh" statt "Das Bild zeigt einen Schuh"). Sollte man den Satzbau aber grundsätzlich vereinfachen?
2. Interpunktion: Gibt es besondere Regeln für die Interpunktion? (Verwendung von oder Verzicht auf: Semikola, Gedankenstriche, Klammern, Anführungszeichen ... Was machen Screenreader damit?)
3. Typographie: Welche Regeln gelten für die Typographie? Macht Schriftauszeichnung mit Wikisyntax irgendeinen Sinn oder soll man darauf verzichten? (Thema Anführungszeichen s. u.)
4. Inhalt: Was ist angemessen ausführlich/detailliert? (Ich tendiere zu ausführlicher Beschreibung. Warum sollte einem blinden Leser ein im Kontext interessierendes Detail verborgen bleiben, dass ein sehender mühelos auf dem Bild erkennt?)
5. Kontext: Giftzwerg08 hat weiter oben vorgeschlagen, den Alternativtext (künftig, derzeit würde das nicht unterstützt) als Attribut an die Bildquelle auf Commons zu hängen. Dagegen könnte sprechen, dass der Alternativtext nach Umfang und Detaillierungsgrad von der jeweiligen Bildunterschrift und vom Kontext des umgebenden Artikels abhängig sein kann. Inhaltliche Aspekte, die dort schon stehen, wären dann im Alternativtext redundant (Beispiel: Der Blindensturz), andere sind viellecht kontextbedingt von besonderem Interesse.

Zu deiner konkreten Anmerkung: Ich verwende die typografischen Anführungszeichen in Artikeltexten immer, habe aber in irgendeiner Diskussion gelesen, dass genau die von Screenreadern nicht richtig interpretiert würden. Was bedeutet denn, dass " ausgegeben wird. Wo passiert das, im Screenreader? (PS: und bitte weiter reviewen ;-)

Schöne Grüße, --Mosmas (Diskussion) 10:01, 29. Sep. 2014 (CEST)

Aus meiner Sicht macht es Sinn, so weiterzumachen.

Ob die Alternativtexte wirklich nur von Screenreader-Benutzern wahrgenommen werden, weiß ich grad nicht; ich dachte eigentlich, dass Mausklicker sie ebenfalls lesen können, wenn sie den Mauszeiger über das Bild bewegen. Sollte dem nicht so sein, dann „stören“ sie wenigstens keinen. Vorlage:Smiley/Wartung/:-) 

Die folgenden, nicht eingerückten Passagen stammen von dir, die eingerückten von mir:

1. Satzbau: Ich verzichte bereits auf ganze Sätze, wo das den Text nur unnötig aufbläht ("Ein Schuh" statt "Das Bild zeigt einen Schuh"). Sollte man den Satzbau aber grundsätzlich vereinfachen?

Das ist okay.

2. Interpunktion: Gibt es besondere Regeln für die Interpunktion? (Verwendung von oder Verzicht auf: Semikola, Gedankenstriche, Klammern, Anführungszeichen ... Was machen Screenreader damit?)

Satzzeichen gehören auf jeden Fall rechtschreibkonform gesetzt, sonst leidet mitunter die Verständlichkeit; zudem wird die Satzmelodie beeinflusst. Wer keine Satzzeichenansage will, stellt das im Screenreader entsprechend ein.

3. Typographie: Welche Regeln gelten für die Typographie? Macht Schriftauszeichnung mit Wikisyntax irgendeinen Sinn oder soll man darauf verzichten? (Thema Anführungszeichen s. u.)

Auf fett, kursiv etc. kann man im Alternativtext getrost verzichten. Anführungsstriche können hingegen durchaus Sinn machen.

4. Inhalt: Was ist angemessen ausführlich/detailliert? (Ich tendiere zu ausführlicher Beschreibung. Warum sollte einem blinden Leser ein im Kontext interessierendes Detail verborgen bleiben, dass ein sehender mühelos auf dem Bild erkennt?)

Ich mag’s auch gerne ausführlich. Schlussendlich ist es aber immer eine Geschmackssache, wie tief eine Beschreibung ins Detail gehen soll.

5. Kontext: Giftzwerg08 hat weiter oben vorgeschlagen, den Alternativtext (künftig, derzeit würde das nicht unterstützt) als Attribut an die Bildquelle auf Commons zu hängen. Dagegen könnte sprechen, dass der Alternativtext nach Umfang und Detaillierungsgrad von der jeweiligen Bildunterschrift und vom Kontext des umgebenden Artikels abhängig sein kann. Inhaltliche Aspekte, die dort schon stehen, wären dann im Alternativtext redundant (Beispiel: Der Blindensturz), andere sind viellecht kontextbedingt von besonderem Interesse.

Den Alternativtext in Commons zu schreiben, würde sich m. E. nicht mit der internationalen Nutzung vereinbaren lassen, denn ein Nicht-Deutschsprachiger bekäme eine Beschreibung aufgebrummt, die er nicht versteht.

Zu deiner konkreten Anmerkung: Ich verwende die typografischen Anführungszeichen in Artikeltexten immer, habe aber in irgendeiner Diskussion gelesen, dass genau die von Screenreadern nicht richtig interpretiert würden.

Mein Screenreader, JAWS, interpretiert die schon richtig; was andere Screenreader damit anstellen, weiß ich nicht.

" wird von der Sprachausgabe vorgelesen, ebenso wird es auf der Braillezeile angezeigt, wenn im Alternativtext " anstelle von „ bzw. “ eingesetzt werden.

Ich hoffe, alles verständlich dargelegt zu haben. --Wikinger08 (Diskussion) 12:03, 29. Sep. 2014 (CEST)

Die Verwendung von Alternativtexten auf Commons würde keinesfalls Einschränkungen beim Gebrauch auf der deutschen Wikipedia bedeuten. Viele Bilder wurden von deutschssprachigen Benutzern hochgeladen und haben bereits diverse Informationen über das Bild auf Deutsch, z. T. schon Erklärung über den abgebildeten Gegenstand, über die Umstände der Aufnahme, aber eben keine Bildbeschreibung und auch keine englischen Informationen. Manche Bilder werden auch mehrfach eingebaut, dann ist eine Beschreibung an zentraler Stelle leichter zu finden und es ist in jedem Fall besser, wenn es irgendwo eine Beschreibung gibt, als nirgends. Auf Commons stünden sie überdies Lesern in anderen Sprachen zur Verfügung und es ist dann von deren Sprachkenntnissen abhängig, was sie daraus machen. Entsprechend wäre es genauso mit englischen Bildbeschreibungen auf Commons. Es gibt sicherlich deutsche Leser, die damit nichts anfangen können, andere sind dankbar dass es wenigstens eine Beschreibung auf Englisch gibt. Es bleibt natürlich nach wie vor möglich und sinnvoll einen Beschreibungstext auf einen speziellen Fall zuzuschneiden. z. B. wenn ein Bild eine lebhafte Straßenszene zeigt, der Artikel aber zu einem Gebäude im Hintergrund ist. Wie wäre es aber, wenn jeder, der eine Bildbeschreibung verfasst, diese zusätzlich nach Commons kopiert? Ein einfaches Ding, aber vielleicht langfristig sehr effektiv. Beschreibungen auf Commons sind offen sichtbarer Text und nicht welcher, der im Quellcode versteckt ist und nur mit Screenreader zu nutzen. Vielleicht machen dann irgendwann die meisten Bilderhochlader schon beim Hochladen eine Bildbeschreibung. Eine Bildbeschreibung ist sehr subjektiv und was genau beschrieben wird liegt im Auge des Betrachters. Der Betrachter wählt bestimmte Details aus, ein anderer Betrachter wieder andere und als nächstes geht es um die Interpretation dieser Details und auch da können die Meinungen auseinander gehen. Die oben beschriebene Unsicherheit des Benutzers bezüglich der Bildbeschreibung rührt genau von dieser vielfältigen Sichtweise her und von den unendlichen Möglichkeiten einer Bildbeschreibung. Tausend verschiedene Benutzer bedeutet tausend verschiedene Bildbeschreibungen. Das größte Problem dabei ist, dass der Betrachter dabei meint eine objektive Beschreibung zu verfassen. Es wäre also zur Sicherung der Qualität von Bildbeschreibungen sinnvoll ein Mehraugenprinzip zu haben und auch die Benutzer von Screenreadern sollten sich regelmäßig mit ihren Bedürfnissen zu Wort melden und z. B. auf der Artikeldiskussion einen Baustein hinterlassen: Dieser Artikel enthält Bilder ohne Bildbeschreibung. Im Moment wird ein Artikel mit Bildern ohne Bildbeschreibung noch nicht als unvollständig oder mangelhaft angesehen, das sollte sich langfristig ändern.--Giftzwerg 88 (Diskussion) 13:27, 29. Sep. 2014 (CEST)

> Wie wäre es aber, wenn jeder, der eine Bildbeschreibung verfasst, diese zusätzlich nach Commons kopiert?

Würde ich sofort mit anfangen. Wie und wohin?

> Im Moment wird ein Artikel mit Bildern ohne Bildbeschreibung noch nicht als unvollständig oder mangelhaft angesehen, das sollte sich langfristig ändern.

Das sehe ich auch so.

> die Benutzer von Screenreadern sollten sich regelmäßig mit ihren Bedürfnissen zu Wort melden

Ja bitte, bitte! Sonst tappen hier ausnahmsweise mal die Sehenden im Dunkeln :-)

--Mosmas (Diskussion) 14:53, 29. Sep. 2014 (CEST)

Hochladen von Bildbeschreibung auf Commons müsste man dort anregen. Eventuell müsste man die entsprechenden Vorlagen ergänzen, das sollte machbar sein.--Giftzwerg 88 (Diskussion) 15:28, 29. Sep. 2014 (CEST)

Ich bin inzwischen zu der Überzeugung gelangt, dass ich mit meinem bisherigen Vorgehen (ausführliche Beschreibungen in den Alt-Text) auf dem Holzweg war. Ich werde damit erst mal nicht mehr weitermachen. Meine bisherigen Erkenntnisse und Überlegungen stelle ich auf dieser Seite zur Diskussion, Beispiele meiner bisher erstellten Bildbeschreibungen sind hier.

Ich habe Kontakt zu diversen Betroffenen, Experten und Verbänden aufgenommen. Wenn sich neue Aspekte ergeben, lasse ich von mir hören.

Wie machen wir jetzt weiter? Diskussion bitte auf dieser Seite weiterführen.

--Mosmas (Diskussion) 11:40, 20. Okt. 2014 (CEST)

Potenzielle Mitstreiter

Die Seite ist noch relativ neu und wird in nächster Zeit hoffentlich noch etwas bekannter werden und mehr Gehör bekommen. Dennoch fällt mir spontan jemand ein, den es sich ins Boot zu holen lohnen würde. Raymond werkelt an der Mediawiki-Software mit und könnte uns sicher gut unterstützen. Nicht in allen Skins, zum Teil aber auch im standardmäßig verwendeten Skin "Monobook" lassen sich nicht immer alle Seitenelemente eindeutig identifizieren. Dadurch wird mitunter eine bessere Anpassbarkeit per JS und CSS erschwert. Es wäre zu überlegen, ob man mal bei ihm anfragt. Wer springt euch eventuell noch so ins Auge? --CyRoXX ^(? ±) 00:18, 27. Jun. 2007 (CEST)

Entwurf Kurier

Wikipedia will Barrieren abbauen

In Zusammenarbeit mit der Aktion Mensch und der Stiftung Digitale Chancen soll die Wikipedia für Menschen mit Behinderungen besser nutzbar werden. Die Umsetzung soll möglichst alle Arten von Behinderungen berücksichtigen, ohne dem unbehinderten Benutzer Barrieren zu schaffen. Dazu wurde das Projekt Wikipedia:BIENE ins Leben gerufen.
Jeder kann mitmachen. Besonders Benutzer und Besucher der Wikipedia, die eine Behinderung haben, werden gesucht. Nur die betroffenen Personen können uns sagen, was sie behindert.
Das Projekt ist mittelfristig angelegt und wird über mehrere Monate dauern. Als Ergebnis sollen in der Wikipedia möglichst viele Barrieren abgebaut sein. Lec/RR

Mal ne Frage: Wie sieht den die Arbeit des Vereins und der Stiftung in dem Wikipedia Projekt den aus? --Mot2 06:21, 18. Sep. 2007 (CEST)

Pflichtenheft für barrierefreies Internet?

Gibt es so etwas wie einb Pflichtenheft, sprich Anforderungsprofil für ein barrierefreies WP. Es fällt in der Tat auf, das insbesondere die deutschsprachige WP sich eher konservativ an ein Print-Medium orientiert. Was konkrewt wären die (grob skizzierten) Anforderungen? Gruß --Times 22:37, 4. Jul. 2007 (CEST)

Potenzielle Mitstreiter

Als erstes sollte man vielleicht als Blinder in der Lage sein, Seiten zu bearbeiten, ohne durch diese CAPTCHAS davon abgehalten zu werden?

Hallo, wenn du selbst blind bist, dann schau doch mal im Rohentwurf der Kurzanleitung für blinde Neulinge. Außerdem findest du weitere Infos zu dieser Problematik hier und dort ebenfalls auf der dazugehörigen Diskussionsseite. Ansonsten dient dieses Projekt genau zum Abbau solcher Barrieren. Wenn bereits jetzt alles prima funktionieren würde, bräuchten wir es ja nicht mehr. -- Lalü 14:43, 25. Jul. 2007 (CEST)

Aktuelle Diskussionen in WP

Zur Kenntnis:

1. Einzelnachweise: Sollen diese in eine eigene Box innerhalb des Artikels mit eigenem Scrollbalken gesetzt werden? Hilfe_Diskussion:Einzelnachweise#Ref-Box mit CSS-Befehl overflow?
2. Verlinkte Seiten: Flash verwenden ja/nein/vielleicht: Wikipedia_Diskussion:Weblinks#flash_(etc.)_ausnahmslos_verbannen?

Grüßle, --Gnu1742 15:10, 4. Sep. 2007 (CEST)

"AxsJAX" - Library für barrierefreies Ajax

Original auf Englisch dort: http://code.google.com/p/google-axsjax/
Schnelle Übersetzung hier: „Die AJAX-Technologie hat den Web-Entwickler geholfen echtzeit Anwendungen innerhalb der Browser zu schaffen. Das AxsJAX-Framework hilft auf Barrierefreiheit bezogene Möglichkeiten in diese Anwendungen zu bringen, so dass Nutzer von Hilfmitteln wie Screenreadern and selbstsprechenden Browsern dasselbe Gefühl von Interaktivität im Web 2.0 bekommen.“
Könnte das hilflich sein? --Revolus Echo der Stille 00:26, 23. Nov. 2007 (CET)

Off-topic

Hi, dies ist nur ein kleiner Hinweis auf WP:AUS#Hilfsmittel für Sehbehinderte. Ich könnte Tipps von euch brauchen. Danke --h-stt !? 22:13, 27. Feb. 2008 (CET)

Mein Bericht

Ich werd in diesem Leben kein Blogger mehr *schwitz*. Meinen Bericht findet Ihr im Vereinsblog. Ich versuche noch ein paar Bilder zu ergänzen, hat gestern nicht mehr geklappt. --elya 08:35, 8. Mai 2008 (CEST)

Write-API

Wie auf Wikipedia:Projektneuheiten#26._August beschrieben, wurde die 'WriteAPI' scharfgeschaltet. Ich sehe darin eine Option, daß eine barrierefrei(ere) Bearbeitung/Nutzung der Wikipedia möglich wird, beispielsweise mit einem entsprechend gestalteten 'Wikipedia-Client' in Form einer StandAlone-Anwendung oder bspw. eines Eclipse-Plugins. Ich habe demnächst Urlaub, vllt. finde ich da ein wenig Zeit, mal ein kleines Java-Programm zu schreiben, mit dem die Möglichkeiten mal erforscht werden können... GUIs programmieren kann ich aber nicht ;-) --Gnu1742 09:58, 27. Aug. 2008 (CEST)

Forensoftware barrierefreier Style

Gibt es für das Burning Board - Forensoftware - einen barrierefreien Style - ? Das Forum sollte für Sehbehinderte geeinget sein. In den "Foren die sich mit Styles und Erweiterungen" beschäftigen konnte mir für leider Niemand weiterhelfen. --Frank Sonnenkind 13:51, 5. Sep. 2008 (CEST)

Wikipedia:WikiProject Check Wikipedia

Hallo, ich arbeite am Wikipedia:WikiProject Check Wikipedia um die Syntax der Wikipedia auch für Behinderte besser lesbar zu machen. Leider gibt es gerade eine Löschdiskussion, vielleicht hat ja jemand von hier Lust, dort mal aus Eurer Sicht dazu Stellung zu nehmen. Danke. -- sk 21:58, 10. Okt. 2008 (CEST)

FYI

Man könnte ihn beizeiten auch mal mit ins Boot holen, er ist wohl ausgewiesener Experte --Gnu1742 13:01, 18. Nov. 2008 (CET)

deutschsprachiges Wikipedia treffen in Barcelona

http://de.wikipedia.org/wiki/Wikipedia:Barcelona hast du zeit und Lust? --Stefanbcn 18:30, 24. Nov. 2008 (CET)

Könnt ihr da bitte mal reinschauen?

Klick!. Geht darum, ob die Verwendung des Semikolons als Überschriftersatz Probleme bei Screenreadern verursacht. Danke und Grüße, -- XenonX3 - (☎:±) 13:20, 8. Jan. 2010 (CET)

Ernie Wasson vs. WP:Fremdwortformatierung

Moin allerseits, ich möchte euch darum bitten, diese Diskussion hier mal durchzusehen und euch sodann einzumischen und euren Rat dazugeben... ;-)
Danke + Grüße, --Jocian 09:17, 12. Jan. 2010 (CET)

HTML5

Nur als kleine Gedächtnisstütze: Heise: Zwei neue Entwürfe für HTML5: Der andere neue Entwurf gehört in den Bereich Benutzbarkeit (accessibility). Er behandelt, was man bei Bildmaterial unternehmen sollte, um das Grafische auch textuell ins Dokument zu bringen. Das reicht von Tipps für die Benutzung der Attribute alt und title für das img-Element bis zu Grafiken, die Text enthalten. — Raymond ^Disk. 18:28, 28. Jun. 2010 (CEST)

Mouseover-Texte

Wikipedia:Fragen_zur_Wikipedia#Punktierte_Unterstreichung vllt für Euch interessant? lg, --Svíčková na smetaně 08:24, 27. Mai 2011 (CEST)

Studie von Aktion Mensch, 2011

Hallo, ist vielleicht für viele hier kalter Kaffee, aber dennoch für viele interessant: Web 2.0/barrierefrei. Studie von Aktion Mensch, März 2011 Da steht eine Menge zu Wikipedia drin. Grüsse --Atlasowa (Diskussion) 13:19, 6. Nov. 2012 (CET)

Treffen mit der Stiftung "Zugang für Alle" in der Schweiz

Hallo Zusammen, mein Name ist Muriel und ich bin vom Schweizer Verein Wikimedia CH. Am 5.August (um 09:00Uhr) haben wir ein gemeinsames Gespräch mit der Stiftung Zugang für Alle, um potentielle gemeinsame Vorhaben zu diskutieren. Gerne wollte ich mich bei euch erkundigen, ob jemand (aus der Schweiz?!) interessiert ist, zu diesem Gespräch dazu zu kommen (wird in Zürich stattfinden, nähe Hardbrücke)? Ich würde mich freuen. Viele Grüsse,--Muriel Staub (WMCH) (Diskussion) 10:57, 22. Jul. 2014 (CEST)

Workshop offenes Editieren in Stuttgart

Hallo! Gibt es in diesem Projekt Leute, die in der Nähe von Stuttgart wohnen? Wikipedia Stuttgart organisiert jeden zweiten Freitag des Monats einen Workshop "offenes Editieren" in der Stadtbibliothek (wenige Gehminuten vom Hauptbahnhof). Es wäre nicht schlecht, wenn das Thema Barrierefreiheit auch mal zur Sprache kommen könnte. Mehr Infos zu den monatlichen Workhops in Stuttgart findet man auf Wikipedia:Stuttgart. Der nächste Workshop findet am 10. April statt und fängt um 17 U an; man muss aber nicht pünktlich dazukommen oder die ganze Zeit bleiben. (Diese Veranstaltungen stehen auch im Veranstaltungskalender der Stadtbibliothek.) --ChristopheS (Diskussion) 18:07, 15. Mär. 2015 (CET)

Kommt ELinks Relevanz in der Überprüfung auf Barrierefreiheit zu?

Dem Artikel zum Webbrowser ELinks ist kürzlich die enzyklopädische Relevanz abgesprochen worden. Der Artikel befindet sich zur Zeit im BNR von Benutzer:Stobaios, der ihn retten möchte. Ich könnte mir vorstellen, daß ELinks in der Überprüfung auf Barrierefreiheit relevant ist. Falls im BIENE-Umfeld jemand diesbezüglich Argumente und Belege beisteuern kann, möchte ich darum bitten. MfG --178.0.95.143 22:55, 4. Okt. 2015 (CEST)

Default-Alternativtexte

Ich habe vor einem Monat auf Wikipedia:Verbesserungsvorschläge/Feature-Requests#Default-Alternativtexte einen Vorschlag zum Thema Alternativtexte zur Diskussion gestellt. Vielleicht hat hier jemand Interesse mitzudiskutieren, den Vorschlag aus Betroffenensicht einzuordnen (sinnvoll oder lieber anders / gar nicht, worauf achten) oder voranzubringen, falls er Euch sinnvoll erscheint. Meinem Verständnis nach hängt die Wahrscheinlichkeit und Art der Realisierung vom Feedback der Wikipedianutzer ab. --78.53.225.245 04:04, 6. Sep. 2016 (CEST)

Diskussion zu Artikeln in Einfacher Sprache

Ich sehe, dass das Thema kognitive Behinderungen und Einfache Sprache hier schon ein- zwei Mal angesprochen wurde. Anlässlich einer Diskussion im Kurier habe ich mal dort: Wikipedia Diskussion:Barrierefreiheit#Einfache Sprache eine Debatte angeregt, in der Hoffnung, dass sich dadurch konkrete Ideen ergeben, wie man in der deutschsprachigen Wikipedia die Zugänglichkeit für Menschen mit eingeschränkter Lesekompetenz verbessern kann. Weiter oben wurde einmal bemerkt, dass man zur Lösung dieser speziellen Problematik wenig machen könne; ich bleibe aber vorerst mal optimistisch, dass, wenn genügend kluge Leute daran arbeiten, dass sich dann auch machbare Ansätze ergeben. Ich habe den Eindruck, dass das Projekt BIENE hier ein wenig eingeschlafen ist, aber vielleicht finden sich doch noch ein paar Leute zusammen, damit wir diesbezüglich weiterkommen, denn Bedarf nach enzyklopädischen Inhalten, die auch für Menschen mit kognitiven Behinderungen zugänglich sind, scheint es ja zu geben, wenn ich mir manche der Diskussionsbeiträge hier anschaue. --Proofreader (Diskussion) 14:51, 31. Aug. 2019 (CEST)

neue Arbeitsgruppe

Wäre es möglich eine neue Arbeitsgruppe zum Thema Bildbeschreibungen für Blinde bei BIENE anzulegen? Menschen mit Sehbehinderung können in Wikipedia oftmals mit den Beschreibungen der Bilder im Kontext der Artikel nicht optimal umgehen. Das könnte man durch die Verbesserung der Alt-Texte (Maus über Bild Text) verbessern - damit wollen sich einige Wikipedianer beschäftigen und wir denken das passt gut hierher. Oder würdet ihr vorschlagen lieber ein WikiProjekt Barrierefreiheit dafür anzulegen? Vielen Dank, Conny 07:40, 4. Dez. 2020 (CET).

@Conny: Ich würde dringend dazu raten, ein eigenständiges Kategorie:Wikipedia:Internes WikiProjekt anzulegen.

• Das hat dann eigenen Kreis an Mitwirkenden, eigene Unterseiten und es ist klar worum genau es gehen soll, und es hat auch einen eigenständigen Start in 2020/21.
• BIENE ist eher ein Dach, eine jahrzehntelange Koordination und die Sammlung von Dokumenten aus der externen Welt, aber eher nichts um konkrete Einzelmaßnahmen zu bearbeiten.

Inhaltlich weise ich vorsorglich darauf hin, falls noch nicht verinnerlicht, dass Bildbeschreibungen nicht einfach nur eine Kopie der Bildlegende wären.

• Ich habe schon sehr oft alt-Parameter wieder gelöscht, die einfach nur per C&P die Bildlegende wiederholt hatten. Das bläht nur den Quelltext auf und bringt nichts, schadet sogar.
• Eine Bildbeschreibung ist typischerweise fünf- bis zehnmal so lang wie eine Bildlegende.
• Eine Bildlegende spezifiziert, welches Objekt das Bild darstellt. Eine Bildbeschreibung erläutert, was optisch zu sehen wäre.
• Nicht so ganz klar ist mir, ob alle Screenreader bei Vorhandensein beider Angaben auch beides vorlesen.
  • Wenn die Bildbeschreibung dann statt der Bildlegende vorgelesen wird, müsste diese mit enthalten sein.
  • Wenn immer beides vorgelesen wird, was ich vermute und hoffe, dann ist das sauber.
  • Umso ärgerlicher dann allerdings, wenn alt nur die Kopie der Bildlegende ist. Das kostet dann bloß Zeit, verwirrt und bringt nichts Neues.

VG --PerfektesChaos 16:14, 5. Dez. 2020 (CET)

Hallo PerfektesChaos :) , vielen Dank für die fundierte Antwort. Ich sehe es ebenso und freue mich auf weiteren Austausch dazu. Deine wertvollen Hinweise werde ich mit einbeziehen. Beste Grüße und Dank, Conny 18:06, 5. Dez. 2020 (CET).

Die ursprüngliche Idee von BIENE ist tot. Ich war bei der Stiftung Mensch von Anfang an dabei. Was da 2003 enthusiastisch begonnen hat, hat sich im Laufe der Jahre als zunehmend undurchführbar erwiesen. Bildbeschreibungen für Blinde sind nur ein ganz kleiner Baustein. Das ist für Blinde "nice to have" aber nicht existenziell. Das soll nicht heißen, daß man das nicht in Angriff nehmen sollte aber es gibt auch andere wichtige Baustellen. Um dabei einigermaßen zukunftssicher zu sein, würde ich das Ganze mit Wikidata angehen, nicht im Quelltext. Oder auf Commons als "halbgare" Lösung mit einem Parameter "Text für Blinde" oder so. Blinde haben aber aktuell in Wikipedia ganz andere Probleme. Screenreader können nur schwierig Mouseover und wenn sie es können, brauchen sie ein Mediawiki-Helferlein, um bei Fremdwörtern die Artikelvorschau aufzurufen. Zu viele Fremdwörter sind für sie schwierig zu erfassen, für Sehende sind sie ja verlinkt und kann schnell einen neuen Tab öffnen. Zu viele Anglizismen sind für Screenreader auch ein Problem, man versteht das nur schwer. Für Braille ist das aber kein Problem. Alt nur als Kopie der Bildlegende ist natürlich vollender Unfug, das stimmt. Das machten Leute früher nur für Google ;) Lange Bildbeschreibungen sind kein Problem, weder für Screenreader noch für Braille, das ist eher erstrebenswert. Aber wenn das im WP-Quelltext auftaucht, kommen sicher schnell Leute daher, die das aus Unwissen "korrigieren".

Die absolute Katastrophe für Blinde sind Referenzen und Infoboxen. Die Fußnoten machen alle Texte unleserlich. Das ist viel schlimmer als doppelte Bildbeschreibungen. Man sollte ihnen anbieten, das zu überspringen. Klappt schon manchmal, meistens jedoch nicht. Das müßte man sich mal ansehen. Wäre Mediawiki normales HTML, würde ich für Normalnutzer und Screenreader bzw. Braille verschiedene CSS ausliefern. @PerfektesChaos: ist sowas für unsereins Normalbenutzer realisierbar? Das könnte auch die Bildbeschreibungen auflösen. --M@rcela 01:50, 6. Dez. 2020 (CET)

• @ Wikidata – hat absolut nichts mit dieser Angelegenheit zu tun. Irgendwie wird das Wort „Wikidata“ immer mal wieder in die Luft geschmissen, wenn es um zentrale Datenhaltung ginge, aber Bilder haben keine Wikidata-Items.
• @ Commons – wäre als theoretischer Lösungsweg vorstellbar, ist aber nicht in Sicht.
  • Gab es vor Jahren schon mal als Vorschlag, vielleicht auch schon Phabricator-Tickets dazu.
  • Wird kaum was werden, wenn es ein paar Tausend Bildbeschreibungen für 50 Millionen Bilder gibt. Müsste schon eine Million Bildbeschreibungen sein, damit ein Entwickler andere Sachen liegenlässt und sich damit befasst.
  • Damit das vom Server bei der Seitendarstellung verarbeitet werden kann, müsste es eine „Tag-Extension“ werden. Vorlagen-Kram ist ungeeignet. Würde aussehen wie folgt: <alternatetext lang="de">…</alternatetext> und dann auf derselben Bildbeschreibungsseite für entsprechende Sprachen zu hinterlegen sein.
  • Kann dann von Bots aus dem Quelltext unserer Artikel ausgelesen, ausgeschnitten und auf der Bildbeschreibungsseite hinterlegt werden, sobald irgendwann™ so eine Extension existiert.
• @ kommen sicher schnell Leute daher, die das aus Unwissen "korrigieren"
  • Glaube ich nicht.
  • Kann immer mal passieren, aber Beobachter bekommen das mit, revertieren und klären auf.
  • Ist wie mit jedem anderen Inhalt der Artikel.
• @ Wäre Mediawiki normales HTML, würde ich für Normalnutzer und Screenreader bzw. Braille verschiedene CSS ausliefern
  • Dieser Satz ist mir völlig rätselhaft.
  • Er ergibt vorn und hinten keinerlei Sinn.
  • Mediawiki generiert normales HTML, und im strukturierten Dokument stehen alle Informationen, die unter unterschiedlichen Bedingungen (Desktop-PC, Mobilgerät, Screenreader) herausgepickt werden. „verschiedene“ braucht es nicht.
  • In sehr vielen unserer generierten HTML-Seiten sind versteckte Hinweise eingebaut, die für Blinde irrelevante Bildchen und Texte ausblenden.
  • CSS hat damit wenig zu tun. Gibt zwar einen Medientyp aural, aber der wäre hier nicht einschlägig. Es gibt nur ein HTML-Dokument, aber ggf. unterschiedliche CSS, jedoch hilft CSS hier überhaupt nicht weiter.
• Umseitig würde man eher das Bild mit den 40 Pokalen als nicht zielführend für Screenreader komplett verschwinden lassen, weil es keinen Mehrwert liefert und über nichts informiert, statt es mit einem alt= auszustatten. Wem bringt das was?
  • Auf mw: gibt es auch so ein Motivationsfoto, mit Hackathon-Teilnehmern, das keine Informationen liefert und unterdrückt wird. Desgleichen alle die Icons über den Textblöcken, weil die Icons die gleiche Botschaft tragen wie die nebenstehenden textlichen Überschriften. Geht übrigens auf mich zurück.
  • Genauso ignorieren Screenreader auf H:? die beiden grünen Rettungsringe, den neben dem Einleitungsabschnitt und den in der grünen Box. Die gibt es schlicht nicht.
• @ Warum BIENE „tot“ sein solle, nur weil es 2020 nicht mehr genauso ist wie 2003, erschließt sich mir grad nicht. Entwickelt sich halt alles weiter.

VG --PerfektesChaos 02:38, 6. Dez. 2020 (CET)

Danke für die Antworten. Alt-Text für Links, ein interessanter Punkt. Ja, leider gibt es nicht für jedes Bild einen Wikidata-Eintrag. Aber vielleicht könnte jede Bildbeschreibung ein Wikidata-Item bekommen? Andere Variante: Dem Gefühl nach ist Structured Commons dafür geeignet mit einem neuen Property Alt-Text. Pro Item könnten mehrere Sprachen dann gehalten werden und vielleicht über Vorlagen an die Bilder in Wikipedia angezeigt und letztlich in den HTML Code gelangen. Parallel zu allen Beschreibungen die dato existieren. Da es nicht im Wikiquelltext auftaucht (und mangels Wissen revertiert werden kann), rechne ich eher mit aktiven Bildbeschreibern an den entsprechenden Stellen dadurch. Wikidata wiederum würde eine Nutzung der neuen Alt-Texte auch außerhalb der Wikimedia-Wikis ermöglichen. Was denkt ihr dazu? Vielen Dank, Conny 06:08, 6. Dez. 2020 (CET).

Irgendwie bin ich absolut nicht verstanden worden.

• Nein, Wikidata hat immer noch nichts mit einzelnen Bildern zu tun.
• Wikidata ist nicht irgendwie ein Zauberwort, das man mal eben so in die Runde schmeißt, wenn man sich von irgendwoher göttliche Eingebung und das Herabfallen magischer Informationen erwartet.
• Jede Mediendatei hat seit immer schon eine Dateibeschreibungsseite, sei es auf Commons oder im lokalen Wiki. Da braucht es nicht noch ein extra Wikidata-Item um etwas abzuspeichern.

Die erforderliche Syntax ist schon seit Jahren bekannt und vorgeschlagen – auf die Dateibeschreibungsseite zum Bild wird geschrieben:

• <alternatetext lang="de">…</alternatetext>
• Derartige Elemente sind dazu geeignet, dass der Wiki-Server sie beim Abruf der das Bild einbindenden Seite in der jeweiligen menschlichen Sprache mit der Grafikdatei zusammen ausliefern kann.
• Structured Commons verwendet ähnliche Daten, hat aber inhaltlich eine andere Zielrichtung. Es geht schlicht darum, dass zu einem Bild, das bisher mit nur wenig Zusatzinformationen hinterlegt worden war, mehr Schlagwörter auftauchen, nach denen sich dann suchen lässt, um neben Kategorien noch mehr beschreibende textliche Inhalte zu bekommen, und zu Suchergebnissen mehr Infos zu liefern. Oder auch sich mit externen Datenbanken zu verknüpfen. Nur sind diese Texte nicht auf die hier benötigte optische Beschreibung ausgelegt, sondern an Sehende adressiert, und wären Material für eine erweiterte Bildlegende. Wobei witzigerweise die Software-Technologie hinter Structured Commons die identische ist wie hinter Wikidata, aber ganz anders genutzt wird. Prinzipiell könnte auch diese Datenbank für die Hinterlegung von vielsprachigem Alt-Text eingesetzt werden, aber das ist nichts worüber sich dieses Wikiprojekt einen Kopf machen sollte.
• Phabricator – Bug/Feature: 26586 beschäftigt sich schon seit 2010 mit ähnlichem; Phabricator – Bug/Feature: 63566 riss 2014 dieses Speicherproblem an. Phabricator – Bug/Feature: 245307 erörtert die Unmöglichkeit, freiwillige Gelegenheitshochlader dazu zu zwingen, zu 50 Millionen Bildern vielsprachige professionelle Bildbeschreibungen abzuliefern, und regt außerdem eine Standardmarkierung von inhaltslosen Bildern (typischerweise Icons) an.

Was den Aspekt „Alt-Text für Links, ein interessanter Punkt“ angeht, so lässt sich der trivial durch ein nicht übermäßig schwieriges JavaScript-Gadget lösen – welches nur einen massiven Netzwerk-Traffic nach sich ziehen könnte.

• Das Gadget muss nur für jedes Wikilink in der ausgelieferten HTML-Seite die PopUp-Infos abrufen.
• Es gibt eine API, die zu jeder Zielseite den PopUp-Text liefert.
• Dies muss nur vorbeugend abgerufen und an die title=-Beschreibung jeder Verlinkung angehängt werden. Dann wäre sie dem Screenreader bekannt, sobald diese Verlinkung erreicht wird.
• Nur ist das ein ziemlicher Ressourcenverbrauch. Normalerweise passiert das erst dann, wenn eine entsprechende Verlinkung erreicht wird, die Maus schwebt, und dann wird nur für diese eine Verlinkung der PopUp-Text abgerufen. Diese Abfrage pro Einzel-Link ist vom Screenreader aus jedoch schwierig. Wenn ein Mechanismus bekannt würde, wie das ausgelöst werden könnte, dann könnte auch hier für Verlinkungen einzeln On-Demand die Ergänzung nur dieses einen title= veranlasst werden. Prinzipiell könnte mit der Seitendarstellung unmittelbar nach jedem Wikilink ein HTML-Button in das HTML-Dokument eingefügt werden, über den der Einzel-Abruf und Ausstattung des vorangehenden Links gestartet werden kann, was im Erfolgsfall den Button wieder entfernt. Und alle anderen Verlinkungen identischer Zielseite auch schon mal klarmacht. Allerdings gibt es Screenreader-Konfigurationen, die JavaScript komplett blocken, und dann hilft auch ein HTML-Button nicht mehr.
• Der Server mit der API könnte über den Abruf Hunderter PopUp-Texte binnen einer Sekunde meckern. Es gibt Drosseln gegen Missbrauch durch Außenstehende; Benutzer müssten wohl beantragen Limit-Ausgenommene zu werden. Alternativ sich selbst drosseln, pro Sekunde ein Wikilink nachrüsten. Kann in die Tausende gehen, selbst wenn man Buch führt welche Linkziele bereits abgefragt wurden. 1000 Sekunden sind über eine Viertelstunde.
• Das Ganze müsste noch mit etwas Logik ausgestattet werden; geht prinzipiell mit allen Zielseiten auf WMF-Wikis, ist jedoch sinnlos bei Spezial- und Diskussionsseiten und Linkziele in einem Abfragemodus (info, history, diff, edit); auch Dateibeschreibungsseiten gingen extra. Wobei für derartige Zielseiten erklärt werden könnte, um was es bei der Spezial- oder Abfrageseite gehen würde, oder dass es eine Diskussionsseite wäre, auch in einem anderen Wiki.
• Phabricator – Bug/Feature: 220777 schlug 2019 einen anderen Weg vor mittels ARIA statt title=. Nicht erörtert wurde dort die Frage, wo denn zu den Hunderten von Verlinkungen die jeweiligen Linkbeschreibungstexte herkommen sollen, ob auch für alle sehenden Leser immer alle Beschreibungstexte in die Wiki-Seiten eingebaut werden sollen (was in nennenswerten Teilen Brandenburgs die Wikipedia flachlegen würde) oder wie dies nur für Screenreader-Benutzer ausgeliefert werden solle oder ob das pro Verlinkung erst auf Anfrage geliefert werden solle.

VG --PerfektesChaos 14:27, 6. Dez. 2020 (CET)

Einladung zum Bereich Bildbeschreibung vom WikiProjekt:Barrierefreiheit

Liebe BIENE Aktiven,
es ist vollbracht, es gibt einen ersten Entwurf zu einem Bereich vom Wikipedia:WikiProjekt Barrierefreiheit :) . Bitte findet auch eine ältere Diskussion zu BIENE auf einer alten Weiterleitungsdiskussionsseite. Vordiskussionen haben hier stattgefunden. Beste Grüße, danke für Rückmeldungen, Conny 19:30, 22. Jan. 2021 (CET).

Interessierte gesucht: Fürsorge bei Veranstaltungen

Im Community-Forum am 5.3. wurde über Sicherheit und Inklusion bei Veranstaltungen von Wikimedia Deutschland diskutiert. Ein zentrales Thema war eine gemeinsame Steuerungsgruppe aus Community-Mitgliedern und Hauptamtlichen. Es gibt jetzt eine Anlaufseite, auf der sich Interessierte eintragen können. Gesucht sind Menschen, die sich vorstellen können, Teil einer solchen Gruppe zu sein.

Mit der Entwicklung und Implementierung eines Fürsorgekonzeptes soll eine klare Haltung zu Umgang und Definition von grenzverletzendem Verhalten (sexuelle Gewalt, Diskriminierung, Rassismus, Sexismus, ..) und Sicherheit und Orientierung für all ihre Mitglieder geschaffen werden, insbesondere für von grenzverletzendem Verhalten betroffene Menschen.

Mehr Informationen zum Ziel, Hintergrund und zum zeitlichen Rahmen etc. gibt es auf dieser Seite. Bitte sehr gerne auch weiter verbreiten! --Nico (WMDE) (Diskussion) 09:28, 24. Mär. 2021 (CET)

Digital Accessibility Summit

Hallo! Vielleicht haben Beteiligte hier Interesse, am Digital Accessibility Summit teilzunehmen. Grüße, —DerHexer (Disk., Bew.) 10:57, 17. Mai 2021 (CEST)