Hi again
Last month, we discussed some of the comments we got from the German Central Library for the Blind (DZB) about Vector's accessibility http://www.mediawiki.org/wiki/Accessibility. I have received a second set of comments, which I'd like you to have a look at. This time, the feedback comes from a blind person actually using a screen reader (JAWS). So, here goes.
1) expansible menu items can not be identified as such. We talked about this before, but did we come up with a good solution?
2) when the browser window is small (which a blind person would never know), some tabs (like "history") get moved into a drop-down menu, glued to a down-arrow icon. The menu drops down when the mouse is hovered over the icon. This is totally inaccessible to blind people, the icon has no title or any other indication what it does, there is no way to activate the drop-down. Actually, I couldn't even fiond a way to navigate there using the keyboard.
3) the suggestions shown under the search field are not accessible via the screen reader. it's not announced, and it does not get read.
4) Alt-Text for edit-buttons are read without spacing between them, they get jammed together. It also does not becopme clear which elements are buittons, which are links, etc. Blind people would probably not bother with toolbars anyway and use wikitext directly, but they should be able to explore the functionality and find their way around.
That's it for the second round of feedback. As to the results of the first round... I'm inclined to turn each item into a feature request / bug report. Do you think that's the way to go?
-- daniel
-------- Original-Nachricht -------- Betreff: AW: Usability von Wikipedia Datum: Thu, 24 Jun 2010 15:57:56 +0200 Von: Brückner, Sebastian Sebastian.Brueckner@dzb.de An: Daniel Kinzler daniel.kinzler@wikimedia.de, maria.schiewe@wikimedia.de Referenzen: 4C1B6DBD.9020902@wikimedia.de
Guten Tag zusammen.
Ich habe soeben mit einer blinden Kollegen die Bearbeiten-Seite eines Wikipediaartikels unter die Lupe genommen und möchte meine Erkenntnisse mitteilen.
Die eingeklappten Ausklappmenüs der Navigation waren mit dem Screenreader Jaws10 lediglich als h5 und nicht als Link o.ä. zu erkennen. Nach deren Einblendung waren die aufgeklappten Links aber an der korrekten Stelle zu finden und auch bedienbar.
Der Link "Versionsgeschichte" wird bei zu kleinem Fenster durch ein Aufklapppfeil ersetzt, dadurch war auch per Jaws nicht direkt anspringbar. Das Aufklappicon wurde lediglich als "Nummernzeichen" erkannt, ohne weitere Erklärung etc.
Die Vorschlagsliste des Suchfeldes war nicht erkennbar, also in irgendeiner Weise angekündigt. Sie war zwar mit den Pfeiltasten bedienbar, aber Jaws las nichts vor.
Die Buttons des Editors wurde nur teilweise erkannt, die Alternativtexte (oder was genau das war) "Fett", "Kursiv" etc. wurden vorgelesen, allerdings ohne Leerzeichen dazwischen. Auch die meisten Funktionen unter Erweitert vorgelesen, allerdings hier auch ohne jegliche Erklärung ob es sich um einen Link oder Button oder ähnliches handelt. Auch mit Verrenkungen über virtuelle Cursoer etc. war es nur umständlich möglich, diese WYSIWYG-Funktion zu nutzen. Vermutlich würden blinde Nutzer hier eher plain (wiki)text eintippen.
So weit so gut :-)
Viele Grüße aus/nach Leipzig Sebastian Brückner
--- Sebastian Brückner BIK-Beratungsstelle Mitteldeutschland in der Deutsche Zentralbücherei für Blinde zu Leipzig Telefon: (03 41) 71 13-180 Fax: (03 41) 71 13-125 E-Mail: brueckner@bik-online.info Internet: www.bik-online.info
-----Ursprüngliche Nachricht----- Von: Daniel Kinzler [mailto:daniel.kinzler@wikimedia.de] Gesendet: Freitag, 18. Juni 2010 15:00 An: Brückner, Sebastian Cc: Maria Schiewe Betreff: Re: Usability von Wikipedia
Guten Tag
Brückner schrieb:
Hallo Herr Kinzler,
wie im Gespräch am 11.06.2010 besprochen, habe ich einen
Blick auf den neuen
Wikipedia-Skin geworfen.
Oh super, vielen Dank!
Dabei sind mir einige verbesserungswürdige Punkte
aufgefallen, teilweise sind
(vermutlich) auch nicht viel Handgriffe zu tun.
Positiv hervorzuheben ist der hohe Kontrast der
Überschriften, Links und
Texte sowie die Skalierbarkeit der Seite, ohne das Überlappungen oder Abschneidungen auftreten.
erfreulich.
Ein schnell zu erledigender Punkt wäre die Ergänzung von
a:focus zu a:hover
im CSS, da bei Tastaturbedienung keinerlei Fokushervorhebung
auftrat. Bei
Mausbedienung wird hingegen eine Unterstreichung bei den
Links hinzugefügt.
Das sollte problemlos möglich sein. Ich geb's mal weiter.
Hinderlich oder irritierend könnte die "ungewöhnliche"
Tab-Reihenfolge sein.
Im IE8 und FF3.6 werden zuerst das Suchfeld, dann die 3-4
Aufklapplinks der
Navigation, der Inhaltsbereich, der Header und anschließend erst die restlichen Navigationlinks und der Footer angesprungen. Im
Opera 10 konnte
ich hingegen nur die Suche und die Aufklapplinks antabben.
Tab-Reihenfolge ist ja immer ein endloser Kampf. Und die linarisierung einer Seite im Inhalt und Navigation ist nicht trivial. Aber auch das geb ich mal weiter...
Auf der Startseite fiel mir auf, dass die unaufgeklappten Links mit display:none; versteckt werden, damit sind sie allerdings auch für Screenreadernutzer nicht auffindbar. Lösungsmöglichkeit
wären z.B. die
Positionierung außerhalb des sichtbaren Bereichs oder die
Höhe auf 0 setzen.
Hm... gibt es da Erfahrungswerte, wie gut das funktioniert, und in wie weit alle Browser das mitmachen? display:none; ist ja "semantisch" durchaus das, was man haben will.
Übrigens: wird die Seite ohne JavaScript geladen, ist immer alles "aufgeklappt". Ich frage mich, ob es ggf möglich wäre, mit JavaScript zumindest die gebräuchlichsten ScreenReader-Plugins zu erkennen und ggf einen speziellen Modus zu aktivieren, der z.B. das Einklappen von Navigationselementen unterbindet. Wäre das sinnvoll?
Zudem wurden Layouttabellen verwenden, es sind nur vier
Zellen, was keine
große Barriere darstellt, allerdings wäre auch diese mit wenig CSS vermeidbar.
Hier ist das Problem, dass es sich um "Wiki-Text" handelt, also um gemeinsam gepflegte Inhalte die nicht Teil der Software sind. Das macht es schwieriger, technisch anspruchsvollere Lösungen umzusetzen und zu warten.
Meiner Erfahrung nach ist es recht schwierig, ein brauchbares Tabellen-Layout mit CSS hin zu bekommen, so, dass es in allen Browsern funktioniert. Für die Hauptseite wäre das machbar, aber es werden schon an sehr vielen Tabellen fürs Layout verwendet.
Eventuell könnte MediaWiki eine Funktion anbieten, die Wiki-Tabellen automatisch in divs konvertiert statt in eine HTML-Tabelle. Das wäre nützlich, aber leider nicht ganz einfach.
Ebenso ließen sich die doppelten Links vermeiden, die durch die getrennte Verlinkung von Icons und Texten auftritt. En masse
tritt dies bei
den Portallinks und Schwesterprojekten der Startseite auf.
Hier sehe ich keine gute Lösung... *gemeinsam* verlinken lässt die Wiki-Syntax nicht zu, und das Ergebnis sähe vermutlich auch nicht besonders aus. Sinnvoll wäre es, die Icons für Screenreader etc komplett zu verbergen. Aber ich weiß leider nicht, wie - außer mit einer Erkennung via JavaScript.
Auf einer Inhaltsseite (die von Leipzig) fielen mir
ebenfalls Layouttabellen
auf, hier aber nur ein- oder zweizellig, aber grad deswegen
eigentlich gut
ersetzbar.
Ich nehme an, das bezieht sich auf die "Infobox" rechts und auf die Positionierung der Bilder. Das auf einer Seite zu ändern ist wohl kein Problem, leider haben wir eine Million davon... Da wären wir wieder bei der Idee, Layout-Tabellen automatisch in divs umzusetzen.
Sämtliche Thumbnails an der rechten Seite des Inhaltsbereichs enthielten leere alt-Attribute. Das ist schon mal besser als
gar keine,
allerdings übergehen manche Screenreader solche Grafiken
dann. Da nach der
Grafik auch erst der vergrößern-Link folgt, ist der "Weg" zur Bildunterschrift doch länger als nötig. Vllt. könnte man
hier die Reihenfolge
optimieren oder die Bildunterschrift als Alternativtext
vergeben, was aber
natürlich zu ebenso unschönen Dopplungen führen kann.
Der "Vergößern"-Link ist in der Tat ärgerlich. Der könnte nach hinten. Das geb ich mal weiter. Warum die Alt-Attribute leer sind, ist mir nicht klar - das war auch nicht immer so, wenn ich mich recht entsinne. Allerdings ist nicht so klar, was die ideale Lösung wäre... es gibt zwei mögliche Inhalte: die Bildunterschrift (die ja ohnehin nochmal kommt) oder den Dateinahmen (der hoffentlich, aber nicht unbedingt, informativ und leserlich ist). Außerdem könnte man Statt dem alt-Attribute auch title= setzen - am Bild oder auch an dem Link, der das Bild umgibt. Da der Link auf die Detailseite des Bildes zeigt, scheint es mir durchaus sinnvoll, in dem Link das Title-Attribut auf den Dateinamen zu setzen.
Ich hoffe dass es sich nicht allzu schlecht anhört, denke
aber das einige
Punkte schnell behoben werden können. Eine Begutachtung der
Bearbeiten-Seite
war mir aus Zeitgründen noch nicht möglich, dass würde ich
Anfang/Mitte
nächster Woche nachholen. Dann auch gern mit einem blinden
Kollegen aus
unserem Haus.
Das wäre super!
Vielen dank erstmal so weit. Ich schreib gleich mal etwas an die Entwickler-Mailingliste.
Gruß Daniel Kinzler
--
Daniel Kinzler Software Developer Wikimedia Deutschland
Phone +49 30 219 158 260
Stellen Sie sich eine Welt vor, in der jeder Mensch freien Zugang zu der Gesamtheit des Wissens der Menschheit hat. Helfen Sie uns dabei! http://spenden.wikimedia.de/
****Unterstützen Sie Freies Wissen mit einer SMS. Senden Sie einfach WIKI an 81190. Mit 5 Euro sichern Sie so die Verfügbarkeit und Weiterentwicklung der Wikipedia.****
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.