Accessibility

Mediawiki accessibility is the goal of making Mediawiki sites easier to navigate and read. While this is primarily intended to assist those with disabilities, it can be helpful to all readers.

Feedback from the DZB, June 2010
In June 2010, some people from the German Wikimedia chapter visited the German Central Library for the Blind (Deutsche Zentralbücherei für Blinde, DZB) in Leipzig. One result of the visit was that the DZB arteed to look at Wikipedia's skin (at that point, Vector), and identify any accessibility problems. The first batch of results was then posted and discussed on wikitech (gossamer / pipermail). Here's a quick summary:


 * 1) CSS uses a:hover but is missing a:focus; Thus, there's no highlighting when navigating links with the keyboard. This should be trivial to fix - or are there any problems with this?
 * 2) The tab order is inconvenient. IE8 und FF3.6 show first the search box, then the show/hide toggles from the sidebar, then content, then the top bar, and only then the actual navigation items from the sidebar. This is probably because the toggles get inserted by JS, i guess. Opera 10 goes to searchm then the toggles, then back to search. That's bad.
 * 3) hidden (collapsed) menus use display:none. This makes them inaccessible to screen readers, etc. Alternative ways for hiding them might be better - such as setting the hight to 0. Has this been tried?
 * 4) * display:none is the Right Thing, but screen readers need some indication that the item is clickable. an onclick event would help, but the only good way is WAI-ARIA.
 * 5) Also, would it be possible to detect at least the most popular screen reader plugins with JS, so a special mode could be triggered for the visually impaired?
 * 6) Tables are used for layout a lot. This is mostly true for content, especially for Infoboxes, Navigation boxes, etc. This is quite bad for screen readers. It's going to be very hard though to get wiki editors to use proper css based code for table layouts.
 * 7) Perhaps it would be possible to make {|...|} generate a div-based layout using some magic word or option? This would be so easy with a real parser :) But doTableStuff looks fairly sane, so perhaps it could be done.
 * 8) * Special:Code/MediaWiki/68230 is a proof of concept for this
 * 9) * table-based display is very hard to replicate exactly in CSS. For one thing, table-based display is actually not defined exactly by any standard at all.
 * 10) In image thumbnail boxes, the "zoom" link is before the caption, so people have to skip over it every time. Perhaps it could be moved after the caption.
 * 11) Image thumbnails have an empty alt attribute. This seems like a bug to me - was it always like this? I suggest to use the image's file name in the alt-attribute of the img tag, and also as the title of the link that wraps the thumbnail. After all, the target of that link is indeed the description of the image file. Could we just implement this, or are there any problems I didn't think of?
 * 12) * might be a bug, Special:Code/MediaWiki/41837 changed the way alt attributes are handled.
 * 13) * We discussed this some weeks ago in the German Wikipedia. The preferred solution would be:
 * 14) *# If ... is given, use this text for the alt attribute.
 * 15) *# If no alt text is given, use the text given as the thumb caption.
 * 16) *# If no alt text or thumb caption exists, use the file name (without px data added, without file extension, without _ for blanks).
 * 17) * WAI-ARIA: aria-describedby. Drawback: That is currently only valid in HTML 5.
 * 18) *# If ... is given, use this text for the alt attribute.
 * 19) *# If no alt text exists, use the "simplified" file name.
 * 20) *# Add aria-describedby="ImageCaption" to the img tag. (With ImageCaption being the id of the caption.)
 * 21) * handling of alt text currently differs depending on whether you use thumb, frameless or pixel . Should be consistent.