Adding accesskeys support for better usability and accessibility.

In moin 1.6.1, it will be possible to use [[target|label|accesskey=1]] to define "1" as access key to jump to target.

See also MacroMarket/Link

We would like to support hotkeys in 1.3 but it needs to be in a sane way:

• Work on all browsers
• Few easy to remember hotkeys
• Localized hotkeys?
• Use localized page names?
• Clean and small patch required for 1.3.

Accesskeys increase usefullness (utility + usability). They make the wiki:

• accessible to people with special needs, that can't use a pointing device.
• Faster to use for everyone, specially heavy wiki users.

Considerations for Access Key Use

Access keys have been implemented infrequently on websites. One reason is that access keys on MS Windows use an ALT-<access key> combination, but users typically expect that various ALT-<access key> combinations that are already built into a Windows browser function as expected. e.g. ALT-F opens up the file menu, ALT-E opens up the Edit menu. Thus, adding ALT-<access key> combinations where the <access key> is a letter, is often discouraged by those who talk of access key standardization or the use of access keys to increase usability.

Thus, many of the articles that I've read on the use of access keys suggest that access keys should only be used with number keys.

Historically, access keys have primarily been used to create universal accessibility, that is, when the needs of users with disabilities are considered.

UK government accesskeys standard

I have seen only a couple of recommendations for access key standardization. The standard that you see most often adopted (both on websites in the UK and outside the UK) is the UK Government accesskeys standard shown below:

* Visually-impaired visitor using a tool that reads the website content would hear that wiki name, user name, preferences, trail, navigation, editbar ... read over and over for every page - or use the accesskey to jump to the page content.

Choosing the accesskeys

Would you want to bypass an accessibility standard or conflict with the expected functionality of a browser when adding access key functionality?

• Its a good question what is the expected behavior. A good layout will use same keys like most other sites when it make sense, but must provide useful accesskeys for moin.

Numbers are hard to remember and to type without looking at the keyboard The UK government accesskeys standard is poor. Numbers are hard to remember and to type without looking at the keyboard, and many items in the standards should not have a shortcut key.

• Once again, the question you have to ask is, "Will you use accesskeys to first focus on assisting people with disabilities or to first focus to assist MoinMoin users?" If you focus on the former, you would not worry that "Numbers are hard to remember and to type without looking at the keyboard" if indeed you believe that the UK standard is the standard most used among people with disabilities, or by websites that are designed to assist people with disabilities.

We should check:

• How accesskeys are used on the popular wikis?
• How accesskeys are used on popular CMS systems?
• How accesskeys are used on popular sites e.g. Google, Yahoo?

Wiki level customization

Would you want to provide a way to turn off MoinMoin-specific access key functionality if it were implemented, or allow customization of access key settings by the wiki administrator, or allow alternatives of MoinMoin-specific functionality and universal-access functionality?

• No - using same access keys on all MoinMoin wikis is very important for usability. Different accesskeys per site is really a bad idea. Since accesskeys are theme based, one can design its own theme with different accesskeys. When I use FireFox, I expect ALT-F, ALT-E, ALT-V, ALT-G, ... to operate the same on all websites because those key combinations are defined by the browser. One might say, "Different accesskeys per MoinMoin is really a bad idea." I'd argue for site-configurable access-key configuration orthogonal to themes. Let me choose a Modern theme with disability-based access-keys, or a right sidebar theme with a MoinMoin power-user access-key theme, or a classic theme with no access-keys,... as the creator/administrator of the site.

  • The order of importance as I see it is:
    1. Be familiar to new users, work like a standard web site
    2. Be easy to use for all users
    3. Can be configured to specific site needs
    First we should make 1 work by finding what other sites are using, then make 2 work by having good shortcuts for general users. I'm not sure this should be configured by sites, but by users. For example, if you don't like to use Alt+F for find, set it to another key for yourself on moin wikis you visit in your user preferences. This is different from the theme, that is part of the site identity, and it make sense that each site want to use one uniqe theme.

I'd also like to mention that Alt-<letter> is not so bad, since you can still easily get to, for example the edit menu, by pressing and releasing Alt, then pressing E. I guess not too many people realize that however... My opinion would be that MoinMoin should not use letters by default, but should allow users to do so if they choose to, either site-wide or for shortcuts on a page. Providing shortcuts for users' QuickLinks would be especially handy, as would customization for global shortcuts on a user-by-user basis... -- SteveDavison 2008-01-30 05:35:15

• You can do that already with ThemeMarket/SimpleMente

Adding links with accesskeys with Link macro

