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).
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.
tracking-firefox17: --- → ?
tracking-firefox18: --- → ?
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.
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.
tracking-firefox17: ? → ---
I don't think it's too late for fx17 - we can add a shortcut without an associated label/menuitem.
Created attachment 674561 [details] [diff] [review] 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 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
Attachment #674561 - Flags: review?(felipc) → review+
This is pretty useless without the shortcut exposed somewhere, e.g. along side a corresponding menu item.
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.
We can probably just add a "Focus chat window" menu item to the keyboard-only menu?
(In reply to :Gavin Sharp (use firstname.lastname@example.org 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.
https://hg.mozilla.org/mozilla-central/rev/cd2b8f31f59b Should this have tests?
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Whiteboard: [leave open]
We can file a followup to expose the shortcut somehow as needed.
Target Milestone: --- → Firefox 19
Jared, please file that bug and make it blocking this one. It's needed to complete the intended keyboard accessibility.
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+.
Attachment #674561 - Flags: approval-mozilla-aurora?
(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.
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).
Fair enough. Thanks for the consideration, Gavin.
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.
Attachment #674561 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora-
You need to log in before you can comment on or make changes to this bug.