Wikipedia Diskussion:BIENE/Screenreader/Skin

Meine Mail an Benutzer:Lalü vom 2008-05-07 11:46

Zu Archivierungszwecken bzw. für potenzielle Mitarbeiter, die keine Kopie erhalten haben

Ich habe bereits angefangen, mir Gedanken anhand Deiner Links zu machen, sehe jedoch ein großes Problem: So ziemlich alle Punkte, die Du in Accessibility and Wikis aufzählst, lassen sich nicht mit Skins korrigieren, sondern erfordern direkte Änderungen an der MediaWiki-Software. Skins selber verändern nur die visuelle Erscheinung der einzelnen Elemente, jedoch welches Element für welchen Textbaustein verwandt wird (beispielsweise in der Frage, ob "Es wurde kein Artikel gefunden" als Überschrift ausgezeichnet wird) und die eigentlichen Inhalte der Elemente (zum Beispiel in der Frage, ob Bearbeiten-Links und Links auf Referenzen in eckige Klammern eingefasst werden) lassen sich, soweit ich weiß, nicht via CSS oder Javascript verändern, das erfordert Änderungen an der Wikisoftware.

Umgedreht ist es natürlich einfacher: Die spezielle Links umfassenden eckigen Klammern lassen sich mit den CSS-Pseudoklassen "before" und "after" problemlos hinzufügen und ob der große, fette Satz vom Element heading oder paragraph ist, dürfte dem sehenden Benutzer herzlich egal sein. Es wäre also vorstellbar, diesen Umstand als Verbesserungsvorschlag einzubringen, ich werde mich mal mit dem Bugzilla-System, welches die MediaWiki-Programmierer benutzen, auseinandersetzen und das einfach mal vorschlagen.

Weiterhin schreibst Du in Making Wikipedia fully accessible for all, dass Du gern den Monobook-Skin Screenreader-kompatibel machen würdest. Ich selbst kann den Gedankengang zwar nachvollziehen, da Monobook der Standard-Wikipedia-Skin ist, halte dies aber für keine gute Idee, da es sich beim Screenreader um ein grundsätzlich anderes Ausgabemedium handelt als bei Monitoren und es daher um einiges einfacher und auch praktikabler wäre, eine Screenreader-kompatible Oberfläche von Null auf zu entwickeln. Der MySkin-Ansatz, der eine komplett unformatierte Wikipedia bereitstellt, scheint mir als Anfang am geeignetsten zu sein und ich glaube (habe es selbst noch nicht ausprobiert), dass sich die Screenreader-Ausgabe unabhängig vom gewählten Skin nur wenig verändern dürfte, da mit CSS, wie erwähnt, eher die visuelle Formatierung verändert wird, auch wenn CSS 2.0 bereits Sprachausgabe-Optionen anbietet. Sollte der Screenreader-Skin irgendwann benutzbar sein, wäre es ein leichtes, in den Monobook-Skin einen für Sehende nicht bemerkbaren Absatz an den Anfang einzufügen, der Screenreader-Benutzer auf den speziellen Skin verweist.

Ende der Mail

– viciarg ᚨ 22:13, 7. Mai 2008 (CEST)

Anmerkungen

Vielen Dank für deine Initiative! Es folgen einige laienhafte Anmerkungen:

