Wikipedia Diskussion:BIENE

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)

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)

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)

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)

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

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)

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)

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)

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)

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)

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}}.

Vorlage: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)

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)