This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13449 - Don't allow blank alt text on area elements
Summary: Don't allow blank alt text on area elements
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML a11y Task Force (show other bugs)
Version: unspecified
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Charles McCathieNevile
QA Contact: This bug has no owner yet - up for the taking
Keywords: a11y, a11ytf, a11y_text-alt
Depends on: 8171
  Show dependency treegraph
Reported: 2011-07-29 13:58 UTC by Michael Cooper
Modified: 2016-02-26 18:58 UTC (History)
9 users (show)

See Also:


Description Michael Cooper 2011-07-29 13:58:53 UTC
The description of <area> states "The alt attribute may be left blank if there is another area element in the same image map that points to the same resource and has a non-blank alt attribute." While there is a procedure later in the spec that details how user agents should handle this situation (looking for other <area> elements referencing the same target and retrieving the alt text for those), the HTML accessibility task force does not believe that user agents will go to those lengths, based on input from UA developers in the task force. A situation where alt text is sometimes required and sometimes not also leads to a high probability of author error. Therefore this provision should be removed.

Edit details:

* Remove the sentence "The alt attribute may be left blank if there is another area element in the same image map that points to the same resource and has a non-blank alt attribute." from
* Remove step 2 in the second numbered list "Remove all the area elements in areas that have no alt attribute, or whose alt attribute's value is the empty string, if there is another area element in areas with the same value in the href attribute and with a non-empty alt attribute." from
Comment 1 steve faulkner 2011-08-01 10:33:24 UTC
As implemented in latest Firefox and IE(haven't tested others) this results in screen readers announcing the presence of a link but providing no information about the link target.
Comment 2 Michael[tm] Smith 2011-08-04 05:02:49 UTC
mass-moved component to LC1
Comment 3 Ian 'Hixie' Hickson 2011-08-10 20:47:38 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:

Status: Rejected
Change Description: no spec change

Duplicating the link is even worse in UAs that convert the <map> to a list of links. It is more likely that graphical UAs exposing stuff to ATs will do the right thing here than non-graphical UAs, since the former have far more engineering resources available.
Comment 4 Mark Sadecki 2013-06-05 17:39:59 UTC
The TF is no longer tracking this bug, but recognize it is still an accessibility issue.  The a11y keyword will remain.
Comment 5 Charles McCathieNevile 2014-03-12 17:57:35 UTC
Chaals will write a test case and see if there is any reason to believe (after a few years) that user agents deal with this or whether we should ask the spec to change to match reality.
Comment 6 Charles McCathieNevile 2015-06-16 07:28:50 UTC
More importantly than screen readers, users who primarily interact visually but rely on assistance from information like alt text are likely to be confused. The scenario implied is that there are several regions of an image that would logically link to the same destination. A visual user who seeks confirmation from alt will not be given the same information for the different area element links.

It seems this is therefore a straight-out bug.
Comment 7 Charles McCathieNevile 2016-02-26 18:58:56 UTC
Nothing useful happened in years, the bug is still a problem. Should be resolved with Pull Request #102