• Der MySkin sieht für mich auf den ersten Blick genau wie Monobook aus, lediglich der Bearbeitungslink sollte so plaziert sein wie bei de.Wikipedia. Meine Idee, Monobook umzuarbeiten beruhte nur auf meiner Unwissenheit.
• Wenn ich die Experten richtig verstanden habe, war CSS Aural eine Fehlentwicklung und braucht nicht weiter beachtet werden.
• Eckige und runde Klammern stören eigentlich nur bei den Auflistungen auf Spezialseiten. Die eckigen Klammern für die Bearbeitungslinks bei den Abschnitten stören nicht wirklich. Wenn sie allerdings ohne größeren Aufwand entfernbar sind, könnte das gleich mit erledigt werden. Im Artikel-Namensraum sind Klammern völlig OK.
• Soweit es geht, könnte man sich bei CSS und eventuell JS auf das Nötigste beschränken, was zur Ausgabe der Textinformationen wichtig ist. Es sollte auch mit einem Screenreader-Skin für sehende Menschen irgendwie möglich sein, den Seiteninhalt zu lesen. Wenn ein blinder Nutzer einem Sehendem am Bildschirm etwas zeigen möchte, sollte das also gehen, wenn auch mit Einschränkungen bei der Optik.
• Am besten wäre es, wenn der Skin auch mit älteren Versionen wie Jaws 4.51 ohne Einschränkungen genutzt werden könnte. (Falls es dagegen keine mir unbekannten Gründe gibt.)
• Der Skin sollte mit IE6, IE7, FF2 und FF3 laufen. Andere Browser werden von Blinden momentan nicht benutzt. Opera wird vielleicht irgendwann auch zu dieser Liste gehören. Mit Linux kenne ich mich nicht genügend aus. Die Mobilversion von Wikipedia scheint auch relativ gut mit Screenreadern auf Mobilgeräten genutzt werden zu können.

Die Navigation mit einem Screenreader auf Webseiten ist eigentlich ziemlich einfach. Es ist also möglich, selber einmal mit einer Screenreader-Software herum zu experimentieren, um sich die Bedürfnisse der blinden Zielgruppe besser vorstellen zu können. Hier gibt es dazu Infos auf deutsch und hier auf englisch. Eigentlich braucht man zur Bedienung von Wikipedia nur einige Tasten. Das folgende bezieht sich auf Jaws, ist aber bei anderer Software gleich bis ähnlich:

• Cursor hoch und runter, Enter, Tab-Taste
• h-Buchstabentaste (zum navigieren von Überschriften)
• f-Buchstabentaste (springt ins nächste Eingabefeld, also beispielsweise ins Suchfeld)
• Buchstabetaste plus Shift springt die Elemente rückwärts an
• Ctrl+Home (zum springen an den Seitenanfang),
• Ctrl plus f (zum durchsuchen des gesamten Seiteninhalts nach bestimmten Zeichenketten, sehr praktisch wenn man weiß, wonach man sucht)
• Die sogenannte Jawstaste (Einfügen-Taste) plus Cursor runter liest den ganzen Seiteninhalt ab der Cursorposition vor
• Mit Ctrl kann das vorlesen in jeder Situation unterbrochen werden.

Soweit ich das verstanden habe, bekommt der Screenreader seine Informationen von der Grafikkarte, modernere Versionen können aber auch auf die MSAA-Schnittstelle zugreifen. Für alle speziellen Fragen, die ich nicht beantworten kann und die für sehende Entwickler absolutes Neuland sind, könnte ich versuchen, Tips und Auskünfte von entsprechenden Experten einzuholen. Ich werde im Rahmen meiner Möglichkeiten anfangen, mich mit diesen Dingen näher zu beschäftigen und melde mich dann wieder. Für meine ungenauen Erklärungen bitte ich um Nachsicht.

P.S.: Es wäre wohl am besten, möglichst wenig bis garnichts an Mediawiki selber verändern zu müssen, da dies leider anscheinend nicht allzu leicht sein dürfte. -- Lalü 15:32, 7. Mai 2008 (CEST)

Meine drölf Cent dazu:

1. Den Bearbeiten-Link anders zu platzieren ist kein Problem.
2. CSS Aural war zwar in CSS2 ein Fehlschlag, da nur Opera die Erweiterung implementierte, soll aber unter dem Namen „CSS Speech“ fest in CSS3 eingebaut werden. Priorität ist derzeit jedoch „low“, von daher bleibt abzuwarten, was am Ende dabei rauskommt. Ich werde jedenfalls keinen CSS3-optimierten Code schreiben, solange es noch nicht als Standard verabschiedet wurde ;)
3. Der Screenreader-Skin wird auf jeden Fall den Text sichtbar und auch farbmarkiert und auch entsprechend kursiv oder fettgeschrieben ausgeben und auch Grafiken und Tabellen einbinden. Er ist also auf jeden Fall für Sehende geeignet.
4. Mit JAWS habe ich leider überhaupt keine Erfahrung, das lässt sich aber sicherlich ändern.
5. Browsertechnisch sollte es nur begrenzt Probleme geben, da ich es gewohnt bin, validen Code zu schreiben. Zusätzlich auf IE-Kompatibilität zu achten, ist dann zwar nicht schick, aber machbar.
6. Die JAWS-Seite von WebAIM habe ich bei meinen Recherchen natürlich gefunden, dadurch ist mir erst klargeworden, warum die Überschriften-Auszeichnung für Blinde so wichtig ist ;)
7. Für die Änderungen an Mediawiki wäre es halt klasse, wenn wir irgendwie Kontakt zu Raymond aufbauen könnten. Was dann im Resultat nicht oder nur sehr umständlich verändert werden kann, muss halt anders gelöst werden.

