Missing keyboard shortcut for navigation

Bug #359180 reported by Milo Casagrande
16
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Launchpad itself
Fix Released
Medium
Adi Roiban

Bug Description

This is more a wish-list rather than a bug.

Would be useful if the First - Previous - Next - Last link in the translation interface had a keyboard shortcut for fast accessing them. Don't need to be visible, but at least documented somewhere.

Maybe even the Save & Continue button.

Related branches

Milo Casagrande (milo)
description: updated
Revision history for this message
Данило Шеган (danilo) wrote :

Completely agreed (I was just thinking about that as well): for 3 of these, we should be able to use standard HTML LINK elements with types "Prev", "Next" and "Start" (see http://www.w3.org/TR/html4/types.html#type-links). We could also try to figure out good "accesskey" values for them.

I'd like to have even more than that but that would require a bit more thinking.

Changed in rosetta:
importance: Undecided → Medium
status: New → Triaged
tags: added: trivial ui
Revision history for this message
Milo Casagrande (milo) wrote : Re: [Bug 359180] Re: Missing keyboard shortcut for navigation

Il giorno lun, 13/04/2009 alle 10.40 +0000, Данило Шеган ha scritto:
> Completely agreed (I was just thinking about that as well): for 3 of
> these, we should be able to use standard HTML LINK elements with types
> "Prev", "Next" and "Start" (see http://www.w3.org/TR/html4/types.html
> #type-links). We could also try to figure out good "accesskey" values
> for them.

Interesting to note that there's a "Start" but not and "End" or a "Last"
for "the last document in a collection of documents". Wonder why.

For the access keys, what about:

_First _Previous Ne_xt _Last

and

Sa_ve & Continue

> I'd like to have even more than that but that would require a bit more
> thinking.

That would be interesting to have the tabs on top (Overview, Code, Bugs,
Blueprints...) and also the 4 buttons in the translation template
(Description, Translate, Upload a file, Download).

Revision history for this message
Данило Шеган (danilo) wrote :

I was more thinking of things like jumping between messages (today, if you use TAB, you get to the next input field, which can really slow you down). And then also stuff like "next untranslated", "next with a suggestion", etc.

Revision history for this message
Milo Casagrande (milo) wrote :

Данило Шеган ha scritto:
> I was more thinking of things like jumping between messages (today, if
> you use TAB, you get to the next input field, which can really slow you
> down). And then also stuff like "next untranslated", "next with a
> suggestion", etc.

Oh wow... that would be definitely great and improve a translator
experience.

--
Milo Casagrande <email address hidden>

Revision history for this message
Adi Roiban (adiroiban) wrote :

I don't think that type links are well supported on major browsers. We have them in Lynx and Opera but I was not able to see them on a standard Firefox or Chromium... don't remember seeing them on Epiphany.

The problem with accesskey is that can conflict with menu accelerators.
Ex. we can not use _First with acesskey="f" as Alt+F will open the file menu on most menus.

Since menu accelerators are configurable and they change with the localization a safe pick will be using characters like [];'\,./
While they are mapped on a US keyboard not all keyboard layout have a direct access for them. Ex in DE / is SHIFT+7

At least on Linux, accesskey conflicts with menu accelerators can be avoided by using SHIFT+ALT+ACCESSKEY

It would be nice to have the most frequent link mapped to shortcuts that can be typed with a single hand :)

_First
_Previous
N_ext - Frequent
_Last
_Save & Continue - Frequent

What do you say ?
I can write the required patch if needed.

Revision history for this message
Milo Casagrande (milo) wrote :

2009/11/26 Adi Roiban <email address hidden>:
> I don't think that type links are well supported on major browsers. We
> have them in Lynx and Opera but I was not able to see them on a standard
> Firefox or Chromium... don't remember seeing them on Epiphany.

Actually I don't know, but type-links are in HTML4, so any browser
that is compliant with that spec should support them.
We probably need to do some research on the matter.

> The problem with accesskey is that can conflict with menu accelerators.
> Ex. we can not use _First with acesskey="f" as Alt+F will open the file menu on most menus.

I think that you are not supposed to access a web page access-keys
with Alt+KEY, but you have to use Alt+Shift+KEY, in almost all
browser.
I do remember that IE has a different way to access them, but
definitely not Alt+KEY, that's for menu entries.

> Since menu accelerators are configurable and they change with the localization a safe pick will be using characters like [];'\,./
> While they are mapped on a US keyboard not all keyboard layout have a direct access for them. Ex in DE / is SHIFT+7

Personally I wouldn't take that path, using "wild-chars" is not
natural for browsing a UI, nor I think it would be for a web page.

> At least on Linux, accesskey conflicts with menu accelerators can be
> avoided by using SHIFT+ALT+ACCESSKEY

I tested a web site that I know has access-keys, and even if they do
not conflict with the menu ones, you have to use Alt+Shift+KEY.

> It would be nice to have the most frequent link mapped to shortcuts that
> can be typed with a single hand :)

