Wikipedia Diskussion:Barrierefreiheit

Audio-Dateien

Umwandlung in Audio-Dateien'-> das wird ja wohl, so die Programme vorhanden, Clientseitig gemacht, oder? --'~' 11:54, 15. Jul 2003 (CEST)

Ja, Nerd, was hast Du Dir da wieder für ein Versteckspiel zugetan, etwa wie der Zorro hinter seiner schwarzen Maske? So viel ich weiss ja, ich habe selbst solche Programme schon mal früher verkauft, muss mal nachschlagen, wie sie heissen, klingt ein wenig blechig, wie ein Jahrmarktautomat im Wurstlprater oder der Donald Duck in der englischen Originalversion. Der grosee Nachteil, es läuft alle nur unter Windows und die meisten Sehgeschädigten lieben das grafische Windows eher weniger. Ich lese gerade, dass es eine extra SuSE-Version für Blinde gibt, ich versuche da weiter etwas zu erfahren. Auffällig viele Blinde studieren Informatik, das finde ich eigentlich sehr gut für alle Seiten! -- Ilja

Mein Eindruck ist, dass die meisten Sehgeschädigten und Blinden wie Sehende in der Mehrheit durchaus Windows benutzen, nur eben mit Vergrößerungtstools und/oder Screenreader. Wer überhaupt so weit mit dem eigenen Computer klarkommt, die Wikipedia zu erreichen, sollte in der Regel auch den Text lesen oder hören können - wenn die Wikipedia barrierefrei gestaltet ist! Das ist der wichtigere Punkt gegenüber der serverseitigen Sprachausgabe. -- Sascha Kraska 23:46, 8. Jan 2006 (CET)

summary

Für HTML-Tabellen gibt es ein Tag "summary" [1], das ungefähr niemand benutzt:

Specifies a summary of the table for speech-synthesizing/non-visual browsers

Ich finde zwar, dass es sich nicht lohnen würde, für jede Tabelle einen eigenen Zusammenfassungs-Text zu schreiben, aber man könnte ja zumindest in den Formatvorlagen einen Standardtext einbauen. Andererseits wird es einem Blinden dann auch kaum helfen, weil er ja auch nur gesagt kriegt, was er da verpasst, an die Daten kommt er trotzdem nicht ran. --Head 14:42, 4. Okt 2003 (CEST)

Wer sagt, dass er nicht ran kommt? Die Daten werden (theoretisch) hintereinander, Zeile für Zeile und Spalte für Spalte vorgelesen oder anderweitig präsentiert. Das summary-Attribut kann das Verständnis einer dadurch entstandenen Textwüste erleichtern. --Sascha Claus 21:32, 7. Dez 2004 (CET)

CSS: autsch :-(

hab mir grad mal die Startseite in Lynx angesehen, die Navigation kommt auf der 8./9. Seite, das ist nicht gerade benutzerfreundlich, hier könnte ein Blindenlink 'zur Navigation' ganz am Anfang hilfreich sein. Ralf 19:36, 5. Dez 2004 (CET)

aus sprachsynth/nahcteile übernommen.

Dieses angebliche gegenargument ist m.e. nach nicht zutreffend. Es geht um Sprachsynthese beim client, was im prinzip einem Screenreader entspricht. Daher müssen auch keine Dateien Downgeloadet werden.

• Überflüssig: Blinde erreichen den Download gar nicht erst, wenn sie keinen Screenreader benutzen, der den Wikipediatext bereits lokal synthetisch umsetzt.

Barrierefrei

hallo freunde der Barrierefreiheit! es gibt mehr, als Ihr denkt!

!diese seite hier ist NICHT barrierefrei: ich habe da gerade unter WP:KEA Layout 800x600 und bevormundende Mechanismen dazu geschrieben!

Hilfetext für blinde Neulinge

Ich bastel auf meinen Benutzerseiten grade an einem einführenden Hilfetext für blinde Neulinge in der WP. Daraus lassen sich eventuell einige mögliche Verbesserungen für Nutzer von Screenreadern entnehmen. Leider bin ich kein IT-Experte, so daß ich nicht einschätzen kann, was man mit einfachen Mitteln wie verändern könnte. -- Lalü 09:47, 24. Jun. 2007 (CEST)

Barrierefreie Lesehilfen

Sichtbare Bildunterschrift

Gibt es eigentlich eine Möglichkeit, Bilder in WP-Artikel so einzubinden, dass sie zusätzlich zu einem „normalen“ Alt-Text für eine Bildunterschrift noch einen zusätzlichen unsichtbaren Text für Lesehilfen enthalten können? -- Qhx 18:48, 6. Dez. 2009 (CET)

Ja. Seit Oktober 2008 ist es möglich, mit alt= eine zweite Bildbeschreibung nur für Screenreader und ähnliche Ausgabegeräte anzugeben. --TMg 12:10, 25. Aug. 2010 (CEST)

Barrierefreiheit von Definitionslisten als Zwischenüberschrift

Irgendwann hat mich mal jemand darauf aufmerksam gemacht, dass man kein Semikolon für Überschriften missbrauchen sollte, da diese eine Definitionsliste einleitet. Programme, die blinden oder zumindest nur eingeschräft sehkräftigen Nutzern helfen sollen, kommen damit nicht zurecht bzw. "übersetzen" falsch.

Leider kann ich das nicht so gut erklären, auch wenn ich mittlerweile schon Übung darin haben sollte, schließlich versuche ich seitdem, diese auch anderen zu erklären. Warum hat das noch niemand hier auf dieser zentralen Seite eingetragen?!?

Bitte fügt einen Passus ein, das hülfe wahnsinnig bei so mancher Diskussion! axp_de^Hallo! 14:37, 2. Apr. 2010 (CEST)

So pauschal verurteilen lässt sich das nicht. Auch die übliche Einrückung von Diskussionen mit Doppelpunkten basiert auf zweckentfremdeten, unvollständigen Definitionslisten. Für kleine Zwischenüberschriften gibt es diverse Möglichkeiten:

• Als === Überschrift === vom dritten bis sechsten Grad. Vorteil: Wäre semantisch die beste Lösung. Nachteil: Taucht im Inhaltsverzeichnis auf und macht es unübersichtlich, erzeugt also u.U. eine Barriere.
• Als '''fett''' formatierte Zeile. Nachteil: Hat semantisch so gut wie keine Bedeutung. Screenreader-Nutzer bemerken schlimmstenfalls gar nicht, dass sie eine Überschrift vor sich haben.
• Als ;Definitionsliste ist das gar nicht so verkehrt, denn das Semikolon markiert semantisch etwas, das im anschließenden Text näher definiert wird. Besser wäre zwar eine echte Überschrift, den pragmatischen Gebrauch der Definitionsliste für solche Zwecke würde ich aber nicht verbieten wollen.
• Außerdem gibt es noch spezielle |+ Kopfzeilen für Tabellen. --TMg 12:00, 25. Aug. 2010 (CEST)

Tabellen als Layoutelement

Immer wieder begegnen mir in WP Tabellen als Layoutelement (im Gegensatz zur darstellung tabellarischer Daten), beispielsweise um lange Listen in mehreren Spalten nebeneinander kompakter darzustellen. Bei zwei oder drei Spalten mag das ja noch in Ordnung sein, gelegentlich werden jedoch fünf Spalten verwendet. Der Layouter geht dabei vermutlich von seiner eigenen Fenstergröße und einer genügend hohen Auflösung aus, denn bei 1600 Pixeln Breite sieht das ganze noch gut aus (Beispiel). Bei kleineren Fenstern werden die Spalten jedoch schnell sehr schmal und es kommt zu hässlichen und unleserlichen Umbrüchen (Ähnliches passiert auch beim vom Benutzer im Browser eingestellten höheren Schriftgrößen). 1024 Pixel sind immer noch die am weitesten verbreitete Auflösung, zudem kommen kleine Netbooks, Handhelds usw. in Mode. Das Problem ist beileibe nicht neu im Webdesign und gilt als "typischer Neulingsfehler" (soll keine Beleidigung sein). In WP wird weder unter WP:Tabelle noch unter Hilfe:Tabelle darauf hingewiesen, so dass ich nie weiß, wie ich diskutieren soll bzw. worauf ich einfach verweisen kann. Die Diskussion an sich ist müßig, erfahrungsgemäß stellt sich die Erkenntnis, dass Webseiten anders als Papier funktionieren erst nach einiger Übung im Webdesign ein. Meine Frage: Gibt es eine passende Stelle in WP, auf die man in diesem Zusammenhang verweisen könnte? Gehört das Thema zudem nicht auch in besagten Tabellenartikeln und hier angesprochen? Barrierefreiheit bezieht sich ja nicht einzig auf körperlich beeinträchtigte Benutzer sondern auch auf solche, deren Teilname an Webangeboten durch technische Voraussetzungen unnötig beeinträchtigt ist. Schöne Grüße --stfn 01:35, 25. Aug. 2010 (CEST)

Solche Diskussionen zur Mehrspaltigkeit gab es häufig bei den Einzelnachweisen. Dort ist das praktisch verboten. Im Artikeltext ist das in der von mir wahrgenommenen, aktuell gelebten Praxis gelegentlich möglich, wenn es sich auf zwei bis maximal drei Spalten beschränkt (z.B. in Landkreisartikeln). Die Tabellen sind aber in jedem Fall nur als Interimslösung zu betrachten. Mit CSS3 wird das in wenigen Jahren hoffentlich technisch sauber lösbar sein. --TMg 12:18, 25. Aug. 2010 (CEST)

Neu: Wikipedia:Spaltensatz. --TMg 09:58, 20. Sep. 2010 (CEST)

Besser spät als nie: Danke! :) --stfn 14:05, 22. Feb. 2011 (CET)

