The AREA attribute "TABINDEX" is not implemented. What should happen is when the user hits the tab key, they will tab through the different links within the imagemap. This should show up on the browser as each "link" or "hotspot" being surrounded by the dash-border similar to the one that appears around FORM elements when a user is tabbing through. These "borders" need to work for these shapes: shape="poly" or shape="polygon" shape="circ" or shape="circle" shape="rect" or shape="rectangle"

Tom: when the tabbing stuff is in place, please reassign this to kipp

Setting all current Open/Normal to M4.

per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser

We don't support AREAs as content yet so this cannot work. They will not exist as content before M4.

Moving out to M7

Added the [4.xP] identifier since IE4 has a working implementation of the feature in question. Rewrote the bug report in accordance with the guidelines as follows: Overview description: Mozilla doesn't support the tabindex attribute of the AREA element of HTML 4.0. Steps to reproduce: 1. View the "tabindex on AREA" attachment. 2. Press the tab key a couple of times. Actual results: The tab key does nothing. Expected results: The tab key should move the focus through the seven link areas in the image map. The tabbing order should match the numbering in the image. Build date & platform: Original bug filed on 1999-01-26. Build date: unknown. Platform: Windows. Additional builds & platforms: - Win32 build 1999070408 (Viewer & Apprunner) - Win32 M7

Moving to M11 per today's bug triage. Will not hold M10 for this.

Is this necessary for beta?

Moving multiple bugs to m12

[monitoring AREA element bugs]

Moving to m13 because Joki seems to be distracted.

Moving M17. Need for FCS for accessibility, but it's not required for beta.

Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!

Setting the keyword all open [4.xp] bugs to 4xp.

Nom. nsbeta3, rec.. nsbeta3+. html4 compliance. Important for accessibility. If not fixed, people who do keyboard-only navigation (e.g. folks with motor disabilities who can't use the mouse) won't be able to use HTML AREAs, which are widely used on the web (and inadvisably so) as navigational tools, e.g. the old "puzzle pieces" for the internal Netscape w3 home page.

Okay, I have a fix in my tree for everything but the hilighting/outlining of each area as it gain focus.

Updating Milestone to M18.

Have a fix for the whole thing, including outlining the map areas.

Marking nsbeta3+...

Fixed

Verified fixed in N6 200080908 build.

Removing '4xp' keyword, since the keyword description no longer mentions "competitor products".