ACCESSKEY allows users to access links, buttons, and form elements through hotkeys (such as Alt-ACCESSKEY on PC or Ctrl-ACCESSKEY on Max, where ACCESSKEY can be any single character). Bug 56701 makes a good point that ACCESSKEYs are largely useless without a visual indicator. However, that primarily applies to sites that the user doesn't visit often. With intranets (or Bugzilla) users can simply be told about the ACCESSKEYs manually, either through extra text on the webpage, or through a glossary page. ===== As for specifics, here're just a few ideas for ACCESSKEY asssignments: Product-field: ACCESSKEY-r (I feel Platform is more deserving of "p") Component-field: ACCESSKEY-o (since "c" is taken) QA-field: ACCESSKEY-q URL-field: ACCESSKEY-u Summary-field: ACCESSKEY-s Status-whiteboard-field: ACCESSKEY-t (or "ACCESSKEY-w"?), since Summary has "s" Keywords-field: ACCESSKEY-k Depends-on-field: ACCESSKEY-d Blocks-field: ACCESSKEY-b Additional-comments-field: ACCESSKEY-a Platform-field: ACCESSKEY-p OS-field: ACCESSKEY-s? (it looks like "o" is already Component) Version-field: ACCESSKEY-v Priority-field: ACCESSKEY-i (since "p" is Platform and "r" is Product) Severity-field: ACCESSKEY-e? (since "s" is already Summary) Target-milestone-field: ACCESSKEY-t Add-CC-field: ACCESSKEY-c Commit-button: ACCESSKEY-m? (since "c" is already CC and "o" is already Component) ==== Well, those are just a few ideas.

see bug 96990. Recommending WONTFIX for the reasons stated in the comments on that bug (2001-08-28 11:41) when you suggested this last time :-) but I'll leave it open for a little bit in case someone can prove me wrong. Anyone have some stats on how well these work on various modern browsers?

Dave: In due fairness, this bug has nothing to do with bug 96990 ;). As for ACCESSKEY support, I have researched this subject. There are varying levels of browser support for ACCESSKEY. Netscape 4 doens't support ACCESSKEY at all (no surprise there, eh?). However, Netscape 4 just treats the links normally, so no harm is done if ACCESSKEY is included. On the other hand, both IE 5 and Mozilla / Netscape 6 fully support ACCESSKEY.

I know it has nothing to do with that bug, but you suggested doing this in a comment in that bug and I said why I didn['t think it would work there. OK, can you explain to me why modifier is used to access an ACCESSKEY in which browsers? For example, what I'm thinking would cause problems is that on a Mac, you use Command-C to copy and Command-V to paste. On a PC I normally do the same with Control-C and Control-V. If ACCESSKEY uses the Command key or the Control key depending on platform (which it sounds like it should from the spec) and you set something to have an ACCESSKEY of C then what happens when I try to copy something? Does the browser ignore the ACCESSKEY because it already uses that key for something or does the webpage override? Or is it actually using a different modifier key?

ok, re-reading your comment, looks like it does Control on the Mac and ALT on the PC. But doesn't that still conflict on the PC side? (it won't on Mac). I thought Windows used the ALT key to access menus and such...

ALT is menus on PC... which means that there has to be a set that isn't used by top-level menus in any major broswers. (FWIW, almost all Win32 apps use ALT for any "internal" accesskey stuff on buttons/labels as well as menus).

Jake: As mentioned in bug 40071, ACCESSKEYs override any menu shortcuts. So, for instance, if someone setup Alt-F as an ACCESKEY for a link, then Alt-F would activate that link instead of the "File" menu for that page. However, that's not necessarily a bad thing. It may be beneficial, for instance, to be able to hit Alt-S and get the "Summary" form-field. CC: Angus, to assist in Accesskey evangelism :).

Personally I think overriding menu shortcuts is a bad thing. But since the Mac browsers use the Control key, which isn't used for shortcuts on the Mac, I care less now, since I use a Mac, personally. :) I won't raise objections unless there's Windows users reading this that object to having their menu shortcuts overridden.

I think "comment" should be C and "add cc" should be A, rather than the other way around.

> Personally I think overriding menu shortcuts is a bad thing. There are only a certain number of meta keys on a keyboard :-). The question is, what's the win here? To enable people to use Bugzilla faster? To enable people to use Bugzilla without a mouse (if so, are there other things we need to look at as well)? To enable disabled people to use Bugzilla? Gerv

Gerv: My opinion is that ACCESSKEY support is very important indeed. It enables quite a few wins, but the one that IMHO is most relevant to bugzilla should be allowing relatively easy keyboard control. One example is bug form submission - the button is very small and you are usually typing into the textarea when you want to submit. A shortcut for submits would be _very_ welcome. Other examples are for marking new/assigned/fixed, accessing your stored queries, and the major navigation options (search/new). I sincerely hope we don't WONTFIX this as we close the opportunity to make Bugzilla much more usable at very little expense. I quote mpt: <mpt> kiko: Indeed it is wrong.