Vorschlag Bedienleiste nicht vorlesen u.a.

Kopiert aus der Wikipedia:Umfragen/Wikipedia 2021, weil ich das für wichtig halte und denke, dass man mit der Realisation nicht bis 2021 warten sollte: (Diff)

Es gibt endlich eine Version der Wikipedia, die wirklich für Blinde & Sehbehinderte geeignet ist! Aus eigener Erfahrung: Wir haben hier eine USB-Braillezeile und auch JAWS-Sprachausgabe - das ist aber alles wirklich unbrauchbar. wie bereits vorgeschlagen: Ähnlich der Druckversion, gut anwählbare Kapitel, nutzbare Suchfunktion und die Bedienleiste links wird dem blinden nicht jedesmal komplett vorgelesen, bevor er seinen Artikel zu sehen bekommt. ↗ nerdi disk. 16:59, 20. Jan. 2011 (CET)

Auszeichnung fremdsprachigen Texts

Hi, die momentane Formulierung, nach der auch „einzelne Begriffe“ mit dem lang-Parameter auszuzeichnen sind, halte ich für nicht mehrheitsfähig. Wir müssen eine Balance zwischen Barrierefreiheit und den Bedürfnissen der Benutzer von Screen Readern einerseits und der Lesbarkeit des Wiki-Quelltexts andererseits hinbekommen. Mit Maria habe ich genau das Anfang des Jahres schon mal besprochen, sie kam zu der Zusammenfassung: „die Auszeichnung fremdsprachiger Passagen, sofern diese längere Wortgruppen oder ganze Sätze sind.“ Ich schlage vor, die umseitige Richtlinie dem anzupassen. Grüße --h-stt !? 13:25, 1. Jul. 2011 (CEST)

Hallo H-stt, ich denke, das könnte ein Start sein, aber m.E. ist es zu einschränkend. Ich denke, die Überlegungen aus einer anderen Stellungnahme des WP:BIENE von Benutzer:TMg sollten in die Überarbeitung mit einfliessen:

„Hier ist schlicht ein gesundes Mittelmaß gefragt, und das heißt für mich:

1. In der Einleitung werden Fremdwörter immer mit {{lang}} markiert.
2. Im weiteren Text nur, wenn es sich um selten verwendete Fachbegriffe und Ähnliches handelt, bei denen die Aussprache entscheidend zum Verständnis beiträgt.
3. Häufig verwendete Namen wie z.B. „New York“ werden außer in der Einleitung ihres eigenen Artikels nie markiert.“

– Diskussion:Ernie Wasson

M.E. sollten fremdsprachige Lemmata zuallermindest einmal im Titel und der Einleitung ausgezeichnet werden:

{{SEITENTITEL:{{lang|fr|Collectivité territoriale}}}}

Eine '''''{{lang|fr|collectivité territoriale}}''''' ([[Französische Sprache|frz.]]; vollständig ''{{lang|fr|collectivités territoriales de la République}}'', vor der Verfassungsänderung vom 28. März 2003 auch ''{{lang|fr|collectivités locales}}'') ist eine [[Körperschaft des öffentlichen Rechts]], die die [[Gebietshoheit]] auf einem räumlich abgegrenzten Teil des französischen [[Staatsgebiet]]es besitzt. Diese Hoheit umfasst auch die [[Einwohner]], wobei die wahlberechtigten Einwohner ([[Bürger]]) gesetzliche Vollmitglieder der [[Körperschaft]] sind. Die ''collectivité territoriale'' zeichnet sich durch ihre Beziehung zu einem [[Territorium]] in Form von [[Hoheitsgewalt]] im Rahmen der ihr zugewiesenen Aufgaben über alle Personen, die sich auf ihrem Gebiet aufhalten, sowie durch den [[Wohnadresse|Wohnsitz]] (bzw. Sitz bei [[Juristische Person|juristischen Personen]]) ihrer Mitglieder, welcher sich in ihrem Gebiet befindet, aus. Sie entspricht damit der deutschen [[Gebietskörperschaft (Deutschland)|Gebietskörperschaft]].

Ich selber habe auch schon die Daumenregel Die Auszeichnung fremdsprachlicher Begriffe erfolgt nur einmal beim ersten Auftreten verwendet.

Was meinen andere?

--S.K. 06:24, 4. Jul. 2011 (CEST)

Ich halte diese Version nicht für wünschenswert. Einzelne Begriffe sollten nicht ausgezeichnet werden. Vollkommen lehne ich es ab, wenn das Lemma in Form einer Vorlage in den Quelltext kommt. Das ist schlicht unverständlich für die gewaltige Masse der Wikipedia-Autoren. Um ein konkretes Gegenangebot zu machen, habe ich eine Frage: Wie genau funktioniert denn ein Screen Reader, wenn er auf ein lang-Attribut trifft? Und kann man evtl eine Kontruktion basteln, durch die IPA-Notation und lang-Attribut der Screen-Reader-Software kombiniert werden? Denn beides hat die selbe Funktion. Meine unausgereift und von keiner software-technischen Kenntnis geprägte Idee wäre es, dass auf dem Bildschirm für Leser die IPA-Notation angezeigt, aber per Screen Reader der Begriff mit lang-Attribut übermittelt wird. Ein so doppelt zugängliches Format könnte wie bisher die IPA-Notation an fremdsprachige Lemmata angehängt werden, darf sie aber natürlich nicht ersetzen. Im weiteren Artikel-Text sollte das lang-Attribut sparsam und nur für längere Wortgruppen, Sätze und noch längere fremdsprachige Anteile verwendet werden. Haltet ihr diese Kombination von IPA und lang für machbar und geeignet? Grüße --h-stt !? 12:27, 4. Jul. 2011 (CEST)

Das Frage zu IPA könnte Maria/Lecartia sicher besser beantworten, aber die Aufgabe der lang-Auszeichnung ist ja genau die Umsetzung von Buchstaben in gesprochen Sprache zu beeinflussen. IPA dagegen ist schon eine Beschreibung der Aussprache. Da ist soweit ich es einschätzen kann {{lang}} eher nicht hilfreich/möglich/notwendig.

Und wie ich oben schon geschrieben habe, halte ich gerade die Auszeichnung des Lemmas für zentral. Es charakterisiert das Thema, um das es geht. Daher sollte gerade dieses für Nutzer von Screenreadern korrekt vorgelesen werden. Die Einleitung fasst das wichtigste zu einem Artikel zusammen, ist daher das nächstwichtige und oftmals einzige was von einem Leser gelesen wird, der sich einen kurzen Überblick verschaffen will. Auch hier hilft eine Sprachauszeichnung mehr Lesern mit Screenreader als eine an übrigen Stellen.

Aber ich würde gerne noch die Einschätzungen von mehr Lesern, insbesondere Lesern die Hilfsmittel verwenden, lesen.

--S.K. 20:05, 4. Jul. 2011 (CEST)

Alternativtext für Bilder

Bildunterschrift

Tooltiptext

