This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
REQUEST: Make @alt permitted on <area> even when there is no @href attribute. USECASE: An area of an image map might be in need of alternative text even if it is not clickable. For example, a link might simply not be available when the map is created. Or there might be a section of the image that needs alternative text, without ever becoming a link (for instance because the iamge consists of two or more images that visually looks like separate images but which, from the computer's point of view, is a single image). OTHER JUSTIFICATIONS: * FIRSTLY: HTML4 had this feature. HTML4 justified it by saying (or rather *showing*) that <a coords="1,2,3,4" >FOO</a> (that is: an anchor element without @href) is conceptually equal to an <area nohref coords="1,2,3,4" alt=FOO > without @href. ( See text to the last code example in HTML4, section 13.6.1.1 <http://www.w3.org/TR/html401/struct/objects.html#h-13.6.1.1>. ) * SECONDLY: HTML5 emphasizes thtat <area> is a link element, just like <a>. Thus when HTML5 says that an <a> without @href ""represents a placeholder for where a link might otherwise have been placed, if it had been relevant", it makes sense to say the same thing about an <area> without @href too. In that regard: HTML5 has not included @coords for the <a> element - which is yet another reason to make sure that <area> and <a> really remains conceptually equal also in their ability contain text that is a *potential link*. * THIRDLY: There seems to be demand for such a thing: http://lists.w3.org/Archives/Public/www-validator/2011Aug/0024.html
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: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Rejected Change Description: no spec change Rationale: You'd never be able to see the text (areas that can't be activated don't get exposed), so this is unnecessary.
(In reply to Ian 'Hixie' Hickson from comment #1) > Status: Rejected > Change Description: no spec change > Rationale: You'd never be able to see the text (areas that can't be > activated don't get exposed), so this is unnecessary. This rationale does not count in the use case that the image map is a navigation menu. In that case, there will be a symbol or text inside the image map image, which e.g. the sighted user will see, whereas e.g. the AT user will not see it but could get the text from the area element that does not create a hyperlink. In navigation menus, it is freequently the case that the link is "dead" if it leads to the current page.
By the way, in Firefox, the <area> elements are included in the tabbing order even if the element lacks both @alt and @href.
(In reply to Leif Halvard Silli from comment #2) > > This rationale does not count in the use case that the image map is a > navigation menu. In that case, there will be a symbol or text inside the > image map image, which e.g. the sighted user will see, whereas e.g. the AT > user will not see it but could get the text from the area element that does > not create a hyperlink. > > In navigation menus, it is freequently the case that the link is "dead" if > it leads to the current page. The point is that an <area> element with no href="" attribute just won't be listed, per the current spec. So making alt="" valid for such elements would be a waste of time. If you want to change the model, that's a different bug. (But probably also a WONTFIX.) (In reply to Leif Halvard Silli from comment #3) > By the way, in Firefox, the <area> elements are included in the tabbing > order even if the element lacks both @alt and @href. That's a bug. Please file it with Mozilla.