I don't think we should block on "single hand" shortcuts though... it
can be almost impossible to achieve for all: different keyboard
layouts have keys at different positions.

> _First
> _Previous
> N_ext     - Frequent
> _Last
> _Save & Continue    - Frequent
>
> What do you say ?
> I can write the required patch if needed.

That would be great! :-)

--
Milo Casagrande <email address hidden>

Revision history for this message
Milo Casagrande (milo) wrote :

2009/11/29 Milo Casagrande <email address hidden>:
> I think that you are not supposed to access a web page access-keys
> with Alt+KEY, but you have to use Alt+Shift+KEY, in almost all
> browser.
> I do remember that IE has a different way to access them, but
> definitely not Alt+KEY, that's for menu entries.

"almot all browser" was not right.

In IE you access them with Alt+KEY+Enter. Other browsers, like Safari
or Chrome, use only Alt, but Chrome doesn't have menu entries, and in
Safari (on Mac) you have them all in the top bar that you access in a
different way. Other browsers access them with Ctrl+KEY, but you have
to release the modifier key before...

Here is the complete list:

http://en.wikipedia.org/wiki/Access_key

and all the accessibility features of browsers:

http://en.wikipedia.org/wiki/Comparison_of_web_browsers#Accessibility_features_.28cont..29

--
Milo Casagrande <email address hidden>

Revision history for this message
Adi Roiban (adiroiban) wrote :

First attempt:

tabindex 1 - cycle through input and textarea
tabindex 2 - Save and continue button

accesskey s - Save and continue
accesskey f - Focus the search field

accesskey r - Go to first
accesskey n - Go to next
accesskey p - Go to previous
accesskey l - Go to last

Here is an excelent resource about tabindex implementation in browsers
http://www.weba11y.com/blog/2009/07/02/more-fun-with-the-tabindex-attribute/

What do you say?

Revision history for this message
Milo Casagrande (milo) wrote :

2009/11/30 Adi Roiban <email address hidden>:
> First attempt:
>
> tabindex 1 - cycle through input and textarea
> tabindex 2 - Save and continue button
>
> accesskey s - Save and continue
> accesskey f - Focus the search field
>
> accesskey r - Go to first
> accesskey n - Go to next
> accesskey p - Go to previous
> accesskey l - Go to last
>
> Here is an excelent resource about tabindex implementation in browsers
> http://www.weba11y.com/blog/2009/07/02/more-fun-with-the-tabindex-attribute/
>
> What do you say?

Sounds great!

One thing: what to you exactly mean with "input and textarea"?
The input intended as all the input fields in the page or some
particular input fields?

--
Milo Casagrande <email address hidden>

Revision history for this message
Adi Roiban (adiroiban) wrote :

Sorry for bad wording "input and textarea" means "New suggestions" or "New translations fields".

After each page load, pressing Tab key will focus the first translation field.
Pressing Tab key again will get you to the next translation of the next plural form.

Maybe we can also auto-focus the first translation field.

Changed in rosetta:
assignee: nobody → Adi Roiban (adiroiban)
status: Triaged → In Progress
Revision history for this message
Данило Шеган (danilo) wrote :

Sounds good, I am just a little bit worried about accessibility: how
well will this work with screen readers and such? (I have no idea, but I
feel the question should be asked!)

Revision history for this message
Adi Roiban (adiroiban) wrote :

From the screen readers point of view there should be no changes. There are just some keybindings and tab ordering.

Type links are already implemented in the general pagination/batching links... but the support for type-links is really bad in current browsers.

Danilo, should I "push" them as a merge proposal.

Revision history for this message
Данило Шеган (danilo) wrote :

Screen readers, as far as I know, go through focused elements when reading out labels and such. Tab ordering might make it impossible/hard to focus on elements such as labels and or information fields (though, I hope screen readers can read the actual labels when they are on a form field).

In general, we can get this in and then later fix it if it causes any issues. Still, it'd be best if somebody can check this for us so we know for sure that we are not breaking user experience for anybody.

Revision history for this message
Adi Roiban (adiroiban) wrote :

Searching the internet it looks like there are some problems.

Do you know someone using Launchpad Translation with a screen reader to ask for some ideas?

I was thinking to use yui3 key events, but it looks like the YUI Key Events library is not loaded.
What is the policy of adding new YUI3 component?

Revision history for this message
Adi Roiban (adiroiban) wrote :

I have linked a new branch from db-devel, where we have the release version of YUI3.

This is just a prototype to see if is feasible to fix this bug using YUI3 event-key.

setFocusField js function should be renamed and moved to lp.pofile .

Also we can add keybinding like in PoEdit - Ctrl + Down , Ctrl + Up, Ctrl + C

This will not interfere with tabindex and will give us more power for keybindings.

The first element to be focused is implemented in the template and I think this can be moved in the view.

The way of finding next element to be focused is a bit of a hack... but I think it is much simpler doing this way, than constructing the chain in the view.

When you have time, please drop your feedback :)

There is no hurry, as we don't have the final YUI3 on edge.

Cheers

Revision history for this message
Данило Шеган (danilo) wrote :

As long as it doesn't conflict regular key combinations people have, I think that's fine. However, combinations you listed for PoEdit do sound risky. Also, if it's something people can accidentally hit (i.e. Ctrl + Down can easily be pressed if you pressed Ctrl + C and then wanted to scroll down using the arrow key), we should do it in a very smart way. I.e. the first time someone uses it, we should show them a pop-up explaining important shortcuts on the page. Then, they should have an option to either dismiss it forever, or be reminded again the next time they use the shortcut. Well, "forever" can be relative: I think it'd be enough if it was tied to a browser session through a JS cookie.

Revision history for this message
Adi Roiban (adiroiban) wrote :

Here we are:

Shift+Alt+1 - First
Shift+Alt+n - Next
Shift+Alt+p - Previous
Shift+Alt+l - Last
Shift+Alt+Down - Next field
Shift+Alt+Up - Previous field
Shift+Alt+C - Copy original text (both singular and plural)
Shift+Alt+S - Save and continue

First field is autofocused.

----

I went for Shift+Alt as they are used for Acceskey, and I assume browsers will try to reserve them.

Adi Roiban (adiroiban)
Changed in rosetta:
status: In Progress → Fix Committed
Revision history for this message
Ursula Junque (ursinha) wrote : A commit mentioned this bug
tags: added: qa-needstesting
Ursula Junque (ursinha)
Changed in rosetta:
milestone: none → 10.01
Revision history for this message
Adi Roiban (adiroiban) wrote :

Since Milo pointed out that Shift+Alt Up / Down is used by compiz, I was thinking to use the vim navigation keys.

Shift + Alt + j - Go down
Shift + Alt + k - Go up

Pros and cons for this keybinding?

Revision history for this message
Milo Casagrande (milo) wrote :

I've dome some other tests:
- Shift-Alt-n and p work, but it's not really straightforward: there is no "visible" action after I press Shift-Alt-n, apart from the link in the status bar (and then I have to press Enter)
- The Shift-Alt-l and 1 don't work with Firefox as expected, not even with Epiphany from jhbuild.

Shift-Alt-[kj] looks OK to me with Ubuntu and Compiz activated... for now they look unused.

Revision history for this message
Adi Roiban (adiroiban) wrote :

There is another problem. If there is an „untranslatable” field (ex translation credits) the field order is broken as no key event is registered for it and it is not skipped.

tags: added: qa-bad
removed: qa-needstesting
Revision history for this message
Adi Roiban (adiroiban) wrote :

As noted in bug 512698, if LP doesn't know about plural forms, the latests changes for this bug are generating an Oops.

We will not include the landed branch into these release.

The new branch should fix these problems and should also look into creating a test page for +translate when there are no plural forms.

Curtis Hovey (sinzui)
Changed in rosetta:
status: Fix Committed → Fix Released
Adi Roiban (adiroiban)
Changed in rosetta:
status: Fix Released → In Progress
Revision history for this message
Adi Roiban (adiroiban) wrote :

Since accesskey behavior is not consistent on all browsers, I have used YUI event-key for all actions.

