Accessible Moin - A Project to Improve the Accessibility of the MoinMoin Wiki

This is the working and gathering place for people interested in a more accessible Moin. Feel free to add concerns, comments, ideas and own code contributions here.

<!> This page is quite a mess and is going to be restructured during the discussions about main branch implementation and a refactoring of http://hg.moinmo.in/moin/1.6-accessibility/

Done

ishihara_plates.png

And here some Gaugin painting:

landscape.png

color2gray.png

Daltonize and Color2Gray can be easily tested. Just download the source given above, install the Python Image Library and NumPy and run the modules form the command-line with e.g.

daltonize.py c:\test.png
color2gray.py c:\test.png False

or with you don't like the given result
color2gray.py c:\test.png True

In Progress

Pending

ToDo

Related Moin Pages

Interesting External Links

General Discussion and Ideas

Moin and Accesskeys

Accesskeys are an often requested feature but prone to a lot of problems (collision with preset browser's access keys, localization, difficult to activate). So in the end, it is not clear whether access keys do really ease and ameliorate access or deterioate it. Skiplink navigation is said to be the better solution for this. However when I worked on Simplemente theme and implemented skip links there I have noticed that Opera does not support this way of navigation through a page at all (also Konqueror and Safari??)!! Accesskeys could help in this case since none of the solutions is the perfect solution. In my eyes accessibility has to be assured by different means, skip links and access keys and others, since none of them alone suffices.

But how to get rid of the problems of access keys? Have user defined accesskeys, i.e. accesskeys which are only set by the user and could also be customized only by the user!! I'm thinking of having like personal.css some shortcuts.txt file attached to ones homepage which includes a javascript array which could be inlined to the html by the theme code. Next we just need some javascript function that manipulates via the DOM and adds to the links, forms, inputs, textareas the accesskey="." attrib as specified in the array. Similar solutions can be found here:

Again this is not a 100% solution since it relies heavily on javascript and there are people working out there which think about javascript being the devil himself. But I think this solution is also prone to problems, however it is better than nothing and also a quite flexible one. -- OliverSiemoneit 2007-03-16 16:33:38

See ThemeMarket/SimpleMente for a first implementation of these thoughts. But it also shows that appending a customization file to the user's homepage isn't perfect since interwiki homepages cause a lot of trouble here (would need fetching the file via wikirpc). So the "file solution" is just a workaround to implement accesskeys by theme code only. In the long run it would be better to move that to the userprefs menu by patching some core code. This will solve most security ('no other person than the user can change these setting'), performance (since it's part of the User's object and cached therefore??) and interwiki problems ('shared user accounts'). -- OliverSiemoneit 2007-03-17 21:48:01

Naming of page elements in Moin

Instead of just having menu and sidebar links like <a class="nbinfo" href="/TestWiki?action=info" rel="nofollow">Info</a> e.g. for the info action in the editbar, it would be desirable to provide for all important elments of a page (pagetrail, navibar..) also a name attrib like <a class="nbinfo" href="/TestWiki?action=info" name="nbinfo" rel="nofollow">Info</a>. This is a least needed to easily get contact to these elements by the javascript function "GetElementsByName"[not the plural: elements] (if there is no "id" and now way to do that by GetElementByName [note the singular:element]). Simplemente accesskeys solution uses this heavily to add to these elements on page load automatically a userdefined accesskey attrib. There is no easy way to get in contact with these elements just with a css class. Maybe the name attrib is also needed for page internal linking as anchor target for the skip link navigation (to be tested). So having also a "name" attrib might be an important accessibility feature. So if "id" must be replaced somewhere for html validation sakes since the id occurs several times in the page, it might be probably better to replace "id" by "class=.." and "name=.." .

CSS Naked Days

Is Moin ready for this: http://naked.dustindiaz.com/?? ThemeMarket/SimpleMente is a first try..

MoinMoin: AccessibleMoin (last edited 2010-01-31 00:54:50 by cm-84)