Der vorliegende Quelltext macht in meinem Fall bei Firefox, IE und Opera keinen Alternativtet/Tooltip. kann es sein, dass dieser bei Datei:...|miniatur|... nicht so funktioniert?--CENNOXX 17:18, 4. Okt. 2011 (CEST)

An der konkreten Umsetzung der Wiki-Syntax in alt- und title-Attribute wurde in den vergangenen Monaten einiges hin und her geändert. Aktuell ist es so, dass es Tooltips nur bei rahmenlosen Bildern gibt, die keine sichtbare Bildunterschrift haben. Bei Bildern mit miniatur (alias thumb) wäre das eine unnötige Doppelung, da der Text ja schon darunter steht. Was man bei allen Einbindungsarten kann, ist das Setzen eines Alternativtextes mit alt=. --TMg 22:38, 4. Okt. 2011 (CEST)

Animationen

Anlässlich dieser Diskussion bitte ich um weitere Meinungen über die Zulässigkeit von Animationen in Wikipedia-Artikeln. Danke und Gruß, Stefan64 (Diskussion) 15:42, 1. Apr. 2012 (CEST)

Es tut mir leid, wenn das böse klingt, aber die Barrierefreiheit dient in der dortigen Diskussion lediglich als vorgeschobenes Pseudoargument. Es hat nichts mit Barrierefreiheit zu tun, wenn man etwas aus einem Artikel löscht, weil es angeblich für Menschen mit Behinderungen nicht nutzbar wäre. Mit diesem Argument müsste man alle Bilder löschen, nicht nur diejenigen, die wackeln. Unabhängig davon ist die dort diskutierte „Animation“ (bewusst in Anführungszeichen) meiner Ansicht nach wertlos. Sie zeigt ein unbewegtes Standbild, das einmal von der einen Seite zur anderen geschoben wird. Das lässt sich genauso gut auch ohne Animation darstellen. Sogar besser, weil man den Vorgang als Ganzes überblickt. --TMg 17:06, 1. Apr. 2012 (CEST)

habe auf der Schall-Diskussionsseite geantwortet.--Fritzbruno (Diskussion) 17:21, 1. Apr. 2012 (CEST)

Barrieren melden?

Gibt es irgendsowas wie eine Redaktion oder eine Seite, bei der Artikel in Punkto Barrierefreiheit gemeledet werden können, die für eine bestimmte Benutzergrppe nicht, oder besonders schwer zugänglich ist? Gibt es vielleicht eine Taskforce, die Artikel die im besonderen Interesse dieser Gruppen stehen in dieser Hinsicht besonders unter die Lupe nimmt? Beispielsweise die Artikel in Kategorie:Blindheit.

Ich denke, dass ein Großteil der Benutzer an Barreierfreiheit nicht denkt, aber für eine Qualitätsüberwachung in dieser Hinsicht offen wäre. Einige male konnte ich z.B. bei einer Tabelle, bei der Felder rot und grün unterlegt waren durch einen kleinen Hinweis dafür sorgen, dass die damit ausgedrückten Informationen auch auf anderem Wege, als nur über die Farbe vermittelt wurden. Esm sind of Kleinigkeiten, die aber einen Unterschied machen. Für die betroffenen Gruppen würde ich mir manchmal wünschen, dass sie deutlich und bestimmt, jedoch höflich darauf hinweisen, was ein Problem im Artikel ist.--Giftzwerg 88 (Diskussion) 19:17, 4. Feb. 2013 (CET)

Ich denke, dass das auf der Diskussionsseite des betroffenen Artikels oder in der zugehörigen Fachredaktion diskutiert werden sollte. Es ist ja inhaltliche Arbeit, wenn eine Information so in den Artikel eingebaut werden soll, dass sie wie im genannten Beispiel nicht nur durch die Farbe vermittelt wird. Meiner Erfahrung nach sind sich die meisten schon etwas länger aktiven Benutzer des Problems bewusst und nehmen Hinweise dankend entgegen. Als unterstützende Diskussionsseite kommt WP:BIENE in Frage. --TMg 20:32, 4. Feb. 2013 (CET)

"Rudelfußnoten"

ich schrieb hier: da ich vorhin geschaut habe wie Public Viewing im Lemma wiedergegeben wird, stieß ich auf das passende Wort Rudelgucken, also ein eng gedrängter fanatisierter nationalistischer Mob. Da ich eng gedrängt nicht für sinnvoll erachte, mache ich auch aus ästhetischen Gründen Freizeichen zwischen Satzende und Fußnoten und auch zwischen mehreren Fußnoten. Du hast nun die Freizeichen entfernt. Gibt es eine wikipeda Vorschrift, das ein derartiges Gedränge sein muss, welches die jeweilige Fußnote ihrer Eigenständigkeit beraubt und ästhetisch dem Auge weh tut und Menschen mit Sehschwäche eventuell unnötigen Schikanen aussetzt ?

Wüßte gern eure Meinung zu der gedrängten Praxis und meiner gelockerteren Vorgehensweise.

Diskussion bitte hier

--Über-Blick (Diskussion) 09:21, 16. Jun. 2014 (CEST)

Die Schreibweise ohne Leerzeichen ist allgemein üblich. Es zeigt, dass die FN direkt zum Satz gehören. Zwei FN sind eigentlich schon viel, mehr als drei FN sind i. A. Overkill und man sollte überlegen, ob man nicht eine Quelle rauswirft oder wenn zwei Sätze mit zwei identischen Quellen vorkommen, kann man beim einen Satz die eine Quelle und beim anderen die andere angeben. Ich hatte mal mit einem Spezialisten zu tun, der hat bei jedem Wort ein oder zwei Quellen angegeben und konnte so in einem einzigen Satz vier oder mehr Fußnoten auf die selbe Quelle unterbringen. Der erste Satz in der Einleitung hatte dann so ungefähr 10 FN. Selbstverständlich hat man dabei nicht die selbe FN wiederverwendet, sondern jedesmal eine neue. Auf diese Weise bekam der Artikel eine imposant wissenschaftliche Anmutung, obwohl natürlich die Quellen das Thema nur am Rande oder sehr allgemein erwähnten. Also weniger ist oft mehr.--Giftzwerg 88 (Diskussion) 10:21, 5. Aug. 2016 (CEST)

Dieser Abschnitt kann archiviert werden. Nebenan schon lange im Archiv. --nenntmichruhigip (Diskussion) 11:51, 5. Aug. 2016 (CEST)

Default-Alternativtexte

Wird ein Bild in mehreren Artikeln eingebunden, kann es unter Umständen sinnvoll sein, je nach Kontext einen anderen Alternativtext zu haben. Dennoch wäre es sehr hilfreich, für jedes Bild zumindest einen Default-Alternativtext zu haben, denn viele Autoren tragen garnichts ein. Und wenn, würden sie sich bei mehreren Artikeln unter Umständen die Arbeit unnötigerweise mehrfach machen. Der müßte natürlich für die deutsche Wikipedia in Deutsch verfaßt sein, für die englische Wikipedia in Englisch usw. Gibt es da eine Möglichkeit, ggf. auch nachträglich, so einen Text zu einem Bild einzutragen, oder ließe sich die schaffen? --92.228.63.21 02:46, 4. Aug. 2016 (CEST)

Bisher gibt es afaik keine solche Möglichkeit, aber du könntest es mal auf WP:VV/F vorschlagen :-) --nenntmichruhigip (Diskussion) 14:52, 4. Aug. 2016 (CEST)

Danke für den Hinweis, werde ich machen.--85.181.141.97 20:23, 4. Aug. 2016 (CEST)

Hallo! hier wurde der Vorschlag archiviert - hat sich in der Sache schon etwas getan? Lg --Lpd-Lbr (d) 10:58, 9. Sep. 2019 (CEST)

Da archiviert, wohl nichts weiter.

• Auf Commons gibt es allerdings seit einigen Jahren ein Projekt, unter dem Schlagwort „Semantic“ bessere Beschreibungen der Bildinhalte bereitzustellen.
  • Einer der Verwendungszwecke wäre dann auch die Auswertung für Bildbeschreibungen.
  • Hauptziel ist es jedoch zunächst, überhaupt inhaltlich einen Bezug herzustellen, worum es denn bei diesem Bild (Medium) gehen solle.
  • Die semantischen Beschreibungen sind aber keine optische Umsetzung dessen, was man sich ohne visuelle Möglichkeiten in dem Bild vorstellen soll (in der Bildmitte ein Fachwerkhaus mit einem Obergeschoss, rotes Dach, …).
