To avoid Musculoskeletal disorders(MSDs), we have to redesign our edit-window with float able buttons. Instead of 3 combination keys, if it is a single key that would be great. To activate, those keys we have to make check box in edit-window itself.

Also, the forward/back buttons in the top tab bar should probably have rel="next" and rel="prev" attributes on them. This makes the paging explicit, which is generally good practice and also helpful for browser extensions that provide keyboard shortcuts for paging (like Vimperator and friends).

Side note: because the buttons are labelled "Next page" and "Previous page", the paging shortcuts already usually work with the extensions, but can be broken depending on the presence of other links on the page.

key board shortcuts is a must for navigating in wikisource proof read pages. Let's make this happen with common keys for most popular browsers.!!

This is a brilliant idea!

I think the arrow keys sound suitable. Do they clash with anything though? I mean, I know they're not currently activated on Wikisource, but are there other common usages of these combinations, or other extensions that use them? (As far as I can see, there aren't.)

Sadly, I don't think arrow keys can be used as accessKey attributes, so if you do want arrow keys (which seem like a good idea to me), a JS method might be required. For example, this works for me (but the Shift-Alt prefix is not correct on all platforms):

$(document).keypress(function(e) {
  if (e.shiftKey && e.altKey) {
    switch(e.key) {
      case "ArrowLeft":
        $("#ca-proofreadPagePrevLink a")[0].click();
        break;
      case "ArrowRight":
        $("#ca-proofreadPageNextLink a")[0].click();
        break;
      case "ArrowUp":
        $("#ca-proofreadPageIndexLink a")[0].click();
        break;
    }
  }
});

I would have thought that < and > were promising candidates though I hazard a guess that they are not standard on keyboards

In T186478#3945740, @Samwilson wrote:

I think the arrow keys sound suitable. Do they clash with anything though? I mean, I know they're not currently activated on Wikisource, but are there other common usages of these combinations, or other extensions that use them? (As far as I can see, there aren't.)

Both "Alf+Shift+→", "Alf+Shift+←", and "Alf+Shift+↑" and "Alf+Shift+>", "Alf+Shift+<", and "Alf+Shift+^" (building off of Billinghurst) are compatible with the current list at https://meta.wikimedia.org/wiki/Help:Keyboard_shortcuts but on my keyboard, the key for ">" is ".", which goes to your userpage (that is one I use a lot).

I have written a change to add rel=prev and rel=next: https://gerrit.wikimedia.org/r/#/c/408339/

About shortcut links. "Alf+Shift+→", "Alf+Shift+←", and "Alf+Shift+↑" looks fine to me. if there is no concern about them I could do a change to add them in the next few days.

Does this mean that it has been added to the MediaWiki codebase: https://integration.wikimedia.org/ci/job/mwext-phpunit-coverage-publish/661/console?

@Koavf: No, that was just this patch for adding rel="prev" and rel="next" to the page links. The shortcut keys will come soon.

In T186478#3951655, @Samwilson wrote:

@Koavf: No, that was just this patch for adding rel="prev" and rel="next" to the page links. The shortcut keys will come soon.

Sam, is there any update on this? I know it's a low priority but I'd like to get an ETA please.

Current accesskeys in Page edit mode:

• Comma: focus header. main, footer (yes, all three, only footer works)
• b: summary
• i: minor
• w: watch this
• s: save
• p: preview
• v: show diff
• fullstop: user page
• n: talk page
• l: Watchlist
• y: My Contribs
• h: History
• w: Watch (again)
• d: delete
• m: Move
• =: Protect
• f: Search box
• z: Main page
• r: Recent changes
• j: What links here
• k: Related changes
• u: Upload files
• q: Special Pages

Purge gadget (commonly used):

• *: Purge
• ,:( Purge recursive
• 0: Null edit

Note that keyboard shortcuts for the page view in particular came with the OSD work: https://www.mediawiki.org/wiki/Extension:Proofread_Page/Page_viewer#Keyboard_navigation

This issue is best solved by the use of Autokey in Linux and Autohotkey in Windows 10, and not by adding application based shortcuts. This allows any user to assign whatever they want and need. Sometimes, when I edit in French Wikisource, I simply use another keyboard definition definition file. Using the same key combinations but the scripts which are activated by user assigned key, in French.

I was made aware that having built-in keyboard shortcuts sometimes has adverse affects on accessibility, as they might also clash with cursor navigation or screen readers hotkeys. We might want to proceed with caution on that one.