W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > March 2010

[Bug 7076] Client-side image maps attributes missing on the a element

From: <bugzilla@wiggum.w3.org>
Date: Mon, 15 Mar 2010 02:51:45 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1Nr0PB-000522-Kb@wiggum.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7076


Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|CLOSED                      |REOPENED
           Keywords|                            |a11y
         Resolution|NEEDSINFO                   |




--- Comment #11 from Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>  2010-03-15 02:51:44 ---
I object to closing this bug. 

EITHER this bug must be solved in accordance with how the bug filer suggested. 
OR an cross browser compatible solution with more or less the exact same
features as <a coords=* shape=*>link text</a> has (with regard to accessibility
and design pattern) must be *worked out* for the <area> element.

I will focus on the OR option, to allow Ian or whoever to come up with
something that I can accept. And in that regard, when Ian suggested removing <a
coords=""> back in April 2005, he described a "workaround":

http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2005-April/003514.html

His solution went like this - i.e. he was suggesting to use a nearby <a>
element sideby side the <area> element:

<image src="foo" usemap="#foo">
<map id="foo">
 <area coords=  href=    alt="Link text." ><a href= >Link text.</a>
</map>

In addition to this option, the HTML5 spec currently also allows us to place an
<area> inside an <a> element  which is more logical  - a better design
pattern.

        <a href="..."><area coords="..." href="...">...</a>

However: 

A) How to actually use this workaround is not described/worked out in the spec. 
    The spec must describe this.

B) There are many open issues.
      * First and foremost duplication of link text, both inside @alt as well
as inside <a>:
             <area  alt="Link text." ><a href= >Link text.</a>
         Can this be avoided, for example when one is nesitng the <area> inside
the <a>?
         (The accessibility issues are known since 2005 ...
          
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2005-September/004667.html
)

C) The nesting option has many open questions:

     1. Again, the general duplication question: is there anything we do not
need to duplicate when we are nesting?
     2. In particular: Do we need to use the @alt attribute when we nest it? Or
can we skip it then, when nesting? Must it be present but empty?
     3. If I place a @title in the <a> element, will it then be used also in
the <area> element?
     4. Is nesting cross browser compatible? 

Regarding C 4., then  *no*, nesting is not fully cross browser compatible.
There are issues with Mozilla browsers to be solved!  Either through a change
in what is permitted in the syntax. OR by giving authoring advice about how to
be Mozilla compatible. Or both ways. 

The  Mozilla issue is that when an <area>element is wrapped inside an <a>
element, then it doesn't "see" the <area> element, and so the image map doesn't
work. However, if you either provide at least a single dummy (also known as
"boolean" ...)  <area> element (which can be entirely empty) inside the <map>
somewhere (but outside any of the <a> elements), then Mozilla browsers will be
triggered to react to all <area> elements. Another way to trigger Mozilla
browsers to see the <area> elements, is to place @coords and @shape on at least
*one* of the <a> elements - this too will trigger them to see the rest of the
<area> elements inside that <map> element.

               Somehow  one or both of these *necessary* Mozilla workaround
techniques needs to baked into the specication! One way to incorporate them
into the spec would be to simply say that <a> *may* contain @coords and @shape
*provided* that it is used as a wrapper around an <area> element.

Regarding C) 3, then Opera and Firefox does the logical thing: If you provide a
@title on the <a> element, then it is propagated to the <area> element. HTML5
does require that @title is propagated like this. But it seems necessary to
specify with regard to <area>. Webkit and IE (IE8 in standards mode) does not
propage the @title of the <a> element to the <area> element.


D) Authoring requirements/advice:  The spec should 

         a) advice authors to  use nesting, since this a better design pattern,
with some advantages, for authors and users (less out of sync data)
         b) give advantages to those that use nesting (less duplications, e.g.
no requirement to supply the @alt attribute etc)
         c) give advice about what to do when duplication is necessary for
compatibility reason: make sure that @title of both <area> and <a> are
identical. Make sure that @href says the same thing in both elements.
         d) specify exactly which features a nested <area> element will
"inherit" from its parent <a> element - in order to spare authors from
duplications (which is prone to errors): could it even inherit the @href value?

E) Finally, this bug also relates to Charles proposes solution of accessibility
for the <canvas> element via image maps.


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Monday, 15 March 2010 02:51:50 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 15 March 2010 02:51:57 GMT