801035 - Keyboard access for Social API chat windows

Status: RESOLVED FIXED

(Firefox Graveyard :: SocialAPI, defect)

Description

[Jared Wein [:jaws] (please needinfo? me)]

The Social API can have docked chats along the bottom of the Firefox window. We need a way to get keyboard focus on to these chat windows.

One idea is to use Ctrl+Shift+Number to select a chat. This would be similar to how tabs can be selected by pressing Ctrl+Number. If this route is taken, we'll have to figure out how to select overflowed chats, and it also only scales up to 10 chats (0-9).

Comment 1

[Jared Wein [:jaws] (please needinfo? me)]

A potentially better solution would be to put access to all of these chat windows through the same keyboard accessible menu that bug 792503 added.

The downside to this is that it doesn't provide fast switching between chats, the upside is that it is not limited to 10 chat windows and a fixed order of the chat windows.

Comment 2

[Lukas Blakk [:lsblakk] use ?needinfo]

Is this a blocker for the feature?  At this point we have about 3 more weeks where we can accept speculative fixes with time to back out if needed.  So I wouldn't track this if it's a feature enhancement.

Comment 3

[Jared Wein [:jaws] (please needinfo? me)]

I think it's hard to define this as a "feature".

The current scenario is one where keyboard users must tab through the browser to reach the chat bar. The quickest solution for this is to open a new tab, then hit tab a bunch of times until keyboard focus is in the chat tab of choice. (Opening a new tab reduces the potential amount of tabs within the selected page.)

Felipe had a good idea of adding a single keyboard shortcut that would place keyboard focus on the first element within the chat bar, which could be the overflow button or the first chat. This might work and would be pretty simple, but probably introduces a string addition due to the new keyboard shortcut.

With all that said, it's probably too late for Fx17 and there is a (albeit, less than ideal) workaround for Fx17 that already exists.

Comment 4

[:Gavin Sharp [email: [e-mail]]]

I don't think it's too late for fx17 - we can add a shortcut without an associated label/menuitem.

Comment 5

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Patch

This patch adds ctrl+shift+C as the keyboard shortcut for the chatbar. If the chatbar is hidden then the user shouldn't see anything happen. If the chatbar is visible then the first focusable element within it is given focus.

Comment 6

[:Felipe Gomes (needinfo for replies!)]

Comment on attachment 674561 [details] [diff] [review]
Patch

>+<!ENTITY social.chatBar.key "c">

Let's call it commandkey to follow the most common name and better differentiate it from an accesskey

Comment 7

[Jared Wein [:jaws] (please needinfo? me)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/cd2b8f31f59b

Comment 8

[Dão Gottwald [:dao]]

This is pretty useless without the shortcut exposed somewhere, e.g. along side a corresponding menu item.

Comment 9

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 674561 [details] [diff] [review]
Patch

I don't think I would characterize it as useless without a corresponding menuitem, because we can have accessibility documentation that covers the various keyboard shortcuts for the Social API.

I do agree that it would be better to have this visible somewhere though.

Comment 10

[:Gavin Sharp [email: [e-mail]]]

We can probably just add a "Focus chat window" menu item to the keyboard-only menu?

Comment 11

[Dão Gottwald [:dao]]

(In reply to :Gavin Sharp (use [e-mail] for email) from comment #10)
> We can probably just add a "Focus chat window" menu item to the
> keyboard-only menu?

Yes, but note that the keyboard-only concept doesn't work on Mac.

Comment 12

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/cd2b8f31f59b

Should this have tests?

Comment 13

[:Gavin Sharp [email: [e-mail]]]

We can file a followup to expose the shortcut somehow as needed.

Comment 14

[Dão Gottwald [:dao]]

Jared, please file that bug and make it blocking this one. It's needed to complete the intended keyboard accessibility.

Comment 15

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 674561 [details] [diff] [review]
Patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): new feature, wanted for a11y
User impact if declined: keyboard users will have to tab through the Firefox UI to reach the chat bar
Testing completed (on m-c, etc.): on m-c for over a week
Risk to taking this patch (and alternatives if risky): n/a
String or UUID changes made by this patch: Adds an accesskey, I'm not sure what the l10n impact of accesskeys are.

This looks like it missed the possibility of getting uplifted to Fx17 with the rest of the Social API patches, but I'll still request Fx18 uplift since it is tracking-firefox18+.

Comment 16

[u279076]

(In reply to Jared Wein [:jaws] from comment #15)
> This looks like it missed the possibility of getting uplifted to Fx17 with
> the rest of the Social API patches, but I'll still request Fx18 uplift since
> it is tracking-firefox18+.

I know Firefox 17b4 is said to be "Social API feature complete" but I'd really like to see this get uplifted for 17b5 if we can. Having this gap in accessibility isn't a show stopper for Firefox 17 but I'd like to close this gap if we can.

Comment 17

[:Gavin Sharp [email: [e-mail]]]

We discussed this in triage, and the accessibility win seems minor - not significant enough to break l10n freeze (and hardcoding the shortcut risks conflicting with other existing ones).

Comment 18

[u279076]

Fair enough. Thanks for the consideration, Gavin.

Comment 19

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 674561 [details] [diff] [review]
Patch

For the same reason, I think we don't need this on Aurora. We'll work on a better shortcut story on trunk.