• Bis wenigstens die Semantik für Milliarden von Bildern auch nur auf Englisch zu 50 % vorläge, wird es noch Generationen dauern.
• Es soll von Anfang an jedem Bild (Medium) eine (inhaltliche) Beschreibung mitgegeben werden, seit anderthalb Jahrzehnten.
  • Nicht einmal das ist mit guter Regelmäßigkeit zu erwarten.
  • Schon der vergebene Name als Bildtitel ist kryptisch; da wird PS 7 reingeschrieben, und für den Hochlader ist klar, dass er das 7. Bild aus Pirmasens meint; könnte aber auch eine Playstation-Version, ein Patrouillenschiff, eine PostScript-Wiedergabe, Palästinensische Autonomiegebiete, irgendeine Sozialistische oder Sozialdemokratische Partei in einem weltweit agierenden Projekt meinen. Im Weltbild der Hochlader haben aber Abkürzungen ausschließlich die Bedeutung, die sie in ihrem Heimatdorf hätten.
  • Die Inhaltsangabe, was auf dem Bild zu sehen wäre, gibt es schon nicht in verständlicher Form und nicht mal auf Englisch. Und das (per Übersetzungssoftware wäre das immerhin ein Anfang) ist nichts anderes, als was in unserem Artikel als Bildlegende sowieso schon immer drunterstünde.
• Es ist kein Software-Problem, es ist ein Benutzer-Problem.
  • Es wird irgendwie auf was Grünes draufgehalten, losgeknipst, Okay Okay Okay, fertig ist der Wettbewerbsbeitrag zu Wiki Loves Earth. Wo jetzt dieser Tümpel mit zwei Bäumen sich befinden würde, ist wurscht; soll doch irgendeine Software sich aus den Geokoordinaten in den EXIF-Daten übelegen, dass dieses Foto das Naturschutzgebiet Rabensee in der Abenddämmerung zeigen würde.

LG --PerfektesChaos 12:42, 9. Sep. 2019 (CEST)

Hallo und Danke für die Antwort! Ich frage deshalb, weil ich eben bei ein paar Bildern angefangen habe, Alternativtexte zu schreiben. Da wäre es natürlich irgendwie praktisch

* schnell sehen zu können, ob das Bild in einer anderen Verwendung vielleicht schon einen Beschreibungstext hat der leicht wiederverwendbar ist

* vielleicht den gerade selbst geschriebenen Text als Bildbeschreibung verwenden zu können.

Allerdings scheint es, als ob die Bildbeschreibung auf commons nicht das gleiche tun soll wie der Alternativtext. Und ehrlich gesagt blicke ich nicht durch, warum es für Bilder sowohl eine Beschreibungsseite auf commons und auf de gibt. Ich hätte ansonsten überlegt, einfach einen meiner Alternativtexte dort einzufügen. --Lpd-Lbr (d) 14:48, 9. Sep. 2019 (CEST)

Erstmal müssen wir dann wohl den Begriff „Beschreibungstext“ klären:

1. Inhaltliche Erläuterung, was auf dem Bild dargestellt wird; etwa „Baudenkmal Bahnhofstraße in Dingenskirchen“.
2. Wiedergabe des optischen Inhalts für Menschen ohne visuellen Zugang („Alternativtext“): „In der Bildmitte ein Fachwerkhaus mit einem Obergeschoss, darüber zeigt ein Dachgiebel mit einem Fenster zur Straße, rotes mit Ziegeln gedecktes Dach, …“

Für den zweiten Fall gibt es meines Wissens bislang nirgendwo abrufbare Textdaten. Das war aber mal der Kern des von dir zitierten archivierten Vorschlags gewesen.

Zu einer Mediendatei, die auf Commons liegt, wird hier lokal und virtuell der Inhalt wiedergegeben, falls du dir hier bei uns die Dateibeschreibungsseite anzeigen lässt.

Auf Commons wird die globale Dateiverwendung aufgelistet; du könntest gucken, wer dieselbe Datei in deutschsprachigen Projekten einbinden würde. Hier bei uns kannst du dir ansehen, welche Seiten das Bild einbinden würden, wenn du von der Dateibeschreibungsseite aus die „Links auf diese Seite“ anklickst.

Insgesamt gibt es zu rund 0,000000001 % der Bilder Alternativtexte; du kannst, wenn du nicht sofort fündig wirst, davon ausgehen, dass es keinen Alternativtext gibt, nirgends.

LG --PerfektesChaos 15:11, 9. Sep. 2019 (CEST)

Ah, ja, da ist mir einmal ein "Beschreibungstext" reingerutscht, wo "Alternativtext" gemeint war. Ja, ich weiß nicht ob das nicht auch ein wünschenswertes Tool wäre: Bei der Bildverwendung auch gleich alle anderen Informationen der Bildverwendung anzeigen zu lassen, also Bildgröße, aber eben auch den Alternativtext. Vielleicht ist so ein Vorschlag schmackhafter für Leute, die das umsetzen können.

PS: Vielleicht nebenbei: mache ich es richtig? [2] [3] [4] --Lpd-Lbr (d) 15:18, 9. Sep. 2019 (CEST)

Was deine Bearbeitungen angeht, so hatte ich da vorhin schon mal reingeguckt gehabt; die passten schon so.

Es gibt zurzeit in den Wikiprojekten extrem wenigst Alternativtexte, somit geringe Rezeption, und somit auch wenig Motivation bei der weltweiten Entwicklergemeinde, sowas softwareseitig zu unterstützen.

commons:Commons:Depicts/de ist das, was geplant und aktuell unterstützt wird; das ist aber eine durch Maschinen auswertbare zusätzliche Bildbeschreibung und setzt Verlinkungen mit Eigenschaften der dargestellten Objekte.

Eine zentrale Unterstützung für nicht-visuelle Beschreibungen sehe ich nirgendwo in konkreter Planung.

LG --PerfektesChaos 16:02, 9. Sep. 2019 (CEST)

@PerfektesChaos „Insgesamt gibt es zu rund 0,000000001 % der Bilder Alternativtexte“ -- Wo finde ich die Quelle zu dieser Aussage?

Wie sieht das eigentlich mit Symbolen, Logos, Flaggen aus? Bringt es Sinn bei Listen, z.B. aus dem Themenkreis Sport, da bei jedem Wappen einen Alternativtext anzulegen? --Klaus-Peter 08:45, 28. Sep. 2019 (CEST)

Les-/Bearbeitbarkeit des Quelltextes

Diese Seite beschreibt ausführlich, was die Lesbarkeit der Artikel auch für Menschen mit eingeschränkter Sehfähigkeit erhöht. Leider wird kein Wort darüber verloren, dass wikipedia nicht nur Wissen für die gesamte Menschheit leicht zur Verfügung stellen will, sondern auch allen Menschen die Möglichkeit gegen will, Wissen zur Verfügung zu stellen. Nicht jeder kann oder will den "visuellen editor" benutzen, daher ist mir persönlich auch die gute Les- bzw. Bearbeitbarkeit des Quelltextes wichtig. Dabei lege ich besonderen Wert darauf, alle Elemente des Quelltextes durch Leerzeilen zu trennen, also insb. Überschriften, Fließtext, Vorlageneinbindungen, Tabellen, Bilder usw. Dieses wird leider immer wieder durch engstirnige Benutzer torpediert, die mit dem Verweis auf "gibt kein Konsens" die Leerzeilen wieder löschen. Wie seht ihr das unter dem Gesichtspunkt der Barrierefreiheit? axp_de^Hallo! 13:01, 14. Apr. 2017 (CEST)

Eine Meinung würde mich auch interessieren. Du verbringst viel Zeit und Arbeit damit, in etlichen Artikeln Dinge zu ändern, die ich für rein geschmackliche (und damit nach unseren Regeln für eher zu vermeidende!) Änderungen halte und behauptest fast jedes Mal, sie würden zu Barrierefreiheit beitragen. Wikipedia:Wie_gute_Artikel_aussehen#Quelltext sagt ausdrücklich, dass Edits etwa wie das Einfügen/Entfernen von Leerezeilen im Quelltext nach Überschriften zu unterlassen sind! Ein gegenteiliger Konsens ist mir nicht bekannt.
Heftig Stirnrunzeln muss ich bei Änderungen wie [5], wo es klare Regelungen gegen die Zeilenumbrüche in der Referenz gibt, siehe Vorlage:Internetquelle bzw. Vorlage:Literatur#Kopiervorlagen'

