Mike Cordeiro Reporter
	Description • 21 years ago

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.5) Gecko/20031007

I have a form which has 10 fieldset elements given accesskey attributes with the
numbers 0-9. ALT-1 is for the first fieldset on the page, ALT-0 is for the the
final fieldset (about two screens down). In IE, when the accesskey for the
fieldset is typed, then that fieldset is scrolled into view if it is off-screen.
The behaviour is as if an anchor link has been clicked. Mozilla does not bring
the fieldset into view.

So I can hit ALT-9 to my hearts content, but the fieldset at the bottom of the
page will never come into view, where in Internet Explorer it does.

Reproducible: Always

Steps to Reproduce:
1. Have a page where fieldset elements are displayed off-screen
2. Hit the accesskey for a fieldset that is off-screen
3. Nothing will happen.

Actual Results:  
Step 3. Nothing occured

Expected Results:  
The fieldset should have scrolled into view.

	Boris Zbarsky [:bzbarsky]
	Comment 1 • 21 years ago

Keyboard nav.  Please attach a testcase showing the problem?

Also, note that there is no "accesskey" attribute on the <fieldset> element in HTML.

	Mike Cordeiro Reporter
	Comment 3 • 21 years ago

This page also shows off bug 129268, only the final accesskey works.

In Internet Explorer the behaviour is as follows. I can quickly jump to any
fieldset by hitting it's accesskey. At this point if there are duplicate
accesskeys in the document the focus is given to those included in the current
fieldset.

So if I have the key "A" defined in the first and last fieldsets, and I use the
accesskey for the last fieldset then hit alt-a, the checkbox with alt-a in that
final fieldset is selected first. If you hit alt-a again then IE begins to cycle
through all the elements using that accesskey.

So as long as you use the accesskey on the fieldset element this form can be
completed entirely by keyboard in IE. I think that IE's implementation has a
higher degree of usability, irrespective of whether or not fieldset has an
accesskey attribute.

	Boris Zbarsky [:bzbarsky]
	Comment 4 • 21 years ago

Well, the problem is that we only implement accesskey on some elements, and
<fieldset> is not one of them... The rest is symptoms. Does IE support accesskey
on <div>?  Or is <fieldset> special that way in IE?

	Hixie (not reading bugmail)
	Comment 5 • 21 years ago

(note: I considered adding accesskey to <fieldset> in my XForms Basic proposal,
but decided that on balance it made no sense and was better dealt with by an
accesskey on the first focussable control in the fieldset. Let me know if you
disagree by e-mailing me ian@hixie.ch)

	Boris Zbarsky [:bzbarsky]
	Comment 6 • 21 years ago

Ian, did you decide it makes no sense because an accesskey just transfers focus
and <fieldset> is not focusable?

	Hixie (not reading bugmail)
	Comment 7 • 21 years ago

bz: that was my thinking, yeah.

	Mats Palmgren (inactive)
	Comment 8 • 20 years ago

We could handle <fieldset>s the same way as for <legend>s (bug 81481).
That is, transfer focus to the first focusable element that follows, except
when the fieldset itself has been made focusable (with tabindex).

	Bryan Henry
	Comment 9 • 17 years ago

No work on this bug since late 2004, resolving WFM. Please reopen if this is still here for a reason.

	Boris Zbarsky [:bzbarsky]
	Comment 10 • 17 years ago

This can't be WFM, since there is no accesskey on fieldsets.  It might be wontfix, but that's the module owner's call.

	Mats Palmgren (inactive)
	Comment 11 • 17 years ago

Bryan, you can't just resolve bugs because they are old.  The testcase
clearly shows that the bug still exists and I still think we should
consider fixing it as suggested in comment 8.

	David Bolter [:davidb] (NeedInfo me for attention)
	Comment 12 • 15 years ago

Mass un-assigning bugs assigned to Aaron.

	Frankie
	Comment 13 • 9 years ago

As stated in comment 8, accesskey could be made to work for fieldset elements.