AFAIK things like "Copy link location", "Copy image location" and "Open link in new browser" are *only* accessible from the context menus, this is wrong, context menus should only be "shortcuts", but everything you can do from the context menus should be possible to do without them.

Reassign to German for now. I'm not sure what to do about this one. I'm assuming this involves all components (Browser, Mail, AIM, AB, etc.) As far as the examples, i'm not sure how you select a link without opening it, so you can access a menu item? There generally are other ways to do theses things they are just more complicated. The context menu provides an easier way/or shortcut. "Copy link location" - open link, then copy URL "Copy image location" - open image location, then copy URL "Open link in new browser" - ?

It is (or should be, and has been) possible to navigate between links on a page with the "tab" key, so to "open link in new window" you tab to the link of interest and push the alt key to get to the normal menu and select "open link in new window" from there, I would imagine that this is really important to people who are unable to use a pointing device (and also for keyboard only web-tv like devices).

Cc'ing Lake, who is resonsible for the Keyboard navigation spec. http://gooey/client/5.0/specs/keyboard/kybdnav2.htm

QA Assigning non-confidential New/Assigned User Interface: Design Feedback bugs to Matthew Thomas (mpt@mailandnews.com). Matthew Thomas is now the QA owner for the User Interface: Design Feedback component. (Bugs that involve UI issues in the Netscape-branded Mozilla browser should continue be QA assigned to elig@netscape.com.)

`IMPORTANT: Contextual menus should never supersede menu bar items; there shouldn't be any items in a contextual menu which are not also accessible through the menu bar' <http://developer.apple.com/techpubs/mac/HIGOS8Guide/thig-56.html>. `Right-click context menus are a useful addition to interfaces. They are intended to be an alternative means of accessing functions; as shortcuts, primarily for advanced users. They should never be required, and should always be used in conjunction with conventional menus. Otherwise, new users might never realize the functions are available, and they will have no keyboard access to the functions once they find them' <http://iarchitect.com/controls.htm#CONTROLS4>. However, no Web browser that I know of has ever actually managed to follow this guideline, because there are a huge number of context menu items which apply only to (for example) an image which is part of a link, and putting them in the main menus could cause a fair bit of clutter with items which are hardly ever enabled. And to some extent, this bug would be solved by bug 36665, `Keyboard access to context menu' -- that still wouldn't work for the context menu for images though, since images in themselves are not something you can tab to. If German accepts this bug, it will probably become a tracker for finding places in the main menus for all the various context menu items.

set to M18 for after PR2 fix.

For the reasons Matt mentions in his last paragraph I think contextual menus have been used in browsers to not only provide shortucts to otherwise accessible items but also to provide target specific options. The older guidelines from MacOS make sense but Browsers are different from other apps like e.g Word or Draw programs as many items on a document cannot be selected without activating them, hence there is not main menu way of reflecting the selection and enabling the appropriate commands. It otherwise would result in enourmous menu clutter if we had to make every single option accessible to say a region which is in an image map in an image which is in a cell which is in a table which is in a frame etc etc. So I agree that while not strictly conformant it provides the most usable solution.

I think this bug is invalid for the aformenetioned reasons. there will always be items that only apply to the item being moused over and would overly cluttere the menu as they are too specific.

Verified invalid. This is ok on an acessibility level only as long as it is possible to access all the context menus using the keyboard, by giving focus to them and then using bug 36665. I've just filed bug 58997 for giving focus to images in Web pages for this purpose; please file other bugs if there are other areas where it is not possible to give focus to a particular area which has its own context menu. (Toolbars don't count.)

So what is the reasoning here, is it that selecting/focussing them is impossible, or that the menus would be too cluttered? We have to do the keyboard focus work for accessibility, so it will not be impossible. Some of these items have been selectable/focussable all along, so I don't understand how that argument ever applied. The clutter argument sounds like it could be better solved by either trimming some feature bloat, or only offering the menu item when the element is focussed. The invalid resolution makes me wonder if UE just disagrees that significant common features should be in the main menus. If that is the case, why not say so? Just curious...

The menus would become too cluttered. Consider, for example, where you'd put `Copy Image Location', or `Add Bookmark for Link', or `Show Only this Frame', in the main menu bar. > Some of these items have been selectable/focussable all along, so I don't > understand how that argument ever applied. Because you have never been able to focus images (bug 58997). > The clutter argument sounds like it could be better solved by either trimming > some feature bloat, If you tried to remove such features as `Copy Image Location', or `Add Bookmark for Link', or `Show Only this Frame', I think people would scream. > or only offering the menu item when the element is > focussed. If you mean enabling/disabling the menu items, that wouldn't save any clutter. And if you mean actually showing/hiding the menu items, I imagine that would contravene just as many HIGs as the current behavior. :-)

(In reply to Matthew Paul Thomas from comment #11) > The menus would become too cluttered. Consider, for example, where you'd put > `Copy Image Location', or `Add Bookmark for Link', or `Show Only this > Frame', > in the main menu bar. In an "Item" or "Object" menu, rather on the right. A nice way to provide the contextual menu actions related to the right-clicked item to the people who cannot right-click.

> A nice way to provide the contextual menu actions related to the right-clicked item to > the people who cannot right-click. Shift-F10 opens the context menu. Also most Wintel keyboards have a context menu key these days.