– viciarg ᚨ 21:39, 7. Mai 2008 (CEST)

Nachsatz: Änderungen an den Spezialseiten betreffen, soweit ich weiß, leider alle die Mediawiki-Software. – Vicitest1 21:57, 7. Mai 2008 (CEST)

Ganz kurz eine Anmerkung zur Arbeitsweise der Screenreader. Wie Lalü richtig geschrieben hat, greifen sie zum Teil direkt über den Videotreiber auf Inhalte zu, zum Teil aber auch eben über die Schnittstellen wie MSAA und UIA sowie über die Objektmodelle (für Browser also das DOM). In welchem Maße was eingesetzt wird, können wir nicht sagen, da Jaws nicht quelloffen ist. Durch diese Dreifaltigkeit ist es ihnen jedoch möglich an alle Daten zumindest heranzukommen. Was sie dann daraus machen, ist die andere Frage. — Lecartia Δ 10:28, 9. Mai 2008 (CEST)

Vorschlag

Um das angestrebte Ziel eines Skins für Screenreader-Nutzer erreichen zu können, brauchen wir Wissen aus verschiedenen Bereichen. Bei Wikipedia gibt es Menschen, die sich mit Mediawiki, CSS und JS auskennen. Ich selbst kann mich als Nutzer einbringen, der mitteilt, was sich gut bedienen lässt und was praktischer sein könnte. Uns fehlt Detailwissen zu Screenreadern im Zusammenspiel mit verschiedenen Browsern und CSS/JS. Ich würde daher gerne alle zu diesen Themen wichtigen Fragen sammeln, um dann beispielsweise Marco Zehe von Mozilla (früher Freedom Scientific), der für diese Bereiche ein wirklicher Experte ist, um Antworten zu bitten. Wichtig wäre allerdings, möglichst klare Fragen zu formulieren, um eine effiziente Klärung zu ermöglichen. .

Das Gute an einem Screenreader-Skin, den ich jetzt einfach mal SRS nenne, ist, daß es wirklich nur um die Darstellung von Text geht, ohne sich viele Gedanken über eine hübsche und alles berücksichtigende Darstellung am Bildschirm machen zu müssen. Vielleicht könnte man dazu sogar einige der Ideen verwenden, die sich mit technischen Einschränkungen als Barriere beschäftigen. Dann ließe sich der SRS eventuell auch gut mit Screenreadern auf Mobilgeräten nutzen, da die Menge der Daten, die beim laden einer Seite übertragen werden, noch mehr reduziert werden könnte, ohne die Funktionalität für blinde Nutzer einzuschränken. -- Lalü 17:35, 7. Mai 2008 (CEST)

Wie bereits erwähnt, lässt sich mit einem Skin nur die visuelle Gestaltung und die Anordnung von Elementen verändern. Wieviele Daten übertragen werden und auch was der Browser an CSS und Javascript interpretieren muss, liegt teilweise außerhalb unserer Reichweite, es sei denn, wir weiten das Projekt gleich auf einen MediaWiki-Klon für Screenreader oder andere Plattformen aus. Dies würde aber ziemlich sicher meine Kenntnisse übersteigen. Anpassungen an kleine Bildschirme oder geringe Kontraste sind jedoch relativ problemlos implementierbar, es stellt sich dann eher die Frage, wie weit wir gehen wollen. Eine nahezu unformatierte Wikipedia ist meiner Meinung nach der Idealzustand für diese Ausgabemedien. – viciarg ᚨ 22:25, 7. Mai 2008 (CEST)