PS: Dringend abraten möchte ich Dir auch davon, nachträglich geschützte Leerzeichen in Datumsangaben einzufügen. Siehe Wikipedia:Datumskonventionen: Es besteht zurzeit keine Einigung darüber, ob in Datumsangaben geschützte Leerzeichen verwendet werden sollten (bessere Lesbarkeit des Artikels) oder nicht (einfachere Handhabung des Quelltextes). Also Änderungen bitte vermeiden.
Und wenn Du hier das Primat auf lesbaren Quelltext liest, steht doch genau das den geschützten Leerzeichen in Datumsangaben entgegen; dafür sprächen allenfalls andere (m.E. nicht so schwerwiegende) Gründe. --Global Fish (Diskussion) 08:02, 15. Apr. 2017 (CEST)

Kleines, zugegebenermaßen arg konstruiertes Beispiel, warum ich in diesem einen Punkt die bessere Lesbarkeit des Quelltextes hintanstelle:

Seine Mutter wurde kurz nach Beginn des zweiten Weltkrieges geboren, ihre Kindheit war eine sehr harte Zeit. Daher ist für Andreas der 2.
Dezember ein Ehrentag.

"Andreas der 2." ;-) axp_de^Hallo! 09:55, 15. Apr. 2017 (CEST)

Dass in speziellen Fällen geschützte LZ Missverständnisse vermeiden können, steht außer Frage. Es geht aber um das standardmäßige Einfügen in Datumsangaben und dafür, nein, gibt es keinen Konsens.
Hat aber wenig mit dem Thema dieser Seite hier zu tun. Was mich und Dich hier interessiert ist die Frage, ob Leerzeilen nach Überschriften (für oder gegen die es, notabene, erwiesenermaßen auch keinen Wiki-weiten Konsens gibt) aus Sicht der Barrierefreiheit sinnvoll oder egal sind. --Global Fish (Diskussion) 11:50, 15. Apr. 2017 (CEST)

Stimmt genau. Was mich an der Diskussion pro/contra "Leerzeile nach Überschrift" so stört, ist das Nichtvorhandensein von Gegengründen. Ich habe nun schon wirklich vielfach meinen (Beweg)Grund genannt, aber die Gegner der Leerzeile verweisen immer nur darauf, "es gäbe keinen Konsens". Ich weiß nicht wie Ihr das seht, aber m.E. ist das kein Grund, sondern nur eine Ausrede, alles wieder zu revertieren. Worin bitte besteht ein Vorteil darin, die Leerzeile wegzulassen (ausser Speicherplatz ...)? So, und nun schöne Ostertage axp_de^Hallo! 12:51, 15. Apr. 2017 (CEST)

Nochmal: dass es keinen Konsens gibt, und Änderungen wie das Einfügen oder Entfernen von Leerzeilen nach Überschriften möglichst (es sei denn, zur Vereinheitlichung innerhalb eines Artikels) zu unterlassen sind, ist explizit festgehalten. Und insofern halte ich Deine jüngsten Äußerungen auf der Diskussion von @Störfix [6] nicht nur vom Tonfall sondern auch inhaltlich für nicht zielführend.
Rein subjektiv mag man es mit Leerzeile besser finden als ohne, tue ich ja auch. Aber das ist subjektiv. Und wenn Du fragst: Worin bitte besteht ein Vorteil darin, die Leerzeile wegzulassen kann man sich genauso fragen: Worin bitte besteht ein Vorteil darin, die Leerzeile zu setzen?
Du behauptest, es würde zur Barrierefreiheit beitragen. Aber solange diese Behauptung nicht durch entsprechende Expertenmeinungen unterfüttert wird, ist es eine rein subjektive Meinungsäußerung genau wie "sieht besser aus" o.ä.
Insofern würde ich mich über Meinungen von Dritter Seite freuen.--Global Fish (Diskussion) 13:34, 15. Apr. 2017 (CEST)

Mein Argument ist eben *nicht* "sieht besser aus" - was auch immer mit "besser" damit gemeint ist.

Mein Argument ist die bessere Erfassbarbeit der Überschrift als solche, und das ist auch nicht meine singläre Meinung, dies wurde mir mehrfach (auch dies habe ich nun schon mehrfach an verschiedensten Stellen gesagt) auf diversen Stammtischen sowie der WikiCon gerade von älteren oder in der Sehfähigkeit beeinträchtigten Benutzern bestätigt, die sich darüber beklagten, dass es für sie zunehmend schwieriger werde, die Quelltexte zu bearbeiten.

