This Wiki page is edited by participants of the HTML Accessibility Task Force. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Task Force participants, WAI, or W3C. It may also have some very useful information.
Spec Review/Image Maps
Under review:
Michael Cooper review
MAP element
No accessibility comments on map element. I wonder though if the usage should be enhanced to phase in id attribute and phase out name attribute.
AREA element
On area element, the sentence "The alt attribute may be left blank if there is another area element in the same image map that points to the same resource and has a non-blank alt attribute." may be problematic. Under this condition the user agent is able to retrieve a text alternative from the other area element, but I wonder if it will. And is there a good use case for this rule? If author has provided alt once but has provided multiple areas, they know the alt and can provide it again. On the other hand, maybe it's easier to only have one pointer to a given resource have the alt, and the others be "merged" by the UA into a single area? The spec covers this idea in the next section, but only for browsers that don't process images; doesn't say what processing is for graphical browsers that also use alt text.
Michael to file bug on this, noting that the UA procedure doesn't seem realistic Bug 13449
Editorially, I had questions reading here that are answered only in the next section by inference from the processing procedure. There should be pointers forward to explain why certain requirements exist.
Image Maps
"In user agents that do not support images, or that have images disabled, object elements cannot represent images, and thus this section never applies (the fallback content is shown instead). The following steps therefore only apply to img elements." Why is this rule here? It renders imagemaps associated with OBJECT inaccessible, unnecessarily. Or, it forces authors to put a redundant copy of the links in the fallback content, but why do that? Unless I better understand the reason for this, I think this is a big accessibility issue.
Michael to file bug Bug 13451
"For historical reasons, the coordinates must be interpreted relative to the displayed image, even if it stretched using CSS or the image element's width and height attributes." If I read this right, changing the size of the image will cause the imagemap areas to be incorrectly sized, as they are not themselves resized but are just smacked onto the resized image. That will create a big accessibility problem, and also a usability one. And there is no reason for a new version of the spec to keep a problematic feature "for historical reasons". The spec should provide a transition to a more workable model.
Michael to file bug that this section is ambiguous and needs clarification; attempt to provide wording; work with Cynthia; also mention use case of browser zoom Bug 13453
Steve Faulker
"The alt attribute may be left blank if there is another area element in the same image map that points to the same resource and has a non-blank alt attribute."
As implemented by browsers this results in screen readers announcing the presence of a link but providing no information about the link target. it is noted that a bug has been filed about this issue Bug 13449.