Closed Bug 102648 Opened 23 years ago Closed 22 years ago

Show_bug should include ACCESSKEY

Categories

(Bugzilla :: Creating/Changing Bugs, enhancement, P3)

Product:
Bugzilla
Component:
Creating/Changing Bugs
Version:
2.15
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Bugzilla 2.18

People

(Reporter: alex, Assigned: myk)

References

(
URL
)

Details

Attachments

(1 file, 1 obsolete file)

Patch v.2
7.61 KB, patch
timeless
: review+
timeless
: review+
Details | Diff | Splinter Review 
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.
Priority: -- → P3
Target Milestone: --- → Bugzilla 2.18
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).
Attached patch Patch v.1 (obsolete) — — Splinter Review 
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
Attached patch Patch v.2 — — Splinter Review 
OK, so <u> is far more sensible than <em>.

Gerv
Attachment #92598 - Attachment is obsolete: true
Attachment #92600 - Flags: review+
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
Blocks: 159199
Using this bug for show_bug; the tracking bug is bug 159199.

Gerv
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Summary: Bug pages should include ACCESSKEY → Show_bug should include ACCESSKEY
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.
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: