Advertisement
Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- Media­Wiki ist ein Wiki-System, das größten­teils in <span lang="en" title="PHP Hypertext Preprocessor">PHP</span> program­miert wurde und <span lang="en" title="Hypertext Markup Language">HTML</span>-, <span lang="en" title="Cascading Style Sheets">CSS</span>- und <span lang="en">Java­Script</span>-Quell­text an den Navi­gator des Nutzers ausgibt. Der baut dann die Seite so zusammen, dass man sie betrach­ten kann. Es gibt einige <span lang="en" title="Hypertext Markup Language">HTML</span>-Ver­sionen. Die bekann­testen sind HTML 4.0.1, XHTML 1.0 und HTML 5. Letz­tere ist vom <span lang="en" title="World Wide Web Consortium">W3C</span> noch nicht end­gültig definiert, wird von Media­Wiki aber bereits verwendet.
- Um Bar­riere­armut zu errei­chen, muss eine Netz­seite regel­konform und seman­tisch program­miert sein und es müssen auch zumin­dest grund­legende Eigen­schaf­ten wie Sprach­angabe von einzel­nen Ele­menten genutzt werden, wie die HTML-Versio­nen es ja anbie­ten. Davon macht Media­Wiki aller­dings kaum Gebrauch. Beson­ders auffäl­lig sind die noch immer verwen­deten logischen statt seman­tischen Textaus­zeich­nungen.
- === Semantische Textauszeichnung ===
- Media­Wiki wurde zu einer Zeit ent­wickelt, als es längst seman­tische Alterna­tiven zu den logi­schen Textaus­zeich­nungen gab. Trotz­dem werden weiter­hin <nowiki><i> und <b></nowiki> verwendet, was inzwi­schen als antik bis fossil gelten muss. Mit diesen beiden HTML-Elemen­ten werden üblicher­weise kursive („'''''i'''talic''“) und fette Schrift („'''''b'''old''“) einge­leitet. Statt­dessen sollten seit etwa 2001 <nowiki><em></nowiki> („'''em'''phasized“) und <nowiki><strong></nowiki> benutzt werden, was aber selbst bei der derzeit neue­sten Version 1.26.3 nicht ge­schieht. Es kümmert offen­bar nie­manden – und das, obwohl den Program­mierern klar sein müsste, wie wichtig die seman­tisch rich­tige Textaus­zeich­nung für gute Such­maschinen­ergeb­nisse ist. Wenn die Wiki­pedia und Google aller­dings zusam­men­arbei­ten – und davon muss ausge­gangen werden –, so nutzt die schlechte Bewer­tung von Wikis mit Media­Wiki nur der Wiki­pedia, deren Positio­nierung auf den Such­maschinen­ergebnis­seiten künst­lich verbes­sert wird.
- Ein Bei­spiel soll klar­stellen, warum seman­tische Auszeich­nungen so wichtig sind: Eine Über­schrift dritter Ordnung wird seman­tisch korrekt mit <h3> einge­leitet. Man kann diese aber auch rein logisch aus­zeichnen, indem man einen Absatz mit dem Über­schriften­text anlegt, der extra fett darge­stellt wird (<p><b>). Im ersten Fall kann ein ''Parser'', der sich ja nicht die Seite, sondern nur deren Quell­text ansieht, klar eine Über­schrift erken­nen („'''h'''eadline '''3'''“); im anderen Fall aber gibt es nur einen Absatz ohne abschlie­ßenden Punkt („'''p'''aragraph“) und eine Text­auszeich­nung »fett« („'''b'''old“). Wie soll der ''Parser'' denn dabei eine Über­schrift erken­nen und daraus ein Inhalts­verzeich­nis erstel­len, das dem Fließ­text voran­gestellt wird?
- Ein Mensch kann zwar oftmals einen Unter­schied in der Gestal­tung dieser beiden Vor­gehens­weisen sehen, '''erkennt''' den Text mit der fal­schen Methode aber trotz­dem als Über­schrift. Dies ist dem ''Parser'' nicht möglich. Solche ''Parser'' werden <abbr title="zum Beispiel">z. B.</abbr> in Such­maschi­nen einge­setzt. Über­schriften­texte werden als Schlüssel­wörter beson­ders stark bewer­tet. Man vergibt sich also eine Aufwer­tung einzel­ner Be­griffe, nutzt man die seman­tischen Möglich­keiten nicht.
- Über­schrif­ten werden in Media­Wiki einwand­frei seman­tisch umge­setzt – das war aber noch nie ein Problem in der gesam­ten Netz­program­mierung. Die meisten anderen seman­tischen Auszeich­nungen aber werden besten­falls stief­mütter­lich behandelt.
- Eine logische Text­auszeich­nung sagt also nur <abbr title="zum Beispiel">z. B.</abbr> an: „mache Text im Element kursiv“, wohin­gegen die seman­tische Text­auszeich­nung sagt: „dekla­riere den Text im Element als hervor­gehoben“. Im letz­teren Fall braucht es eine (aber ohnehin vorhan­dene) <span lang="en" title="Cascading Style Sheets">CSS</span>-Defini­tion des <nowiki><em></nowiki>-Elemen­tes als kursiv. Dies klingt nach einem Umweg, dient aber der klaren Tren­nung von Struk­tur und Gestal­tung. Aus dem bislang verwen­deten <nowiki><i></nowiki> ist für einen ''Parser'' also nicht zu erkennen, '''warum''' ein Text als kursiv ausge­zeichnet ist.
- === Einrückungsstil ===
- Deswei­teren ist der vom Wiki ausgegebene HTML-Quell­text alles andere als leicht zu lesen. Sämt­liche Ele­mente haben eine anschei­nend zufäl­lige Anzahl von Tabu­lator­zeichen davor. Es gibt keine saubere Ein­rückung. Ursache dafür ist die Program­mier­weise „Inline-PHP in HTML in PHP-Datei“, was als ziem­licher Schwach­fug gelten darf. Die Aus­gaben werden ober­flächen­spezi­fisch vorge­nommen. Ich habe die Program­mierung bei der ''Vector''-Ober­fläche auf „PHP in PHP-Datei“ zurück­gestellt. Der Haupt­inhalt wird derzeit zwar noch immer <abbr title="komplett">kpl.</abbr> ohne Ein­rückung einge­baut, der Seiten­kopf und ‑fuß, die Navi­gation und einige weitere Bedien­ele­mente haben jetzt aber eine anstän­dige Ein­rückung. Der Nutzer bekommt davon nichts mit, aber Program­mierer haben ihre Freude daran, wenn sie sich den HTML-Quell­text ansehen müssen.
- === Arbeitsaufwand ===
- Bei alledem ist die Korrek­tur nun wirk­lich nicht auf­wendig! Ein PHP-Program­mierer, der sich erst in Media­Wiki einar­beiten und auch noch die rich­tigen Stellen im Quell­text finden und analy­sieren muss, braucht etwa zwei Stunden. Mit den von mir ange­sagten Text­stellen ist es eine Sache von <abbr title="zirka">ca.</abbr> 15 Minuten. Ich habe mir diesen Aufwand ’mal gemacht und habe jetzt auf meinem Rechner ein lokales Wiki, das wesent­lich besser auf Bar­riere­armut hin getrimmt ist. Dummer­weise dürften die Aktua­lisie­rungen von Media­Wiki diesen Fort­schritt sofort wieder zunichte machen. Also ist der beste Weg, Media­Wiki diese Ver­besse­rungen über­nehmen zu lassen. Dann hätten alle Media­Wiki-Nutzer etwas davon, die ihre Instal­latio­nen regel­mäßig aktua­lisieren lassen. Die zu verän­dernden Dateien sind:
- * skins/Vector/VectorTemplate.php
- * skins/Vector/SkinVector.php
- * includes/OutputPage.php
- * includes/Sanitizer.php
- * includes/parser/Parser.php
- Man braucht also nur noch schrei­benden Zugriff (<abbr title="zum Beispiel">z. B.</abbr> per FTP) auf den ''Server'' für diese Dateien.
- === Weitere Verbesserungen zur Barrierearmut ===
- ==== Allgemeine Verbesserungen ====
- Ein weite­res Sorgen­kind ist die bei all den Instal­lationen verschie­den gehand­habte Methode der Auszeich­nung von Abkür­zungen, Akro­nymen und Spra­chen. In den aller­meisten Fällen wird gar nichts ausge­zeichnet. Wird ein Begriff mit einer anderen Sprache als der des regulären Fließ­textes ausge­zeichnet, so wird besten­falls der Begriff kursiv gesetzt. Dabei bietet HTML bereits eine Menge an Möglich­keiten, um Bar­riere­armut ohne großen Aufwand zu errei­chen. Fol­gende Möglich­keiten sind denkbar, Media­Wiki im Sinne der Barriere­armut drastisch zu verbes­sern:
- * <nowiki><small>, <big>, <tt>, <center> und (sofern noch verwen­det) <font></nowiki> elimi­nieren und durch <span lang="en" title="Cascading Style Sheets">CSS</span> erset­zen
- * <nowiki><q></nowiki> gehört einge­baut
- * <nowiki><acronym></nowiki>-Ele­mente sollten zumin­dest als Option anschalt­bar einge­baut werden; viel­leicht kommt die <span lang="en" title="World Wide Web Consortium">W3C</span> doch noch zur Vernunft, die das Element <nowiki><acronym></nowiki> aus HTML 5 unsin­niger­weise ver­bannte
- * <nowiki><abbr></nowiki>- und <abbr title="gegebenenfalls">ggf.</abbr> <nowiki><acronym></nowiki>-Ele­mente benö­tigen im Editor Eingabe­masken für ihre ''lang''- und ''title''-Attri­bute
- * oftver­wendete Abkür­zungen sollten gleich fertig formatiert im Editor verfügbar sein: z. B., u. a., u. ä., o. ä., uvm., usw., ggf., kpl., allg., dt., ehem., Jh., ugs., vgl.
- * ''alt''- und ''title''-Attri­bute in <nowiki><img></nowiki>-Elemen­ten setzen; ''longdesc'' er­scheint derzeit unnötig
- * wenn doch HTML 5 einge­setzt wird, warum dann nicht auch dessen Ele­mente <nowiki><aside>, <footer></nowiki> <abbr title="und so weiter">usw.</abbr>?
- * starre Größen­defini­tionen wie »px« gehören <abbr title="komplett">kpl.</abbr> elimi­niert, damit die Größen­verhält­nisse zwischen Text und Bildern gleich bleiben
- * gerade lange Aufzäh­lungs­listen profi­tierten von der mehr­spal­tigen Dar­stel­lung, was sehr einfach und elegant mit ''column-width'' zu errei­chen ist.
- ==== Mehrspaltigkeit und Silbentrennung ====
- Es folgt ein kleines Bei­spiel von mehr­spal­tigem Fließ­text. Je nach Satz­spiegel­breite dieses Blocks auf dem Monitor des Nutzers werden unter­schied­lich viele Spalten angelegt und mit Text befüllt. Dabei wird eine Mindest­breite von 16em definiert. Das ist die 16fache Breite des Klein­buch­stabens „m“. »em« wird zur barriere­armen Größen­defini­tion genutzt statt des leider noch immer all­gegen­wär­tigen starren »px«.
- <div style="column-width: 16em; column-gap: 1em; column-rule: 0.1em dotted maroon; font-size: 0.8em;"><p>Dies ist ein Typo­blind­text. An ihm kann man se­hen, ob al­le Buch­sta­ben da sind und wie sie aus­se­hen. Manch­mal be­nutzt man Wör­ter wie Ham­bur­ge­fonts, Raf­gen­duks oder Hand­glo­ves, um Schrif­ten zu te­sten. Manch­mal ver­wen­det man Sät­ze, die al­le Buch­sta­ben des Al­pha­bets ent­hal­ten – man nennt die­se Sät­ze »Pan­grams«. Sehr be­kannt ist die­ser: <span lang="en">The quick brown fox jumps over the lazy old dog.</span> Oft wer­den in Typo­blind­tex­te auch fremd­spra­chi­ge Satz­tei­le ein­ge­baut (<span lang="en">AVAIL® and Wefox™ are testing aussi la Kerning</span>), um die Wir­kung in an­de­ren Spra­chen zu te­sten. In La­tei­nisch sieht zum Bei­spiel fast je­de Schrift gut aus. <span lang="la">Quod erat demonstrandum.</span> Seit 1975 feh­len in den mei­sten Test­tex­ten die Zah­len, wes­we­gen nach TypoGb. 204 § ab dem Jahr 2034 Zah­len in 86 der Tex­te zur Pflicht wer­den. Nicht­ein­hal­tung wird mit bis zu 245 € oder 368 VS-$ bestraft. Ge­nau­so wich­tig sind mitt­ler­wei­le auch Âç­cèñ­të, die in neue­ren Schrif­ten aber fast im­mer ent­hal­ten sind. Ein wich­ti­ges, aber schwie­rig zu in­te­grie­ren­des Feld sind OpenType-Funk­tio­na­li­tä­ten. Je nach ''Soft­ware'' und Vor­ein­stel­lun­gen kön­nen ein­ge­bau­te Ka­pi­täl­chen, ''Kerning'' oder Li­ga­tu­ren (sehr pfif­fig) nicht rich­tig dar­ge­stellt wer­den.</p></div>
- Kurioser­weise werden auf Seiten von Regis­seuren oder Schau­spie­lern mit vielen auf­geli­steten Filmen diese in einem fest auf <abbr title="zum Beispiel">z. B.</abbr> 3spaltige Darstel­lung defi­nierten Ab­schnitt formatiert. Hat sich jemand ’mal angesehen, welcher Murks dabei heraus­kommt, wenn das Navi­gator­fenster <abbr title="zum Beispiel">z. B.</abbr> nur noch 800px Breite hat? Gerade Anwen­der mit höher auflö­senden Bild­schirmen wie 1920×1200 Bild­punkte nutzen das Navi­gator­fenster oftmals nicht mehr maxi­miert. Bei 600px Breite kann man die einzel­nen Wörter in den Listen­punkten nicht mehr ver­nünftig lesen und bei 400px ver­schwinden Teile der Wörter im Nirvana.
- Im Sinne des „<em lang="en">responsive web design</em>“, also dass sich die Darstel­lung von Inhalt dem zur Verfü­gung ste­henden Platz anpasst, sollte nicht eine feste Spalten­anzahl, sondern eine feste Mindest­breite definiert werden. Der Navi­gator wählt dann selb­ständig die rich­tige Anzahl der Spalten. Damit ist einspal­tige Darstel­lung genauso möglich wie acht­spaltige. Anstelle
- <code>columns: 3 auto;</code>
- ist die einfache Lösung,
- <code>column-width: 20em;</code>
- zu schrei­ben. Der Raum zwischen Spalten hat standard­gemäß 1em Breite. Folgende Satz­spiegel­breiten führen dann zur entspre­chenden Ein­teilung:
- * 0…40,94em: einspaltig 20…40,94em
- * 41…61,94em: zweispaltig je 20…30,47em
- * 62…82,94em: dreispaltig je 20…26,98em
- * 83…103,94em: vierspaltig je 20…25,24em
- * usw..
- Gerade die deut­sche Sprache hat wegen ihrer langen Wort­formen oftmals Pro­bleme mit kleinen Spalten­breiten, denn dies führt zu extrem starkem Flat­tern am rechten Rand des Satz­spie­gels. Die einzige Lösung ist, Silben­trennung einzu­bauen. Da aber nur wenige Naviga­toren eine Silben­trennungs­defini­tion (für jede Sprache separat) verar­beiten können und die veröf­fent­lichten Defini­tionen für die deutsche Sprache fast immer die des Stan­dards „de-DE-Latn-1996“ statt „de-DE-Latn-1901“ sind, wird wild <abbr title="zum Beispiel">z. B.</abbr> s-t ge­trennt. Man kommt also nicht um eine manu­elle Tren­nung herum oder zumin­dest um eine riesige Tren­nungs­tabelle, die in Media­Wiki einzu­bauen ist. Wer sollte diese pflegen? Und: Sollte sie separat für jede Instal­lation erzeugt werden oder global? Wer will dann die Liste vor Fehltren­nungen und anders­spra­chigen Ein­schlägen schüt­zen und reinigen?
- Will man also Flatter- oder gar Block­satz anwen­den, muss man auf eine gün­stige Zeilen­länge achten. Derzeit nutzt man in allen Wikis die volle Fenster­breite des Navi­gators (abzüglich Navi­gations­menü und „Fleisch“ an Elemen­ten). Das Auge hat speziell bei größe­ren Fenster­breiten Pro­bleme, die nächste Zeile zu finden. Anderer­seits muss man bei der jeweils verwen­deten Sprache eine akzep­table Mindest­breite finden, da sonst zu große Lücken am Zeilen­ende oder zwi­schen den Wörtern geris­sen werden. Eng­lisch mit seinen ver­mehrt kurzen Wörtern kommt sehr gut mit 23…30em Breite aus (mit Silbentrennung: 20…25em), Deutsch dage­gen erfor­dert 26…32em (mit Silbentrennung: 20…26em). Die <abbr title="oben genannte">o. g.</abbr> Mindest­spalten­breite in <span lang="en" title="Cascading Style Sheets">CSS</span> von 20em trifft also die gün­stige Spalten­breite für den deut­schen Sprach­duktus recht gut.
- Nun ergibt sich aber ein anderes Problem bei der Nutzung von mehr­spal­tigem Fließ­text: Werden die Spalten vertikal so lang, dass der Leser mit seinem Mobil­telefon ständig auf- und abscrollen muss, ist der Wert der verbes­serten Lesbar­keit in horizon­taler Rich­tung dahin. Man hat den Teufel mit dem Beel­zebub ausge­trieben. Also erfor­dert die Verwen­dung von mehr­spal­tiger Darstel­lung bei län­geren Fließ­texten entweder beim Autor der Seiten soviel Diszi­plin, nur kleine Text­mengen auf einmal mehr­spaltig anzei­gen zu lassen (was wie­derum bei großen Fenster­breiten die Blöcke sehr flach macht) oder man über­läßt es einer Auto­matik, eine gesunde Text­menge in einen solchen Block zu setzen.
- Da die Fenster­größe (oder genauer: ''Viewport''-Größe) nicht zwangs­weise vom Navi­gator an den ''Server'' weiter­gereicht wird, sodass dieser die Berech­nungen vor­nehmen könnte, wird die Berech­nung klienten­seitig, also im Navi­gator vorge­nommen. Dafür braucht es aber angeschal­tetes ''JavaScript'', was nicht immer der Fall ist. Folg­lich muss der Seiten­quelltext so ausge­liefert werden, dass Nutzer bei abgeschal­tetem ''JavaScript'' die Seiten <abbr title="komplett">kpl.</abbr> ohne Mehrspal­tigkeit betrach­ten können. Eine solche Auto­matik ist bereits program­miert und wird ge­nutzt.
- Die beiden letzten denk­baren Pro­bleme beste­hen erstens darin, so große Absätze zu schrei­ben, dass die Spalten­länge bei wenig­stens zwei­spal­tiger Darstel­lung größer als die ''Viewport''-Höhe wird und doch wieder etwas ge­scrollt werden muss. Hier darf man dann eine Empfeh­lung an Autoren abgeben, eine Maximal­länge eines Absat­zes einzu­halten. Zwei­tens können in den Fließ­text mit <float> einge­bundene Bilder bei kleinen Bild­schirmen die ''Viewport''-Größe über­schrei­ten. Dies ist die klas­sische Konse­quenz aus der ''per se'' nicht-bar­riere­armen Einheit „px“, die in Wikis, Blogs, Foren und vielen Netzprä­senzen noch immer vorherr­schen.
- Grund­sätz­lich auf Mehr­spaltig­keit ausge­legte Netzprä­senzen gibt es nur sehr wenige. Dies liegt an der Komple­xität der Thema­tik, dem zu trei­benden Aufwand und der Notwen­digkeit zur expli­ziten Vermei­dung der Größen­einheit „px“ (und aller anderen abso­luten Einhei­ten). Ein <span lang="en" title="Web Content Management System">WCMS</span> wie <abbr title="zum Beispiel">z. B.</abbr> ein Wiki auf diese extrem lese­freund­liche Gestal­tung nach­träg­lich umzu­stellen, ist mit vielen Hürden verbun­den und erfor­dert den Ein­griff in den Quelltext, wozu wie­derum Schreib­rechte auf den ''Server'' non­nöten sind.
- === Einsatz eines <em lang="en">Bot</em>s ===
- Experi­mentiere gerade ein wenig mit den Möglich­keiten von Media­Wiki herum. Ich habe mir in meiner lokalen Instal­lation deshalb spaßes­halber ein neues Nutzer­konto angelegt und den Nutzer zum <em lang="en">Bot</em> erklärt. Der Zugriff über das Konto auf das Wiki ist genau wie bei einem regu­lären Nutzer angelegt, was mich erstaun­te. Habe also damit begon­nen, einen <em lang="en">Bot</em> in <span lang="en" title="PHP Hypertext Preprocessor">PHP</span> zu schrei­ben, der zu­nächst nur die Abkür­zungen im Wiki­text (Media­Wiki-Artikel­quell­text) auf eine ordent­liche Schrei­bung bringt. Weitere Entwick­lung auf äußerst rudi­men­tärem Stand ge­stoppt, bis klar wird, ob ein <em lang="en">Bot</em> benö­tigt/ge­wünscht wird.
- <em lang="en">Bot</em>s ermög­lichen also als automati­sierte Nutzer die Artikel nach und nach zu durch­forsten und folgende Ände­rungen durchzu­führen:
- * Verwen­dete Abkür­zungen mit seman­tischer Auszeich­nung versehen.
- * Akro­nyme einbauen, sofern ge­wünscht; alter­native Nach­bildung mit <span> ist möglich.
- * Weiter­leitun­gen insbe­sondere von Per­sonen­arti­keln anlegen, Quer­ver­weise in Dritt­arti­keln auf die aktu­elle Methode „Nachname, Vorname“ abän­dern und dann den Per­sonen­arti­kel mit „Vorname Nachname“ löschen <abbr title="beziehungsweise">bzw.</abbr> dafür einen Lösch­antrag stellen.
- * Dop­pelte Weiter­leitun­gen elimi­nieren.
- * Bekann­te Recht­schreib­fehler direkt korri­gieren.
- * Log-Datei anlegen für Artikel, die mög­liche Recht­schreib­fehler ent­halten. Ände­rung dann manuell.
- Da <em lang="en">Bot</em>s genau dafür vorge­sehen wurden, um Rou­tine­arbei­ten abzu­nehmen, wundert mich, dass diese Auf­gaben immer noch die Zeit, Verant­wortung und Nerven von mensch­lichen Nutzern kosten. Wird ein <em lang="en">Bot</em> gewünscht? Welche Auf­gaben soll er erfüllen? Wenn ja und erfüll­bar, muss ein extra Konto dafür er­stellt werden.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement
