[uf-new] include pattern: <object> has a11y issues, suggest <area> instead

[Leif Halvard Silli]

Proposal: introduce AREA at href as an alternative to OBJECT at data in the 
include pattern. [1]

OBJECT at data#fragment isn't perefect - the wiki tells that it:
(1) causes extra http requests in many browsers, 
(2) needs to be actively hidden from GUI browsers (e.g. by setting the 
dimensions to zero) 
(3) tells authors to use a at href, whenever extra http requests is a 
problem.

The wiki fails to mention:
(4) accessibility risk: unless its dimensions are set to zero and/or 
CSS display:none is used, then Webkit browsers render the current page 
as the content of the OBJECT. A screenreader will then read the content 
of the page as the content of the OBJECT at data element. 
(5) display issue in IE: "foo <object></object> bar" is displayed as 
'foobar' instead of 'foo bar'. Working around this is complicated. 
Hiding the OBJECT has not effect on the problem.
(6) the command line browser Links notify the user, visually, that the 
code contains an OBJECT.
(7) Several of the issues above may cause authors to use A at href instead 
of OBJECT at data

AREA at href - in comparison:

                History: area at href was been discussed, 
                         inconclusively it seemed, in 2006. [2]
                         (And may be later also?)
                Example: <area class=include data=#foo >
         VoiceOver test: works: outside MAP element, the link 
                         isn't read. No CSS needed.
              JAWS test: works if area.include{visibility:hidden}
              NVDA test: works if area.include{visibility:hidden}
    Other screenreaders: ?
           GUI browsers: automatically invisible, without CSS
          HTTP requests: not an issue
          HTML validity: Neither HTML4, XHTML1 nor the HTML5 draft
                         consider an AREA element outside a MAP
                         element as valid.
Reuse in RDFa/Microdata: easy to use area at href in RDFa/Microdata

Evaluation: 

AREA at href: that CSS is needed to hide it from screenreaders is a 
drawback - OBJECT can be hidden, for all UAs, via width="0" + 
height="0". (Whether the @alt is empty or not, does not have any effect 
on JAWS and VoiceOVer.) However, if - in reality - authors choose 
a at href due to the problems with object at data, then screenreader users 
will anyhow be told that the AREA at href is a link. (It isn't a link, 
though, unless it is located inside a MAP. This is only an issue if 
visibility:hidden is *not* used, however.) 

AREA at href seems easier and safer to use than OBJECT at data. However, the 
validity issue needs to be solved (could be solved in HTML5). And the 
requirements w.r.t. screenreaders must be finalized: it seems logical 
to *require* that authors use area.include{visibility:hidden}. A fine 
detail is the use of @alt: whenever visibility:hidden fails to be used, 
then a meaningful @alt text may work better than the empty string, 
since the empty string seems to lead the screenreader to read the link 
address in place of the @alt text. Thus from one point it makes sense 
to permit a non-empty @alt - though I don't really propose that.

Now, over to you - does this sound like an idea?

[1] http://microformats.org/wiki/include-pattern
[2] 
http://microformats.org/discuss/mail/microformats-discuss/2006-June/004357.html
-- 
leif halvard silli