Aber auch ich möchte weitere Meinungen hören, daher habe ich das hier angesprochen, aber bislang hast nur Du dazu Deine Meinung geäussert, die ich natürlich schon vorher kannte und mir insofern keine neuen Erkenntnisse bringt :-(

Bitte, bitte, weitere Meinungen! axp_de^Hallo! 13:56, 15. Apr. 2017 (CEST)

Hilfe_Diskussion:Bilder#Einbindung_von_Panoramabildern

Ich bitte um Beteiligung von Drittmeinungen zum Thema der Panoramabilder, insbesondere unter dem Gesichtspunkt der Vereinheitlichung und unter dem Gesichtspunkt der Barrierefreiheit. Es gibt derzeit mehrere Möglichkeiten, Panoramabilder einzubinden. Eine Möglichkeit ist die Einbindung des Bildes mit einer speziellen Vorlage, der als Parameter die Bildbreite übergeben werden kann. Sobald diese Breite ca. 800px übersteigt wird im Bild ein Scrollbalken erzeugt, der generell nicht wirklich zielführend ist und ein Problem für die Barrierefreiheit schafft. -- Alabasterstein (Diskussion) 11:18, 2. Nov. 2018 (CET)

Einfache Sprache

Bislang wird hier praktisch ausschließlich auf Barrieren von Menschen mit körperlichen Behinderungen eingegangen. Anlässlich einer Diskussion im Kurier möchte ich aber einmal den Blick auf Barrieren beispielweise bei Menschen mit eingeschränkter Lesekompetenz richten. Spontan hatte ich in der entsprechenden Diskussion angeregt, eine eigene Sprachversion in Einfacher Sprache analog zur Simple-English-Wikipedia einzurichten, bin aber darauf hingewiesen worden, dass entsprechende Versuche auf Meta abgewiesen wurden, da das offenbar nicht der aktuellen Wikimedia-Policy entspricht, wobei zugleich betont wurde: "We strongly encourage existing projects to make provisions to include simple content" (wie es auch der Accessibility-Guideline entspricht). Die Frage wäre nun, wie solche Vorkehrungen aussehen könnten. Wenn also keine eigene Sprachversion möglich ist, was wären die Alternativen? --Proofreader (Diskussion) 14:30, 31. Aug. 2019 (CEST)

Einschlägig und praktisch seit immer ist Wikipedia:Allgemeinverständlichkeit.

Nicht explizit steht an dieser Stelle, aber gute Praxis ist außerdem: Je dichter das Thema des Artikels am Grundwissen, Alltagswissen, Schulwissen ist, desto ausgedehntere Teile des Artikels müssen allgemeinverständlich sein.

• Bei einem komplexen Fachthema kann ich vielleicht gerade mal dem Einleitungsabschnitt entnehmen, um welche Thematik es so grob geht.
• Was zum Wissen von Schulkindern gehört, muss auch entsprechend einfach dargestellt werden; und wenn das in der Grundschule verständlich erklärt werden kann, dann müssen wir das auch hinbekommen.
• Ein Artikel über Gänseblümchen oder sowas muss über weite Teile allgemeinverständlich sein, darf aber durchaus wissenschaftliche komplexe vertiefende Forschungsergebnisse über Genetik oder Biochemie usw. enthalten, die dann halt überspringen werden können, wenn außerhalb des Interesses liegend.
• Ein Artikel über das Reimschema altgriechischer Liebeslyrik, Biochemie bestimmter Verdauungsenzyme von Regenwürmern oder subatomarer kernphysikalischer teilchenartiger Gebilde wird seiner Natur nach sehr viel Vorkenntnisse bedürfen, die im Artikel schlicht nicht mehr geliefert werden können. Wenigstens sollte dann aus dem Einleitungsabschnitt hervorgehen, in welcher Liga das spielt.
• Ein Artikel über eine Stadt, einen Berg oder sowas muss immer über weite Strecken allgemeinverständlich sein. Auch hier kann es aber vorkommen, dass die kriegerischen Ereignisse der 17. Pingpong-Dynastie für die Stadtgeschichte als bekannt vorausgesetzt werden, oder die Schwierigkeitsgrade von bestimmten Kletterpfaden nur verlinkt sind. Da muss dann eben den Verlinkungen gefolgt werden, falls das näher interessieren sollte.

VG --PerfektesChaos 16:03, 31. Aug. 2019 (CEST)

Hm, zu Punkt 2 von PerfektesChaos: das Alltagswissen und das Bedürfnis danach, mehr davon zu verstehen, ist Wandlungen unterworfen. Beispielsweise bezüglich Themen im Zusmmenhang mit dem Klimawandel (aktuell) oder astronomische Zusammenhänge, abzulesen an zahlreichen Dokus, die Fragestellungen dazu im Fokus haben. Da diese Wandlungen nicht vorhersehbar sind, sollten alle unsere Artikel, sofern keine Trennung zwischen Fach- und Allgemeinenzyklopädie vorgenommen wird, eine Einleitung aufweisen, die das Thema allgemeinverständlich beschreibt (was ist es), wo ist es verankert, welche Grundlagen sind zum Verständnis notwendig (worauf baut es auf) und Fachbegriffe, die für das weitere Verständnis des Artikels notwendig sind, erläutert, um dem fachfremden Leser (damit meine ich nicht mal lernbehinderte, bildungsbenachteiligte BürgerInnen - das ist noch mal ein ganz andere relevante Baustelle), einen Zugang zum Artikel zu eröffnen. Es kann, darf (m.E) ja nicht sein, dass Texte nur dem verständlich sind, der sie im Endeffekt nicht benötigt, da er auf Grund seiner Ausbildung genug davon verstanden hat.--Belladonna Elixierschmiede 21:38, 31. Aug. 2019 (CEST)

Hallo @Proofreader:, danke für das Anstoßen dieser Debatte. Vielleicht ist es sinnvoll, mal die WMF darauf anzusprechen, dass sie ihre Richtlinie überdenken sollte. Allerdings stellt sich dann die Frage, welches Konzept hinter der "einfachen Sprache" stecken soll, und wer die Zielgruppe sein soll. Es ist ja ein Problem, dass die Simple English Wikipedia sich an drei verschiedene Zielgruppen wendet: Kinder, Menschen mit geistigen Einschränkungen und Sprachausländer. Alle haben unterschiedliche Bedürfnisse, und es gibt Untergruppen: Die Menschen mit geistigen Einschränkungen etwa können eine Lese-Rechtschreib-Schwäche oder aber einen niedrigen IQ haben. Wir können ja nicht für jedes Individuum eine eigene Wikipedia machen, aber man sollte sich wenigstens für eine der drei großen Gruppen entscheiden. (Das Klexikon richtet sich ja an eine der drei Gruppen, an Kinder. Ein neues Wiki in Leichter Sprache würde sich an die Menschen mit niedrigem IQ wenden.)

Man muss sich aber nicht für eine der drei Gruppen entscheiden, sondern gründet eine neue Wiki-Enzyklopädie in einfacher Sprache für die Allgemeinheit. Die bisherige Wikipedia darf sich dann gern weiterhin in Richtung Fachenzyklopädie entwickeln. (Oder umgekehrt: Die bisherige Wikipedia unter großen Mühen auf Verständlichkeit umschreiben und dafür ein neues Wiki wie "Wikipedia Scholar" gründen.)

Ich hielte es für interessant, dass eine neue Wikipedia in einfacher Sprache entsteht. Man könnte sie "Wikipedia Basics" nennen. Sie müsste gar keine Millionen Artikel haben: 10.000 wären schon absolut ausreichend für eine nützliche Enzyklopädie. Natürlich müssen die gut ausgewählt sein (nicht: 2500 über Eisenbahnlinien, 2500 über Sterne, 2500 über Städte in Ungarn und 2500 über Fußballspieler).

Eine Schwierigkeit bestünde darin, dass tatsächlich in einfacher Sprache geschrieben wird. Leider haben so manche Wikipedianer die Haltung: Ich will über mein Hobby schreiben, die Leser sollen sich halt an mich anpassen. Einer der ersten Schritte wäre also die Verständigung auf ein Konzept, bei dem man

1. die Zielgruppe etwas besser als bisher umschreibt: Menschen ab 12 Jahren, mit Alltagswissen, aber ohne "Allgemeinbildung" und ohne Fachkenntnisse. Mit deutscher Muttersprache, mehrjähriger Zweitsprache oder guter Fremdsprache, mit Niveau B1/B2 (nicht C1/C2).
2. die Sprachform umreißt.
3. einen sozialen Mechanismus einführt, der es wahrscheinlicher macht, dass das Konzept wirklich umgesetzt wird - etwa Mindestanforderungen und bestimmte Feedback-Möglichkeiten.
4. den Bezug zur Wikipedia verdeutlicht: Teil der Wikipedia, neues Wikimedia-Wiki, Branding?

Besten Gruß Ziko (Diskussion) 23:14, 31. Aug. 2019 (CEST)

Ein Argument, das gegen eine eigene Sprachversion in Einfacher Sprache hervorgebracht wurde, war, dass nicht klar sei, was genau man denn damit meint, denn anders als beim Simple English gäbe es dafür kein genormtes Regelwerk, keine Wörterbücher, etc. Unbestritten ist aber, dass Einfache Sprache bereits heute verwendet wird, etwa wenn Vorträge oder Fernsehsendungen in Einfacher Sprache wiedergegeben oder untertitelt werden. Wenn wir Leute einbinden könnten, die Einfache Sprache bereits heute anwenden, wäre das sicher hilfreich, denn die könnten mit am besten einschätzen, was zielgruppengerecht ist. Wir müssten uns halt überlegen, wie wir das technisch umsetzen könnten. Mein Vorschlag einer eigenen Sprachversion wäre halt am einfachsten gewesen: Man hätte weiterhin die bisherige de-Version, in der man weiter auch hochkomplexe Sachverhalte in entsprechender Fachsprache wiedergeben könnte und daneben eine Sprachversion in Einfacher Sprache, die unvermeidlicherweise eine etwas geringere Informationsdichte hat, die aber Personen mit eingeschränkter Lesekompetenz dennoch eine vollwertige Enzyklopädie bieten würde. Wenn das nicht geht und beides quasi in eine Sprachversion gepackt werden muss, wird es schwierig, beidem gerecht zu werden. Dann müsste man vielleicht an sowas denken wie ein- oder ausklappbare Passagen o.ä., sodass man eine Grundversion eines Artikels hat, die auch für eingeschränkte Personen vertständlich ist, und dann eine detailliertere Version für die anderen. Wie gesagt, mein Anliegen war halt, etwas Brainstorming anzuregen, wie man sowas umsetzen könnte. Komme zwar selbst auch aus dem Behinderten-Selbsthilfebereich (Autismus), aber ich muss zugeben, dass speziell kognitive Einschränkungen nicht wirklich meine Expertise sind. --Proofreader (Diskussion) 10:05, 1. Sep. 2019 (CEST)

Meines Wissens orientiert Simple English WP sich teilweise an Basic English, das hat auch seine Grenzen. - "Teil der WP", damit meine ich nicht so sehr Abschnitte in bestehenden Artikeln, sondern eine Lösung wie bei der Txikipedia: eigene Tabs am oberen Rand der Artikel. Es gibt aber natürlich auch gute Gründe für ein eigenes Wiki. --Ziko (Diskussion) 11:30, 1. Sep. 2019 (CEST)

Alternativtext zu Formeln

Hallo! Ist es möglich und sinnvoll, für (im konkreten Fall) chemische und mathematische Formeln Alternativtexte anzugeben? Anscheinend können Screenreader gut mit MathML umgehen[7], die Wikipedia benutzt allerdings TeX-Schnittstellen. Das wirft bei mir Fragen auf: Können die Tex-Formeln vorgelesen werden? Können sie in MathML konvertiert werden? (Wie) Kann in den <math> und <chem> Umgebungen ein Alternativtext eingefügt werden? Wie sollte der aussehen? Vielen Dank, --Lpd-Lbr (d) 10:37, 17. Sep. 2019 (CEST)

Laut https://www.mediawiki.org/wiki/Extension:Math/Help:Formula#Rendering sollte man eigentlich einfach ein alt-Attribut beim math-Tag angeben können. Aber das scheint nicht zu funktionieren (siehe mein Test). Muss das womöglich in der Math-Extension aktiviert werden? DestinyFound (Diskussion) 11:02, 17. Sep. 2019 (CEST)

Gemeldet in Phabricator
Task T233121

Ich habe das jetzt einmal als Bug T233121 eingetragen. --Lpd-Lbr (d) 18:21, 17. Sep. 2019 (CEST)

Der Vollständigkeit halber der aktuelle Stand aus dem Bug-Report: Es ist ein Feature und die Dokumentation ist wahrscheinlich veraltet. --Lpd-Lbr (d) 20:09, 17. Sep. 2019 (CEST)

Das mit "ist ein Feature" hast du (evtl durch den nicht gerade idealen Zeilenumbruch zwischen "feature" und "request") falsch verstanden: User:Physikerwelt meinte, dass das momentane Verhalten nicht versehentlich sei, was bedeutet dass ein Wunsch nach Änderung dieses Verhaltens nicht als Fehlermeldung, sondern als Verbesserungsvorschlag behandelt wird. --nenntmichruhigip (Diskussion) 23:19, 17. Sep. 2019 (CEST)

In meiner Interpretation bedeutet "This is the intended behavior of the Math extension", dass das Ignorieren des Alternativtext-Tags das gewollte Verhalten ist. "Gewolltes Verhalten" habe ich - vielleicht zu Unrecht (ich lasse mich da gerne berichtigen) - mit "Feature" übersetzt. --Lpd-Lbr (d) 19:34, 20. Sep. 2019 (CEST)

Ja, „intended behavior“ (eher beabsichtigtes als gewolltes Verhalten) und „Feature“ (Funktion) sind zumindest für mich etwas sehr deutlich unterschiedliches :-) Stell dir eine ganz normale Drehtür vor: Funktion ist meist nur/hauptsächlich, dass man eine verschließbare Öffnung in einer Wand hat. Dass die Tür ggf im offenen Zustand im Weg ist (z. B. in einem schmalen Gang) entspricht dem beabsichtigten Verhalten der Tür, auch wenn das eventuell unerwünscht ist. Das kann darüber hinaus auch zur Funktion werden wenn dieses beabsichtigte Verhalten auch explizit gewünscht ist. Wenn die Tür sich bei Öffnung zur Seite schieben würde wäre das ein Fehler (also nicht dem beabsichtigten Verhalten entsprechend), selbst wenn dieses abweichende Verhalten erwünscht wäre. --nenntmichruhigip (Diskussion) 00:18, 21. Sep. 2019 (CEST)