Erste Anpassungen

Das verschieben des Bearbeitungslinks funktioniert gut. Die neuen Infos zu gesichteten Versionen sehen so aus:

Gesichtet

(+/-)klickbar

Der Artikelanfang ist eine sehr häufig gelesene Stelle und wenn es geht, sollten dort möglichst wenig weitere Text- und Leerzeilen stehen. Die einzelne Zeile "Keine Version gesichtet" stört nicht, aber für die gesichteten Versionen wäre es praktisch, wenn man das folgende ausblenden könnte:

• (+/-) (zusätzlich liest die Sprachausgabe klickbar vor

Es könnte vielleicht sinnvoll sein, Screenshoots zu machen, die die Seitendarstellung unter Jaws oder einem anderen SR zeigen. Dann wären viele Screenreader-Problematiken einfacher für Sehende verständlich. Die Darstellung einer Seite wie Versionen oder anderer Spezialseiten wäre alleine schon aufschlußreich genug, um die Usability-Probleme schnell erkennen zu können. Leider habe ich keine Ahnung, wie man Screenshoots macht oder wie man sie hier einbindet. -- Lalü 10:16, 8. Mai 2008 (CEST)

Dieser (+/-)-Link öffnet eine Erläuterung und weitere Details dazu, welche Version gesichtet wird und ob die gesichtete oder die aktuelle Version angezeigt werden soll. Den Link auszublenden halte ich für unpraktisch, es ist aber technisch möglich. Eine Umbenennung in „Details“ wäre praktischer, ich schau mal, ob das irgendwie möglich ist. – viciarg ᚨ

Ich kann nur empfehlen unter Einstellungen, Markierte Versionen auf Benutze für markierte Versionen die detaillierte Benutzerschnittstelle umzustellen. Dann gibt es keine Box mehr, sondern einen lesbaren Satz. — Lecartia Δ 16:01, 9. Mai 2008 (CEST)

Danke für den Tip. Mit dieser Einstellung bekommt man zwar interessante Erläuterungen und Links, Die Zeichenfolge (+/- wird aber weiterhin mit der Zusatzinfo "klickbar" von der Sprachausgabe vorgelesen. Der Hinweis "klickbar" ist übrigens das erste Mal von mir in Wikipedia registriert worden, normalerweise stoße ich nur auf anderen Seiten auf einen Link, der nicht als Link sondern so bezeichnet ist. Eine Umbenennung in "Details" wäre gut, aber nur, wenn das ganz einfach geht. Insgesamt ist die Stelle, an der diese Meldung steht, eine der am häufigst aufgesuchten Stellen, da man dort den Artikelanfang vermutet. Vielleicht könnte man die Mitteilung über gesichtet/geprüft auch mit dem Gadget von TM zwischen den Einleitungstext und das Inhaltsverzeichnis verschieben. Dann könnte man die detailierte Benutzerschnittstelle für den SRS verwenden, da man nach dem lesen des Einführungsteils eines Artikels einfach mit "h" weiterspringen könnte. Aber wie gesagt, aus meiner Sicht ist dieses Thema momentan nicht besonders wichtig sondern gehört eher zur Luxusabteilung. ;-) -- Lalü 16:56, 9. Mai 2008 (CEST)

Bugreport?

Was genau muss ich mir unter (Unüberwindliche Probleme, die einen Bugreport wert sind): „heading-Format für „Es existiert kein Artikel mit dem Namen“ auf spezial:Suche“ vorstellen? Wo genau liegt das Problem? — Raymond ^{Disk. Bew.} 10:07, 8. Mai 2008 (CEST)

Benutzer:Lalü hat in seinem Artikel Accessibility and Wikis vorgeschlagen, dass dieser Text und auch andere statt mit span- mit h2-tags ausgezeichnet werden. Hintergrund ist, dass Screenreader-Benutzer durch simple Tastenkombinationen schnell zwischen den Überschriften hin- und herschalten können und sich daher nicht die ganze Seite vorlesen lassen brauchen. Ob daraus ein Bugreport wird, ist noch abzusehen, ich will mich, wie ich schrieb, erst mit Eurer Arbeitsweise etwas vertraut machen und ungefähr einschätzen, was machbar ist und was nicht, bevor ich Euch mit unnützen Bugreports überschwemme. – viciarg ᚨ 15:31, 8. Mai 2008 (CEST)

Nun, das war einfach: Es gab bereits eine Systemnachricht, die war aber im Code falsch platziert und wurde daher nicht angezeigt. Jetzt wird sie es, siehe dieses Beispiel: http://de.wikipedia.org/wiki/Spezial:Suche?search=test2222&go=Artikel

Ich werde aber nicht versprechen, dass alles so schnell zu lösen ist :-) — Raymond ^{Disk. Bew.} 22:53, 8. Mai 2008 (CEST)

Ah, klasse! Vielen Dank! :) – viciarg ᚨ 00:04, 9. Mai 2008 (CEST)

Super, ich bin total begeistert. Vielen Dank. Ich hätte nicht gedacht, daß das so einfach machbar sein könnte. Das ist für jeden blinden Benutzer auf jeden Fall eine Erleichterung. Könnte man die folgenden beiden Zeilen vielleicht auch noch so verändern? Dann wäre die Suchseite fast schon paradisisch:

• Es folgen die Suchergebnisse ... von ...
• Suche in den Namensräumen

-- Lalü 00:09, 9. Mai 2008 (CEST)

Die "Suche in den Namensräumen" ist Teil des Formulars "Erweiterte Suche", welches eigentlich via Hotkey angesprungen werden können müsste. – viciarg ᚨ 17:16, 9. Mai 2008 (CEST)

Stimmt. Ich habe eben alle Buchstaben ausprobiert und herausgefunden, dass "x" auf der Seite Spezial:Suche immer nur zu der Zeile "Suche in den Namensräumen" führt. Da ich dies aber bislang nicht wusste, könnte es sein, dass sehr viele andere blinde Benutzer dies auch nicht wissen. Toller wäre es sowieso, die Zeile "Es folgen die Suchergebnisse ..." mit Heading zu haben. Übrigens, ich nehme zwar an, das dies auch nicht ohne weiteres zu ändern ist, aber die folgende Leiste über den Suchergebnissen, die auch noch einmal darunter steht, ist für einen Screenreadernutzer auch störend:

• Zeige (vorherige 40) (nächste 40) ( 20 | 50 | 100 | 250 | 500)

-- Lalü 18:41, 10. Mai 2008 (CEST)

Die von Lalü angesprochene Leiste über und unter den Suchergebnissen „Zeige (vorherige 40) usw.“ kann ich zwar nicht entfernen. Das würde die Navigations-Konsistenz zu anderen Seiten brechen. Aber ich habe ihnen CSS-Klassen gegeben: mw-search-pager-top und mw-search-pager-bottom, so dass man sie sich wahlweise oben oder unten über seine Monobook.css ausblenden kann. An den anderen Sachen arbeite ich noch. — Raymond ^{Disk. Bew.} 00:13, 14. Mai 2008 (CEST)

Vielen Dank für deine Arbeit. Ich bin gespannt, was sich durch ähnliche Vorgehensweisen vielleicht ebenfalls noch so alles positiv beeinflussen lässt. -- Lalü 20:54, 15. Mai 2008 (CEST)

Anführungszeichen

Lalü schrieb mir gerade, dass Jaws nicht in der Lage ist, die korrekten deutschen Anführungszeichen „ und “ wiederzugeben. Nun verwenden wir diese völlig berechtigt in den Artikeln. Wäre es denkbar über JavaScript oder sonstwie auf Wunsch diese Zeichen durch das Zollzeichen " zu ersetzen? Das müsste ähnlich wie die Umwandlung vom Eszett zum Doppel-S funktionieren. Lalü, gibt es noch Probleme mit anderen Zeichen, die Jaws nicht lesen kann? Zum Beispiel Gedankenstriche – oder lange Gedankenstriche — ? — Lecartia Δ 13:59, 9. Mai 2008 (CEST)

Also, der Bindestrich (-) wird vorgelesen. Der Gedankenstrich (—) auch. Wie man den Gedankenstrich mit der Tastatur erzeugt, weiß ich nicht, ich habe ihn eben einfach über die Zwischenablage hierher kopiert. Ich stoße in der Wikipedia oft auf Zeichen, bei denen meine Sprachausgabe stumm bleibt. Vielleicht liegt es auch am IE6 oder vielleicht können neuere Screenreaderversionen als Jaws7 diese Zeichen erkennen. Lecartia, du hast doch schon mal mit Jaws herumprobiert. Was hältst du davon, dir mit Jaws einmal die Sonderzeichenliste auf irgendeiner Bearbeitungsseite anzugucken? Du würdest dann hören können, bei welchen zeichen nichts angesagt wird. Ich kann dies nicht machen, da ich ja nicht erfahre, um welche Zeichen es sich handelt.

Dieses Thema wäre übrigens eine gute Frage für Marco Zehe, den ich oben erwähnt habe. Er müsste fast alles über die Einschränkungen und Fähigkeiten von Screenreadern wissen. Gibt es eigentlich irgendwo eine Liste im Web, di erklärt, wie man Zeichen wie den Gedankenstrich mit der Tastatur erzeugen kann? -- Lalü 15:48, 9. Mai 2008 (CEST)

Lieber Lalü, wir können es testen, indem du versuchst die Tabellen in der alternativen Tastaturbelegung zu lesen, die dort ein Nutzer zusammengestellt hat. Da in den Tabellen auch immer eine lesbare Bezeichnung steht, weißt du so, womit du es zu tun hast. Liebe Grüße — Lecartia Δ 15:53, 9. Mai 2008 (CEST)

Lalü, den Gedankenstrich, den Du kopiert hast, war der Geviertstrich "—", der am häufigsten verwandte Gedankenstrich ist jedoch der Halbgeviertstrich "–", liest den JAWS auch vor? Ich hab gestern etwas mit NVDA rumprobiert, der erkannte ihn nicht. – viciarg ᚨ 17:22, 9. Mai 2008 (CEST)

Lecartia: Schick, dieses Gadget könnte es sogar ermöglichen, die ganzen Layout-Klammern auszufiltern. Ich werd damit mal etwas rumbasteln. – viciarg ᚨ 17:22, 9. Mai 2008 (CEST)

Hallo Lecartia. Danke für den Link zur Liste. Mich persönlich stört es nicht, dass der SR die Zeichen nicht alle kennt. Wenn andere blinde Nutzer aber an Artikeln mitschreiben wollen, bei denen es auf solche Sonderzeichen ankommt, wäre es wichtig, ihnen diese Zeichen irgendwie zugänglich machen zu können. Da dies aber nur für wenige blinde Menschen wichtig sein wird, wäre es wohl praktischer, einfach der Screenreader-Software die Zeichen beizubringen.

Hallo Viciarg. Der Halbgeviertstrich wird nur als "Strich" vorgelesen. Wenn das Gadget die eckigen und runden Klammern aus den Spezialseiten herausfiltern könnte, wäre das auch schon ein echter Usability-Gewinn. Ich freue mich, dass du NVDA ausprobiert hast, jetzt hast du mir was vorraus. ;-) Ich lese zwar seit einigen Monaten manchmal in der NVDA-Liste mit, aber meine Experimentierlust mit Programmen ist nicht besonders ausgeprägt. Das betrifft insbesondere so komplexe Software wie Screenreader. Ich bin froh, dass ich wenigstens die wichtigsten funktionen von Jaws, meinem Browser und meinem Mailclient kenne und vielen anderen blinden Anwendern geht es ebenso. -- Lalü 19:17, 10. Mai 2008 (CEST)

Hi Lalü! Dass der Halbgeviertstrich vorgelesen wird, reicht mir. Bei der Mitarbeit ist es auch weniger wichtig, dass die richtigen Bindestriche und Ausführungszeichen verwandt werden, dafür finden sich schon Benutzer, die die auf der Tastatur vorhanden durch typografisch korrekte Zeichen ersetzen können. Momentan steht erstmal die Usability für die lesenden Benutzer im Vordergrund. Von daher reicht es vollkommen, wenn Du uns als Tester für JAWS zur Verfügung stehst, da dieser mir bisher als der verbreitetste Screenreader vorkommt. Ich kann leider keinen genauen Zeitpunkt festlegen, hoffe aber, dass ich in den nächsten Tagen einen verwertbaren Zwischenstand vorführen kann. Grüße, viciarg ᚨ 21:13, 10. Mai 2008 (CEST)