It will take some time until we come up with a good solution. So I create a quick solution, a Link macro, that let you create links to pages with accesskeys. You can use this to create all needed links on your FrontPage to make your site compatible with the UK standard. See MacroMarket/Link.

One disadvantage of this approach is that the accesskeys will be available only on the page you define theme.

• Anyway, MoinMoin will probably never have all the links used in the UK standard in every moin page, this simply does not make sense. For example, there is no need to have a link to FAQ page in every page, but it make sense to put this link in FrontPage and in HelpContents.

  • Why do not you want to have a FAQ key on every page? I think that FAQs can come up at any point on the Wiki.

    • FAQ is not really interesting after you read it once or twice, and it can be accessible from HelpContent, 2 clicks from any page.

User level customization

For Windows users who like to use Alt + Key for menu navigation, turning off accesskeys might be useful. One can choose to use same keys on all sites (Mac OS X has this feature, you can set shortcut keys for all applications).

This will make problems with caching, like any user customization.

Suggested user preferences:

• [x] - Use shortcut keys

Reference

Here's some more reading for consideration:

• Using Accesskeys - Is it worth it?

• More reasons why we don't use access keys

• Access keys and Reserved Keystroke Combinations

• http://www.w3.org/TR/WCAG10-HTML-TECHS/#link-accesskey

• http://www.w3.org/TR/WCAG10-HTML-TECHS/#adef-accesskey

accesskey patch

This patch use standard HTML accesskey attribute recommended by W3C, tested on Mac OS X using Safari and Firefox.

Hotkeys should be available to the important visible links on the page that are used a lot. Here are the list of actions and access keys for English:

• Edit (E) - open an editor with this page
• Show Changes (D) - show last diff
• Show info (I) - show page info, default to revisions list
• Home page (H) - visit user home page (or suggest to create one)
• Search box (F)- jump to the search box
• Main wiki pages (0-9) - the page names and the order can change from wiki to wiki. The first tab will use accesskey "0", the last "9"

This patch also include:

• Localized accesskeys, each language can use different keys - see bellow
• Localized title for each item with accesskey, that show the access key for the item, e.g "Edit this page (E)"

  This patch does not include "special" code per browser.

Problem

• Accesskeys 1-9 use the location of pages and not the page name. Most wikis will use FrontPage as the first page, so accesskey 1 will always work in the same way. But pages like RecentChanges, FindPage, HelpContents and like, can be at any location, and the shortcuts to these pages can change between wikis.

• Often, the page contains multiple links with the same access key. This may not happen as it confuses the screen reader/browser and the user. -- AlexanderSchremmer 2005-03-24 22:18:30

accesskey.patch

localized accesskeys

We can use different accesskeys for each langauge, for example, in English, "Edit" will use "e", and in Hebrew, "ערוך" will use "ע" (located on the G key).

• This can make it easier to remember the key
• On the other hand, can be confusing and harder to remember if you visit one wiki using Hebrew ui, and another with English UI.

Seems that on Mac OS X shortcut keys are NOT localized. I still did not check on the user interface guidlines about this issue.

Please comment on this subject - do we need want this feature?

I first added this feature because its so easy, just add _('E'), but when thinking about it, changing language should not change your shortcut keys. Imagine that you change language, and suddenly Control + C does not work any more on ALL applications.

Good user interface allow you to develop habits - you can act without thinking. If we use constant accesskeys, one can click Alt + E (Control + E on a Mac) on any moin wiki when he like to edit a page, ignoring the user interface language of the wiki. -- NirSoffer 2005-03-15 00:17:22

Yes, I very dislike software that translates keys. Apple used to do that with Final Cut Pro, which is a sin... Consider having to learn a new set of keys for cut and paste.... No, definitely, user defined keys are a good idea, but not localized keys. -- 70.83.13.223 2006-04-21 15:45:55 (AlexandreQuessy)

accesskeys-by-name patch

This patch adds a dict of pagename: accesskey in the wiki config, and use this dict to render pages with accesskeys, both pages that the theme render, and pages that the user add on the page.

There is a localization support for pages the wiki localize for users, for example, if you define accesskey to FrontPage, and an Hebrew user access the wiki and get פתיחה, then the Hebrew page name will use the accesskey you defined for FrontPage.

On the other hand, if the user add a link to a localized page that is not in the accesskeys dict, this page link will not have an accesskey.

This patch work fine for most wikis, when you want to supply one language only, as even international sites have one common language and does not need more than one set of system pages. If you want to supply few other langauges, with accesskey support, you will have to manually add pages to the accesskeys dict.

For full i18n support, this dict should be pre-built from the language files and cached.

accesskeys-by-name.patch

Test patch here: http://nirs.dyndns.org/main/

accesskeys using custom javascript

Solution 1