Also: Es gibt jetzt die Möglichkeit, entlang dieses Feature Requests darüber zu diskuieren, wie die barrierefreie Anzeige von Formeln am Besten gemacht werden sollte, die Hilfeseiten sind derzeit veraltet und das Feature wurde bisher auch kaum genutzt. --Lpd-Lbr (d) 19:34, 20. Sep. 2019 (CEST)

ASCII-Art verbieten

Hallo, ich würde gerne den Vorschlag einbringen ASCII-Art zu verbieten, mit Ausnahme von ASCII-Art relevanten Artikeln. Grund dafür ist der dass ASCII-Art für Menschen mit Screenreadern zu massiven Problemen führen kann. --Emil Engler (Diskussion) 14:11, 30. Mär. 2020 (CEST)

Was genau meinst du denn? In welchen Artikeln fiel dir das auf? Ich wüsste spontan keine.

Generell verwenden wir auch nicht in Teilen ASCII-Art. Autoren, die es nicht besser können, nutzen schon mal -> für einen Pfeil nach rechts, aber das ersetzt dann meist bald jemand durch →. Wobei ein „Pfeil von links nach nach rechts“ oder „Pfeil von West nach Ost“ auch nicht gerade hilfreich ist; gemeint ist vermutlich das Klartext-Wort „siehe“. Deshalb sind solche Pfeile auch unerwünscht; es sei denn sie werden im redundanten Fall für Nicht-Sehende ausgeblendet und obendrein mit einenm Tooltip versehen.

„Verbieten“ ist in der Wikipedia schwierig; maximal lässt sich irgendwas für „unerwünscht“ erklären. Aber es gibt bereits Hunderte von Regeln, und gerade auch Typografie ist für viele Menschen ungewohnt, die inhaltlich gute Beiträge schreiben, weshalb wir da sehr tolerant und geduldig nachbessern und immer wieder gute Vorbilder liefern müssen.

LG --PerfektesChaos 15:37, 30. Mär. 2020 (CEST)

Ein Beispiel, wo sowas verwendet wird, ist der Abschnitt "Beispiel" in Sozialversicherungsnummer in Frankreich#Struktur. Das habe seinerzeit ich verbrochen, weil ich zu faul war (und anscheinend immer noch bin), es besser zu machen. --Yen Zotto (Diskussion) 17:57, 21. Mai 2021 (CEST)

Kleinschreibung

Zur Info: Auf WD:DISK#Regelvorschlag zu Textformatierungen (small, etc.) wird gerade zur Verwendung von Kleinschreibung in Diskussionsbeiträgen diskutiert. --Johannnes89 (Diskussion) 14:51, 5. Feb. 2022 (CET)

Navigations-Popups

Ich fände es gut wenn bei den Alternativtexten das Aktivieren von Navigations-Popups in den Einstellungen erwähnt wird. Dann ist es möglich via mouseover den Alt-Text direkt zu sehen, siehe auch hier das PS. --Fan (Diskussion) 20:25, 19. Feb. 2022 (CET)

Test Alternativ Text

Gibt es einen frei verfügbaren Screenreader mit dem man den eingetragenen Alternativtext ansehen kann? Schrauber5 (Diskussion) 19:40, 2. Apr. 2022 (CEST)

Hallo Schrauber5, danke für dein Interesse! NonVisual Desktop Access ist kostenlos; der kostenpflichtige Screenreader JAWS kann pro Sitzung 40 Minuten lang im Demomodus getestet werden. --Wikinger08 (Diskussion) 22:38, 2. Apr. 2022 (CEST)

Es gibt auch wikipediainternes Helferlein: Einstellungen → Reiter Helferlein → Abschnitt Navigation → Navigation-Popups → blauen Haken setzen und Einstellungen speichern. --Fan (Diskussion) 23:50, 5. Apr. 2022 (CEST)

Schriftgröße in Tabellen in Motorsport-Artikeln

Siehe Portal_Diskussion:Motorsport#Schriftgrößen_und_Glaskugel mit Bitte um Beteiligung. --ɱ 23:40, 18. Nov. 2022 (CET)

Farben in Diagrammen

Guten Abend zusammen, im Portal Diskussion:Auto und Motorrad#Festlegung der Randbedingungen entwickeln wir gerade eine neue Darstellungsform für die Zulassungszahlen von Kraftfahrzeugen, um beispielsweise besser zwischen Antriebsvarianten (Benziner, Diesel, Elektro...) zu unterscheiden. Dabei stellten wir uns die Frage nach Barrierefreiheit von solchen Darstellungen, insbesondere bzgl. der Farben. Da sich bislang keiner so richtig eine Antwort zugetraut hat, hoffe ich, dass ich hier auf fachkundigeres Publikum treffe. Vielleicht mag ja jemand unter dem genannten Link kommentieren. Danke und viele Grüße.--Alexander-93 (Diskussion) 18:50, 17. Jan. 2023 (CET)

Position von "Gesprochene Version"

Gibt es dazu Ansichten aus Gründen der Barrierefreiheit? Vgl. diese Änderung. --Pistazienfresser (Diskussion) 23:14, 25. Feb. 2023 (CET)

Naja, wer noch ein klein wenig gucken kann, und gleichzeitig scharfe Augen hat, sieht rechts oben einen Icon mit dem vorlesbaren Hinweis „Dieser Artikel existiert auch als Audioversion“.

• Damit ist es völlig egal, an genau welcher Stelle im Artikel die eigentliche Kiste dann sichtbar wird.
• Tatsächlich soll er nach allgemeinem Usus nach ggf. KALP und allgemeinen Hinweisen angeordnet werden.

