- From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
- Date: Tue, 18 Sep 2012 01:12:21 +0200
- To: James Craig <jcraig@apple.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>, Ted O'Connor <eoconnor@apple.com>
- Cc: Janina Sajka <janina@rednote.net>, Cynthia Shelly <cyns@microsoft.com>
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