Lecartia: "Wäre es denkbar über JavaScript oder sonstwie auf Wunsch diese Zeichen durch das Zollzeichen " zu ersetzen?" - ja, ist für reines Lesen sogar ziemlich simpel (siehe nachstehenden Code). Man könnte auch überlegen, nicht durch Zollzeichen, sondern passende Texte - etwa 'Anführungszeichen links' und 'Anführungszeichen rechts' - zu ersetzen, dann geht die Information nicht verloren. Viele Grüße, —mnh·∇· 01:35, 22. Mai 2008 (CEST)

function quote2ascii() {
    /* Seiten mit action= ignorieren, soll nicht beim Editieren verändern */
    if(location.href.match("action="))
        return; 
    /* Ersetzen */
    document.body.innerHTML=document.body.innerHTML.replace(/[„“”«»]/g,'"');    
}
addOnloadHook(function() { quote2ascii(); });

Hervorhebung von Links zu ungeschriebenen Artikeln

Auf diese Diskussion Bezug nehmend, wollte ich fragen, ob es im Rahmen eines Skins oder Gadgets möglich wäre, solche ins Leere führende Links mit beispielsweise eckigen Klammern oder Sternchen zu umschließen. Diese Markierung müsste aber Bestandteil des Links sein. Beispiel: Diese [Seite] und dieser *Artikel existieren noch nicht. -- Lalü 15:39, 10. Mai 2008 (CEST)

Ist theoretisch möglich, ich habe auch schon ein Gadget gesehen, welches Links zu nichtexistierenden Artikeln auf "klassische" Wikiart darstellt, mit Fragezeichen dahinter. Also bei Deinen Beispielen so: Loadstone-GPS?. Ich probier das aus. – viciarg ᚨ 13:33, 11. Mai 2008 (CEST)

Was mir grade einfällt: Wären das nicht zusätzliche unnötige Zeichen, die eigentlich vermieden werden sollten? Oder überseh ich da was? – viciarg ᚨ 13:53, 11. Mai 2008 (CEST)

Ich denke, dass die beste Kennzeichnung für einen ungeschriebenen Artikel beim Beispiel *Loadstone-GPS* wäre. Solche Links sind bei Wikipedia selten, so dass das vorlesen des Fließtextes nicht beeinflusst würde. Generell kann man sagen, daß zu Layoutzwecken verwendete Sonderzeichen dann besonders stören, wenn sie entweder sehr häufig auftauchen oder es sich um Zeichen handelt, die sehr viele Silben haben. Die Sprachausgabe liest "Stern" sehr viel schneller vor als "Eck-ige-Klam-mer-auf" oder "do-ppelt-ge-wink-el-te-Klam-mer-auf". Für ein effizientes lesen ist es unpraktisch, wenn solche Zeichen wie auf Spezialseiten oder in optisch aufgehübschten Artikeln/Portalen regelmäßig in großer Zahl vorkommen. Dass es schon ein Gadget gibt, finde ich gut, allerdings wird die Bedeutung des Links, der von der Sprachausgabe nur als "Link" ohne weitere Bezeichnung vorgelesen wird, im Fließtext für unerfahrene Leser wahrscheinlich nur schwer verständlich sein. -- Lalü 14:57, 11. Mai 2008 (CEST)

Ah, verstehe. Auf die Aussprache der Sonderzeichen bin ich selbst noch gar nicht gekommen. Unter dem Aspekt ist der Stern wirklich um einiges sinnvoller als die eckigen Klammern. – viciarg ᚨ 16:33, 11. Mai 2008 (CEST)

War mal so dreist, ein myskin.css für den Testaccount anzulegen, das Links auf Referenzen aus- und Sterne einblendet. Das ist ja nur Kleinzeug.