Das ist technisch auf dem Stand um 2010 in Vorlage:Gesprochene Version definiert.

• Lässt sich mit mittlerweile umgesetzten Hilfsmitteln noch etwas schlauer ausbauen; insbesondere dass dieser Hinweis von Screenreadern als wichtiges Element klassifiziert wird und in das automatisch generierte Super-Inhaltsverzeichnis der Seite aufgenommen wird, wo es dann von Blinden navigiert werden kann.

Ansonsten sind unsere Ideen aus den Nuller Jahren, eine Audioversion des Artikelstands von 2013 menschlich einzusprechen und dies dann 2024 in einem Stück abzuspulen, zwar weiterhin gut gemeint und bringt unterschiedliche Stimmen und Tonfärbungen zu Gehör; bloß ist der Inhalt schon ein Jahrzehnt alt und nicht mehr der aktuelle Stand.

• Die Screenreader können schon seit Jahren jede Webseite vorlesen, und dabei interaktiv nach Wunsch gesteuert: Welcher Abschnitt, Tabellen überspringen, das Bild interessiert nicht weiter, nochmal einen Abschnitt zurück, folge jetzt dieser Verlinkung.
• Das ist aktueller, und es kann dynamisch im Text herumgesprungen werden, statt jede Audiodatei von Anfang bis Ende abzuspulen.

VG --PerfektesChaos 17:22, 25. Jun. 2024 (CEST)

So, der Icon ist jetzt so aufgepeppt, dass Screenreader wissen dass er wichtig für die Gesamtseite ist, und noch etwas besser erklärt was das macht.

Ansicht aus Gründen der Barrierefreiheit ist, dass Blinde überhaupt nicht sehen können, an welcher Stelle des Artikels die Audioplayer-Box eingebunden wäre, und ihnen das auch völlig egal ist.

VG --PerfektesChaos 17:52, 25. Jun. 2024 (CEST)

Hilfe:Galerie/VisualEditor Alternativtext

Die Bildunterschrift als Alternativtext verwenden

@PerfektesChaos, Hgzh, Raymond: Wem ist denn das „Die Bildunterschrift als Alternativtext verwenden“ eingefallen? Da muss ich mich nicht wundern, wenn das jetzt ständig so in Artikeln vorkommt, zumal es als Standard angeschaltet ist. Herrjeh ! Und was wohl auch noch bald hinzukommt ist dann noch Fehlender Alternativtext für Bilder das wird eine neue Linterfehlerkategorie wohl als Ersatz für ihren vorherigen missglückten Versuch „Inline-Medien mit Bildunterschriften“ uns in den Wahnsinn zu treiben. Das widerspricht aber dem was wir hier unter Alternativtexten verstehen und haben wollen, es kann doch nicht ernsthaft gewünscht sein die Alternativtexte mit redundantem Inhalt zuzumüllen, oder? Es gibt Leute die wiederholen dort stur den Dateinamen, andere wiederholen eben die Bildlegende, aber ein vernünftiger Alternativtext wird daraus ganz sicher nicht entstehen. Dann kann ich das hier Spezial:Diff/243821326/246019802 ja wieder entfernen, scheinbar habe ich da etwas völlig falsch verstanden. Grmpf das nervt, aber sowas von. --Liebe Grüße, Lómelinde Diskussion 16:43, 25. Jun. 2024 (CEST)

Gerade bei dir mitgelesen: phab:T368415 – in Google Translator stopfen.

LG --PerfektesChaos 17:01, 25. Jun. 2024 (CEST)

Formulierung

Danke für den ersten Wurf einer Formulierungshilfe. Aus meiner Sicht ist das aber in der Praxis nicht so absolut zu sehen. Es gibt auch sehr unterscheidliche Vorstellungen von Alt-Texten, was daran liegt, dass sie von unterschiedlichen Gruppen genutzt wird. Also es ist einfach besser einen ersten Text zu schreiben, der dann verbessert werden kann, als gleich die Latte so hoch zu legen, dass es am Ende niemand macht. Beste Grüße --Fan-vom-Wiki (Diskussion) 23:38, 25. Jun. 2024 (CEST)

Es ist besser, keinen Alt-Text zu haben, als einen schlechten Alt-Text zu haben. – Sprach der Herr Lindner.

Das Problem ist, dass ein Alt-Text im allerersten Anlauf bereits einen Minimal-Umfang und Mindestqualität haben muss.

• Wenn Blinde sich die Alt-Texte vorlesen lassen, und das wird regelmäßig als dummes Geschwätz und Zeitvergeudung erlebt, dann geben sie nach einem Dutzend Versuchen auf und lassen sich niemals wieder irgendeinen Alt-Text bei uns vorlesen. Auch falls die eines Tages viel besser geworden sein sollten.
• Deshalb müssen 80 %, besser 90 % der Alt-Texte tatsächlich weiterhelfen.
• Wenn sie nur plump die ohnehin bereits vorgelesene Bildlegende duplizieren, Petra Meyer 1980 Petra Meyer 1980, dann ist das nur nervtötend, und nach ein paar derartiger Erfahrungen nacheinander hat sich das Thema Alt-Text in der Wikipedia für immer erledigt.
• Die Hoffnung auf das Wiki-Prinzip, irgendwer werde erstmal mit sechs Wörtchen Gestammel anfangen, und irgendwann in einigen Jahrzehnten würde jemand anders kommen und das weiter ausbauen, führt bei Millionen an Bildeinbindungen direkt in den Abgrund.

Es gibt eigentlich keine „sehr unterscheidliche Vorstellungen von Alt-Texten“ – wenn man mit jemand telefoniert (ohne Kamera), dann muss beschrieben werden, was auf dem Gemälde zu sehen ist, und beim Mensch am anderen Ende muss dieses Gemälde vor dem inneren Auge entstehen. Wenn der Alt-Text das auch nicht ansatzweise leistet, dann ist das für keine der „unterschiedlichen Gruppen“ zu gebrauchen, fertig.

Mein Eindruck ist so allmählich, dass es zurzeit nur darum geht, irgendeinen Wettbewerb zu gewinnen und statistisch möglichst ganz ganz viele alt= mit irgendwas auszufüllen, völlig egal wie schwachsinnig das Ziel verfehlt würde, Hauptsache in der Statistik hat man einen Treffer mehr.

Ohnehin hat sich 2024 mit der KI das gesamte Thema der statisch im HTML-Dokument hinterlegten Texte erledigt, und wird völlig an Bedeutung verlieren.

• Es gibt bereits Smartphone-Apps für Blinde im täglichen Einsatz, mit denen kann ein Foto der Straße gemacht werden und an einen Alexa-Siri-Server geschickt werden. Der antwortet mit der Beschreibung, dass dort eine zweispurige Straße wäre, links gäbe es eine Fußgängerampel, es wäre rechts ein Straßenschild vorhanden aber momentan nicht lesbar, auf der anderen Straßenseite ist ein Supermarkt und zwei weitere Häuser.
• Genauso laufen momentan Experimente für Screenreader der neueren Generation: Da kann zu einem Bild eine Beschreibung angefordert werden, die URL wird an den Server geschickt, der Server fängt an zu erzählen dass auf dem Gemälde ein Segelschiff wäre, auf einem Fluss, am Ufer im Vordergrund eine Gruppe von Menschen, das gegenüberliegende Ufer ragt steil auf, oben eine Burgruine.
• Die nächste Entwicklungsstufe soll dann in einen Dialog eintreten, je nach persönlichem Interesse: Wie viele Masten hat das Schiff? Sind Segel gesetzt? Wie ist der Himmel, gibt es Wolken, welche Tageszeit, scheint die Sonne? Was machen die Menschen links am Ufer? Gibt es noch weitere Boote?
• Das ist unseren statisch gedrechselten Texten dann haushoch überlegen, weil es detaillierter wird je nach persönlichem Interesse, und schweigt wo es für diese Person uninteressant ist.

VG --PerfektesChaos 00:08, 26. Jun. 2024 (CEST)

„dummes Geschwätz“, „Zeitvergeudung“, „nervtötend“ – Mit so einem Diskussionsstil schwächst du die allgemeine Motivation hier konstruktiv mitzuarbeiten. Schade --Fan-vom-Wiki (Diskussion) 00:24, 27. Jun. 2024 (CEST)