The kind of code is far from sane and testing that it works on multiple browsers and platforms is great pain. -- NirSoffer 2005-03-14 22:58:29

kbd.js

How does one install this javascript file soas to add the hotkeys to one's wiki?

This javascript support several hotkeys and support the following simple unified Find form --WkPark

 <form name="go" id="go" method="get" action=''>
 <input type="text" name="value" size="20" style="width:100" />
 <input type="hidden" name="action" value="goto" />
 <input type="submit" value="Go" class="goto" style="width:23px;" />
 </form>

Solution 2

For another solution to dynamically add accesskeys to page which can be fully customized by the user just be appending a shortcut definition list to his homepage, see ThemeMarket/SimpleMente. Accesskey customization solves most of the problems of localization, clashing of accesskeys from Moin, browsers, screenreaders.. See also AccessibleMoin for a discussion on that.

Hot Keys

When you press below keys, action applied immediatly.

• D: ?action=diff

• I: ?action=info

• E/W: ?action=edit

• F: FrontPage

• C: RecentChanges

• T: TitleIndex

• H: ?action=home (see ActionMarket)

• <ESC>: goto the 'go' form

• /: FullSearch mode

• ?: TitleSearch mode

Only for Mozilla Browser etc.

• F1: HelpContents

• F3: FindPage

WishList

For localized WikiWikiWeb,

• @@ -43,6 +43,10 @@
  
   //url_prefix="/mywiki";
   //FrontPage="/FrontPage";
  +//RecentChanges="/RecentChanges";
  +//FindPage="/FindPage";
  +//TitleIndex="/TitleIndex";
  +//HelpContents="/HelpContents';
  
   _dom=0;
   //strs="";
  @@ -135,9 +139,9 @@
   //                else
   //                        strs = ""; // reset;
           } else if(_dom !=3 && cc == 112) { // 'F1' Help! (Mozilla only)
  -                self.location = url_prefix + '/HelpContents';
  +                self.location = url_prefix + HelpContents;
           } else if(_dom !=3 && cc == 114) { // 'F3' Find (Mozilla only)
  -                self.location = url_prefix + '/FindPage';
  +                self.location = url_prefix + FindPage;
           } else if(cc == 9 || cc == 27) { // 'TAB','ESC' key
                   if (cc == 27) {
                           document.go.elements[0].focus();
  @@ -157,7 +161,7 @@
                   document.go.elements[2].value="/";
                   }
           } else if(ch == "c") {
  -                self.location = url_prefix + '/RecentChanges';
  +                self.location = url_prefix + RecentChanges;
           } else if(ch == "d" || ch== "i" || ch=="b" || ch=="h") {
                   var my=''+self.location;
                   var idx=my.indexOf("?");
  @@ -177,9 +181,9 @@
           } else if(ch == "f" || ch == 'h') { // frontpage
                   self.location = url_prefix + FrontPage;
           } else if(ch == "s" || ch == 'q') { // findpage
  -                self.location = url_prefix + '/FindPage'
  +                self.location = url_prefix + FindPage
           } else if(ch == "t") { // frontpage
  -                self.location = url_prefix + '/TitleIndex'
  +                self.location = url_prefix + TitleIndex
           } else if(ch=="e" || ch=="w" || ch=="i" || ch=="r") { // Edit or reflash
                   var my=''+self.location;
                   var idx=my.indexOf("?");

-- KkaBi

Nice Idea! But Hotkeys for the SlideShow Extention would be really useful! -- FlorianFesti 2003-06-01 14:50:22

On IE, 'BS' is back to the previous page. (Mozilla? I don't know.)

•         } else if(cc == 9 || cc == 27) { // 'TAB','ESC' key
                  if (cc == 27) {
                          document.go.elements[0].focus();
                  }
                  //strs = "";
                  //document.getElementById("status").innerHTML="";
  +        } else if (cc == 15) { // 'BS' key
  +                history.back();
          } else if(ch == "/" || ch == "?") {
                  if (ch == "?") {
                  // Title search as vi way

-- KkaBi

How other people do it

Dokuwiki

Have a look at how Dokuwiki does it http://wiki.splitbrain.org/wiki:accesskeys?s=alt - I use it daily and I am addicted to using ALT+S to save the currently edited page. Having to grab the mouse and click on 'Save Changes' is a hassle compared to the keyboard shorcut goodness.

Doku also uses Alt-E for Edit. (It doesn't instantly go into edit, but focuses on the button.) I think that's even more handy than Alt-S. -- SteveDavison 2008-01-30 05:35:15

Mediawiki

view page:
 f find

page editor:
 , textarea of editor
 s save
 p preview
 v view changes