MoinMoin: FeatureRequests/AccessibilityVersusUsability

Short description

I'm a big fan of eye candy in wikis. So I would like to see more spiced up MoinMoin themes and extensions which have a high usability and provide eye candy.

But the chance is high that accessibility suffers from this a lot if you don't take care about it. My feeling from a lot of discussions about this topic is, that MoinMoin tries to have the highest grade of accessibility which is possible. Personally I understand this effort and appreciate it also. But nevertheless the idea of being able to present my colleagues a spiced up version of MoinMoin is also important for me.

This feature request should show some ways, how we could bring this two topics together: Usability and Accessibility.

Ways to gain good accessibility and usability

User configuration switch for Accessibility level

The user settings menu could get a new configuration switch called "Accessibility level". Each user would than be able to set the grade of accessibility on his own. Themes and extensions could read out this global config variable and decide on the value how they want to present the content: in a highly accessible way or full of eye candy.

Possible values for "Accessibility level":

• High Accessibility
  • no Javascript code allowed
  • no flash plugins
• Medium Accessibility
  • Javascript allowed, but...

    • no MouseOver events

• Eye candy mode
  • everything what brings usability is allowed

Each extension and theme must at least work in the "High Accessibility" mode. So a user can decide on it's own if accessibility is very important for him or not.

Discussion

Before answering a question, it is always a good idea, to analyze the question itself first and elaborate on the special view of the problem the question implicitly holds. In the case under consideration here, accessibility is clearly opposed to usability, i.e. accessibility reduces usability -- a view which I personally consider as problematic and I want to refute in the following. In my eyes, 1) accessibility is usability and 2) usability is not just about eye-candies and compelling looking themes.

• Concerning 1) accessibility is usability: IMHO usability in general needs some improvment in Moin. But I know, that the Moin core team has a different view on that. However my personal experience with wiki users are different -- even at university. E.g. a lot of people don't know, aftering having called the page diff action or having uploaded a file, how to return to the underlying wiki page again. Most people don't know that they shouldn't use the browsers back button but to click (in modern theme) on the tab with the current page name. Especially with ThemeMarket/SimpleMente I tried to change some things e.g. by changing the bread-crumbs navigation a bit (Annotation: Today, I don't consider the idea a good idea to replace the page title by the breadcrumbs). Also sometimes people are confused about the huge amount of actions in the "more actions" menue. The actions are often named in a way, people don't understand. There are even actions listed there, people are not not allowed to call. It would be nice to have an easy way for theme developpers/for the wiki admin to customize the edit bar and list there only actions his users really needs and also name them in a sensible way (see ThemeMarket/SimpleMente e.g. for a new "backlink"-action, a new "create new page"-action and other ideas). This reduction of complexity is IMHO important for mentally disabled as well as for unexperienced users. Accessibility is therefore usability at the same time. Also providing Moin with the ability to have access-keys (not: to built in access-keys) would be an improvement for both, the disabled and non disabled in my eyes(FeatureRequests/BasicAccesskeySupportInsteadOfBuiltInAccesskeys). Accessibility is usability in this case either.

• Concerning 2): I really love compelling looking themes and eye-candies (e.g. ThemeMarket/Solenoid)! I would like to see more of this, too. Please, please go ahead with this. Javascript is not always bad for accessibility. It just depends on the way you use javascript. And there are some cases, where it is not good or the given solution is just too short-sighted. All in all: There are plenty of examples to do good looking sites, that are accessible and usable, see e.g. http://www.einfach-fuer-alle.de, http://www.zdf.de (German only). And as I tried to point out above: usability is not just about eye-candies but rather about a logic design of pages and tasks.

Annotation: Don't know much about the state of the art of accessibility of flash applications. Adobe works a lot on that, as well as on the accessibility of pdf.

-- OliverSiemoneit 2009-09-13 22:55:16

My point of view includes the assumption that a system which is optimized for accessibility is not always the one with the best usability. The same is for the opposite: best usability may be problematic for the accessibility. The approach with the user defined accessibility level would reduce the need for tradeoffs in theme and extension design. You can optimize your extensions and themes to the max for either usability AND accessibility. I'll underline what you say if you speek about that a good structure and so on is crucial for every system. But (there's always a but somewhere ) that's often hard to reach. [JosefMeier, 2009-09-14 01:07:00]

CategoryFeatureRequest