Map element clarification (Was: additional sentence for 204)

I have become more and more sceptic about whether the <map> element 
fits into the "reveal hidden='' element as user request" model. To make 
you think, let me - once again - ask you look at this <map> example hat 
Ian has placed in HTML5:

http://dev.w3.org/html5/spec/the-map-element.html#the-map-element


* That <map> contains <area> elements that are duplicated as <a> 
elements, where the latter are purely textual links as apposed to the 
image area links.
* The intention being that <a> and <are> are read in different modes: 
The <area> links when processing the image, and the <a> links when 
processing the content of the <map>.

QUESTION: Doesn't this example show that <map> clashes with Ted's text 
about user-initiated hidden map content? After all, here, the user 
would only be getting duplicate links - something neither the author 
nor the user is likely to be wanting to get. Thus, effectively, killing 
off that HTML5 example as as an accessible way to code. Per HTML4, this 
did not need to be a problem, as there, the <a> elements could have the 
@coords and the @shape attribute and thus function as <area> element. 
Hence, the need to duplicate <area> with <a> was, in HTML4, eliminated. 
A functionality that would have nice to have now! (Cuff, cuff.)

THESIS:
        1. For headers="" is already revealed to users at their request 
- so to to extend this also to when <th> is hidden, is not be a 
dramatic change. However, for <map>, thene there there currently are no 
ATs (known to me) that reveal the *visible* (to sighted) content of a 
<map> at the AT user’s request. 
        2. Consequently, if AT starts, at user request, to reveal the 
content of <map> when it is hidden="", then my assumption is that they 
will also start, at user request, to reveal it when it is visible. This 
is strengthened by the fact that Ted's text does not anywhere state 
that the content has to be hidden="" in order to be revealed.
        3. As explained in my preceding letters to public-html-a11y@: 
<map> really has two modes. One is the image map mode, which relates 
purely to <area>. This mode is never affected by hidden="" - not even 
if you do <area hidden="">. The other mode is the non-image map mode, 
and it covers all elements *but* <area>. The two modes are typically 
parallel modes. 

Therefore I think that EITEHR we have to remove <map> from this model. 
OR we have to define more accurately how <map> fits into this model. 3 
ideas: 

(1) AT could make sure to not reveal the <map> content if it only
    contains duplicate links.
(2) As part of (1), HTML5 could reinstate @coords/@shape in <a>
(3) One could make the "at user request" thing *be* dependent on
    hidden="" (as hidden="" <map>s are more likely to have been
    authored with this new functionality in mind than visible <map>s)

Please let me hear how you view these issues. Thanks.
-- 
Leif Halvard Silli

Received on Monday, 17 September 2012 23:12:50 UTC