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
Letzter Kommentar: vor 16 Jahren4 Kommentare4 Personen sind an der Diskussion beteiligt
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. --RalfR20: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. --Mot221:33, 17. Sep. 2007 (CEST)
Das kann ja durch die neue AJAX-Funktion (Vorschlagsliste im Suchfeld bei aktiviertem Javascript) als abgehakt gelten - oder? -- Hunding13:12, 4. Mai 2008 (CEST)
Der Arbeitsgruppe "junge Benutzer" ...
Letzter Kommentar: vor 16 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
... 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. --Wolli20: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. --Mot219:57, 17. Sep. 2007 (CEST)
Sehbehinderte/Sehschwache/Senioren
Letzter Kommentar: vor 16 Jahren2 Kommentare1 Person ist an der Diskussion beteiligt
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
Letzter Kommentar: vor 16 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
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. ArtMechanic18: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 Hilfe12:35, 3. Jul. 2007 (CEST)
Ist vielleicht ne blöde Frage...
Letzter Kommentar: vor 16 Jahren7 Kommentare4 Personen sind an der Diskussion beteiligt
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)
Letzter Kommentar: vor 16 Jahren5 Kommentare3 Personen sind an der Diskussion beteiligt
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)
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)
Wieviel Barrierefreiheit wäre möglich ohne artikelspezifische Änderungen?
Letzter Kommentar: vor 16 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
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. --Uwe21: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 --Xwolf23: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. --TM21:00, 17. Jul. 2007 (CEST)
Letzter Kommentar: vor 16 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
Müsste das ganz oben in der Einleitung nicht Artikel statt § sein? Ich glaube nicht, dass das austauschbar ist. --Gruß, Constructor01:40, 8. Jul. 2007 (CEST)
Letzter Kommentar: vor 16 Jahren4 Kommentare4 Personen sind an der Diskussion beteiligt
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?
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 (DTools) 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 Hilfe08: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. --TM00:39, 12. Jul. 2007 (CEST)
Eine Barriere für alle: Suche und Navigation
Letzter Kommentar: vor 16 Jahren7 Kommentare4 Personen sind an der Diskussion beteiligt
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? --TM00: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 Hilfe00: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 Hilfe00: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. --TM01: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)
Letzter Kommentar: vor 16 Jahren13 Kommentare5 Personen sind an der Diskussion beteiligt
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):
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? --TM20:52, 17. Jul. 2007 (CEST)
Seltsam, bei mir im FF2 sieht der Quelltext (genauso gekürzt) so aus:
<atitle=""><imgalt=""></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. --TM10: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. --TM11: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. --Gnu174212: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. --TM09: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. --TM10: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:
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)
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. --TM20:09, 2. Aug. 2007 (CEST)
Öffentlichkeitsarbeit
Letzter Kommentar: vor 16 Jahren6 Kommentare3 Personen sind an der Diskussion beteiligt
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. --Gnu174212: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 Hilfe12: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)
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. --Gnu174213:25, 20. Jul. 2007 (CEST)
Biene-Projekt im accessBlog
Letzter Kommentar: vor 16 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
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)
Letzter Kommentar: vor 16 Jahren4 Kommentare4 Personen sind an der Diskussion beteiligt
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? -- Hunding23: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... --Gnu174209: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
Letzter Kommentar: vor 16 Jahren5 Kommentare2 Personen sind an der Diskussion beteiligt
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. --Gnu174208:19, 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)
Letzter Kommentar: vor 16 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
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.
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.)
Letzter Kommentar: vor 16 Jahren19 Kommentare8 Personen sind an der Diskussion beteiligt
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, --elya22:20, 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. --TM09: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
// ============================================================
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><aname="Was_immer_auch_geschehen_ist_..."id="Was_immer_auch_geschehen_ist_..."></a></p><h2><spanclass="mw-headline">Was immer auch geschehen ist ...</span><spanstyle="font-size: x-small; font-weight: normal; float: none; margin-left: 0px;"class="editsection">
[<ahref="/w/index.php?title=Wikipedia_Diskussion:BIENE&action=edit&section=23"title="Abschnitt bearbeiten: Was immer auch geschehen ist ...">Bearbeiten</a>]
</span></h2>
ist, aber besser wäre es wie folgt:
<p><aname="Was_immer_auch_geschehen_ist_..."id="Was_immer_auch_geschehen_ist_..."></a></p><h2><spanclass="editsection">
[<ahref="/w/index.php?title=Wikipedia_Diskussion:BIENE&action=edit&section=23"title="Abschnitt bearbeiten: Was immer auch geschehen ist ...">Bearbeiten</a>]
</span><spanclass="mw-headline">Was immer auch geschehen ist ...</span></h2>
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)
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)
@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)
Diplomarbeit "Methoden zur Verbesserung der Zugänglichkeit von Wikis"
Letzter Kommentar: vor 16 Jahren5 Kommentare4 Personen sind an der Diskussion beteiligt
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. ––Bender23516:08, 25. Aug. 2007 (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
Letzter Kommentar: vor 16 Jahren4 Kommentare4 Personen sind an der Diskussion beteiligt
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ß --Times22:46, 19. Aug. 2007 (CEST)
Ich habe zwei Aspekte ergänzt bzw. ausformuliert. Ich hoffe, meine Erläuterungen sind nachvollziehbar. --TM11: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? --Mot219:48, 17. Sep. 2007 (CEST)
Sucht...
Letzter Kommentar: vor 16 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
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. --elya21:47, 9. Sep. 2007 (CEST)
Rot/Grün-Sehschwächen-Verbesserungsvorschlag auf Mediazilla
Letzter Kommentar: vor 16 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
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)
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
Letzter Kommentar: vor 16 Jahren13 Kommentare4 Personen sind an der Diskussion beteiligt
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 Hilfe17:52, 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 Hilfe09: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).
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)
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. — RaymondDisk.Bew.12:11, 20. Sep. 2007 (CEST)
{| 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:
Letzter Kommentar: vor 16 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
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, --Birger02:25, 1. Okt. 2007 (CEST)
Letzter Kommentar: vor 16 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
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, --Birger02: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 Hilfe10:55, 1. Okt. 2007 (CEST)
Unsichtbare Null
Letzter Kommentar: vor 16 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
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? --32X23: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. --TM22:29, 29. Nov. 2007 (CET)
Projekt noch aktiv?
Letzter Kommentar: vor 16 Jahren8 Kommentare5 Personen sind an der Diskussion beteiligt
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 --RevolusEcho der Stille00: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 ;-) --RevolusEcho der Stille00: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 ;-)
Letzter Kommentar: vor 16 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
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ß -- Yellowcard18: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. --TM22: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 Hilfe03:50, 10. Jan. 2008 (CET)
Letzter Kommentar: vor 9 Jahren5 Kommentare4 Personen sind an der Diskussion beteiligt
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--Cumtempore21: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 Hilfe03: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. :)--Cumtempore15: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 Iridos20: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
Letzter Kommentar: vor 16 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
Letzter Kommentar: vor 16 Jahren7 Kommentare5 Personen sind an der Diskussion beteiligt
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)
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)
Letzter Kommentar: vor 16 Jahren6 Kommentare4 Personen sind an der Diskussion beteiligt
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 Hilfe15: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 Hilfe16: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,
--elya22: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"
Letzter Kommentar: vor 16 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
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)
Letzter Kommentar: vor 16 Jahren11 Kommentare7 Personen sind an der Diskussion beteiligt
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. -- Uwe21: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 Hilfe22: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? -- Uwe22:13, 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 Hilfe22: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. -- AchatesYou’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 Rauenstein17:40, 2. Mai 2008 (CEST)
Interaktive Beteiligungsmöglichkeit an der Fachtagung
Letzter Kommentar: vor 16 Jahren5 Kommentare3 Personen sind an der Diskussion beteiligt
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, --elya10: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 Hilfe11: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 Hilfe15:43, 4. Mai 2008 (CEST)
Spezielle Benutzeroberfläche für Screenreader
Letzter Kommentar: vor 16 Jahren8 Kommentare3 Personen sind an der Diskussion beteiligt
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)
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
Letzter Kommentar: vor 16 Jahren4 Kommentare3 Personen sind an der Diskussion beteiligt
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. --Goldzahn00:28, 24. Mai 2008 (CEST)
Ich bin gerade dabei, die gesamte Arbeitsgruppe inklusive aller Unterseiten von "Blinde" nach "Screenreader" zu verschieben. --TM23:38, 28. Mai 2008 (CEST)
Letzter Kommentar: vor 14 Jahren3 Kommentare3 Personen sind an der Diskussion beteiligt
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. --Gnu174209: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
Letzter Kommentar: vor 15 Jahren3 Kommentare2 Personen sind an der Diskussion beteiligt
Hallo ich würde gerne die BIENE erweitert sehen zum Thema Schwerhörigkeit, Ertaubung, Spätertaubung etc...
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 Sonnenkind22: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. --TM18:09, 31. Aug. 2008 (CEST)
Letzter Kommentar: vor 15 Jahren7 Kommentare4 Personen sind an der Diskussion beteiligt
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
--Kleines21415: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 200811: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.
--Kleines21405: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 200806: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)
Letzter Kommentar: vor 15 Jahren5 Kommentare3 Personen sind an der Diskussion beteiligt
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 200810: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. --TM21: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 200822: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. --TM19:21, 4. Sep. 2008 (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)
Letzter Kommentar: vor 14 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
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 Umherirrende12: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
Letzter Kommentar: vor 13 Jahren15 Kommentare5 Personen sind an der Diskussion beteiligt
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. --TMg23: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...
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 0800: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. --TMg00: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 0801:14, 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. --Marcela08: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.
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.
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.
„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.
„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 0806: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. --TMg20:04, 10. Sep. 2010 (CEST)
Letzter Kommentar: vor 13 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
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:
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 -- Mabschaaf11: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? -- Mabschaaf12: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. --TMg16:29, 22. 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.
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 <abbrtitle="40">XL</abbr> ergibt XL. --Fomafix16: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. --Wikinger08Diskurs?14:14, 26. 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. --TMg02:03, 28. Dez. 2010 (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. --TMg09: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. --Wikinger08Diskurs?14:57, 10. Jan. 2011 (CET)
Klasse zum Ausblenden überflüssiger Elemente
Letzter Kommentar: vor 10 Jahren4 Kommentare2 Personen sind an der Diskussion beteiligt
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ß --PerfektesChaos01: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. --TMg01: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.
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. --TMg17:30, 16. Aug. 2013 (CEST)
Inaktivität...
Letzter Kommentar: vor 12 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
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.
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)
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.
Letzter Kommentar: vor 11 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
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.7208:01, 16. Feb. 2013 (CET)
Das Sachthema "Behinderung" in der Wikipedia hat noch kein Portal
Letzter Kommentar: vor 10 Jahren2 Kommentare2 Personen sind an der Diskussion beteiligt
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.
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
Letzter Kommentar: vor 9 Jahren16 Kommentare4 Personen sind an der Diskussion beteiligt
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:
Gibt es irgendwo Hinweise, wie (Art, Umfang) man Alternativtexte sinnvollerweise gestaltet?
Gibt es eine Möglichkeit, bereits mit Alternativtexten versehene Bilder in der Wikipedia zu finden (als Orientierungshilfe)?
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:
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. — RaymondDisk.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.
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):
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?
Interpunktion: Gibt es besondere Regeln für die Interpunktion? (Verwendung von oder Verzicht auf: Semikola, Gedankenstriche, Klammern, Anführungszeichen ... Was machen Screenreader damit?)
Typographie: Welche Regeln gelten für die Typographie? Macht Schriftauszeichnung mit Wikisyntax irgendeinen Sinn oder soll man darauf verzichten? (Thema Anführungszeichen s. u.)
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?)
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 ;-)
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.
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 :-)
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.
Letzter Kommentar: vor 17 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
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
Letzter Kommentar: vor 16 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
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? --Mot206:21, 18. Sep. 2007 (CEST)
Pflichtenheft für barrierefreies Internet?
Letzter Kommentar: vor 16 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
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ß --Times22:37, 4. Jul. 2007 (CEST)
Potenzielle Mitstreiter
Letzter Kommentar: vor 16 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
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
Letzter Kommentar: vor 16 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Letzter Kommentar: vor 16 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
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? --RevolusEcho der Stille00:26, 23. Nov. 2007 (CET)
Off-topic
Letzter Kommentar: vor 16 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Letzter Kommentar: vor 16 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
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. --elya08:35, 8. Mai 2008 (CEST)
Write-API
Letzter Kommentar: vor 15 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
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 ;-) --Gnu174209:58, 27. Aug. 2008 (CEST)
Forensoftware barrierefreier Style
Letzter Kommentar: vor 15 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
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 Sonnenkind13:51, 5. Sep. 2008 (CEST)
Wikipedia:WikiProject Check Wikipedia
Letzter Kommentar: vor 15 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
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. -- sk21:58, 10. Okt. 2008 (CEST)
FYI
Letzter Kommentar: vor 15 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Letzter Kommentar: vor 14 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
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)
Letzter Kommentar: vor 14 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Moin allerseits, ich möchte euch darum bitten, diese Diskussion hier mal durchzusehen und euch sodann einzumischen und euren Rat dazugeben... ;-)
Danke + Grüße, --Jocian09:17, 12. Jan. 2010 (CET)
HTML5
Letzter Kommentar: vor 14 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
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. — RaymondDisk.18:28, 28. Jun. 2010 (CEST)
Mouseover-Texte
Letzter Kommentar: vor 13 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
Treffen mit der Stiftung "Zugang für Alle" in der Schweiz
Letzter Kommentar: vor 9 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
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
Letzter Kommentar: vor 9 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
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?
Letzter Kommentar: vor 8 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
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.14322:55, 4. Okt. 2015 (CEST)
Default-Alternativtexte
Letzter Kommentar: vor 7 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
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.24504:04, 6. Sep. 2016 (CEST)
Diskussion zu Artikeln in Einfacher Sprache
Letzter Kommentar: vor 4 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
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
Letzter Kommentar: vor 3 Jahren7 Kommentare3 Personen sind an der Diskussion beteiligt
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, Conny07:40, 4. Dez. 2020 (CET).
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.
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, Conny18: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@rcela01: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.
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, Conny06: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.
Interessierte gesucht: Fürsorge bei Veranstaltungen
Letzter Kommentar: vor 3 Jahren1 Kommentar1 Person ist an der Diskussion beteiligt
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.