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 17821 - <area> should be classified as "interactive content"
Summary: <area> should be classified as "interactive content"
Status: RESOLVED INVALID
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: http://dev.w3.org/html5/spec/content-...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-18 06:55 UTC by contributor
Modified: 2012-09-26 18:30 UTC (History)
3 users (show)

See Also:


Attachments

Description contributor 2012-07-18 06:55:10 UTC
This was was cloned from bug 15948 as part of operation convergence.
Originally filed: 2012-02-10 07:15:00 +0000
Original reporter: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>

================================================================================
 #0   Leif Halvard Silli                              2012-02-10 07:15:04 +0000 
--------------------------------------------------------------------------------
Created attachment 1076 [details]
Demo of how a <area> styled look like <a>

It is inconsistent:

* that <area> has 'link' role within the WAI ARIA section [1], 
* and yet the element isn't  listed as 'interactive content'. [2]

For example, a consequence of the current status is that it is conforming to place an <area> element inside an <a> element: 

      <a href=foo ><area href=foo ></a>

I don't rule out that it could make sense to nest <area> inside <a>. However, for the most part, it would only leads to trouble. For instance, screenreaders are likely to hear the same link announced twice.

But even if it can be justified to permit <area> inside <a>, the <area> should still be treated as interactive content, and instead a special exception to the rule which says that interactive content cannot be the child of an <a> should be made.

The justification for why <area> must be considered interactive content is that when the image of an image map does not display -  or otherwise when it is wanted, then one can make <area> visible via area{display:inline-block} and area:before{content:attar(alt)} etc. In that case, one can also navigate to the <area> link via tabulation or click it with the mouse and it reacts to :focus. In other words: It attains all the interactive features of <a>.

Demo of how a <area> styled look like <a>: http://tinyurl.com/7detoab 
(Or use the attached variant - if your browser does not support data URIs.)

[1] http://dev.w3.org/html5/spec/wai-aria.html#table-aria-strong
[2] http://dev.w3.org/html5/spec/content-models.html#interactive-content-0
================================================================================