I have also added keybinding for reviewer workflow.

        // Shift+Alt+s - Save form
        // Shift+Alt+f - Go to search field
        // Shift+Alt+b - Go to first translation field
        // Shift+Alt+n - Go to next page in batch
        // Shift+Alt+p - Go to previous page in batch
        // Shift+Alt+a - Go to first page in batch
        // Shift+Alt+l - Go to last page in batch

        // Shift+Alt+j - Go to next translation
        // Shift+Alt+KEY_DOWN - Go to next translation
        // Shift+Alt+c - Copy original text
        // Shift+Alt+r - Toggle someone should review
        // Shift+Alt+d - Toggle dismiss all translations
        // Shift+Alt+0 - Mark current translation
        // Shift+Alt+NUMBER - Mark suggestion NUMBER (only for 9 suggestions)
        // Shift+Alt+KEY_UP - Go to previous translation
        // Shift+Alt+k - Go to previous translation

Adi Roiban (adiroiban)
tags: removed: qa-bad
Revision history for this message
Ursula Junque (ursinha) wrote : Bug fixed by a commit
Changed in rosetta:
milestone: 10.01 → 10.03
status: In Progress → Fix Committed
tags: added: qa-needstesting
Revision history for this message
Adi Roiban (adiroiban) wrote :

Here are the current keybindings:

First field is autofocused.
Shift+Alt+b - Focus first translation field
Shift+Alt+a - First page
Shift+Alt+n - Next page
Shift+Alt+p - Previous page
Shift+Alt+l - Last page
Shift+Alt+s - Save and continue
Shift+Alt+Down - Next field
Shift+Alt+Up - Previous field
Shift+Alt+j - Next field
Shift+Alt+k - Previous field
Shift+Alt+C - Copy original text (both singular and plural)
Shift+Alt+0 - Mark current translation
Shift+Alt+NUMBER - Mark suggestion NUMBER
Shift+Alt+d - Dismiss all suggestions
Shift+Alt+r - Tick "Someone should review this translation"

Revision history for this message
Milo Casagrande (milo) wrote : Re: [Bug 359180] Re: Missing keyboard shortcut for navigation

2010/3/17 Adi Roiban <email address hidden>:
> Here are the current keybindings:
>
> Shift+Alt+a - First page

I have a problem with this one, it gets one of the menu in Firefox
(Firefox with Italian translation though).

> Shift+Alt+s - Save and continue

With Firefox it gets one of its menus.

> Shift+Alt+Up - Previous field

Problem with this one too on Firefox/Ubuntu and compiz enabled: looks
like it's a compiz shortcut...

> Shift+Alt+NUMBER - Mark suggestion NUMBER

I can get this one to work...

The others work pretty well.

Thanks Adi!

--
Milo Casagrande <email address hidden>

Revision history for this message
Henning Eggers (henninge) wrote :

Thanks Adi, playing around with this is really great! Having these short cuts will really improve work, I like it.

But I have similar problems as Milo. Some short cut collide with (German) Firefox menus. I have a feeling "Shift+Ctrl" would be a safer choice? I don't have that problem in Epiphany, btw, but that does not help when Firefox is the default browser in Ubuntu...

Also, the combinations with the numbers don't work at all for me, the radio button always jumps to the input field. Same for "dismiss all suggestions". Could it be possible that this is colliding with the fix for bug 540105?

Revision history for this message
Curtis Hovey (sinzui) wrote : Bug 359180 Fix released

Fixed released in launchpad-project 10.03.

Changed in rosetta:
status: Fix Committed → Fix Released
Revision history for this message
Adi Roiban (adiroiban) wrote :

Hi Henning,

Shift+Ctrl will not work as it is heavily used in Firefox for menu shortcuts, together with Ctrl.

Ctrl+Alt is used by window managers.

I went for Shift+Alt because it is used by HTML access keys and I was thinking that web browsers and window managers will not use those key bindings.

Revision history for this message
Adi Roiban (adiroiban) wrote :

Shift+Alt+NUMBER - Mark suggestion NUMBER , is working now in Firefox.

The only outstanding issues are:
 * the overlapping of „Shift+Alt” with Windows change keyboard layout
 * the overlapping of „Shift+Alt” with Firefox menu accelerators
 * the lack of documentation for the keyboard shortcuts

Revision history for this message
Sophea Sok (sksophea) wrote :

I'm using Firefox browser version 34 but I still can't use all those shortcut keys, such as Shift+Alt+s to Save & Continue. Does anyone have solution?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.