(Oops, accidentally sent the above incomplete comment as part of renaming the bug. Here's the complete comment.)
*Ah, thank you. I've adjusted it to 'access key' now. (It might be redundant to have 'context menu' in the title as well, but I've left it there so the issue is more clearly visible to users unfamiliar with the term.)
(In reply to CronoCat from comment #33)
If accessibility is a concern for folks who mouse with their left hand, why not just have two underlines, or allow natively allow customization?
Thank you for the historical context! I thought I'd seen two underlines recommended earlier, though I can't find the comment now. I'm not sure whether or not this has technical precedence, but if so, it's an option.
Native customization I discussed earlier in comment 9. I'm in agreement that it is the best option if accessibility is a concern, which, gauging by the impact-reach of this change (for QWERTY/right-hand mouse users, anyhow), it probably ought to be. However, I don't feel it's as 'on the table' as other solutions, since a feature of that scale would probably have to go through much design time Mozilla / the Firefox devs would be more interested in spending elsewhere. If it is of interest to them, I'm all for it! I'm only doubtful of this as a prompt fix for those currently affected.
Similar goes for foundational support for addons which customize access keys, ala the XUL days, as you brought up. Leaving design up to the community allows users to choose which UI they are most comfortable with, and propose improvements amongst themselves -- but it would likely be contrary to the current direction of addons, or otherwise difficult to integrate cleanly. Again, this would be a long ways off for those currently affected, but it's still a nice goal, and could well be part of a grander response to the community's concern with Firefox lacking customizability it had in past. (Ditto for native customization options.)
(In reply to Mathew Hodson from comment #35)
Using 'C' would conflict with the Copy menu item. That's why it was changed from 'C' in bug 410973, and that reasoning still applies.
Ah, got it. I'd assumed 'Copy' and 'Copy Link' would never show up simultaneously, but this is apparently still possible (drag to create a selection, then right-click a link). I suppose dynamically disabling that shortcut (leaving the only remaining one, such as current 'L') if the 'Copy' option is present is off the table?
It may be counterintuitive to have shortcut 'C' refer to both copying text, i.e. what is visible on-screen, as well as links, i.e. something not immediately visible. This gives some additional strength to using an altogether unique access key, even if it isn't a character visible in the 'Copy Link' label.
(In reply to L. James from comment #36)
May we consider why Ctrl+D is used for bookmarking? Is it because 'bookmarks' contains a D? Rather, it is because 1) It's an easily-accessible key for the majority of users 2) It is well-established and familiar. I stand by this logic.
Similar goes for Copy/Paste, which are Ctrl+C/V rather than Ctrl+C/P. (I'm actually not not sure if either of these were originally made with QWERTY-accessibility in mind, but they've certainly took on that role over time—as you mentioned, familiarity.)
Context menus are a somewhat different scope, but I'm in agreement that we can still learn from these arguments. Familiarity can get in the way of progress towards otherwise better solutions; however, here, the concern is a very minor feature which has notable impact on a significant group of people. In order to reasonably set aside familiarity, I feel a solution which does not leave the familiar group under the bus is due—or else you'll bring difficulty and upset to that group. Since all-out native customizability, while a powerful feature to aim for, is probably too much to design and implement as a prompt fix for one inconvenience, I feel keeping with what's familiar may reasonably take priority.