mpt, what should be ACCESSKEYed, and how could we avoid UA clashes?

You can't possibly avoid clashes between ACCESSKEYs of a Web app and the access keys of the menus of every single localization of every single ACCESSKEY-supporting browser. Avoiding such clashes is the job of the browser, not the job of the Web page, and in bug 51940.2000-09-16 I described how MSIE does it and Mozilla should do it. (If Mozilla on Windows or X isn't following that behavior, please file a bug.) Given that, I think Bugzilla should use ACCESSKEY everywhere.

Okay, but could we be more specific about what elements we want to concentrate on the first round of implementation, and what would be most useful? How is visual feedback on ACCESSKEY right now?

Christian: Since bug 56701 is still pending, there is currently no visual indicator. So, in the short run, we may have to provide that manually, such as: * A bolded letter * A different colored letter * A double-underlined letter

OK, I think I'm convinced here.

Noooo, please don't provide Bugzilla-specific highlighting of access keys, otherwise you'll mess up the UA highlighting when UAs get their act together.

mpt: Not even highlighting /until/ UAs get their act together? Well, even if that's the case, I'd still like to have ACCESSKEY support.

I don't disagree; it is essential. This bug should be used as a tracker for smaller, individual-page ACCESSKEY implementations. Feel free to hack on your favorite page, but be careful not to be clobbered by template work.

Here are my suggestions, based on Alex's. My methodology was to allocate all the first letters to the most used thing which began with them, and then see what's left. Product: ACCESSKEY-r (Only choice left) Component: ACCESSKEY-m (Choice: mne) (This is fine; Product and Component change relatively infrequently.) QA: ACCESSKEY-q URL: ACCESSKEY-u Summary: ACCESSKEY-s Status Whiteboard: ACCESSKEY-w Keywords: ACCESSKEY-k Depends-on: ACCESSKEY-d Blocks: ACCESSKEY-b Additional Comments: ACCESSKEY-a Platform: ACCESSKEY-p OS: ACCESSKEY-o Version: ACCESSKEY-v Priority: ACCESSKEY-i (Choice: iy) Severity: ACCESSKEY-e (Choice: eiy) Target Milestone: ACCESSKEY-t Add-CC: ACCESSKEY-c Commit: No accesskey required. The changes from Alex's scheme are: O for OS because it's an initial letter M for component because it's a strong consonant Commit has no accesskey, because "Enter" when any form element is focussed (except Additional Comments) submits the form. The problem then becomes how to indicate the letters. Bolding won't work, as all the field titles are bold. Underlining won't work at the moment in many cases, because many field titles are Help links. This second problem will go away with the new Help system (bug 114179) so we should use underline. Patch coming up. Gerv

Gerv: If accesskeys are also going to be used on the Bugzilla Query page (which they may as well), then it may indeed be handy to have an accesskey for "Commit" (because hitting enter will just trigger "Add another boolean", at least until bug 28763 goes live).

OK, C was already the accesskey for the Additional Comments field, so for backwards compatibility (and, in hindsight, sense) I swapped with add CC so now Additional Comments is C, and Add CC is A. You will note I've used <label>s for the <select> elements - <select> does not support accesskey, according to HTML 4.01. So why didn't we put the <label> tags around the actual labels for each box? Because accesskey doesn't work across <td> boundaries. I've used restyled <em> elements to highlight the accesskeys. This is good because: a) <em></em> is shorter than <span class="accesskey"></span> b) The keys do need emphasis, so it's semantically OK. Gerv

OK, so <u> is far more sensible than <em>. Gerv

Alex - didn't see your comment. But the new query interface will go live in a month or so on b.m.o - and it's the default for everyone else anyway. The right way to submit forms is Enter; we shouldn't work around temporary form layout brokenness. Checked in on the bug page. Checking in template/en/default/bug/edit.html.tmpl; /cvsroot/mozilla/webtools/bugzilla/template/en/default/bug/edit.html.tmpl,v <-- edit.html.tmpl new revision: 1.15; previous revision: 1.14 done Gerv

Using this bug for show_bug; the tracking bug is bug 159199. Gerv

Could someone enlighten me whether "=>" or "=" is correct? bug/edit.html.tmpl: [% PROCESS select selname => "version" accesskey => "v" %] [% PROCESS select selname => "priority" accesskey => "i" %] [% PROCESS select selname = "bug_severity" accesskey => "e" %] [% PROCESS select selname = "target_milestone" accesskey => "t" %]

The equals sign by itself (=) is correct.