Wo ich aber schonmal hier bin: Ich frage mich, ob es nicht langfristig sinnvoller wäre, ein geeignetes Frontend als externe Software mit der MediaWiki-API zu schreiben. Damit wird man immerhin auf einen Schlag alle Einschränkungen des Browsers und der auf Sehende ausgerichteten Oberfläche los: die Software bekommt den Wikitext und kann diesen und die Wikipedia-Funktionen präsentieren, wie sie das möchte. Ich hab keine Ahnung von Accessibility, stell ich es mir beispielsweise recht hilfreich für einen blinden Leser vor, wenn auf Tastendruck das Inhaltsverzeichnis eines Artikels als Auswahlliste zum direkten Anspringen präsentiert wird. Im Browser kann man sowas wenn überhaupt nur mit viel Aufwand implementieren, in einer externen Software ist das eine simple Sache. Anderes Beispiel wären Versionsgeschichten oder auch Difflinks: Wenn man diese Seiten nur linear über den Screenreader sieht, muss diese Linksammlung doch wie völliges Chaos erscheinen, die räumliche Struktur kann ja vermutlich gar nicht vermittelt werden. Das ginge bestimmt auch besser. Momentan kann man zwar meines Wissens nach noch nicht via API schreiben (wobei Bots dieses Problem ja auch irgendwie lösen), aber zumindest intensiver drüber nachdenken könnte man ja schonmal. Viele Grüße, —mnh·∇· 01:27, 14. Mai 2008 (CEST)

Eine externe Software wäre natürlich auch klasse, allerdings muss man dafür programmieren können. ;) – viciarg ᚨ 12:16, 15. Mai 2008 (CEST)

Darum kommt man ja auch so nicht vollkommen herum, ob man nun an Javascript-Gadgets oder einer recht kleinen Java-Applikation herumwerkelt ist (jedenfalls aus meiner Sicht) nicht so ein riesiger Unterschied. Viele Grüße, —mnh·∇· 01:54, 22. Mai 2008 (CEST)

Hallo MNH, vielen Dank. Ich habe es zwar noch nicht selber mit Vicitest ausprobiert aber es funktioniert bestimmt gut. Wenn Referenzlinks die Links zu den Einzelnachweisen wie [1] sind, die einen auf der gleichen Seite zur richtigen Stelle innerhalb der Einzelnachweise bringen, sollten diese nicht ausgeblendet werden. Diese Links stören einen Screenreadernutzer nicht, da sie nicht allzu häufig in den Artikeln auftauchen, sondern geben die Information, dass es eine Quelle für eine Behauptung des Artikels gibt und bringen einen direkt zu dieser Angabe. Ein blinder Wikipedia-Benutzer hat mich darauf hingewiesen, dass angestrebte Verbesserungen möglichst keine Einschränkungen bei der Funktionalität mit sich bringen sollten und er hat wohl recht.

Eine externe Software könnte vielleicht die perfekte Lösung für viele Usability-Probleme sein, aber die Installation eines speziellen Programms wäre für die meisten blinden Nutzer wohl zu aufwendig und nicht niedrigschwellig genug. Für einen blinden Power-User von Wikipedia, der auch fleißig mitschreibt, wäre das wahrscheinlich eine tolle Sache, aber solche blinden Nutzer gibt es wohl leider nur selten, so dass sich der Entwicklungsaufwand nicht lohnen würde. Es könnte aber interessant sein, als blinder Anwender einen externen Texteditor benutzen zu können. Ich habe mich damit bislang noch nicht beschäftigt, aber es gibt dafür ja bereits anscheinend einige Tools. Wenn solch ein Werkzeug sich auch mit einem Screenreader gut bedienen ließe, könnte das Editieren dadurch eventuell komfortabler gemacht und einige Bedienungsbarrieren abgebaut werden. -- Lalü 20:59, 15. Mai 2008 (CEST)

Hallo Lalü, hm, ok, die Niedrigschwelligkeit kann ich nur sehr schwer beurteilen. Ich ging einfach davon aus, dass eine Installation nicht viel aufwendiger als das Auswählen zahlreicher Gadgets ist, das mag aber ohne technischen Hintergrund sehr anders aussehen. Viele Grüße, —mnh·∇· 01:54, 22. Mai 2008 (CEST)

P.S.: Sorry wegen der späten Antwort, war einige Tage rechnerlos.